HTML缓存投毒测试与检测方法

最近发现不少小伙伴都对文章很感兴趣，所以今天继续给大家介绍文章相关的知识，本文《HTML缓存投毒测试方法与检测流程》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

HTML缓存投毒漏洞指攻击者利用缓存键盲区，通过非标准HTTP头注入恶意内容，使其被CDN或代理缓存并分发给其他用户，导致XSS、开放重定向等危害。

HTML缓存投毒漏洞的测试，核心在于理解Web应用与代理服务器或CDN之间的缓存机制，并通过操纵请求，注入恶意内容，使其被缓存并分发给其他用户。这需要我们像攻击者一样思考，找到缓存键（Cache Key）的盲区，然后验证恶意内容的持久性。

解决方案

要模拟并检测HTML缓存投毒漏洞，我们通常会遵循一个结构化的流程，但在这个过程中，保持探索性和对细节的敏感度至关重要。

我们首先需要对目标网站进行侦察，了解其是否使用了CDN、反向代理（如Nginx、Varnish等）。这可以通过观察HTTP响应头，如 Server、X-Cache、Via 等来初步判断。这些头信息能给我们提供缓存架构的线索。

接着，便是对缓存键的深入分析。缓存服务器如何决定两个请求是否“相同”并能共享同一个缓存响应？这通常基于URL路径、查询参数、Host头、User-Agent、Accept-Encoding等。特别要关注 Vary 响应头，它明确告诉代理服务器，在决定是否返回缓存响应时，需要考虑哪些请求头。如果 Vary 头配置不当或缺失，就可能存在投毒的机会。

在攻击载荷的构造上，我们不应局限于URL或标准的HTTP头。很多代理服务器会处理一些非标准的HTTP头，例如 X-Forwarded-Host、X-Original-URL 甚至自定义的 X-Host 等。这些头在某些情况下可能被后端应用处理，但却不在缓存键的考虑范围之内。我们可以尝试在这些头中注入简单的HTML标签，如 ，或者一个开放重定向的URL。

触发缓存是关键一步。发送带有恶意载荷的请求后，需要确保这个响应被代理服务器缓存下来。这通常意味着我们需要发送至少两次相同的请求（在恶意载荷被注入的情况下），并观察响应头中的 X-Cache: HIT 或 Age 字段。如果第一次请求是 MISS，第二次是 HIT 且 Age 值不为零，那就表明内容被缓存了。

最后，也是最重要的一步，是验证投毒是否成功。这需要我们模拟一个“干净”的用户，即使用一个没有发送过恶意请求的浏览器、不同的IP地址或清除本地缓存后，再次请求相同的资源。如果此时收到的响应中包含了我们之前注入的恶意内容，那么恭喜你，投毒成功。

什么是HTML缓存投毒漏洞，它如何影响用户？

在我看来，HTML缓存投毒漏洞就像是公共饮水机里被人下了“慢毒”。攻击者并非直接攻击最终用户，而是巧妙地利用了Web基础设施中的一个信任环节——缓存服务器。当一个网站使用CDN或反向代理来加速内容分发时，这些中间层会根据一定的规则（即缓存键）来存储并提供内容。

这个漏洞的核心在于，缓存服务器在生成缓存键时，没有充分考虑到所有可能影响最终响应内容的请求元素。例如，某个HTTP头（比如 X-Forwarded-Host）可能会被后端应用用来动态生成页面上的链接，但CDN却可能没有将其纳入缓存键的计算范围。

攻击流程通常是这样的：攻击者发送一个精心构造的请求，其中包含一个恶意载荷（例如一个XSS脚本或一个指向钓鱼网站的链接），这个载荷通过某个被缓存键忽略的请求头或参数传递。代理服务器收到这个请求后，后端应用处理并返回了一个包含恶意内容的响应。由于缓存键的“盲区”，代理服务器认为这个响应是针对某个“标准”请求的，于是将其缓存。此后，任何其他用户请求相同的URL时，代理服务器就会直接返回这个被投毒的缓存响应，从而导致恶意内容被分发给大量无辜用户。

这种漏洞的影响是相当深远的。最直接的可能是实现存储型XSS，攻击者可以在受害者浏览器上执行任意JavaScript，窃取Cookie、篡改页面内容，甚至进行会话劫持。此外，它还可能导致开放重定向，将用户引导至恶意网站；或者通过注入钓鱼页面，诱导用户提交敏感信息。更甚者，如果攻击者能注入恶意CSS或HTML，甚至能对网站进行临时的“页面篡改”，严重损害网站的信誉。一个被缓存的恶意响应，其传播范围和持续时间都可能远超一次性的攻击。

如何识别潜在的HTML缓存投毒攻击点？

识别潜在的HTML缓存投毒攻击点，需要我们像侦探一样，仔细观察HTTP请求和响应的每一个细节。我个人觉得，这不仅仅是工具扫描能完全覆盖的，更多的是一种思维模式和经验的积累。

最直接的线索是HTTP响应头。

