| 关键词: 使用 语句 可以 我们 注入 传入 Mingsoft 代码 SQL 直接 |
0x00 前言MCMS是政府、教育等其他行业常用的CMS,应用广泛,但是底层的代码中仍然遗留不少的问题。这篇文章主要针对SQL注入进行审计并探讨如何快速定位SQL注入漏洞,以及其他工具的应用。
0x01 审计环境0x02 审计思路现代做代码审计的工具市面上已经有很多了,在拿到源码的时候,第一时间当然是先使用工具进行扫描,节省人工时间。尽管有fortify、奇安信代码卫士这些工具在,但避免不一些纰漏,仍然需要人工经验的判断。 利用自动化代码审计工具这里我们使用 fortify 工具对源码进行扫描,记录了我遇到的两个问题。该 fortify 工具为收费工具,本文不提供破解版的下载方式。 1.反编译 jar 包使用 fortify 导入MCMS 源码进行代码审计,但效果往往不如意。因为这一套源码使用 Maven 作为项目管理工具软件,其中包括依赖管理,MCMS项目依赖的jar包都是远程拉取的。其中net.mingsoft.ms-base、ms-basic、ms-mdiy为底层逻辑代码。拉取的时候是以jar包的形式存在的,而自动化工具不会对jar包进行扫描。 我们可以将 jar 包重命名为 zip,然后解压就能获得 class 文件。但 fortify 同样不会扫描 class 文件,我们需要进一步反编译。这里我们可以使用 jadx 进行反编译。 我们可以直接打开 jar 文件,通过快捷键 Control+S 将反编译后的资源进行保存。 导出之后就是 java 文件,是可以被扫描的文件类型。 2.不扫描 JS 文件在扫描代码的实践中,我遇到 JS 文件数量过多情况,导致整体的扫描进度大幅度拉长,这不是我想要的。 其中 人工审计SQL注入思路造成SQL注入一般需要满足以下两个条件: 0x03 审计过程由上面的描述可以知道使用 ${}的地方往往可能存在SQL注入风险,所以我们审计过程中可以直接全局搜索${}。 1. 底层映射存在注入漏洞引发多个前台注入原因在SQL持久化层 IBaseDao.xml 文件中可以看到绑定id 为 sqlWhere 的 Sql 映射里使用了 ${} 导致存在SQL注入的风险。 第一处 GET类型在 IDictDao.xml 中引入 IBaseDao.xml 映射语句。 在 IDictBiz 这个业务层是继承了 IBaseBiz 从而有 query 确定返回类型为 DictEntity。 在控制层 web/DictAction.class 中可以看到这里请求数据包的数据变成了实体,然后直接传入 dictBiz.query 中。 我们请求这个接口时,所有传入的参数与值会别当作 DictEntity,所以这里直接传 sqlWhere 即可。 第二处 GET 类型在 IDictDao.xml 中引入 IBaseDao.xml 映射语句。id 为 queryExcludeApp。 在控制层 web/DictAction.class 中可以看到这里请求数据包的数据变成了实体,然后直接传入 dictBiz.queryExcludeApp中。 同样的这里所有传入的参数与值会别当作 DictEntity,存在同样的问题。 第三处 POST类型在 ICategoryDao.xml 中引入 IBaseDao.xml 映射语句。 在控制层 web/CategoryAction.java 中可以看到这里请求数据包的数据变成了实体,然后直接传入categoryBiz.query 中。 这里的实体类型有了变化,但不妨碍我们传入 sqlWhere导致漏洞的执行。 第四处 POST类型在 IContentDao.xml 中引入 IBaseDao.xml 映射语句。 |
|
声明:文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|