文章总结： 本文分析了因缓存服务器与源服务器对URL分隔符的解码时机与顺序差异导致的缓存欺骗漏洞。攻击者可利用%23等编码字符构造请求，使缓存误存敏感响应，造成信息泄露。建议统一解码逻辑，规范URL编码使用，并实施严格的规范化与验证机制以缓解风险。 综合评分： 90 文章分类： WEB安全,漏洞分析,安全建设

“缓存欺骗第四章”分隔符被解码，而且顺序不一样？可以挖掘的漏洞点就在这里了！

原创

升斗安全XiuXiu

升斗安全

2025年12月23日 18:53 广东

【文章说明】

• 目的：本文内容仅为网络安全技术研究与教育目的而创作。
• 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
• 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
• 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。

阅读即代表您同意以上条款。

在第三章中，基本都是在介绍分隔符的作用及影响，但实际情况下，很多网站会对分隔符进行解码，这个解码的操作可能会引发差异问题，并进一步导致缓存欺骗漏洞的产生。

网站有时需要在URL中，传输包含特殊分隔符的数据字符。为确保这些字符被正确识别为数据而非分隔符，通常会对它们进行编码。

有编码就会有解码，某些解析器在处理URL前会提前解码特定字符。如果分隔符被提前解码，它就可能被误认为实际的分隔符，从而导致URL路径被截断。

缓存服务器与源服务器在对分隔符的解码行为上可能存在差异，这会导致它们对同一URL路径产生不同解析，即使它们使用相同的字符作为分隔符。以 /profile%23wcd.css 为例（其中 %23 是 # 的URL编码）：

• 源服务器 将 %23 解码为 #。由于它将 # 视为分隔符，因此将路径解析为 /profile，并返回用户资料信息。
• 缓存服务器 同样将 # 作为分隔符，但没有解码 %23。它会将路径解析为 /profile%23wcd.css。如果存在针对 .css 扩展名的缓存规则，它就会存储该响应。

潜在风险：这种解析不一致可能导致缓存污染、安全绕过（如路径遍历），或返回错误的资源内容。【这就是因为：解码时序差异导致的路径解析不一致】

此外，不同缓存服务器的处理先后顺序也可能导致问题：

• 有些会先解码URL再转发请求
• 而另一些则先基于编码后的URL应用缓存规则，然后再解码并转发给后端服务器。

这两种行为同样可能造成缓存服务器与源服务器对URL路径的解析差异。

以 /myaccount%3fwcd.css 为例（%3f 是 ? 的URL编码）：

缓存服务器先基于编码路径 /myaccount%3fwcd.css 应用缓存规则。由于存在针对 .css 扩展名的规则，它决定存储响应。随后将 %3f 解码为 ?，并将重写后的请求转发给源服务器。

源服务器收到请求 /myaccount?wcd.css。由于它将 ? 视为查询字符串分隔符，因此将路径解析为 /myaccount（将 wcd.css 视为查询参数）。

这种先缓存服务器进行解码，然后传输给源服务器进行请求，可能造成的影响：

• 缓存污染：缓存可能存储了与源服务器实际响应不匹配的内容（例如缓存的是 /myaccount 的响应，却用在了对 .css 资源的请求上）。
• 安全风险：攻击者可能利用这种解析差异绕过安全规则或访问未授权资源。
• 功能异常：用户可能收到错误的资源或页面内容。

针对这些情况，系统正确的做法应该是：

• 统一缓存与源服务器的解码逻辑和时机
• 避免在URL路径中使用编码分隔符作为数据
• 实施严格的URL规范化策略
• 对关键路径进行双重验证
• 利用分隔符解码差异进行攻击

除了以上因为解码顺序导致的问题以外，攻击者还可以通过在URL中插入编码的分隔符来制造缓存与源服务器之间的路径解析差异。具体方法是：添加一个静态扩展名（如 .css），使缓存服务器将其视为特定类型的资源（从而应用对应缓存规则），而源服务器却因解码后将其识别为分隔符，导致路径被截断，忽略该扩展名。

测试方法：

沿用识别和利用分隔符差异的常规测试流程，但需扩展测试范围，重点包含以下编码字符：

常见分隔符的编码形式：

• %23 → #（片段标识符）
• %3f → ?（查询字符串起始符）
• %26 → &（查询参数分隔符）
• %3d → =（键值对赋值符）

关键非打印字符的编码（解码后可能截断路径）：

• %00 → 空字符（NULL，C语言字符串终止符）
• %0a → 换行符（LF，可能被解析为行结束）
• %09 → 制表符（TAB，可能被用作分隔符）
• %0d → 回车符（CR）

攻击场景示例：

假设存在针对 .css 文件的缓存规则，攻击者可构造如下请求：

GET /profile%23wcd.css HTTP/1.1

缓存服务器看到 /profile%23wcd.css（符合 .css 规则）并缓存响应。

源服务器解码后得到 /profile#wcd.css，将 # 视为片段分隔符，因此实际路径为 /profile，返回用户资料页面。

结果：用户资料页面被错误地缓存为CSS资源，可能造成敏感信息泄露或缓存投毒。

以上，通过利用源服务器和缓存服务器对分隔符的编码和解码方式、顺序不一致，就可以实现缓存欺骗、投毒的可能性。

于缓存欺骗，合集《缓存欺骗漏洞的原理及相关利用手法》持续更新中，想系统学习、打牢基础的小伙伴们，记得点赞、分享、关注了~

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：升斗安全 升斗安全XiuXiu《“缓存欺骗第四章”分隔符被解码，而且顺序不一样？可以挖掘的漏洞点就在这里了！》