1. Cache-Control 头：如果看到 Cache-Control: public, max-age=...，这明确表示内容是可缓存的，并且指定了缓存时长，这是个明显的信号。
2. Vary 头：这是最关键的头之一。它告诉代理服务器，哪些请求头会影响响应内容。例如，Vary: Accept-Encoding, User-Agent 意味着服务器会根据 Accept-Encoding 和 User-Agent 头来缓存不同版本的响应。如果 Vary 头缺失，或者没有包含所有影响响应的请求头（比如 Host 或 X-Forwarded-Host），那么就存在潜在的投毒风险。一个常见的误区是，开发者认为 Vary 足够了，但可能忽略了某些非标准头。
3. X-Cache、X-Served-By 等自定义头：这些头通常由CDN或反向代理添加，用于指示请求是否命中了缓存（HIT 或 MISS），以及由哪个节点提供服务。观察这些头对于理解缓存行为至关重要。

在探测缓存键时，我们需要进行系统性的测试。我们可以使用Burp Suite的Repeater或Intruder，逐步修改请求的各个部分，包括：

• URL路径：尝试对路径进行规范化操作，例如 /path/../admin 和 /admin。
• 查询参数：添加、修改或删除查询参数，观察是否影响缓存。
• Host头：这是最常见的投毒点之一。尝试修改 Host 头为一个恶意域名，看是否能在响应中被反射或链接到。
• 非标准HTTP头：这是我个人觉得最容易被忽视的区域。很多代理服务器会处理 X-Forwarded-Host、X-Original-URL、X-Rewrite-URL 等头。尝试在这些头中注入恶意内容，观察响应。
• Cookie：虽然Cookie通常是用户会话相关的，但某些情况下，如果Cookie影响了页面内容且未被 Vary 头考虑，也可能导致缓存投毒。

一个实用的技巧是，当你修改一个请求头或参数后，发送两次请求。第一次请求通常会是 MISS，第二次如果变成 HIT，并且响应内容与第一次不同（或者包含了你注入的内容），那么这个请求头/参数可能就是缓存键的一部分，或者其处理方式存在漏洞。

模拟攻击成功后，如何验证并报告漏洞？

模拟攻击成功，只是万里长征的第一步。更重要的是如何严谨地验证漏洞，并清晰、有条理地将其报告给开发者或安全团队。这不仅仅是为了证明你的发现，更是为了帮助他们理解问题的根源并有效修复。

验证步骤：

1. 模拟“全新”用户：这是最关键的一步。你需要确保你不是在看自己本地的浏览器缓存。最可靠的方法是：
   • 使用浏览器的隐私/隐身模式。
   • 彻底清除浏览器缓存和Cookie。
   • 尝试从不同的网络环境或IP地址（例如，切换到手机热点，或者使用一个代理服务器，但要避免与投毒过程混淆）访问被投毒的URL。
   • 使用 curl 命令，确保不带任何本地缓存或会话信息，例如 curl -i "https://example.com/path" -H "User-Agent: clean-user"。
2. 确认恶意内容持久性：多次请求同一URL，观察响应是否持续包含你注入的恶意内容。同时，检查响应头中的 X-Cache 或 Age，确保它表明命中了缓存。如果 X-Cache 仍然是 MISS 或者 Age 为零，那说明可能只是后端服务器的响应，而非缓存投毒。
3. 验证攻击效果：如果你注入的是XSS载荷，确认脚本是否在浏览器中执行；如果是开放重定向，确认是否能成功跳转到指定URL。这能直观地展示漏洞的实际危害。

漏洞报告： 一份好的漏洞报告，应该能让任何一个技术人员都能理解并复现。

1. 漏洞标题：简洁明了，例如“HTML缓存投毒漏洞导致存储型XSS”。
2. 漏洞描述：解释什么是HTML缓存投毒漏洞，以及它为什么会发生。说明你利用了哪个HTTP头或参数，以及它如何绕过了缓存机制。
3. 重现步骤（Proof of Concept - PoC）：
   • 详细的请求序列：提供你用来触发投毒的HTTP请求（最好是Burp Suite的请求/响应截图或文本）。明确指出哪些部分是恶意载荷，哪些是关键的HTTP头。
   • 验证请求：提供你用来验证投毒成功的HTTP请求和对应的响应。
   • 受影响的URL：清晰指出哪个URL或资源受到了影响。
   • 预期结果与实际结果：说明在正常情况下应该看到什么，以及因为漏洞你实际看到了什么。
4. 攻击载荷：明确列出你使用的恶意载荷，例如 。
5. 潜在影响：阐述这个漏洞可能带来的最坏后果，例如用户会话劫持、钓鱼攻击、网站信誉受损等。这有助于团队理解漏洞的严重性。
6. 建议修复方案：虽然修复是开发团队的职责，但提供一些建设性的建议总是有益的。例如，建议正确配置 Vary 头，确保它包含所有影响响应的请求头；或者在后端应用中，对所有可能被用户控制的输入进行严格的输入验证和输出编码，尤其是在HTTP头中。

通过这种方式，你的发现不仅有技术深度，也具备了实际的指导价值，能够真正帮助提升网站的安全性。

今天关于《HTML缓存投毒测试与检测方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！