文章总结： 文章介绍了Web缓存欺骗漏洞中的一种特殊情况，即分隔符差异导致的漏洞。当缓存服务器与源服务器对URL中的分隔符(如分号;)有不同解释时，可能导致缓存服务器错误地将敏感信息(如用户资料)缓存为静态资源(如CSS文件)。文章以JavaSpring框架为例，详细解释了漏洞成因、攻击步骤和利用方式。建议开发人员了解不同框架对URL解析的差异，并配置适当的缓存规则以防止此类漏洞。 综合评分： 86 文章分类： WEB安全,漏洞分析,渗透测试,安全建设,应用安全

“缓存欺骗第三章第四节”缓存规则中的另一个特殊规则–分隔符差异

原创

升斗安全XiuXiu

升斗安全

2025年12月19日 18:35 广东

【文章说明】

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

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

分隔符用于界定URL中不同元素的边界。字符和字符串作为分隔符的使用通常是标准化的。例如，? 通常用于分隔URL路径和查询字符串。然而，由于URL规范（RFC）较为宽松，不同框架或技术之间仍存在差异。

缓存服务器与源服务器在将字符或字符串用作分隔符时的差异可能导致Web缓存欺骗漏洞。以 /profile;foo.css 为例：

Java Spring框架将 ; 视为添加矩阵变量的参数分隔符。因此，使用Java Spring的源服务器会将 ; 解析为分隔符，截取 /profile 之后的部分，并返回用户资料信息。【就是相当于只请求 /profile 后面的内容直接忽略】

大多数其他框架并不将 ; 视为分隔符。因此，未使用Java Spring的缓存服务器很可能将 ; 及其后的所有内容视为路径的一部分。若缓存规则要求存储以 .css 结尾的请求响应，则它可能将用户资料信息当作CSS文件缓存并提供。

以上简短内容中，其实包含了较多基础的技术原理，我们继续来拆解下以上内容：

1.Web如何处理URL？

URL的结构看似简单，但不同组件（Web服务器、应用框架、反向代理、缓存服务器）对其解析方式可能存在差异。这主要源于两个关键点：

分层解析模型：一个HTTP请求从客户端发出到被应用处理，会经过多层组件（如CDN/缓存层 -> 负载均衡器 -> Web服务器 -> 应用框架）。每一层都可能根据自己的规则解析URL，来决定请求的路由、缓存或处理逻辑。

RFC的“灵活性”：URI规范（RFC 3986）定义了诸如;、?、&、# 等字符，但它也允许应用层对部分字符（尤其是;）进行语义重定义。这为框架的特定行为（如Spring的矩阵变量）留出了空间。

2. 漏洞成因：不一致性如何产生？

漏洞的核心是 “解析不一致” 。我们以 /profile;foo.css 这个经典示例来分解：

步骤一：攻击者诱导用户访问恶意URL

攻击者通过社交工程等方式，诱使已登录的用户访问一个精心构造的URL，例如：

https://example.com/profile;foo.css

或嵌入在一个可信域中的链接。

步骤二：各层组件的“分歧”

步骤三：漏洞触发

用户请求发出后，源服务器（Spring应用）返回了敏感的个人资料页面内容。

缓存层看到这个响应是对一个“.css文件”请求的200 OK响应，便将其存入缓存，缓存键可能就是 /profile;foo.css。

此时，攻击者直接访问 https://example.com/profile;foo.css。

请求到达缓存层，缓存层发现存在匹配的缓存条目，于是直接将之前缓存的用户敏感信息返回给攻击者，而请求根本不会到达源服务器。

合集《缓存欺骗漏洞的原理及相关利用手法》系列内容持续更新中，感兴趣的小伙伴们，别忘了收藏、点赞、分享、关注

查看原文：《“缓存欺骗第三章第四节”缓存规则中的另一个特殊规则–分隔符差异》