Mybatis框架

MyBatis是一个流行的Java数据库框架，它简化了数据库操作，允许开发人员通过映射文件或注解将Java对象与数据库中的数据进行关联。与其他ORM（如 Hibernate）不同，MyBatis不会自动生成SQL，而是允许开发者手动编写SQL语句，因此能够提供更精细的控制。目前大部分JavaWeb的学习和开发都绕不开学习他

MyBatis的利用基本分为三步

1.创建一个SQL映射.xml文件

2.创建Mapper接口，调用映射文件中的SQL语句

3.在代码中执行Mapper接口的函数即可

本文不过多说明，更加具体的使用方式就需要自己去学习了

Mybatis导致SQL注入

Mybatis框架在解析SQL语句时支持两种参数符号${}和#{}

${}这种方式是将参数直接拼接到SQL语句当中，和正常的SQL注入产生原因没两样

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

当name传入值为abcde时，Mybatis将${name}替换为abcde

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

然后Mybatis再去数据库执行该语句进行查询

#{}这种方式是使用预编译的方式进行的

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

当name传入值为abcde时，Mybatis将#{name}替换为预编译符号?

select * from sqldemo.user where name = ?

然后Mybatis使用参数化的方式进行数据库查询的，也就解决了SQL注入问题

Mybatis框架导致SQL注入的原因也简单了解一下即可

判断SQL注入点

Mybatis注入产生的原因了解了，发现和普通的SQL注入没两样，使用俩单引号一样判断，反正都是拼接产生的SQL注入

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

按照目前判断SQL注入的方式，如果一个单引号报错

然后两个单引号正常，大概率这能判断是一个字符型SQL注入了，实在不放心就再继续三个单引号报错，四个单引号正常也能判断完全了。

那不行，搞他

Mybatis解析顺序

在上面Mybatis的SQL注入产生的原因中已经提到过

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

${}是产生注入的原因，那如果${}和#{}同时在一个语句中，Mybatis是怎么解析的

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

当我把name传入数值bob

我本以为是按照语句顺序从前往后解析，按照顺序先替换#{name}为?，再替换${name}为数值bob

然而在后面调试中发现，解析顺序是并不是想象的那样

1.Mybatis会先优先替换${}中的内容

从下面调试中可以看出，进入parse()函数后，第一次是先解析${字符所在的位置

最终builder得到的值是

select * from sqldemo.user where name = #{name} or name = 'bob'

2.替换完所有${}中的内容后，再去解析#{}

使用都是parse()函数，只是转为解析#{字符了

调试过程中可以看到，现在#{位置被替换的不是数值了，而是?预编译字符

最终builder得到的值是

select * from sqldemo.user where name = ? or name = 'bob'

3.都解析完之后，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>

当语句如果需要解析多个参数位置，如何确认${id}和#{name}数据从何而来，就需要在编写Mapper接口时进行参数绑定

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

绑定之后，就可以使用#{name}了

如果我在写SQL映射文件时，使用了一个没绑定过的参数名，比如#{test}

则会产生一个错误Parameter 'test' not found，也就是test参数没有定义，所以找不到

记住这个报错，后面有用

Mybatis判断注入点

铺垫这么多，先解析${}再解析#{}到底有什么用？

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

正常我们SQL注入，name参数直接给单引号判断

那如果我给name的值是#{name}会怎样？

发现报错了，并且SQL语句最终变成了

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

那是因为mybatis先解析了${}

select * from sqldemo.user where id = #{id} and name = '${name}'====>select * from sqldemo.user where id = #{id} and name = '#{name}'

然后再解析#{}

select * from sqldemo.user where id = #{id} and name = '#{name}'====>select * from sqldemo.user where id = ? and name = '?'

SQL预编译丛一个?变成了两个?，因为后面预编译符号在单引号中包裹，所以失效导致了数量对不上的错误

但是实际环境我们不能确定参数名就是name，这无所谓，我们可以给任意不存在的参数名，比如#{test}

就出现了上面提到的参数未发现的错误

有错误产生就会有对比出现，就能判断注入点，当我给name赋值为#{test}和#test}

因为在第二次解析时会解析#{test}，但不会去解析#test}

产生的报错差别，就可以完全肯定这name参数位置使用的${}，所以就必定存在SQL注入

到这就可以通过不使用单引号的方式，判断出Mybatis的注入点了

好方式当然要工具化，直接二开了xiasql集成到里面了，有兴趣可以去星球下载试一下

但是还有几个点没考虑到：数字型怎么去判断，order型怎么去判断

<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

/*#xxxx}*//*#{xxxx}*/