MCMS5.2.8后台SQL代码审计

本篇只对MCMS5.2.8后台SQL代码审计复现做一个记录。

一，审计工作准备

配置好数据库，直接运行MSApplication的main函数

二，白盒审计

查看官网的cms的框架使用情况，mcms使用的SQL框架是mybatis框架

mybatis拼接SQL语句的特性是使用$进行拼接

因为使用了mybatis框架这里就全局搜使用$进行拼接的

（1）从下往上追溯

发现在

/net/mingsoft/ms-base/2.1.13/ms-base-2.1.13.jar!/net/mingsoft/base/dao/IBaseDao.xml

进一步跟进queryBySQL

查看对应接口中的实现方法

然后在/net/mingsoft/base/biz/impl/BaseBizImpl.java这里进行了重写queryBySQL，然后调用getDao().queryBySQL

然后发现在/net/mingsoft/basic/action/BaseAction.class#validated 验证的时候进行调用

父类validated方法的处理逻辑

validated方法中新建了一个HashMap，然后将字段名filedName和字段值filedValue以键值对的格式加进了map中。然后调用了appBiz.queryBySql方法。

继续跟，这时候只要找到前端路由中能调用validated就可以了，然后发现在/net/mingsoft/ms-mdiy/2.1.13.1/ms-mdiy-2.1.13.1-sources.jar!/net/mingsoft/mdiy/action/PageAction.java#verify

调用了validated方法

从源码中发现，在调用vertify方法时传入了String fieldName/String fieldValue/String id/String idName这四个参数。然后调用了父类的validated方法。

总结：原因就是效验参数时没有对参数进行过滤，到时能够SQL注入

（2）从上往下追溯

打断点调试查看传参过程：

访问传参url：http://127.0.0.1:8080/ms/mdiy/page/verify.do?fieldName=11111&fieldValue=b&id=c&idName=1

用户传参会到verify的四个参数里面

进行布尔判断：

如果verify = false就进如if

如果verify ！= false就进如else

三，黑盒验证

漏洞复现

这里寻找路由，通过分析我们这个是个GetMapping 然后参数fieldName、fieldValue、id、idName 随便构造一下，最开始我们看到的key对应的就是前端传进来的fieldName

注入点是fieldName

http://127.0.0.1:8080/ms/mdiy/page/verify.do?fieldName=11111&fieldValue=b&id=c&idName=1

SQL延迟注入：http://127.0.0.1:8080/ms/mdiy/page/verify.do？fieldName=1;select/**/if(substring((select/**/database()),1,4)='mcms',sleep(5),1)/**/and/**/1&fieldValue=b&id=c&idName=1

成功返回延迟五秒确定存在SQL注入

四，漏洞修复

时间盲注（延迟注入）

时间盲注又称延迟注入，个人理解，适用于页面不会返回错误信息，只会回显一种界面，其主要特征是利用sleep函数，制造时间延迟，由回显时间来判断是否报错。

官方理解：利用sleep()或benchmark()等函数让mysql执行时间变长经常与if(expr1,expr2,expr3)语句结合使用，通过页面的响应时间来判断条件是否正确。if(expr1,expr2,expr3)含义是如果expr1是True,则返回expr2,否则返回expr3。

个人觉得还是对用户可控的参数做个全局过滤防止参数可控，如黑白名单，预编译如果在某种情况下需要使用拼接那么最好在此处添加过滤和黑白限制。

总结：本文对该漏洞进行复现并且将代码审计的流程进行记录，可以很清楚的看到审计SQL注入的点无非就是找到爆发点-》是否有过滤参数-》是否做了预编译。