在控制层 web/ContentAction.java 中可以看到这里请求数据包的数据变成了实体，然后直接传入contentBiz.query 中。

只要引入之后，如果没有过滤都是存在漏洞的。

2. 后台自定义模型任意SQL语句执行

在持久化层 IBaseDao.xml 中存在一处绑定了 id 为 excuteSql 的 SQL 操作语句。该地方直接执行了传入 SQL 语句。

持久化层代理 IBaseDao.class 写好了对应 IBaseDao.xml 的接口

IModelDao.class 继承了 IBaseDao 确定了类型为 ModelEntity

业务层 IModelBiz.class 定义了一些接口

业务实现层 ModelBizImpl.class 实现了 IModelBiz.class 接口，通过阅读代码，可以发现实际上在 importModel 函数里面使用了 IModelDao.class 中的 excuteSql 方法。

在控制层 ModelAction.class 中 importJson 函数里调用了 ModelBizImpl.class 的 importModel 函数。

该漏洞产生位置存在后台自定义模型的导入功能处，要使用该功能需要到
https://code.mingsoft.net/ 生成代码。

新建业务表单 ——> 拖动表单组件 ——> 填写字段名和默认值 ——> 生成代码

可以看到生成的自定义模型代码，我们复制出来将 sql 字段的 value 改成我们自定义的即可。

任意都行没有过滤和限制，语句的行是通过 split(';')来分割的。

这个其实是MCMS的核心业务，无法避免的使用，所以只要使用 MCMS 拥有自定义模型的导入功能的权限就可以利用SQL注入获取数据或者系统权限。

3.校验参数接口前台SQL注入

因为使用了 mybatis 框架这里就全局搜使用 $ 进行拼接的，发现在
/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就可以了，然后发现在
/net/mingsoft/ms-mdiy/2.1.13.1/ms-mdiy-2.1.13.1-sources.jar!/net/mingsoft/mdiy/action/PageAction.java#verify
调用了validated方法

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

http://127.0.0.1:8008/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
fieldName`是传入了 `${key}直接拼接到SQL语句导致SQL注入。

0x04 总结

代码审计论证了预编译不是万能的，否则不会出现这么多的 SQL 注入漏洞。在不能使用预编译处理参数值，只能通过拼接进行操作的地方，除了手工写过匹配危险字符滤函数之外还有什么方法吗？我们还可以严格要求传入的参数类型，例如数字的地方将用户输入的内容进行强制转化成 int 不行就报错处理，这种称之为表单过滤层。如果我们的代码体积庞大无法花费大量人力去排查漏洞存在，可以购买安全公司的代码审计服务和WAF防火墙产品。

0x05 参考

*   [https://gitee.com/mingSoft/MCMS/issues/I5OWGU](https://gitee.com/mingSoft/MCMS/issues/I5OWGU)
*   [https://gitee.com/mingSoft/MCMS/issues/I5X1U2](https://gitee.com/mingSoft/MCMS/