Java代码审计，高手就是这样“硬看”的

   

前言

本文作者是360特邀讲师，每月开讲一堂代码审计课，曾在2017年中国互联网安全大会上作为白帽大咖的嘉宾身份参加并在沙龙上担当讲师。在补天众测平台上，他有一个响当当的ID：jkgh006。接下来我们来看看高手是如何通过“硬看”来进行代码安全审计的。

                                                                                           

      大多数人问我是怎么看代码并且在没有本地环境的情况下审计出来漏洞的，我一般都是两个字 “硬看”，今天我们要说的就是怎么在几百M甚至上G的程序中剥茧抽丝，审计出来我们希望的结果。

       首先查看web.xml,看看全局的配置以及路由，这个非常重要；

     这里是一个全局的filter，按照开发者的习惯来说，一般都是做一些登录验证或者授权之类的东西。继续跟进

这里可以看出来系统只接收GET和POST的请求，重点看webServiceCheck请求的内容

看到这个我们就明白了，采用的是黑白名单的形式决定是否校验登录

这几类都不会进行登录校验

通过全局的分析，有以下可以利用的两个path，分别为/login/ 和 /ycsbBjWss/

继续再分析web.xml

可以看到这个是一个webservice的请求，我们访问一下某网站看看

还是有很多接口可以利用的，看看最后一个接口

这里调用的就是auth，直接跟进分析看看

我们分析一下这个xmltobean

在解析xmlSource的时候

这里没有进行实体禁用，存在一个xxe，当然了这个不是我们这次关心的内容

重点看看这个xmlTobean，很多人看到这个的时候就放弃了，因为太复杂，跳来跳去，但是要继续往下走还必须得了解这个的逻辑，通常这里的做法是不用去读懂它干什么，可以自己写一个test，然后去跑这一段代码，前提是要删除掉web上下文的东西。

此时你就可以调试代码了，这里就不操作了，直接解释一下这段代码的逻辑，意思就是把你传递进来的xml中的内容通过xpath解析出来，然后通过BeanUtils.populate(model,var18),把var18里面对应的键值对赋给model对象的属性。

这个xml的结构可以看出来

里面分为两大部分，大家都知道java里面的变量定义是区分大小写的，所以它这里在Head里面定义的会被转化为小写，然后拼接一个H就是类的属性，例如

到时候就会在model对象里面，如果它存在abcH属性，这个值就会被赋为123，我们看看model的基类属性都有那些

其中框起来的这些比较特殊，属性本身存在大小写，根据它代码的意思，比如nsrdjNoH我们只需要写123

       头部的语法已经完全解开，剩下的就是body里面的语法，body是不做任何转换的，基本上你写什么到时候就是什么，继续跟进程序逻辑

       checkMethod 校验头部里面是否包含method， 对应到xml里面就是123

       继续往下走看看service.check(model),这里就是进行了每一个参数的校验

我们调用的是YcsbWebService，所以选择下面那个

这里面就是对xml头部的校验，缺少一项都不可以。

函数有以下几个

1. checkCpcode()         不为空即可

2. checkMethod()         不为空即可

3. checkTranToken()      

4. checkConf()            内置校验不用关心

5. loginForm()        

6. checkCpcodeWhitelist()  内置校验不用关心

7. checkLegalCpcode()     内置校验不用关心

重点分析第三个和第五个

分析可以看出这个是可以绕过的，因为没有秘钥，但是这个类似于请求的token有一个超时的限制，从代码中可以看出来，肯定会有加密部分

直接都不用分析，写入test即可根据CpcodeP加密出来一个token

这里是一个登陆的验证，通过上下文分析，这里采用map映射方式查询数据库，只要这个通过即可以

这里可以看出来，没有密码的限制，其实对于这个应用来说，cpcode就是税号，天眼查是可以查到的，等于再次绕过

InnerStrategyService service = StrategyFactory.getInstance().creator(model.getMethodpre(), StrategyFtConst.YCSB.fact);

这一段代码要依赖web上下文，所以只能硬看，跟进分析一下

这里可以看出来所有的对应关系，继续往下分析

ex1 = service.execute(model);

跟我们分析的映射关系一模一样

此时所有的校验都通过，流程从一个小水管慢慢变成一片开阔地，各种各样的接口从而暴露出来，我们主要分析一下这个YcsbWbxxServiceImpl

当method为WBXX_FP_CZ_LIST的时候

看到这里进行了一次复杂的解析，通过读上下文，没有web上下依赖，直接代码调试并且我们打印出来customViewSQLStr

这里就输出来一个sql语句，其中可以进行拼接，对应的xml为

我们访问一下看看

返回的东西居然是加密的，这个不用怕，相信解密的东西也能找到

回头再看看

最终输出的时候进行了加密，zKey就是秘钥，所有代码都是写死的，所以加解密其实没有什么意义，看看有没有解密的代码

直接test调试一下

这个就是我们刚才说的那个token失效了，重新做一个，去天眼查找一个税号，例如

91**********087

然后再次请求

这时候响应的内容已经发生了变化，我们解开看看

说明整个验证过程已经通过了，分析到这里，至于怎么构造SQL造成注入就不再做分析。

本文来源：杭州敏信科技有限公司

公众号内回复“1”带你进粉丝群