Spring + Jetty 场景下越权分析

前言

环境搭建

package com.example.jettytest.Config;

import com.example.jettytest.Filter.TestFilter;
import org.springframework.boot.web.servlet.DelegatingFilterProxyRegistrationBean;
import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.boot.web.servlet.ServletRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class FilterConfig {

    @Bean
    public TestFilter testFilter(){
        return new TestFilter();
    }
    
    @Bean
    public FilterRegistrationBean registrationBean(){
        FilterRegistrationBean bean = new FilterRegistrationBean();
        bean.setFilter(testFilter());
        bean.addUrlPatterns("/portals/resume/*");
        bean.setName("testjetty");
        bean.setOrder(1);
        return bean;
    }

}

流程分析

1. jetty对filter的处理上

2. Spring对路由的处理上

深入分析

jetty对filter的处理

从filter处理入口分析 ，在org.eclipse.jetty.servlet.ServletHandler#doHandle 会初始化相关的filterchain，此外，在jetty启动服务的时候，会直接将全局的所有filter以及对应的url mapping内容存放在_filterMappings 这个变量中，后续初始化filterchain会根据这个变量进行处理

通过getFilterChain 函数去确定当前路由所需要的filterchain，jetty处理filter的关键点就在于org.eclipse.jetty.servlet.ServletHandler#getFilterChain ，这个过程中，jetty会对处理过的路由做一次缓存，缓存的filterchain内容会放在_chainCache 变量中，这是一个Map类型的变量，后续只要是重复出现的路由都会使用这个Map去匹配key，快速返回对应的filterchain

如果不存在缓存就会迭代所有的_filterMappings ，然后会把所有路由能够匹配上的filter添加到filters里面，也就是生成这个对应路由的filterchain了，这个也是jetty处理filter路由的关键了，此时会走这样一个流程，org.eclipse.jetty.servlet.FilterMapping#appliesTo(java.lang.String, int) —>org.eclipse.jetty.http.PathMap#match(java.lang.String, java.lang.String, boolean) —>org.eclipse.jetty.http.PathMap#isPathWildcardMatch —> java.lang.String#regionMatches(int, java.lang.String, int, int)

最后在java.lang.String#regionMatches(int, java.lang.String, int, int)函数进行具体的匹配，可以在这里分析为什么//这样的payload是可以绕过的

一开始filter对应的Mapping是/portals/resume/* ，处理之前会先把/* 删除掉，剩下/portals/resume ，以这个字符的长度再去与输入的路由/portals//resume/get进行比较，一旦出现不一样的的字符就会认为这个当前的filter这个路由不匹配

所以可以得出一个结论，只要这个filter的路由通配符之前的内容有一点点不一样都不会把相关的filter放进filterchain里面，也就不会进行相关的filter检测

 

 

 

Spring对路由的处理

从 org.springframework.web.servlet.DispatcherServlet#doDispatch 入口分析，相关的请求会进入到org.springframework.web.servlet.DispatcherServlet#getHandler 最后会进入到org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#getHandlerInternal

在getHandlerInternal函数中有一个lookupHandlerMethod 方法，是Spring处理路由的关键方法，可以分析这个函数，去了解Spring的路由解析的原理

该方法首先会寻找是否存在对应的路由，在this.mappingRegistry 里面加载了项目里面所有路由，触发org.springframework.web.servlet.handler.AbstractHandlerMethodMapping.MappingRegistry#getMappingsByUrl 函数，以输入的/portals//resume/get为例，一开始是找不到对应的路由在这里面的，所以directPathMatches 返回了null，所以会进入到matches.isEmpty() 的判断分支，在这个分支里面遍历所有路由进行具体路由解析操作，会把适合/portals//resume/get 的路由匹配出来，代码的注释也很清楚了// No choice but to go through all mappings...

后续跟进到org.springframework.web.servlet.mvc.method.RequestMappingInfo#getMatchingCondition ，会在这一处地方进行具体路由的正则匹配

继续往下跟，跟进到org.springframework.util.AntPathMatcher#doMatch ，在这里可以观察到是如何进行路由解析的，对应的匹配的路由/portals/resume/get 会被分割成["portals", "resume", "get"]，而输入的路由/portals//resume/get 也会被分割成["portals", "resume", "get"] ，然后再对这个数组内容进行相应的判断，最后返回是否匹配，可以看到代码里面关键处理path的地方在tokenize 的相关操作

跟进tokenize 相关函数并进行分析，其实本质上的功能就是以/进行分割 ，并取到内容不为空的作为判断的列表内容

所以根据分析结果，绕过的payload其实可以在中间添加上无数的斜杠也能打

 

思路扩展

/portals/;/resume/get
/portals/;xxxxxxx/resume/get     #这里的xxxx代表任意字符
/portals/;/;/resume/get
/portals/;xxxx/;xxxxx/resume/get
/portals/abc/..//resume/get
/portals/abc/haha/../..//resume/get
/portals//abc/../resume/get
portals//abc/../;xxx/./resume/get
/portals/.//resume/get
/portals/%2f%2f/resume/get
/portals/%2f%2f/;xxxxxxx/resume/get

高版本测试

总结