绕过Web缓存投毒防御策略
翻译
原文：https://portswigger.net/research/bypassing-web-cache-poisoning-countermeasures
- name: 翻译
desc: 原文：https://portswigger.net/research/bypassing-web-cache-poisoning-countermeasures
bgColor: '#F0DFB1'
textColor: 'green'
2
3
4
# 绕过 Web 缓存投毒防御策略
在我上个月发表了关于 Web 缓存投毒 (opens new window)的演讲 (opens new window)和白皮书 (opens new window)之后，许多公司都部署了防御措施，试图减轻缓存投毒攻击。在这篇文章中，我将介绍一些可用于绕过它们的常见弱点。
这项研究引起了几家主要缓存供应商的回应。Akamai 发布了一个微弱的回应，且令人困惑地引用了 Web 缓存欺骗的缓解措施 (opens new window)，这些措施对防止 Web 缓存投毒几乎没有任何作用。Fastly 发布了一份安全公告 (opens new window)，其中包含有关缓解措施的详细建议，Cloudflare 更进一步，部署了全球缓解措施，并在一篇名为《Cloudflare 如何保护客户免受缓存投毒》 (opens new window)的博客文章中进行了详细说明。
让我们仔细看看 Cloudflare 部署的两种防御措施。他们首先在 WAF 中添加一条规则，以阻止 XSS 友好的字符，例如我在某些标头中使用的<字符 ，以X-Forwarded-Host作为示例：
GET / HTTP/1.1
Host: wafproxy.net
X-Forwarded-Host: xss<
HTTP/1.1 403 Forbidden
Attention Required!
2
3
4
5
6
7
这样一来，通过缓存投毒利用这些标头直接获取 XSS 变得更加困难，但正如他们所指出的，这仍然使一些应用程序容易受到攻击，因为这些字符并不总是必需的。
第二个更强大的缓解措施，将这些标头添加到默认缓存键中，从理论上讲，无法将这些标头用于缓存投毒：
GET / HTTP/1.1
Host: wafproxy.net
X-Forwarded-Host: evil.net
HTTP/1.1 200 OK
<a href="https://evil.net/"
2
3
4
5
6
7
缓解前的缓存键：https://wafproxy.net/
缓解后的缓存键：https://wafproxy.net/|evil.net
但不幸的是，这两种防御措施都存在严重的实现缺陷，这意味着它们可以被完全绕过。这个阶段是通过一个小优化设置的，这意味着如果X-Forwarded-Host与Host匹配，Cloudflare 将不会把X-Forwarded-Host添加到缓存键中：
GET / HTTP/1.1
Host: wafproxy.net
X-Forwarded-Host: wafproxy.net
2
3
缓解后的缓存键：https://wafproxy.net/
致命的缺陷是 Cloudflare 只查看每个标头的第一个实例，因此攻击者可以提供重复的标头，第一个实例是无害的，第二个实例包含有效负载。当后端服务器处理此类请求时，它通常会使用逗号将两个标头值连接起来。
GET / HTTP/1.1
Host: wafproxy.net
X-Forwarded-Host: wafproxy.net
X-Forwarded-Host: evil.net"/><script...
HTTP/1.1 200 OK
<a href="https://wafproxy.net, evil.net"/><script...
2
3
4
5
6
7
8
缓解后的缓存键：https://wafproxy.net/
我上周向 Cloudflare 报告了这个问题，所以它可能很快就会被修补。缓存键绕过现在已经修补。
尽管他们的缓解措施最初没有奏效，但他们是唯一一个尝试实施缓解措施的供应商，现在我的绕过方式得到了修补，我认为在默认配置情况下，他们是最安全的供应商。但值得注意的是，这种缓解措施永远不会使托管在 Cloudflare 上的站点免受缓存投毒的影响——它只能防止使用最流行的标头进行攻击。
个别公司的修补尝试也可能出错。一个常见的错误是检测缓存投毒攻击，并使用可缓存的响应来阻止它。这实际上会造成拒绝服务问题。这种危险也可能是由 WAF 引起的，例如 www.tesla.com 使用 WAF 来阻止在任何标头中包含字符串 “burpcollaborator.net” 的请求：
GET /en_GB/roadster HTTP/1.1
Host: www.tesla.com
Any-Header: burpcollaborator.net
HTTP/1.1 403 Forbidden
Access Denied. Please contact waf@tesla.com
2
3
4
5
6
7
在这次攻击之后，任何试图访问该页面的人都会发现自己被阻止了：
GET /en_GB/roadster HTTP/1.1
Host: www.tesla.com
HTTP/1.1 403 Forbidden
Access Denied. Please contact waf@tesla.com
2
3
4
5
6
我看到的另一个错误，该公司试图修补引入漏洞的框架，但低估了标头的全部潜力。例如，一个目标将request.host变量的可接受值列入白名单，该变量由X-Forwarded-Host标头填充。但是，他们没有注意到此标头也可以填充request.port，从而实现持久的拒绝服务：
GET / HTTP/1.1
Host: redacted.com
X-Forwarded-Host: redacted.com:123
HTTP/1.1 301 Moved Permanently
Location: https://redacted.com:123/
2
3
4
5
6
归根结底，临时修补 Web 缓存投毒可能很棘手，而 Web 框架的作者是解决最常见类型的最佳人选。近年来，像 Django 和 Flask 这样的框架已经禁用了对这些头文件的支持，而像 Ruby on Rails 这样的框架也一再被警告 (opens new window)，但直到最近才开始部署修复程序。
最后，我应该提一下，我已经对 Param Miner (opens new window) 进行了一些实质性的更新，这些更新将于周一发布，特别是默认禁用静态 “fcbz” 缓存破坏器，因为它会破坏某些站点。这意味着，当使用浏览器或 Repeater 尝试缓存投毒时，您需要手动指定自己的缓存破坏程序，否则可能会意外影响其他访问者。
祝你好运，注意安全！