【JAVA代码审计】从零开始的Mybatis框架SQL注入审计(下)

上期说到 Mybatis 的数据库执行操作都存在 Mapper 文件中 ， 因此我们主要是在 Mapper 文件中进行漏洞挖掘 。

Mapper 文件基本格式如下 ：

以下图为例 ：

（1） id 对应 Dao 接口中相应的方法名 。

（2） parameterType 为接收参数的类型 。

（3）${} 处则用于接收参数的值 。

在 Mybatis 框架中， 接收 参数有两种方式：

(1) 通过 $ {param} 方式 ，拼接的方式构造 SQL 。

(2) 通过 # {param} 方式，会自动使用 ? 作为占位符，通过 预编译 的方式构造 SQL 。

因此我们挖掘的重心就放在不会预编译的 $ 符上了 ， 需要满足 2 个基本条件 ：

（1） $ 符接收的参数需要为用户可控 。

（2） $ 符接收的参数类型需要为字符型 ， 如 String型 。

// 假如为 int 等数字型 ， 即使参数可控 ， 但在尝试注入时 ， 拼接上其他语句 JAVA 会语法报错 。

当我们找到满足上述条件的注入点后 ， 只需要一步一步往上追溯 ， 看是否存在安全过滤 ， 并最终确定访问 URL 即可 。

下面一起来看几个案例吧 。

全局搜索 ${ value } ， 我们可以找到以下 Mapper 文件 ：

// 使用 ${} 符，不会对 参数 进行预编译等处理。

先来看 ArticleMapper.xml ， 删除文章和文章内容处均可能存在注入 ：

// 更新文章内容使用 # 号 ， 则不存在

deleteArticleByIds ， deleteArticleContentByArticleIds 方法可能存在问题。

根据 Article Mapper 命名规则 ， 这两个方法存在于接口 Article Dao 中：

// 找不到可以直接全局搜索 deleteArticleByIds

接口 对应 的 实现类 ArticleDaoImpl ：

往上 追溯可发现 ArticleServiceImpl 类 的 deleteArticleByIds 方法 ， 调用了 articleDao 接口的 这两个方法，且没做过滤 ：

ArticleServiceImpl 类 对应的接口为 ArticleService ：

// 因此只要调用了 ArticleService 接口的 deleteArticleByIds 方法 ， 就会触犯上面的 sql 语句 。

全局搜索 delete A rticle B yIds ，可以找到控制器 AdminArticleController ：

// delete 方法会进行调用 ， 对应的 url 为 /delete

查看控制器 AdminArticleController 信息：

// 确定该接口 url 为 /admin/article / delete ，注入点参数为 articelId

全局搜 /admin/article/delete ，可以找到前端页面 ar ticle-list.jsp:

// 也可以不找前端了 ， 因为已经知道 url 和参数名 ， 直接发包就行了 。

直接访问会跳到后台登陆界面，因该是做了会话校验：

通过 admin/111111 登陆：

再次访问 ：

http://localhost:8080/inxedu_war/admin/article/delete

会跳转至 ：

http://localhost:8080/inxedu_war/admin/article/showlist

// 删除按钮就是我们要找的接口

点击删除，抓包，可以看到是我们想要的接口：

输入单引号报错：

原本的 sql 语句为：

构造延时注入语句进行验证 ，漏洞存在：

验证完毕 ~