某认证平台未授权注入漏洞的审计

由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，文章作者不为此承担任何责任。

1 漏洞信息

这是某统一身份平台会用的模块，存在一处sql注入，属于针对某些单位的供应商吧.

2 漏洞分析

2.1 漏洞点

其实漏洞点比较好找，在某jar包中找到了SqlService类 indexController中发现了对excuteSql这层路由的处理，找到excuteSql函数

跳转查看update函数，找到未作规避直接带入sql语句的位置 于是就存在了注入，说实话这个点的问题很直观，直观的让我以为是后门

1. publicMap<String,Object> excuteSql(HttpServletRequest request)
2. {
   1. Map<String,Object> result =newHashMap<>();
   2. String sql = request.getParameter("sql");
   3. try{
      1. if(StringUtils.isNotEmpty(sql))
      2. Db.update(sql);
      3. }catch(Exception e){
         1. result.put("result",");
         2. return result;
      4. }
   4. result.put("result", "Ok");
   5. return result;
   6. }
3. }
4. //这里可以很明显看出直接把get请求参数中的sql带入执行了

2.2 绕过

但其实刚刚说过了，这是个统一认证的平台，所以这处路由是不能直接未授权访问的，都会跳转到认证界面 所以接着看filter 先进web.xml中看filter跟servlet，先注意到了一个对认证做校验的servlet，路由是/check/*

为什么先看这个servlet而不是急着查找功能函数呢，因为在WEB-INF的配置文件中对该路由放开了限制 接着去看这个路由对应的Checkclass类

可以看到就是加载了一些基本配置

跟进这个SimpleUrlHandler句柄

这边主要做了个静态资源的配置，这个配置主要是拿来做资源配置确认的，大概就是后缀为suffixs中的对象数组的，不会被跳转或做限制，而是能够直接访问

其中有一处判断用到suffixs数组，是用来判定是否为静态资源的

很明显可以看出，是通过url的后缀判断是否为静态资源，如果为静态资源则跳出判断无需认证，基本可以总结为如下两点

• 存在路由不需经过统一认证
• 该路由的类根据requestURI后缀来做认证判断依据，且静态资源后缀直接跳过

  认证绕过的注入poc基本就出来了，为http://xxx/check/index/execsql;.json?sql=注入语句，利用tomcat对字符的特殊处理能绕过该统一认证的限制，达到未授权执行sql语句的目的

3 末了

有关认证绕过的更多探索更思考，我觉得橙子大佬之前的pdf已经说的很多了，感兴趣可以看看，其实现在对；处理不严导致的问题还是蛮多的。

https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf

原文始发于微信公众号（渗透安全团队）：某认证平台未授权注入漏洞的审计