漏洞原理

核心点就是shiro和spring对uri进行配合匹配的时候有缺陷导致的，shiro中很轻易就能绕过，其次spring中对;分号好像情有独钟，被大牛们发现后也就一下子绕过了。
主流payload：/xxx/..;/admin/
具体后台路由不一定是admin，得看情况而定，但是下面的分析都由admin为后台路由进行分析。

源码分析与复现

环境说明：后台路由为/admin
下面我用vulhub开启对应的靶场
在这里插入图片描述
接着访问uri：/xxx/..;/admin
xxx是随便填，而最重要的认证绕过的是..;能够让你走到admin后台，复现成功了。

在该漏洞中，认证过程需要走两个框架，一个是shiro另一个是spring，uri第一个进入的是shiro接着判断完了才交给spring，这个交给spring的时候也出了问题，下面开始讲解过程。
1.shiro中可能会有这样的过滤器对uri进行匹配，分支判断是否需要认证
在这里插入图片描述
这里是配置map.put会出现问题，所以是否出现认证绕过还得看匹配的规则写的如何，这不重要，我们约定配置为：/admin/** 然后该规则下需要authc，表示需要进行身份认证，这看起来很正常，admin路由确实要求身份认证。

2.接着我们下面开始分析当请求http://xxx.xxxx.com/xxx/..;/admin在后台是如何走的：
首先经过shiro处理，直接看最重要的部分，shiro对;分号的处理。
作用：直接匹配59，即;的ascii码值，发现有分号就返回分号前的字段，否则返回整个uri。
那么这里就拿到uri：xxx/..
在这里插入图片描述

3.接下去的函数都是规范化，比如//处理成/这些就不说了，直接看最后给到拦截器判断的requestURI值为/xx/..，pathMatches就会根据拦截器判断是否为/admin/**，那么很显然不是，现在就相当于你bypass掉了shiro的认证。
在这里插入图片描述
4.shiro认证完了就到spring对uri进行认证了
怎么拿到uri就跳过了，主要分析他怎么处理;的即可
最主要跟进removeSemicolonContentInternal(requestUri)方法，他的作用就是：移除uri中/与/之间的的分号以及分号后面的内容。
根据这句话可以得知最后的uri应该是：/xxx/../admin/ == /admin/。
../ 为回到上一层目录，就到admin了，认证绕过结束，收工。