在 Web 开发的日常实践中，URL 路径中的连续斜杠（//）往往被视为无意义的冗余字符，大多数服务器和框架会将其自动规范化为单个斜杠（/）。然而，这种看似合理的「优化」操作实际上隐藏着严重的语义分裂风险，可能导致安全检查被绕过、访问控制失效，甚至产生路径遍历漏洞。本文将从技术原理、攻击场景和工程实践三个维度，系统性地阐述为何在 HTTP URL 路径处理中不应随意将双斜杠规范化为单斜杠。
RFC 3986 与路径规范化的基本原理
从协议层面来看，RFC 3986 对 URL 路径的语法定义相对宽松。根据该规范，路径段落（path segment）之间由单个斜杠分隔，但连续多个斜杠在语法上是合法的，不会被判定为非法。这意味着 /api//user 与 /api/user 在严格的协议解释下是两个不同的资源标识符。然而，现实中的 Web 服务器、应用程序框架和 CDN 供应商在实现上存在巨大差异：部分组件会在请求进入应用层之前将多个连续斜杠压缩为单斜杠，而另一部分则保留原样。这种处理方式的不一致，正是安全问题的根源所在。
当一个请求经过多层代理（如 CDN → 负载均衡器 → 反向代理 → 应用服务器）时，每一层可能对路径进行不同的规范化处理。假设某攻击者发送请求 //admin//dashboard，如果边缘 CDN 将其规范化为 /admin/dashboard 而应用层仍然认为这是两个独立的路径片段，则可能触发意外的行为。更关键的是，许多应用程序的安全检查逻辑假设输入路径已经被规范化，因此仅在单斜杠版本上施加访问控制，这给了攻击者绕过这些检查的可乘之机。
攻击向量分析：双斜杠如何突破安全防线
双斜杠规范化漏洞的核心攻击逻辑在于利用不同层之间的规范化解码差异。在实际渗透测试中，研究者已经发现了多个可被利用的场景。第一种常见场景是 disabledPaths 绕过：许多 Web 框架提供配置选项来禁用特定的敏感路径，如管理接口或调试端点。如果路由库将 /admin///settings 与 /admin/settings 视为不同路径，而安全检查仅在规范化后的路径上生效，则攻击者可以通过插入额外斜杠来访问本应被禁用的端点。Better Auth 框架的 rou3 依赖库就存在此问题，CVSS 评分高达 8.6，攻击者可借此绕过 disabledPaths 配置并访问受限功能。
第二种攻击场景涉及速率限制绕过。许多 Web 应用基于请求路径实施按路径的速率限制策略，例如限制每秒对 /api/login 的请求次数。如果规范化逻辑不一致，攻击者可以通过变换斜杠数量（如 /api//login、/api///login）来绕过基于路径的限流规则，因为每个变体可能被计为不同的路径，从而分散请求计数。第三种场景与路径遍历防护相关：虽然现代框架普遍对 ../ 等序列保持警惕，但连续斜杠与路径遍历结合时可能产生意外的解析结果，导致安全检查失效。
主流服务器的规范化行为与配置策略
不同的 Web 服务器对多斜杠路径的处理方式存在显著差异，这直接影响到整个请求链路的安全性。Nginx 默认启用 merge_slashes 指令，会自动将多个连续斜杠合并为单斜杠后再进行路由匹配。这意味着在默认配置下，/api//user 会被视为 /api/user。然而，这种合并行为仅作用于 location 匹配层面，不会修改原始请求 URI。如果应用程序依赖原始 URI 进行安全检查，仍然可能受到双斜杠攻击。针对这一问题，推荐在 Nginx 配置中显式设置 merge_slashes off;，并使用 rewrite 规则将规范化操作提前到代理层之前：
server {
merge_slashes off;
# 将所有连续斜杠重定向到单斜杠版本
location ~ // {
rewrite ^//+(.*)$ $1 permanent;
}
}
Apache 服务器的行为则更加依赖配置。在默认情况下，许多 Apache 安装会保留请求路径中的多个斜杠，这与应用框架的处理方式可能产生冲突。建议在 VirtualHost 配置中使用 mod_rewrite 强制规范化：
RewriteCond %{REQUEST_URI} //+
RewriteRule ^(.*)$ $1 [R=301,L]
对于部署在云端的应用程序，还需要特别关注 CDN 和负载均衡器的配置。Cloudflare、AWS CloudFront 等边缘服务通常不会默认折叠斜杠，因此规范化责任完全落在下游服务身上。如果上游边缘节点与下游应用的规范化解码不一致，即使应用层代码完全正确，整个系统仍然存在被绕过的风险。
工程实践：多层防御与监控参数
要在工程实践中有效防御双斜杠规范化带来的安全风险，需要建立多层防御体系。首先是边界层规范化：所有外部请求应在进入内部网络之前在边缘节点完成路径规范化，确保到达应用层的路径已经过统一处理。具体参数建议将 Nginx 的 merge_slashes 设置为 off 并配合 rewrite 规则主动规范化，Apache 启用 mod_rewrite 重定向规则，CDN 层面检查并拒绝包含连续斜杠的请求或将其规范化。
其次是应用层防御：无论边界层是否进行规范化，应用代码都应在处理请求前自行执行路径规范化操作，并将其作为安全检查的前置步骤。建议的工程参数包括：在请求处理管道最早期执行 path.replace(/\/+/g, '/') 规范化；安全检查（访问控制、速率限制等）必须在规范化后的路径上执行；记录所有包含连续斜杠的请求用于审计，阈值设定为每分钟超过 10 次异常请求即触发告警。
第三是监控与检测。建议部署以下监控指标：请求路径中包含连续斜杠的比例（正常情况下应接近零，任何非零值都可能表明存在攻击尝试）；被规范化请求的重定向次数；规范化前后路径不匹配的次数。这些指标应集成到现有的 API 网关或反向代理日志中，便于安全团队进行溯源分析。
总结与实施清单
双斜杠规范化问题的本质是 Web 系统多层架构中信道处理不一致导致的语义分裂。在分布式系统中，请求从边缘到应用层可能经历十余个组件，每个组件都可能以不同方式处理路径中的连续斜杠。攻击者正是利用这种不一致性，在不同层之间寻找「灰色地带」来绕过安全检查。
实施层面建议按以下清单逐步推进：第一，审计现有基础设施（CDN、负载均衡器、Web 服务器、应用框架）对多斜杠路径的处理方式，确认每一层的具体行为；第二，在 Nginx 或 Apache 配置中启用强制规范化，将所有连续斜杠重定向到单斜杠版本；第三，在应用层入口处增加显式规范化逻辑，并将安全检查置于规范化之后；第四，配置监控告警，跟踪包含连续斜杠的请求流量；第五，将依赖库更新到最新版本（如 Better Auth 1.4.5 已修复 rou3 规范化问题）。
通过以上措施，可以在保持协议兼容性的同时，消除因路径规范化不一致引发的安全风险。
资料来源：本文技术细节参考了 Vulert 漏洞数据库中关于 Better Auth rou3 依赖库的双斜杠路径规范化漏洞报告，以及 Nginx 官方文档中关于 merge_slashes 指令的配置说明。