我将阐明我在受控环境中破解 Web 应用程序时的思维方式，以帮助您学习如何自己测试应用程序。

目的

使用在受害者浏览器中执行的响应来毒害该缓存。alert(document.cookie)

什么是 Web 缓存中毒？

Web 缓存中毒是指攻击者操纵 Web 缓存向用户提供恶意内容。这种攻击可以将有害负载、误导性信息或网络钓鱼网站重定向分发给广泛的受众，从而使检测变得困难。

我的目标是在各种网络安全主题中为您提供价值，并成为您扩展专业知识或成为有抱负的网络安全专业人士的最终目的地。

方法论

想要亲自尝试一下实验室并跟随？您可以在 PortSwigger 的网站上免费查看。

侦察

开始此实验时，我们获得了一些信息：

• 该实验室包含一个缓存中毒漏洞，该漏洞仅在您使用多个标头时可利用。

• 该实验室支持 X-Forwarded-Host 和 X-Forwarded-Scheme 标头。

当我们通常接近目标时，我们可以从单击 “all of the things” 开始。

该实验室设有一个商店，其中包含不同的商品，但产品页面没有任何功能。

该实验室具有登录功能，但我们没有提供的凭证可供使用。

我们还应该注意我们有一个可用的漏洞利用服务器。我怀疑这是我们发动攻击的地方，但我们首先需要找到攻击媒介。

让我们把目光转向 SiteMap。

我们可以在 Root Request 中看到响应中存在 X-Cache 标头，这是一个关键指标，应用程序中正在发生缓存。

引起我注意的一个请求位于 resources/js/tracking.js 下。

它引起了我的注意，因为在 HTTP History 中，它被调用的频率相当高。

让我们将其发送到 Repeater 进行一些手动测试。

测试

我们可以先将具有任意主机名的 X-Forwarded-Host 标头添加到请求中。

这不会在响应中产生任何明显的变化。

让我们使用 X-Forwarded-Scheme 标头重试。Wec an send 具有相同的测试域。

我们可以看到，我们现在收到了 302 响应，但在响应中没有看到任何反射。

让我们尝试将 HTTPS 作为值添加到标头中。

我们可以看到，现在返回 200 响应。

注意：如果 X-Cache 标头返回 “hit”，则必须等待 Pain 过期，然后才能测试新的有效负载。此环境的生存时间 （TTL） 为 30 秒。

接下来，将 X-Forwarded-Host 标头添加回去，并将 X-Forwarded-Scheme 标头更改为 nothttps。

发送请求，直到您再次收到 302 响应。

请注意，这一次，位置已更改，以反映我们放置在 X-Forwarded-Host 标头中的测试域。

我们已经找到了攻击媒介。

开发

正如预期的那样，我们需要利用 Exploit Server 来交付 paylod。

在 Exploit Server 中，更改 File path 以反映应用程序正在搜索的路径：/resources/js/tracking.js

将有效负载写入漏洞利用服务器的 Body 中，然后单击 Store： alert（document.cookie）

将 URL 复制并粘贴到 X-Forwarded-Host 标头中，并将 X-Forwarded-Scheme 标头保留为 nothttps。

请注意，当您选择 Copy URL 并在浏览器中加载 URL 时，您将看到有效负载的脚本，但警报不会执行。

为了利用您的受害者，请删除缓存无效化程序并重新发送请求，直到您再次毒害缓存。

重新加载浏览器。

实验室解决了！

我们学到了什么

虽然 Web 缓存中毒本身可能不是最有效的漏洞，但我们已经看到，当与 XSS 链接时，缓存策略可能会产生毁灭性的影响。最重要的是，由于该漏洞在繁忙的站点上可能具有潜在的爆炸半径，因此该漏洞能够在一次快速攻击中影响数千名用户。

请务必清理用户输入，确保缓存键是唯一且无法操纵的，并正确使用 cache-control 标头以避免应用程序中的此漏洞。

原文始发于微信公众号（安全狗的自我修养）：具有多个标头的 Web 缓存中毒