之前致远爆了关于ajax.do的权限绕过漏洞，虽然看网上和官方都说是由于shiro的权限认证绕过导致的，但是我并没有在代码中找到致远使用shiro进行权限认证的相关代码，所以想深入分析下致远会产生权限绕过漏洞。还是以解决问题的方式来分析这个漏洞吧。
致远请求ajax.do的流程是怎样的？
根据web.xml中的配置，当我们请求*.do会进入到SecurityFilter过滤器，这也是致远的核心过滤器。
这个过滤器中会对多种url请求做处理，我们访问ajax.do会经过SpringControllerAuthenticator的认证。
在com.seeyon.ctp.common.web.filter.SpringControllerAuthenticator#authenticate中，当通过session中没有获取到用户信息，会进行一个关键的处理，这个处理是由isNeedlessCheckLogin做的，主要是判断用户访问的url是否在白名单中，如果在则通过认证。
在isNeedlessCheckLogin中首先判断是否访问ajax.do，如果是则通过managerName参数来判断是否在白名单，在needless_check_login.xml中配置了白名单，如果请求url在白名单中，则再去判断method是否在白名单中，如果配置中的methods包含*则任意method均可访问。
假如通过了白名单认证，后面还会判断是否为ajax.do请求，如果是还要再经过一次认证。
这层检测会检测managerName参数是否在白名单中，当不在白名单中，会再调用validateResource进行检测。
这里也有一个白名单，显然之前用的payload是没有在这个白名单中的，这里也可以通过调试看到这里抛出了异常。
主要的问题是com.seeyon.ctp.common.web.filter.CTPSecurityFilter#doFilter中catch了这个异常并且程序继续以accept为ture执行后面的过滤器。所以这套程序对于ajax.do中白名单是无效的，我觉得这也是致远权限绕过的关键。
致远绕过权限认证后为什么还能匹配到/ajax.do?
我们看下请求绕过的payload,通过之前的分析，由于autoinstall.do在白名单中，并且它的method为*,所以可以绕过filter的认证。
1 | /seeyon/autoinstall.do/../ajax.do?method=ajaxAction&managerName=formulaManager&requestCompress=gzip |
虽然这里绕过了filter的认证，但是是在哪一步对/seeyon/autoinstall.do/../ajax.do处理为/ajax.do的呢？根据之前shiro权限认证绕过的经验，大概可以确定在spring中会decodeAndCleanUriString会对url进行处理。但是这里也仅仅移除了;到/之间的内容，并没有对uri进行处理。
在继续追代码发现org.springframework.web.util.UrlPathHelper#getPathWithinServletMapping中经过org.springframework.web.util.UrlPathHelper#getServletPath处理后url发生了变化。
而request.getServletPath();是tomcat中的方法，经过这个方法处理后会得到去除../后的url。
这里可以用./来进行验证。
所以可以得出结论，这个问题是spring和tomcat组合产生的，它可以接收/xxxx/../xxx.do之类的请求并在最终请求是转换为xxx.do。
这种绕过适用于什么场景？
通过上面的分析我们已经了解了这个漏洞形成的原理，当然想利用该漏洞中的技巧挖掘其他产品的漏洞。
1 | 1. 使用了spring技术 |