performing-security-headers-audit

执行安全头审计（Performing Security Headers Audit）

适用场景

• 在授权 Web 应用程序安全评估期间作为标准配置审查
• 评估针对 XSS、点击劫持和数据泄漏的浏览器级保护时
• 对要求实施安全头的合规评估（PCI DSS、SOC 2）
• 执行初始侦察以识别易于改进的安全问题时
• 在新部署的 CI/CD 管道安全门禁检查期间

前置条件

• 授权：针对目标应用程序的书面范围（头部审查风险较低）
• curl：从目标端点获取响应头
• SecurityHeaders.com：用于快速头部评估的在线扫描器
• Mozilla Observatory：Mozilla 的 Web 安全测试工具
• Burp Suite：用于跨多个页面的综合头部分析
• Browser DevTools：实时检查头部和 CSP 违规

工作流程

步骤 1：从目标收集安全头

检索并记录所有与安全相关的响应头。

# 获取所有响应头
curl -s -I "https://target.example.com/" | grep -iE \
  "(strict-transport|content-security|x-frame|x-content-type|x-xss|referrer-policy|permissions-policy|feature-policy|x-permitted|cross-origin|set-cookie|server|x-powered-by|cache-control)"

# 跨多个页面检查头部
PAGES=("/" "/login" "/api/health" "/admin" "/account/settings" "/static/app.js")

for page in "${PAGES[@]}"; do
  echo "=== $page ==="
  curl -s -I "https://target.example.com$page" 2>/dev/null | grep -iE \
    "(strict-transport|content-security|x-frame|x-content-type|x-xss|referrer-policy|permissions-policy|set-cookie|server|x-powered)"
  echo
done

# 检查 HTTP 和 HTTPS 响应
echo "=== HTTP 响应 ==="
curl -s -I "http://target.example.com/" | head -20
echo "=== HTTPS 响应 ==="
curl -s -I "https://target.example.com/" | head -20

步骤 2：评估传输安全（HSTS）

评估 HTTP 严格传输安全（HSTS）配置。

# 检查 HSTS 头
curl -s -I "https://target.example.com/" | grep -i "strict-transport-security"

# 预期：Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# 验证 HSTS 属性：
# max-age：预加载资格应 >= 31536000（1 年）
# includeSubDomains：保护所有子域
# preload：符合浏览器 HSTS 预加载列表的资格

# 检查 HTTP 是否重定向到 HTTPS
curl -s -I "http://target.example.com/" | head -5
# 应为 301/302 重定向到 https://

# 检查是否在预加载列表中
# 访问：https://hstspreload.org/?domain=target.example.com

# 测试仅 HTTPS 的 Cookie
curl -s -I "https://target.example.com/login" | grep -i "set-cookie"
# 所有会话 Cookie 应带有 Secure 标志

# 检查混合内容
curl -s "https://target.example.com/" | grep -oP "http://[^\"']+" | head -20
# 在 HTTPS 页面上加载 HTTP 资源会产生混合内容漏洞

步骤 3：审计内容安全策略（CSP）

分析 CSP 头的有效性和潜在绕过方式。

# 提取 CSP 头
CSP=$(curl -s -I "https://target.example.com/" | grep -i "content-security-policy" | cut -d: -f2-)
echo "$CSP"

# 检查危险指令：
# script-src 中的 'unsafe-inline'：允许内联脚本（XSS 风险）
# script-src 中的 'unsafe-eval'：允许 eval()（XSS 风险）
# 任何指令中的 *：允许从任何来源加载
# script-src 中的 data:：允许 data: URI 脚本
# 缺少 default-src：无回退策略

echo "$CSP" | tr ';' '\n' | while read directive; do
  echo "  $directive"
  if echo "$directive" | grep -q "unsafe-inline"; then
    echo "    警告：unsafe-inline 允许内联脚本执行"
  fi
  if echo "$directive" | grep -q "unsafe-eval"; then
    echo "    警告：unsafe-eval 允许 eval() 调用"
  fi
  if echo "$directive" | grep -q " \* "; then
    echo "    警告：通配符允许从任何来源加载"
  fi
done

# 检查 CSP report-only（未强制执行）
curl -s -I "https://target.example.com/" | grep -i "content-security-policy-report-only"
# Report-only 不阻止违规，只记录

