浅谈SpringSecurity与CVE-2023-22602
一、前言
前段时间Apache报告了CVE-2023-22602,由于 1.11.0 及之前版本的 Shiro 只兼容 Spring 的ant-style路径匹配模式(pattern matching),且 2.6 及之后版本的 Spring Boot 将 Spring MVC 处理请求的路径匹配模式从AntPathMatcher更改为了PathPatternParser,当 1.11.0 及之前版本的 Apache Shiro 和 2.6 及之后版本的 Spring Boot 使用不同的路径匹配模式时,攻击者访问可绕过 Shiro 的身份验证。
在Java生态中,还有一个常用的鉴权组件SpringSecurity,其中AntPathRequestMatcher是SpringSecurity中基于Ant风格模式进行匹配的实现类,那么是否也会有类似的问题。查看源码进行简单的分析:
二、相关原理
按照前面的猜想,SpringSecurity某种条件下使用的是AntPathMatcher进行匹配,而高版本的Spring使用的是PathPatternParser,利用解析的差异在某些条件下可能会存在绕过鉴权的风险。
AntPathRequestMatcher是SpringSecurity中基于Ant风格模式进行匹配的实现类。一般使用如下:
protected void configure(HttpSecurity httpSecurity) throws Exception{
httpSecurity.authorizeRequests().antMatchers("/admin/*").authenticated();
}
查看AntPathRequestMatcher以及PathPattern的具体实现:
2.1 AntPathRequestMatcher
主要的匹配在org.springframework.security.web.util.matcher.AntPathRequestMatcher#matches方法中进行。
首先判断请求方法是否一致,然后如果pattern是/**
的话,说明是全路径匹配返回true。否则获取当前请求的url,然后调用当前matcher的matches方法进行进一步的匹配:
首先是当前请求url的获取方法,如果没有配置urlPathHelper的话,则通过请求的ServletPath和PathInfo进行拼接,获取归一化处理后的url,否则调用Spring中的 UrlPathHelper (封装了有很多与URL路径处理有关的方法)的getPathWithinApplication方法(进行了URI解码、移除分号内容并清理斜线等进一步的处理)进行获取:
获取完url后,会调用当前matcher#matches方法进行匹配,从AntPathRequestMatcher的构造器可以看出,这里涉及到两个matcher(SubpathMatcher&SpringAntMatcher):
如果 pattern 的值以 /**
结尾并且不包含路径变量(即通配符{}),会使用SubpathMatcher,否则 matcher 赋值为 SpringAntMatcher 类的对象。
- SubpathMatcher
例如Pattern为/admin/**
,此时会使用SubpathMacher#matches进行解析。具体实现如下:
subpath从前面构造方法的调用可以知道主要是通过切割Pattern得到的(pattern.substring(0, pattern.length() - 3)),例如/admin/**切割后的subPath就是/admin。
首先是统一转换成小写,然后如果请求的path以subpath开头,并且path的长度等于subpath的长度或者subpath长度后第一个字符是/
则返回ture(满足/admin或者/admin/目录的访问方式):
- SpringAntMatcher
例如Pattern为/admin/*,此时会使用SpringAntMatcher#matches进行解析。具体实现如下:
从构造方法可以看出实际上是调用的org.springframework.util.AntPathMatcher#match进行匹配:
核心方法是org.springframework.util.AntPathMatcher#doMatch,首先会调用tokenizePattern()方法将pattern分割成String数组,如果是全路径并且区分大小写,那么就通过简单的字符串检查,看看path是否有潜在匹配的可能,没有的话返回false:
然后调用tokenizePath()方法将需要匹配的path分割成string数组,主要是通过java.util 里面的StringTokenizer来处理字符串:
接着将pathDirs和pattDirs两个数组从左到右开始匹配,这里涉及一些正则的转换还有通配符的匹配。以/admin/*
为例,首先会调用getStringMatcher方法:
这里会调用AntPathStringMatcher的构造方法,实际上就是对Patten里的字符进行正则转换:
这里*
最后会变成.*
:
最后封装java.util.regex.Pattern对象返回:
最后调用matchStrings方法调用java.util.regex.compile#matcher进行匹配:
2.2 PathPattern
Spring Framework的逻辑中,org.springframework.web.servlet.handler.AbstractHandlerMapping#initLookupPath方法中会初始化请求映射的路径,因为高版本默认使用的是PathPattern进行解析,所以会执行this.usesPathPatterns()为true时的逻辑:
以spring-webmvc-5.3.22为例,查看具体的解析过程:
首先从request域中获取PATH_ATTRIBUTE属性的内容,然后使用defaultInstance对象进行处理:
这里会根据removeSemicolonContent的值(默认为true)确定是移除请求URI中的所有分号内容还是只移除jsessionid部分:
这里逻辑会比较简单,缺少一些归一化的处理,例如并不会将//
处理成/
,也没有处理路径穿越。
通过initLookupPath获取到路径后,会调用lookupHandlerMethod方法,根据请求的uri来找到对应的Controller和method。
直接查看PathPattern的核心实现,主要在org.springframework.web.util.pattern.PathPattern#matches方法:
这里根据/将URL拆分成多个PathElement对象,然后根据PathPattern的链式节点中对应的PathElement的matches方法逐个进行匹配。举个例子:
例如Pattern的第一个元素为/的话,会调用SeparatorPathElement的matches方法进行处理,结束后pathIndex++,继续遍历下一个元素进行处理:
除此之外,根据不同Pattern的写法,还有很多PathElement:
- WildcardPathElement(/api/*)
- SingleCharWildcardedPathElement(/api/?)
- WildcardTheRestPathElement(/api/**)
- CaptureVariablePathElement(/api/{param})
- CaptureTheRestPathElement(/api/{*param})
- LiteralPathElement(/api/index)
- RegexPathElement(/api/.*)
三、绕过场景
根据前面的分析,利用解析的差异在某些条件下可能会存在绕过鉴权的风险。
3.1 java.util.regex.Pattern模式差异
对于默认的Pattern模式,不开启DOTALL时候,在默认匹配的时候不会匹配\r \n 字符。
根据前面的分析,AntPathRequestMatcher解析时,会调用AntPathStringMatcher的构造方法对Patten里的字符进行正则转换并封装成java.util.regex.Pattern对象返回,然后跟请求的Path进行匹配。不同版本间是存在差异的。
- spring-core-5.3.21
- spring-core-5.3.22
可以看到,在5.3.22版本之前,Pattern并没有配置dotall模式,从5.3.22版本开始,配置了dotall模式,此时的表达式.
匹配任何字符,包括行结束符。
结合前面的分析,结合实际场景进行Auth Bypass尝试。
假设SpringSecurity配置如下:
protected void configure(HttpSecurity httpSecurity) throws Exception{
httpSecurity.authorizeRequests().antMatchers("/admin/*").authenticated();
}
访问的Controller如下:
@GetMapping("/admin/*")
public String Manage(){
return "manage";
}
正常情况下/admin/page接口应该是需要认证以后才可以访问的:
当使用高版本的Spring时,在进行路由解析时使用的是PathPatternParser。且当这个版本低于5.3.22时,AntPathRequestMatcher是无法匹配行结束符的。
以5.3.21版本的Spring为例,使用\r或者\n(\r的URl编码为%0d,\n的URL编码为%0a)即可绕过当前的鉴权规则:
因为没有启用dotall模式,SpringSecurity匹配/admin/page%0a
会失败,然后转由Spring的PathPattern进行解析,首先是admin字符匹配,当解析到*
时会使用WildcardPathElement进行解析,若没有下一个Element元素的话,只要pathElements的元素个数和PathPattern中的元素个数一致都会返回true,也就是说page%0a跟*
是可以成功匹配的:
利用上述的差异即可达到auth Bypass的效果,当使用spring-core-5.3.22时,因为AntPathRequestMatcher在匹配时启用了dotall模式,此时的表达式.
匹配任何字符,包括行结束符,无法auth Bypass:
同样是上面的SpringSecurity配置,当请求的Controllerr如下,也存在Auth Bypass的问题:
@GetMapping("/admin/{param}")
public String Manage(){
/*return "Manage page";*/
return "manage";
}
当处理{param}
时,PathPattern会使用CaptureVariablePathElement进行处理,因为通配符{}中没有正则,所以这里只需要pathElements的元素个数和PathPattern中的元素个数一致都会返回true:
PS:
- 低版本的Spring使用的是AntPathMatcher,即使绕过了SpringSecurity也会因为解析差异找不到对应的Controller返回404。
- SpringSecurity高版本的StrictHttpFirewall对\r或者\n(\r的URl编码为%0d,\n的URL编码为%0a)进行了拦截处理:
3.2 请求Path归一化差异
根据前面的分析,对于SpringSecurity来说,在获取当前请求url时会对请求的url进行一定的处理,例如/admin/..
最终会处理为/
:
而在Spring Framework的逻辑中,因为高版本默认使用的是PathPattern进行解析,所以会执行this.usesPathPatterns()为true时的逻辑,根据之前的分析,这里会根据主要是对请求URI中的所有分号内容进行处理,判断是移除全部部分还是只移除jsessionid部分,并没有处理编码,路径穿越符等内容:
同样是前面的场景:
假设SpringSecurity配置如下:
@Override
protected void configure(HttpSecurity httpSecurity) throws Exception{
httpSecurity.authorizeRequests().antMatchers("/admin/*").authenticated();
}
访问的Controller如下:
@GetMapping("/admin/*")
public String Manage(){
return "manage";
}
当尝试访问/admin/..
时,AntPathRequestMatcher在处理时会认为当前请求的path是/
,在进行匹配的时候因为请求的path为/
,在isPotentialMatch方法处理时会认为没有潜在匹配的可能返回false:
但是对于PathPattern而言,WildcardPathElement解析时若没有下一个Element元素的话,只要pathElements的元素个数和PathPattern中的元素个数一致都会返回true,也就是说..
跟*
是可以成功匹配的。
同样的,如下的场景也会有绕过的风险:
假设SpringSecurity配置如下:
@Override
protected void configure(HttpSecurity httpSecurity) throws Exception{
httpSecurity.authorizeRequests().antMatchers("/admin/**").authenticated();
}
访问的Controller如下:
@GetMapping("/admin/**")
public String Manage(){
return "manage";
}
如果 pattern 的值以 /**
结尾并且不包含路径变量(即通配符{}),会使用SubpathMatcher。匹配逻辑也比较简单,若请求的path以subpath开头,并且path的长度等于subpath的长度或者subpath长度后第一个字符是/
则返回ture(满足/admin或者/admin/目录的访问方式)。这里/
跟/admin
以及/admin/
明显是不匹配的。
但是PathPattern在解析/admin/**时候,在解析/**时会调用WildcardTheRestPathElement进行处理,因为PathPattern通配符只能定义在尾部(不能以/结尾),所以pathElements的元素个数大于PathPattern中的元素个数即可匹配,所以..
是可以匹配上/**
的,同样的由于SpringSecurity不能解析但是Spring Framework的PathPattern可以解析导致了Auth Bypass问题。
PS:SpringSecurity高版本的StrictHttpFirewall对路径穿越符进行了拦截处理:
四、其他
实际上Spring官方很早就意识到解析差异带来的风险了。SpringSecurity还有一种匹配模式MvcRequestMatcher。
参考https://docs.spring.io/spring-security/reference/servlet/integrations/mvc.html#mvc-requestmatcher
其使用Spring MVC的HandlerMappingIntrospector来匹配路径并提取变量。相比AntPathRequestMatcher会更严谨。在一定程度解决了差异的问题。避免了前面AntPathRequestMatcher的绕过一些问题。
同样是前面的例子,使用MvcRequestMatcher 后无法绕过鉴权逻辑: