描述

Spring Security 在处理安全约束时未考虑 URL 路径参数。通过在请求中添加带有编码"/"的 URL 路径参数，攻击者可能会绕过安全约束。此问题的根本原因是 Servlet 规范中关于如何处理路径参数的说明不够清晰（见下文）。一些 Servlet 容器会将路径参数包含在 getPathInfo() 返回的值中，而另一些则不会。Spring Security 使用 getPathInfo() 的返回值来映射请求到安全约束。路径参数的出人意料的存在可能导致约束被绕过。

Apache Tomcat 的用户（所有当前版本）不受此漏洞的影响，因为 Tomcat 遵循 Servlet Expert Group 此前提供的指导，并从 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：发布初始漏洞报告