# 使用 Google 的 CSP 评估器测试
# https://csp-evaluator.withgoogle.com/
# 粘贴 CSP 头进行自动化分析

# 通过白名单域检查 CSP 绕过
# 如果 CDN 域被白名单，检查 JSONP 端点或 angular 库

步骤 4：检查框架保护和点击防御头

验证反点击劫持和 iframe 嵌入控制。

# X-Frame-Options
curl -s -I "https://target.example.com/" | grep -i "x-frame-options"
# 预期：DENY 或 SAMEORIGIN
# ALLOW-FROM 已弃用，现代浏览器不支持

# CSP frame-ancestors（取代 X-Frame-Options）
curl -s -I "https://target.example.com/" | grep -i "content-security-policy" | grep -o "frame-ancestors[^;]*"
# 预期：frame-ancestors 'none' 或 frame-ancestors 'self'

# X-Content-Type-Options
curl -s -I "https://target.example.com/" | grep -i "x-content-type-options"
# 预期：nosniff（防止 MIME 类型嗅探）

# X-XSS-Protection（旧版，但对旧浏览器仍有用）
curl -s -I "https://target.example.com/" | grep -i "x-xss-protection"
# 预期：1; mode=block（或在 CSP 全面覆盖时为 0）
# 注意：CSP 存在时，现代建议是 0（禁用）

# Referrer-Policy
curl -s -I "https://target.example.com/" | grep -i "referrer-policy"
# 预期：strict-origin-when-cross-origin 或 no-referrer
# 防止通过 Referer 头泄漏敏感 URL 数据

步骤 5：审计 Cookie 安全属性

检查会话和认证 Cookie 的安全标志。

# 获取所有 Set-Cookie 头
curl -s -I -L "https://target.example.com/login" | grep -i "set-cookie"

# 检查每个 Cookie 的必需属性：
# Secure：仅通过 HTTPS 发送
# HttpOnly：JavaScript 不可访问（防止 XSS Cookie 盗窃）
# SameSite：控制跨站 Cookie 发送（Strict、Lax、None）
# Path：限制 Cookie 范围
# Domain：控制哪些域接收 Cookie
# Max-Age/Expires：Cookie 生命周期

# 自动化 Cookie 检查
curl -s -I "https://target.example.com/login" | grep -i "set-cookie" | while read line; do
  echo "Cookie: $(echo "$line" | grep -oP '[^:]+=[^;]+')"
  missing=""
  echo "$line" | grep -qi "secure" || missing="$missing Secure"
  echo "$line" | grep -qi "httponly" || missing="$missing HttpOnly"
  echo "$line" | grep -qi "samesite" || missing="$missing SameSite"
  if [ -n "$missing" ]; then
    echo "  缺少：$missing"
  else
    echo "  所有标志均存在"
  fi
done

# 检查 __Host- 和 __Secure- Cookie 前缀
# __Host- Cookie 必须有 Secure、Path=/、无 Domain
# __Secure- Cookie 必须有 Secure 标志

步骤 6：检查 Permissions-Policy 和信息泄露

审查浏览器功能控制和信息泄漏头。

# Permissions-Policy（原 Feature-Policy）
curl -s -I "https://target.example.com/" | grep -i "permissions-policy"
# 控制浏览器功能：摄像头、麦克风、地理位置等
# 预期：限制未使用的功能
# 示例：permissions-policy: camera=(), microphone=(), geolocation=()

# 跨域头
curl -s -I "https://target.example.com/" | grep -iE "(cross-origin-embedder|cross-origin-opener|cross-origin-resource)"
# COEP：Cross-Origin-Embedder-Policy: require-corp
# COOP：Cross-Origin-Opener-Policy: same-origin
# CORP：Cross-Origin-Resource-Policy: same-origin

# 需要标记的信息泄露头
curl -s -I "https://target.example.com/" | grep -iE "(server|x-powered-by|x-aspnet|x-generator)"
# Server: Apache/2.4.52（应删除或使用通用值）
# X-Powered-By: PHP/8.1.2（应删除）
# 这些头向攻击者暴露技术栈

# 敏感页面的 Cache-Control
curl -s -I "https://target.example.com/account/settings" | grep -i "cache-control"
# 敏感页面应使用：Cache-Control: no-store, no-cache, must-revalidate
# 防止浏览器缓存敏感数据

