Mybatis框架-怎么判断SQL注入，从零基础到精通，收藏这篇就够了！

本文链接：https://blog.youkuaiyun.com/Python_0011/article/details/147590025

Mybatis框架？老生常谈？不！

MyBatis，这玩意儿在Java圈子里谁还没听过？ORM框架嘛，把Java对象和数据库表里的数据对应起来，省得你写一堆JDBC代码。但它跟Hibernate那种“全自动”选手不一样，MyBatis更像个“半自动”挡位，SQL还得你自己操刀。好处是啥？灵活！ 你想怎么玩SQL就怎么玩，控制权都在你手里。

现在JavaWeb开发，谁敢说自己没用过Mybatis？反正我是没见过。

MyBatis玩起来其实就三板斧：

XML映射文件： 先搞个XML文件，把你的SQL语句写进去。
Mapper接口： 再定义一个Mapper接口，接口里的方法对应XML里的SQL。
代码调用： 最后在你的Java代码里，调用Mapper接口的方法，MyBatis就帮你执行SQL了。

具体咋用？自己去看文档！这年头，伸手党要不得。

Mybatis凭啥能搞出SQL注入？这锅该谁背？

Mybatis这玩意儿，用好了是神器，用不好就是埋雷。它支持两种参数占位符：${}和#{}。注意，坑就在这里！

${}这货，就是个耿直boy，直接把参数拼到SQL里。这跟传统的SQL注入有啥区别？没区别！ 就是个裸奔的SQL注入漏洞。

<select id="selectC" parameterType="String" resultType="com.demo.bean.User">
    select * from sqldemo.user where name = '${name}'
</select>

比如，你传个name=abcde，Mybatis直接给你拼成：

select * from sqldemo.user where name = 'abcde'

然后丢给数据库执行。这要没问题，那才叫见了鬼！

#{}呢？它就聪明多了，用的是预编译。

<select id="selectC" parameterType="String" resultType="com.demo.bean.User">
    select * from sqldemo.user where name = #{name}
</select>

同样传个name=abcde，Mybatis会先把SQL变成这样：

select * from sqldemo.user where name = ?

然后把abcde当做参数传给数据库。这样一来，就算你传的是' or 1=1 --，数据库也只会把它当成一个普通的字符串，SQL注入？不存在的！

所以说，Mybatis本身没啥问题，问题在于用错了${}！

如何在Mybatis的枪林弹雨中找到注入点？别再傻乎乎地用单引号了！

既然${}这么危险，那怎么判断有没有SQL注入呢？你还在用传统的单引号大法？

<select id="selectC" parameterType="String" resultType="com.demo.bean.User">
    select * from sqldemo.user where name = '${name}'
</select>

一个单引号报错？

两个单引号正常？

OK，字符型SQL注入，安排！

Too young, too simple! 我在一次渗透测试中，就遇到了这种情况：一个单引号报错，两个单引号直接被WAF拦截！三个、四个单引号？统统拦截！当时我就懵了，WAF都这么智能了？

不行，必须搞清楚！

扒开Mybatis的底裤：`${}`和`#{}`的恩怨情仇

要绕过WAF，就得了解Mybatis的解析顺序。如果${}和#{}同时出现，Mybatis会怎么处理？

<select id="selectC" parameterType="String" resultType="com.demo.bean.User">
    select * from sqldemo.user where name = #{name} or name = '${name}'
</select>

你以为Mybatis会按顺序从左到右解析？Naive！

调试结果告诉我，Mybatis会先解析${}，再解析#{}！

先干掉${}： Mybatis会找到${}，把里面的内容替换掉。

比如，你传个name=bob，替换后SQL就变成了：

sql select * from sqldemo.user where name = #{name} or name = 'bob'
再收拾#{}： 替换完${}，Mybatis才会处理#{}，把它替换成?。

最终SQL变成了：

sql select * from sqldemo.user where name = ? or name = 'bob'
交给数据库： Mybatis带着SQL和参数，去数据库查数据了。

是不是有点意思了？

Mybatis报错小秘密：参数绑定是关键！

在深入之前，还得补充一个Mybatis的参数绑定知识点。

<select id="select" parameterType="String" resultType="com.demo.bean.User">
    select * from sqldemo.user where id = '${id}' or name = #{name}
</select>

SQL里有两个占位符${id}和#{name}，Mybatis怎么知道id和name的值从哪里来？需要在Mapper接口里用@Param注解绑定参数：

List<User> select(@Param(value="id") String id, @Param(value="name") String name);

这样，Mybatis才能把id和name的值正确地传递给SQL。

如果你在SQL里用了个没绑定过的参数名，比如#{test}，Mybatis就会报错：Parameter 'test' not found。

记住这个报错，后面要考！

终极武器：不靠单引号也能搞定Mybatis注入！

现在，把前面的知识点串起来，就是见证奇迹的时刻！

<select id="selectC" parameterType="String" resultType="com.demo.bean.User">
    select * from sqldemo.user where id = #{id} and name = '${name}'
</select>

如果我把name的值设为#{name}，会发生什么？

报错了！SQL变成了：

select * from sqldemo.user where id = ? and name = '?'

因为Mybatis先解析${}，把'${name}'替换成了'#{name}'，然后再解析#{}，把#{name}替换成了?。结果SQL里出现了两个?，参数数量对不上，就报错了。

但是，我们不知道参数名是name怎么办？没关系，我们可以用一个不存在的参数名，比如#{test}。

这样，Mybatis就会报Parameter 'test' not found的错误。

关键在于，如果name参数使用了${}，我们传入#{test}就会报错；如果name参数使用的是#{}，传入#{test}就不会报错。通过这个差异，我们就能判断出是否存在SQL注入！

是不是很巧妙？

我已经把这个方法集成到了xiasql里，欢迎来星球体验！

进阶：数字型和排序型注入怎么搞？

如果SQL里没有单引号限制，比如：

<select id="selectA" parameterType="String" resultType="com.demo.bean.User">
    select * from sqldemo.user where id = ${id}
</select>

<select id="selectB" parameterType="String" resultType="com.demo.bean.User">
    select * from sqldemo.user where id = #{id} order by ${sort}
</select>

传统的判断方法当然也能用，但我们也可以用上面的方法。直接给个更完善的POC：