缓存投毒在查什么
共享缓存按「缓存键」决定把响应存给谁。如果某个输入没有进入缓存键、却会影响响应内容，攻击者就可能让缓存保存一份被污染的内容，随后回放给其他用户——从 XSS 到跳转劫持都可能由此产生。风险特点是波及面大：一个标记被缓存，可能影响大量真实用户。因此验证方式必须极度克制：用无害标记、间隔请求观察，并在结束前按客户流程清理。
基本信息
| 缓存键要素 | 路径、查询参数、Host、部分请求头 |
|---|---|
| 关注输入 | 未进入缓存键但影响响应内容的请求头（如各类转发头） |
| 识别方式 | 响应头中的缓存标识与命中指示（如 age、x-cache） |
| 风险等级 | 共享缓存场景下波及面大，需要严格限定窗口 |
| 前置条件 | 先与客户确认缓存清理方式与验证窗口 |
典型使用场景
- CDN 前置站点的评估项，重点是缓存键覆盖是否完整
- 解释「不同用户看到相同异常内容」这类现象
- 评估缓存层与源站对同一请求的理解是否一致
- 为跨站脚本与跳转类问题评估放大效应
- 修复验证：确认缓存键已包含关键输入或缓存已旁路
验证思路
验证思路
# 1. 识别缓存层与缓存键构成
curl -sI https://example.com/ | grep -Ei 'age|x-cache|cache-control|via'
# 2. 选一个未进入缓存键但影响响应内容的头，用无害标记请求两次
curl -s -H 'X-Forwarded-Host: marker.example' https://example.com/ | head -3
curl -s https://example.com/ | head -3 # 第二次若命中标记，说明被缓存
# 3. 用独立浏览器会话复核，避免本机会话干扰
# 4. 结束后等待缓存自然过期，或按客户流程清理；全程控制请求次数现象与判断
| 现象 | 含义 | 处置 |
|---|---|---|
| 第二次请求命中注入标记 | 污染内容被缓存 | 按共享缓存影响定级，并说明已清理 |
| 仅本机会话可见标记 | 本地缓存而非共享缓存 | 区分本地与共享缓存，影响面不同 |
| 响应头显示不缓存 | 该路径未进入缓存 | 记录为已核查 |
| 标记在过期后消失 | 缓存按预期过期 | 记录生命周期，便于评估影响时长 |
验证前必须与客户确认缓存清理方式：标记若长期驻留，会影响真实用户，后果远超测试本身。
把正常缓存命中当作投毒成功是常见误判：判定标准是「注入的标记被缓存并回放给其他会话」，而不是响应被缓存这件事本身。