Web 缓存投毒：被忽略的 CDN 攻击面

缓存键 = 决定"哪些请求共用一个缓存条目"的参数集合

默认缓存键通常包含：
  · 请求方法（GET/POST）
  · 完整 URL（路径 + 查询字符串）
  · Host 头
  · 部分请求头（如 Accept-Encoding、Accept-Language）

Vary 头的作用：告诉缓存"除了 URL，还要按哪个响应头区分条目"
  Vary: Accept-Encoding   → 压缩与未压缩的响应分开缓存
  Vary: Cookie            → 不同用户的响应分开缓存（若错误使用会击穿缓存）

① 用户 A 请求 /static/app.js
② 缓存未命中 → 回源到应用 → 得到 200 与 Cache-Control: public, max-age=3600
③ 响应被缓存，键 = GET /static/app.js
④ 用户 B 请求相同键 → 缓存命中，直接返回用户 A 的响应副本

关键点：任何"没有进入缓存键、却影响响应内容"的输入，
        都是投毒的候选入口（Unkeyed Input）。

缺陷代码（示意）：

  GET /search?q=foo
  → 响应头 Cache-Control: public, max-age=300
  → 响应体 <h1>搜索：foo</h1>

攻击：
  GET /search?q=<script>alert(document.cookie)</script>
  → 同样的 Cache-Control 允许缓存
  → 恶意脚本作为缓存条目被存储
  → 后续所有访问 /search?q=任意值 的用户拿到 XSS 载荷

安全原则：
  ① 只缓存"内容完全由缓存键决定"的响应
  ② 动态片段（用户信息、CSRF Token、个性化内容）要么不进响应，
     要么用 Cache-Control: no-store / private 明确排除
  ③ 校验响应头：只允许白名单 Cache-Control，杜绝应用层随手 public

攻击者发送：

  GET /index.html
  Host: example.com
  X-Forwarded-Host: evil.com

后端信任 X-Forwarded-Host 并把它拼进页面资源 URL：

  <script src="https://evil.com/static/main.js"></script>

若 /index.html 允许缓存，恶意响应进入共享缓存：

  → 所有用户访问 /index.html，浏览器都会从 evil.com 拉取脚本
  → CDN 边缘节点把"植入了远程脚本的首页"分发给全站访客

反向代理架构中，X-Forwarded-Host 等头默认由代理设置；
应用误以为"既然经过了代理，头一定可信"。

实际上：
  · CDN/代理若允许客户端透传该头，客户端即可任意指定
  · 应当只在代理与源站之间"重新生成"这些头，而非原样转发
  · 白名单化：只接受代理签名后的头，或剥离全部客户端传入值

目标站：/myaccount/profile   返回用户个人资料（含敏感信息）

攻击者构造 URL：
  /myaccount/profile/foo.css

服务器按路径映射，仍返回 profile 内容；
而缓存规则按"扩展名"判断——.css 是静态资源，允许 public 缓存：

  /myaccount/profile/foo.css → 200 + Cache-Control: public

攻击者把该链接发给受害者，受害者登录后访问；
边缘缓存存储了"受害者的个人资料页"；
攻击者再访问同一 URL → 缓存命中 → 读到受害者数据。

受害者看到的是正常的个人资料页，URL 尾部多了一个 .css 后缀；
浏览器按 text/html 渲染，一切正常；
攻击者在缓存键上做文章，无需受害者做任何可疑操作。

变体：
  · 路径分隔符混淆：/profile/；/foo.css
  · 编码混淆：/profile%2ffoo.css
  · 空路径段：/profile//foo.css
  · 文件名伪装：/profile/..;/foo.css 等

请求走私利用"代理与后端对消息边界的理解不同"。

CL.TE 示意（代理按 Content-Length，后端按 Transfer-Encoding）：

POST / HTTP/1.1
Host: example.com
Content-Length: 4
Transfer-Encoding: chunked

60

GPOST /search?q=alert(1) HTTP/1.1
Host: example.com
Content-Length: 0

0

代理：只看到第一个请求（Content-Length: 4 → 只消费 "60\r\n"）
后端：按 chunked 解析，把后续字节当作"走私进来的第二个请求"

攻击步骤：
  ① 走私一个"只对后端可见"的请求：POST /search?q=<script>...
  ② 该请求绕过了代理的 WAF/校验（代理根本没看到它）
  ③ 后端处理并返回可缓存的响应
  ④ 代理把这条响应存入缓存（键 = 走私请求的 URL）
  ⑤ 后续正常用户请求命中该条目 → 拿到恶意载荷

相比普通投毒的优势：
  · 恶意请求对代理完全隐形，WAF 拦不到
  · 不必依赖"未进键的头/参数"，直接利用协议层差异

辅助标志：
  · CDN 响应头：CF-Cache-Status、X-Cache（HIT/MISS）、Age
  · 自定义头：X-Proxy-Cache: HIT / MISS
  · 两次请求对比：第二次是否仍返回同一版本内容

探测是否可缓存：
  GET /assets/app.js
  → 记录响应头 Cache-Control、Age
  → 换一个 User-Agent 再请求 → 观察 X-Cache 是否仍 HIT

① 找一个可缓存的页面（静态资源或带 public 的动态页）
② 修改某个请求头（如 X-Forwarded-Host: test123.example）
③ 观察响应中是否回显该值（搜 test123 字符串）
④ 若回显：尝试替换为恶意值，确认缓存键未包含该头
⑤ 让代理缓存后，用"干净请求"复现，验证扩散性

工具化思路（伪代码）：
  遍历候选头/参数列表 → 注入唯一标记 → 比对响应回显 → 标记可投毒点

# Nginx 反向代理缓存示例（示意）

# 只有特定路径允许缓存
location ~ ^/(assets|static|images)/ {
    proxy_cache cache_zone;
    proxy_cache_valid 200 1h;
    proxy_set_header X-Forwarded-Host "";          # 剥离不可信头
    proxy_set_header X-Original-URL "";            # 剥离
    proxy_cache_key $scheme$request_method$host$uri$is_args$args;
}

# 动态页面一律不缓存
location / {
    proxy_cache off;
    add_header Cache-Control "no-store";
}

· 输出安全：动态内容即使误缓存，也按 XSS 标准做输出编码（纵深防御）
· Host 校验：后端只接受白名单域名，非白名单 Host 直接 400
· 统一响应头：由框架统一输出 Cache-Control，应用层禁止私自 public
· 定期扫描：把"可缓存的动态页 + 未入键输入回显"加入自动化扫描