# 使用在线工具生成综合报告
echo "使用 SecurityHeaders.com 扫描：https://securityheaders.com/?q=target.example.com"
echo "使用 Mozilla Observatory 扫描：https://observatory.mozilla.org/analyze/target.example.com"

核心概念

概念	定义
HSTS	强制浏览器对域名仅使用 HTTPS，防止协议降级攻击
CSP	限制页面上可以加载的资源（脚本、样式、图片）
X-Frame-Options	控制页面是否可嵌入 iframe（点击劫持防御）
X-Content-Type-Options	防止 MIME 类型嗅探；强制浏览器遵守声明的 Content-Type
Referrer-Policy	控制跨域请求发送多少引用者信息
Permissions-Policy	限制页面可用的浏览器功能（摄像头、麦克风、地理位置）
SameSite Cookie	控制 Cookie 在跨站上下文中的发送时机（Strict、Lax、None）
HSTS 预加载（HSTS Preloading）	在浏览器源代码中硬编码 HSTS 策略以实现首次访问保护

工具与系统

工具	用途
SecurityHeaders.com	提供字母评级的安全头评估在线扫描器
Mozilla Observatory	带评分和建议的综合 Web 安全扫描器
CSP Evaluator（Google）	分析内容安全策略的弱点和绕过方式
Burp Suite Professional	检查所有应用程序页面的响应头
securityheaders（CLI）	命令行安全头扫描器
Hardenize	TLS 和安全头监控服务

常见场景

场景 1：完全缺少头部

旧版应用程序完全不返回安全头。没有 HSTS、CSP、X-Frame-Options 或 Cookie 安全标志。每个页面都容易受到点击劫持，XSS 没有浏览器级缓解，Cookie 通过 HTTP 发送。

场景 2：带 unsafe-inline 的弱 CSP

CSP 头包含 script-src 'self' 'unsafe-inline'。虽然限制了外部脚本加载，但 unsafe-inline 指令允许任何内联脚本执行，使 CSP 对 XSS 失效。

场景 3：没有 Secure 标志的会话 Cookie

会话 Cookie 设置时没有 Secure 标志。在 HTTP/HTTPS 混合站点上，会话令牌可能被网络攻击者通过普通 HTTP 请求拦截。

场景 4：缺少 HSTS 导致 SSL 剥离

没有 HSTS 头。网络上的攻击者可以执行 SSL 剥离攻击，将受害者的 HTTPS 连接降级为 HTTP 并拦截所有流量。

输出格式

## 安全头审计报告

**目标**：target.example.com
**评级**：D（SecurityHeaders.com）
**评估日期**：2024-01-15

### 头部评估
| 头部 | 状态 | 当前值 | 推荐值 |
|--------|--------|---------------|-------------|
| Strict-Transport-Security | 缺失 | - | max-age=31536000; includeSubDomains; preload |
| Content-Security-Policy | 弱 | script-src 'self' 'unsafe-inline' | script-src 'self' 'nonce-{random}' |
| X-Frame-Options | 缺失 | - | DENY |
| X-Content-Type-Options | 存在 | nosniff | nosniff（正确） |
| Referrer-Policy | 缺失 | - | strict-origin-when-cross-origin |
| Permissions-Policy | 缺失 | - | camera=(), microphone=(), geolocation=() |
| X-XSS-Protection | 缺失 | - | 0（配合强 CSP） |

### Cookie 安全
| Cookie | Secure | HttpOnly | SameSite | Path |
|--------|--------|----------|----------|------|
| session | 否 | 是 | 未设置 | / |
| user_pref | 否 | 否 | 未设置 | / |
| csrf_token | 是 | 否 | Strict | / |

### 信息泄露
| 头部 | 值 | 风险 |
|--------|-------|------|
| Server | Apache/2.4.52 | 技术指纹识别 |
| X-Powered-By | PHP/8.1.2 | 针对特定版本的漏洞利用 |

### 修复建议优先级
1. **严重**：向会话 Cookie 添加 Secure 和 SameSite 标志
2. **高**：实施最短 1 年 max-age 的 HSTS
3. **高**：将 CSP 中的 'unsafe-inline' 替换为基于 nonce 的策略
4. **中**：添加 X-Frame-Options: DENY
5. **中**：添加 Referrer-Policy: strict-origin-when-cross-origin
6. **低**：删除 Server 和 X-Powered-By 的版本信息
7. **低**：添加 Permissions-Policy 以限制未使用的浏览器功能