描述

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：发布初始漏洞报告