Cache Poisoning and Cache Deception
学习与实践 AWS 黑客技术：
HackTricks 培训 AWS 红队专家 (ARTE)
学习与实践 GCP 黑客技术： 
HackTricks 培训 GCP 红队专家 (GRTE)
使用 Trickest 轻松构建和 自动化工作流，由世界上 最先进 的社区工具提供支持。 今天就获取访问权限：
The difference
Web 缓存中毒和 Web 缓存欺骗之间有什么区别？
在 Web 缓存中毒 中，攻击者使应用程序在缓存中存储一些恶意内容，并且这些内容从缓存中提供给其他应用程序用户。
在 Web 缓存欺骗 中，攻击者使应用程序在缓存中存储属于另一个用户的一些敏感内容，然后攻击者从缓存中检索这些内容。
Cache Poisoning
缓存中毒旨在操纵客户端缓存，强迫客户端加载意外、部分或由攻击者控制的资源。影响的程度取决于受影响页面的受欢迎程度，因为被污染的响应仅在缓存污染期间提供给访问该页面的用户。
执行缓存中毒攻击涉及几个步骤：
识别无键输入：这些是参数，尽管不是缓存请求所必需的，但可以改变服务器返回的响应。识别这些输入至关重要，因为它们可以被利用来操纵缓存。
利用无键输入：在识别无键输入后，下一步是弄清楚如何滥用这些参数，以修改服务器的响应，从而使攻击者受益。
确保被污染的响应被缓存：最后一步是确保被操纵的响应被存储在缓存中。这样，任何在缓存被污染时访问受影响页面的用户将收到被污染的响应。
Discovery: Check HTTP headers
通常，当响应被 存储在缓存中 时，会有一个 指示的头部，您可以在此帖子中检查您应该关注哪些头部：HTTP 缓存头部。
Discovery: Caching error codes
如果您认为响应正在被存储在缓存中，您可以尝试 发送带有错误头部的请求，这应该会以 状态码 400 响应。然后尝试正常访问请求，如果 响应是 400 状态码，您就知道它是脆弱的（您甚至可以执行 DoS）。
您可以在以下位置找到更多选项：
Cache Poisoning to DoS但是，请注意 有时这些状态码不会被缓存，因此此测试可能不可靠。
Discovery: Identify and evaluate unkeyed inputs
您可以使用 Param Miner 来 **暴力破解可能 改变页面响应 的参数和头部。例如，一个页面可能使用头部 X-Forwarded-For 来指示客户端从那里加载脚本：
引发后端服务器的有害响应
通过识别的参数/头部检查它是如何被清理的，以及在哪里它被反映或影响头部的响应。你能以任何方式滥用它吗（执行XSS或加载你控制的JS代码？执行DoS？...）
获取响应缓存
一旦你识别了可以被滥用的页面，使用哪个参数/头部以及如何滥用它，你需要让页面被缓存。根据你尝试缓存的资源，这可能需要一些时间，你可能需要尝试几秒钟。
响应中的头部**X-Cache可能非常有用，因为当请求未被缓存时，它的值可能是miss，而当它被缓存时，值为hit。
头部Cache-Control**也很有趣，可以知道资源是否被缓存，以及下次资源将何时再次被缓存：Cache-Control: public, max-age=1800
另一个有趣的头部是**Vary。这个头部通常用于指示额外的头部**，这些头部被视为缓存键的一部分，即使它们通常没有键。因此，如果用户知道他所针对的受害者的User-Agent，他可以为使用该特定User-Agent的用户毒化缓存。
与缓存相关的另一个头部是**Age**。它定义了对象在代理缓存中存在的时间（以秒为单位）。
在缓存请求时，要小心使用的头部，因为其中一些可能会被意外使用为键，而受害者需要使用相同的头部。始终使用不同的浏览器测试缓存中毒是否有效。
利用示例
最简单的示例
像X-Forwarded-For这样的头部在响应中未经过清理地被反映。
你可以发送一个基本的XSS有效负载并毒化缓存，这样每个访问该页面的人都会受到XSS攻击：
Note that this will poison a request to /en?region=uk not to /en
Cache poisoning to DoS
Cache Poisoning to DoS使用网络缓存中毒来利用 cookie 处理漏洞
Cookies 也可能在页面的响应中被反射。如果你能利用它造成 XSS，例如，你可能能够在加载恶意缓存响应的多个客户端中利用 XSS。
注意，如果易受攻击的 cookie 被用户频繁使用，常规请求将清除缓存。
使用分隔符、规范化和点生成差异
检查：
Cache Poisoning via URL discrepancies通过路径遍历进行缓存中毒以窃取 API 密钥
这篇文章解释了 如何通过一个像 https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 的 URL 窃取 OpenAI API 密钥，因为任何匹配 /share/* 的内容都会被缓存，而 Cloudflare 不会对 URL 进行规范化，这在请求到达 web 服务器时完成。
这在以下内容中也有更好的解释：
Cache Poisoning via URL discrepancies使用多个头部来利用 web 缓存中毒漏洞
有时您需要 利用多个未键入的输入 来滥用缓存。例如，如果您将 X-Forwarded-Host 设置为您控制的域名，并将 X-Forwarded-Scheme 设置为 http，您可能会发现一个 开放重定向。如果 服务器 将所有 HTTP 请求转发到 HTTPS 并使用头部 X-Forwarded-Scheme 作为重定向的域名。您可以控制重定向指向的页面。
利用有限的 Vary头
Vary头如果你发现 X-Host 头被用作 加载 JS 资源的域名，但响应中的 Vary 头指示 User-Agent。那么，你需要找到一种方法来提取受害者的 User-Agent，并使用该用户代理来污染缓存：
Fat Get
发送一个带有请求的 GET 请求，URL 和请求体中都包含该请求。如果 web 服务器使用请求体中的内容，但缓存服务器缓存了 URL 中的内容，那么任何访问该 URL 的人实际上将使用请求体中的参数。就像 James Kettle 在 Github 网站上发现的漏洞：
There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get
参数伪装
例如，在 ruby 服务器中，可以使用字符 ; 来分隔 参数，而不是 &。这可以用来将无键参数值放入有键参数中并加以利用。
Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
通过滥用 HTTP 请求走私来利用 HTTP 缓存中毒
在这里了解如何通过滥用 HTTP 请求走私进行缓存中毒攻击。
Web 缓存中毒的自动化测试
Web Cache Vulnerability Scanner 可用于自动测试 Web 缓存中毒。它支持多种不同的技术，并且高度可定制。
示例用法: wcvs -u example.com
漏洞示例
Apache Traffic Server (CVE-2021-27577)
ATS 在 URL 中转发了片段而没有去掉它，并仅使用主机、路径和查询生成缓存键（忽略片段）。因此，请求 /#/../?r=javascript:alert(1) 被发送到后端为 /#/../?r=javascript:alert(1)，而缓存键中没有负载，只有主机、路径和查询。
GitHub CP-DoS
在内容类型头中发送错误值触发了 405 缓存响应。缓存键包含 cookie，因此只能攻击未授权用户。
GitLab + GCP CP-DoS
GitLab 使用 GCP 存储桶来存储静态内容。GCP 存储桶 支持 头部 x-http-method-override。因此，可以发送头部 x-http-method-override: HEAD 并使缓存返回空响应体。它还可以支持 PURGE 方法。
Rack 中间件 (Ruby on Rails)
在 Ruby on Rails 应用程序中，通常使用 Rack 中间件。Rack 代码的目的是获取 x-forwarded-scheme 头的值并将其设置为请求的方案。当发送头 x-forwarded-scheme: http 时，会发生 301 重定向到相同位置，可能导致该资源的拒绝服务 (DoS)。此外，应用程序可能会识别 X-forwarded-host 头并将用户重定向到指定主机。这种行为可能导致从攻击者的服务器加载 JavaScript 文件，构成安全风险。
403 和存储桶
Cloudflare 之前缓存了 403 响应。尝试使用错误的授权头访问 S3 或 Azure 存储 Blob 会导致 403 响应被缓存。尽管 Cloudflare 已停止缓存 403 响应，但这种行为可能仍然存在于其他代理服务中。
注入键参数
缓存通常在缓存键中包含特定的 GET 参数。例如，Fastly 的 Varnish 在请求中缓存了 size 参数。然而，如果发送了 URL 编码版本的参数（例如，siz%65）并且值错误，缓存键将使用正确的 size 参数构建。然而，后端将处理 URL 编码参数中的值。对第二个 size 参数进行 URL 编码导致缓存省略了它，但后端使用了它。将该参数的值设置为 0 会导致可缓存的 400 错误请求。
用户代理规则
一些开发人员阻止与高流量工具（如 FFUF 或 Nuclei）匹配的用户代理的请求，以管理服务器负载。讽刺的是，这种方法可能引入漏洞，例如缓存中毒和 DoS。
非法头字段
RFC7230 指定了头名称中可接受的字符。包含超出指定 tchar 范围的字符的头理想情况下应触发 400 错误请求响应。在实践中，服务器并不总是遵循此标准。一个显著的例子是 Akamai，它转发包含无效字符的头，并缓存任何 400 错误，只要 cache-control 头不存在。发现了一种可利用的模式，发送带有非法字符（如 \）的头会导致可缓存的 400 错误请求。
查找新头
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
缓存欺骗
缓存欺骗的目标是使客户端 加载将被缓存保存的敏感信息资源。
首先要注意的是，扩展名如 .css、.js、.png 等通常被 配置 为 保存 在 缓存 中。因此，如果您访问 www.example.com/profile.php/nonexistent.js，缓存可能会存储响应，因为它看到 .js 扩展名。但是，如果 应用程序 正在 重放 存储在 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
使用不太常见的扩展名，如
.avif
另一个非常清晰的例子可以在这个写作中找到: https://hackerone.com/reports/593712。 在这个例子中，解释了如果您加载一个不存在的页面，如 http://www.example.com/home.php/non-existent.css，将返回 http://www.example.com/home.php 的内容（包含用户的敏感信息），并且缓存服务器将保存结果。 然后，攻击者可以在自己的浏览器中访问 http://www.example.com/home.php/non-existent.css 并观察之前访问过的用户的 机密信息。
请注意，缓存代理 应该 配置 为 基于 文件的 扩展名 (_ .css_) 而不是基于内容类型。在示例 http://www.example.com/home.php/non-existent.css 中，将具有 text/html 内容类型，而不是 text/css MIME 类型（这是 _ .css_ 文件的预期）。
在这里了解如何通过滥用 HTTP 请求走私进行 缓存欺骗攻击。
自动化工具
toxicache: Golang 扫描器，用于在 URL 列表中查找 Web 缓存中毒漏洞并测试多种注入技术。
参考文献
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Last updated
