描述

Spring Security 在处理安全约束时不考虑 URL 路径参数。 通过向请求添加带有编码“/”的 URL 路径参数，攻击者可能能够绕过安全约束。 此问题的根本原因是 Servlet 规范中对路径参数的处理缺乏明确性（见下文）。 一些 Servlet 容器在为 getPathInfo() 返回的值中包含路径参数，而另一些则不包含。 Spring Security 使用 getPathInfo() 返回的值作为将请求映射到安全约束的过程的一部分。 路径参数的意外存在可能导致约束被绕过。

Apache Tomcat（所有当前版本）的用户不受此漏洞的影响，因为 Tomcat 遵循 Servlet 专家组先前提供的指导，并从 getContextPath()、getServletPath() 和 getPathInfo() [1] 返回的值中删除路径参数。

基于 Apache Tomcat 的其他 Servlet 容器的用户可能会受到影响，具体取决于路径参数的处理是否已修改。

已知 IBM WebSphere Application Server 8.5.x 的用户会受到影响。

实现 Servlet 规范的其他容器的用户可能会受到影响。

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=25015

受影响的 Spring 产品和版本

• Spring Security 3.2.0 - 3.2.9
• Spring Security 4.0.x - 4.1.3
• Spring Security 4.2.0
• 较旧的不受支持的版本也受到影响

缓解措施

采用以下缓解措施之一将防止此漏洞。

• 使用已知不在 getServletPath() 和 getPathInfo() 的返回值中包含路径参数的 Servlet 容器
• 升级到 Spring Security 3.2.10、4.1.4 或 4.2.1 将拒绝请求，如果检测到存在编码的“/”，则会抛出 RequestRejectedException。 注意：如果您希望禁用此功能，可以通过设置 DefaultHttpFirewall.allowUrlEncodedSlash = true 来禁用它。 但是，禁用此功能意味着应用程序容易受到攻击（在使用 getServletPath() 或 getPathInfo() 返回路径参数的容器中）。

致谢

此问题由 NTT DATA Corporation 的 Shumpei Asahara 和 Yuji Ito 发现，并负责任地报告给 Pivotal。

参考文献

• http://www.securityfocus.com/archive/1/archive/1/514517/100/0/threaded
• https://github.com/spring-projects/spring-security/issues/4169

历史记录

2016-12-28：发布初始漏洞报告