一 前言

本文将针对开发过程中依旧经常出现的SQL编码缺陷,讲解其背后原理及形成原因。并以几个常见漏洞存在形式,提醒技术同学注意相关问题。最后会根据原理,提供解决或缓解方案。

二 SQL注入漏洞的原理、形成原因

SQL注入漏洞,根本上讲,是由于错把外部输入当作SQL代码去执行。目前最佳的解决方案就是预编译的方式。

SQL语句在执行过程中,需要经过以下三大基本步骤:

  1. 代码语义分析
  2. 制定执行计划
  3. 获得返回结果

而一个SQL语句是由代码和数据两部分,如:

SELECT id, name, phone FROM userTable WHERE name = ‘xiaoming’;

SELECT id, name, phone FROM userTable WHERE name = 是代码,’xiaoming’是数据。

而预编译,以Mybatis为例,就是预先分析带有占位符的语义:

如SELECT id, name, phone FROM userTable WHERE id = #{name};

然后再将数据’xiaoming’,传入到占位符。这样一来,错开来代码语义分析阶段,也就不会被误认为是代码的一部分了。

在最早期,开发者显式使用JDBC来自己创建Connection,执行SQL语句。这种情况下,如果将外部可控数据拼接到SQL语句,且没有做充分过滤的话,就会产生漏洞。这种情况在正常的业务开发过程中已经很少了,按照公司规定,无特殊情况下,必须使用ORM框架来执行SQL。

但目前部分项目中,仍会使用JDBC来编写一些工具脚本,如DataMerge.java 、DatabaseClean.java,借用JDBC的灵活性,通过这些脚本来执行数据库批量操作。

此类代码不应该出现在线上版本中,以免因各种情况,被外部调用。

三 直接使用Mybatis

1 易错点

目前大部分的平台代码是基于Mybatis来处理持久层和数据库之间的交互的,Mybatis传入数据有两种占位符${}和#{}。
${}可以理解为语义分析前的字符串拼接,将传入的参数,原封不动地传入。

比如说

SELECT id, name, phone FROM userTable WHERE name = ‘${name}’;
传入name=xiaoming后,相当于
SELECT id, name, phone FROM userTable WHERE name = ‘xiaoming’;

实际应用中

SELECT id, name, phone FROM userTable WHERE ${col} = ‘xiaoming’;
传入col = “name”,相当于
SELECT id, name, phone FROM userTable WHERE name = ‘xiaoming’;

就像预编译原理介绍里讲的一样,使用#{} 占位符就不存在注入问题了。但有些业务场景是不可以直接使用#{}的。

比如order by语法中

如果编写SELECT id, name, phone FROM userTable ORDER BY #{}; ,执行时是会报错的。因为order by后的内容,是一个列名,属于代码语义的一部分。如果在语义分析部分没有确定下来,就相当于执行SELECT id, name, phone FROM userTable ORDER BY 。肯定会有语法错误。

再比如like场景下

SELECT id, name, phone FROM userTable WHERE name like ‘%#{name}%’;
#{}不会被解析,从而导致报错。

in 语法和 between语法都是如此,那么如何解决这类问题呢?

2 正确写法

order by(group by)语句中使用${}

  1. 使用条件判断

    1. <select id="getUserAndOrder" resultType="Emp" parameterType="Emp">
    2. select * from users where id < #{id}
    3. <choose>
    4. <when test="order == \"name\"">
    5. order by name
    6. </when>
    7. <when test="order != \"age\"">
    8. order by age
    9. </when>
    10. <otherwise>
    11. order by id
    12. </otherwise>
    13. </choose>
    14. </select>
  2. 使用全局过滤机制,限制order by后的变量内容只能是数字、字母、下划线。

如使用正则过滤:

  1. keyword = keyword.replaceAll("[^a-zA-Z0-9_\s+]", "");

这里需要注意,过滤需要使用白名单,不能使用黑名单,黑名单无法解决注入问题。

LIKE语句

由于需要like中的关键词需要包裹在两个%符号中,因此可以使用CONCAT函数进行拼接。

<select id="selectStudentByFuzzyQuery" resultMap="studentMap">
    SELECT *
    FROM student
    WHERE student.stu_name
            LIKE CONCAT('%',#{stuName},'%')
</select>

注意不要用 CONCAT('%','${stuName}','%') ,这样仍然存在漏洞。也就是说,使用$符号是不对的,使用#符号才安全。

IN语句

类似于like语句,直接使用#{}会报错,常见的错误写法为:

tenant_id in (${tenantIds})

正确的写法为:

select * from news where id in
<foreach collection="ids" item="item" open="("separator="," close=")">#{item}</foreach>

这里需要注意,过滤需要使用白名单,不能使用黑名单,黑名单无法解决注入问题。

LIKE语句

**

由于需要like中的关键词需要包裹在两个%符号中,因此可以使用CONCAT函数进行拼接。

而一d 个SQL语句是由代码和数据两部分,如
SELECT
d
id, name, phone FROM userTable WHERE name = ‘xiaoming’;

SELECT id, name, phone FROM userTable WHERE name = 是代码,’xiaoming’是数据。

而预编译,以Mybatis为例,就是预先分析带有占位符的语义:

如SELECT id, name, phone FROM userTable WHERE id = #{name};

然后再将数据’xiaoming’,传入到占位符。这样一来,错开来代码语义分析阶段,也就不会被误认为是代码的一部分了。