一、MyBatis框架中的注入漏洞

Mybatis框架支持的CURD功能可以直接搜索XML文件中的${和${}拼接的SQL语句，如果SQL的参数可控，就可能造成注入风险。

另外，有的SQL语句使用的是注解开发，把SQL语句可以直接写在了代理接口方法上方，审计的时候可以将两种情况都注意一下，或许有不同的发现。

安全的方式应该是使用#号接收参数，但很多时候如数据库表的字段名，又只能使用$符接收参数。
白名单的方案是可以将数据库表的字段名维护为一个数组，再检查参数是否在数组内，经过拼接的payload就不能通过检查, 例如：对于排序，只用了到ASC、DESC中的一个，把这两做成白名单即可，SQL注入的payload不在这个名单中，在反序列化时就会被拦截。

二、JPA中的SQL注入

JPA受SpringBoot官方支持直接提供启动依赖，和MyBatis一样，JPA框架方便开发人员完成与数据库的各种交互操作。

对于JPA中的SQL注入，一般出现时使用的是+号直接拼接。

安全的方式应该用冒号或者问号进行参数绑定：

三、无法利用的SQL注入

在文章开头提到，如果SQL参数可控可能造成注入风险，即使直接拼接到SQL语句的参数可控，也并不意味着这个SQL注入漏洞可以被利用。

比如前端将JSON传送到后端后，会有一个反序列化的操作，将JSON串反序列化为目标类，期间会有一个数据类型转换过程。

查看如下两个字段在实体类的定义，发现是int类型，但是SQL注入的payload是字符串类型（形如”OR IF(SLEEP(5), 0, 1)--+"的字符串），数据类型不匹配，在反序列化这一步的数据类型转换就通过不了，因此这个注入漏洞并不能利用。
的参数可控，就可能造成注入风险。

原创 洞源实验室