在接下来的章节中，将展示如何通过利用缓存系统具体实施实现机制问题来获得更大的Web缓存中毒攻击面。将亚你就为什么缓存键生成方式的缺陷有时会使网站容易受到缓存中毒的影响，而这些漏洞通常被认为是不可利用的。另外还将展示如何进一步使用经典技术来潜在地破坏应用程序级缓存，通常会带来毁灭性的结果。
无键端口
Host标头通常是缓存键的一部分，因此，最初看起来不太可能注入任何类型的payload。
然后，一些缓存系统解析标头的时候会从缓存键中排除端口。
在这种情况下，有可能可以利用这个标头来进行Web缓存中毒。
例如，考虑上一节中看到的情况，根据Host标头动态生成一个重定向URL，这可能能够通过简单地在请求中添加一个任意端口来构建一个拒绝服务攻击。所有浏览到主页的用户都会被重定向到一个假的端口，有效地使主页瘫痪，直到缓存过期。
如果网站允许指定非数字端口，这种攻击可以进一步升级。例如，可以用它来注入一个XSS的payload。
Unkeyed查询字符串
和Host标头一样，请求行通常也是有缓存键的。然而，最常见的缓存键转换之一是排除整个查询字符串。
检测unkeyed查询字符串
如果响应明确的表明有缓存命中，这种转变就比较容易发现，但如果没有呢？
这样做的副作用是使动态页面看起来就像完全静态的一样，因为很难知道是在与缓存还是服务器通信。
要识别动态页面，通常需要观察参数值对响应的影响。但是，如果查询字符串是unkeyed的，大多数情况下，仍然会得到一个缓存命中。因此，无论你添加任何参数，都是一个不变的响应。很明显，这也使得经典的缓存破坏器查询参数变得多余了。
幸运的是，有一些替代的方法来添加缓存破坏器，比如把它添加到一个不干扰应用程序行为的缓存键中，典型的例子如下：
如果使用"Param Miner"，可以选择"Add static/dynamic cache buster"和"include cache busters in headers"。然后，在使用Burp进行手动测试发送任何请求时会自动地在常见的缓存键信息中添加一个缓存破坏器。
另一个方法是查看缓存和后端如何规范化请求路径的方式是否存在差异。由于路径几乎肯定是缓存键，因此有时可以利用这一点，发出具有不同键值的请求，但这些请求仍然到达相同的端口。例如，下面条目可能都被单独缓存，但在后端被视为等价于GET /：
这种转变有时会掩盖原本非常明显的XSS漏洞，如果渗透测试人员或自动扫描器只接收缓存的响应而没有意识到，那么页面上可能就没有反射型XSS。
利用unkeyed查询字符串
从缓存键中排除查询字符串实际上可以使这些反映出来的XSS漏洞更加严重。
通常情况下，这种攻击依赖于诱使受害者访问恶意制作的URL。然后，通过unkeyed的查询字符串毒害缓存会导致payload被提供给访问正常URL的用户。这就有可能影响更多的受害者，而攻击者并没有做进一步的互动。
场景试验-通过unkeyed的查询字符串导致Web缓存中毒：
https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-unkeyed-query
场景说明：
这个试验场景容易受到Web缓存中毒的影响，因为查询字符串是unkeyed，用户经常使用Chrome浏览器访问这个网站的主页。
试验目的：
要完成这个试验，需要在访问者的浏览器中执行alert(1)的响应来毒害主页。
攻击过程：
①访问主页后把这个请求发送到Repeater，添加任意查询参数重放请求后可以发现，仍然可以命中缓存，说明它们不包含在缓存键中
②在请求中加入"Origin"标头，重放后发现这个标头可以作为缓存破坏器
③可以注意到，URL的参数被缓存到了响应中，哪怕现在不输入参数了，仍然会从缓存进行响应
④在原来的请求中，去掉"Origin"缓存破坏器，在URL参数后面加入下面的反射型XSS：
GET /?evil='/><script>alert(1)</script>，发送这个请求直到命中缓存，即可完成试验
Unkeyed查询参数
到目前为止已经看到在一些网站上，整个查询字符串被排除在缓存键之外。
但有些网站只排除与后端应用程序不相关的特定查询参数，例如用于分析或服务目标广告的参数。像utm_content之类的UTM参数是测试期间很好的候选参数。
从缓存键中排除的参数不太可能对响应产生重大的影响，很可能不会有任何有用的小工具接受来自这些参数的输入。也就是说，有些页面以一种易受攻击的方式处理整个URL，这使得利用任意参数成为可能。
场景试验-通过unkeyed的参数导致Web缓存中毒：
https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-unkeyed-param
场景说明：
这个试验场景容易受到Web缓存中毒的影响，因为它将某个参数排除在缓存键之外，用户经常使用Chrome浏览器访问这个网站的主页。
试验目的：
要完成这个试验，需要在访问者的浏览器中执行alert(1)的响应来毒害主页。
攻击过程：
①访问主页后把请求发送到Repeater，在修改查询参数后可以发现，每次响应都未命中缓存，说明参数是缓存键的一部分，同时也可以看到，所查询的字符串会出现在响应中
②使用"utm_content"作为参数时可以发现，可以命中缓存，不会因为参数的变化而变化
③再次修改请求，发送一个带有"utm_content"参数的payload，即可完成试验
GET /?utm_content='/><script>alert(1)</script>
SQL注入攻击-检索隐藏的数据
HTTP Host头漏洞攻击-概念梳理
原文始发于微信公众号（H君网安白话）：Web缓存中毒-攻击示例（四）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论