深入解析 Web 安全三剑客：CSP、CSRF 与 MITM 防御
——从策略配置到协议层防御的全链路实践

一、Content Security Policy 的进阶实践

CSP 的本质是通过声明式策略控制资源加载，其核心机制是浏览器对 白名单机制 的强制执行。通过 Content-Security-Policy 响应头，开发者可以精确控制脚本、样式、多媒体等资源的加载源，从而有效防御 XSS 和数据注入攻击。

1.1 策略配置的深层逻辑

示例配置中的 img-src * 看似灵活，实则暗藏风险：

1Content-Security-Policy: 
2  default-src 'self';
3  img-src *;
4  media-src media1.com media2.com;
5  script-src userscripts.example.com;

• default-src 'self'：默认策略的"安全基线"作用，避免遗漏未显式声明的内容类型
• img-src * 的隐患：允许任意图片源可能导致 图片劫持攻击（如 EXIF 数据泄露），建议升级为 img-src https: 或限定可信 CDN 域名
• 子域名管控：media-src 未包含子域名时，可通过 media-src *.media1.com 扩展，或通过 frame-src 控制嵌套内容

1.2 CSP 部署的常见陷阱

• 内联脚本阻断：未使用 unsafe-inline 时，所有内联脚本（包括常见前端框架的初始化代码）将被拦截
  • 解决方案：使用 nonce 或 hash 签名（CSP Level 3 特性）
  html

  Copy Code

  1<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  2  // 允许执行的非内联脚本
  3</script>

• 动态加载问题：通过 script-src 'strict-dynamic' 可兼容动态脚本加载（如 Webpack 生成的 chunk）
• 报告机制：通过 report-uri /csp-report-endpoint 收集策略违规日志，用于策略调优

二、CSRF 防御体系的多维度构建

CSRF 攻击利用的是 浏览器自动携带 Cookie 的机制，防御需要构建多层级校验体系。

2.1 CSRF Token 的工程实践

• Token 生成算法：
  python

  Copy Code

  1# Django 的实现示例
  2from django.middleware.csrf import get_token
  3def generate_csrf_token(request):
  4    token = get_token(request)  # 基于会话ID与时间戳的HMAC加密
  5    return token

• 分布式系统挑战：
  • 方案1：采用 JWT 替代 Session，将 Token 编码到 JWT Payload
  • 方案2：使用 Redis 集群存储 Token，通过 redis-cluster 实现跨节点同步

2.2 SameSite Cookie 的攻防博弈

Chrome 80+ 已默认开启 SameSite=Lax，这改变了传统的防御格局：

• Lax 模式的漏洞：允许 GET 请求携带 Cookie，攻击者可构造 <img src="https://bank.com/transfer?to=attacker">
• 防御升级：关键操作（如转账）仍需结合 POST 方法 + CSRF Token

2.3 双重 Cookie 验证的局限性

虽然规避了 Session 存储，但存在 子域名漏洞：

1攻击者控制 sub.hack.com 设置 Cookie 
2（Domain=.hack.com）
3当用户访问 legit.com 时，若该站允许 *.hack.com 则可能泄露 Cookie

解决方案：验证 Cookie 的 Domain/Path 属性，或结合 Origin 头校验

三、MITM 防御的协议层纵深防御

3.1 HTTPS 的部署进阶

• 证书管理：
  • 使用 ACME 协议自动续期（如 Let's Encrypt）
  • 部署 OCSP Stapling 减少验证延迟
• HSTS 的军事级配置：
  nginx

  Copy Code

  1add_header Strict-Transport-Security 
  2  "max-age=63072000; includeSubDomains; preload";

  • preload 列表需提交至 Chrome HSTS Preload List
  • 注意：误配置可能导致子域名服务不可用

3.2 开发者侧的进阶防护

• 证书透明化监控：
  通过 Certificate Transparency Log（如 crt.sh）监控域名证书签发情况
• HPKP 的替代方案：
  由于 HPKP 已被弃用，改用 CAA（Certificate Authority Authorization）DNS 记录限制 CA 签发权限
  js

  Copy Code

  1example.com. IN CAA 0 issue "letsencrypt.org"

3.3 用户教育的技术赋能

• 网络层工具：推荐使用 DNS-over-HTTPS（DoH）防止 DNS 污染
• 终端防护：建议安装证书监控插件（如 Certificate Patrol）

四、关联攻击链的防御思考

当 XSS 与 CSRF 结合时，传统防御可能失效：

1. 攻击者通过存储型 XSS 窃取 CSRF Token
2. 构造自动化脚本发起 CSRF 攻击

立体化防御方案：

• 前端：CSP 限制脚本源 + 关键 Cookie 设置 HttpOnly
• 后端：CSRF Token 与请求指纹（如 User-Agent 哈希）绑定
• 传输层：TLS 1.3 加密 + 双向证书认证

五、前沿趋势与挑战

• CSP Level 3 新特性：
  script-src-elem 与 script-src-attr 实现更细粒度控制
• SameSite Cookie 的演进：
  Chrome 正在试验 SameSite=Lax-by-default 策略
• Post-Quantum Cryptography：
  NIST 后量子加密算法（如 CRYSTALS-Kyber）在 TLS 1.3 中的集成测试

结语
Web 安全防御是持续演进的系统工程。开发者需建立"纵深防御"思维，既要在协议层筑牢基础，也要在业务层实现精准管控，更需关注浏览器生态的最新动向。只有将标准规范、工程实践、威胁情报三者结合，才能构建真正可靠的防御体系。