代码审计之某高校通用系统getRequsetURI函数的三次鉴权绕过

前言：

写个随笔，写个代码审计的漏洞案例，该系统为大量高校使用的一个系统。
三次绕过。

正文：

如图所见，系统厂商采用的是利用过滤器的写法进行鉴权

第一次的校验代码：

即requestURI转为小写后，后缀只要不为jpg gif png swf html htm js这些后缀即进行鉴权。

且代码requestURI=httpServletRequest.getRequestURI();
该函数由于tomcat+requestURI的特性问题，会导致默认处理时 …/ ; ./以及其的编码造成权限绕过。

这里因此我们能构造的bypass的方法即可
/（鉴权路由）index.do;.jpg或 （鉴权路由）index.do;.htm等后缀方式进行绕过。

第二次的校验代码：

有图可见，厂商修复了利用仅仅用ends后缀判断是否存在进行做权限判断，然后采用利用判断是否包含/js/ /css和/assets 来进行权限判断

这个地方忽略了一个js/…/鉴权路由这种攻击手法，造成第二次绕过。

第三次鉴权绕过：

代码没找到了，大概的原因就是 开发者考虑到了
/…/ 目录穿透符的问题
对这些目录跳跃的做了一个过滤，导致没办法在通过上面的穿透的思路去绕掉鉴权。

但是却忽略了indexof(“es5”)这串代码的问题，即包含es5即可filter掉
即if(path.indexOf(“es5”))即绕过

因此攻击者可以利用
鉴权路由;es5去进行再次绕掉鉴权
实现再次权限绕过。

走到这里后自此，该路由的权限绕过问题彻底解决，彻彻底底无法再次绕过。

后言：

细化挖掘，谁说开发修复漏洞后该漏洞就一定不会存在了呢？
具体情况具体分析才是正解。