CVE-2016-5007：Spring Security / MVC Path Matching Inconsistency

概要

编辑：Spring by Pivotal

产品名称：Spring Web + Spring Security / Spring Boot

标题：Spring Security / MVC Path Matching Inconsistency

CVE ID： CVE-2016-5007

Intrinsec ID：ISEC-V2016-01

风险级别：中

漏洞利用：远程

影响：请求授权绕过

描述

此漏洞影响的Spring Web和Spring Security使用HttpSecurity.authorizeRequests用于URL访问控制的应用。

Spring提供了Spring Security一个使用文档：

http://docs.spring.io/spring-security/site/docs/current/reference/html/jc.html#authorize-requests

protected void configure(HttpSecurity http) throws Exception {

http.authorizeRequests()

.antMatchers("/resources/**", "/signup", "/about").permitAll()

.antMatchers("/admin/**").hasRole("ADMIN")

.antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")

.anyRequest().authenticated()

.and()

// ...

.formLogin();

}

在以下示例中，用户"User"不是管理员，并且无法访问"/admin/"管理目录：

但是，如果在URL中将空格(或其他空格字符)附加到"admin"前后，可以轻易绕过安全过滤器。

附加空格(由浏览器自动编码为"%20")：

%0D前置：

问题是使用不同的匹配器来实现访问控制，并且识别哪个控制器类应该处理请求。用于访问控制的第一个匹配器是严格的："admin "被认为不同于"admin"：

然而，用于找到适当的控制器的第二匹配器应用删除每个URL令牌之前和之后的空白的修剪操作，因此"admin"变为"admin"：

总之：访问控制匹配器不识别受保护的路径，因此应用默认的“允许”规则，而控制器查找器匹配器找到受保护的控制器。

两个匹配器之间的严格性不匹配导致了这种情况。

这个漏洞危害性高低与否取决越权查看页面后查询数据的时候是否有校验当前用户的session。

版本受影响

Spring Security 3.2.x，4.0.x，4.1.0

Spring框架3.2.x，4.0.x，4.1.x，4.2.x

其他不受支持的版本也会受到影响

解决方案

Spring Security提供了可以将模式匹配委派给Spring框架的URL授权，要利用这个选项，应用程序应该升级到Spring Security 4.1.1+和Spring Framework 4.3.1+并使用MvcRequestMatcher。

Spring Framework 3.2.x，4.0.x，4.1.x，4.2.x的用户可以使用MVC Java配置或MVC命名空间将AntPathMatcher的trimTokens属性设置为“false”。

此外，应用程序应该总是使用Spring Security的一种机制(例如添加@Secured注释)，在应用程序的业务层使用额外的授权来补充基于URL的授权。

分享一个两年前的测试案例

目标是基于拦截器的访问控制，但是系统做拦截判断的时候是采用完全匹配模式校验，所以可以轻易绕过。

http://xxx.com:8000/security/security!admin.action --blocking

http://xxx.com:8000////security/security!admin.action --bypass

简单总结下这个两个漏洞产生的原因

第一个案例的问题问题出现在第二个规则检测前的数据处理工作,do_work(a)的时候已经不知道do_check(a)是什么内容了!这里能做什么?只能保证保持输入a不变，能做事就做，做不了就反馈错误!此类问题绝非个案，平时代码审计可以多加关注。