SQL注入

一、什么是SQL注入

SQL注入（SQL lnjection）是发生在Web程序中数据库层的安全漏洞，是比较常用的网络攻击方式之一，他不是利用操作系统的BUG来实现攻击，而是针对程序员编写时的疏忽，通过SQL语句，实现无账号登录，甚至修改数据库。也就是说，SQL注入就是在用户输入的字符串中添加SQL语句，如果在设计不良的程序中忽略了检查，那么这些注入进去的SQL语句就会被数据库服务器误认为是正常的SQL语句而运行，攻击者就可以执行计划外的命令或者访问未授权的数据。

二、SQL注入的原理

1.恶意拼接查询

SQL语句可以对数据进行增删改查，且使用分号来分隔不同命令。例如：

SELECT * FROM user WHERE user_id = $user_id

 其中user_id是传入的参数，如果传入参数的值为"1234;DELETE FROM user",那么最终执行的查询为：

SELECT * FROM users WHERE user_id = 1234; DELETE FROM users

如果执行以上语句，则会删除user表中的所有数据

2.利用注释执行非法命令

 SQL语句中可以插入注释，例如

SELECT COUNT(*) AS 'num' FROM score WHERE id=24411 AND version=$version

如果version包含了恶意的字符串" '-1' OR 3 AND SLEEP(500) ",那么最终查询的语句会变为

SELECT COUNT(*) AS 'num' FROM score WHERE id=24411 AND version='-1' OR 3 AND SLEEP(500)

以上恶意查询只是想耗尽系统资源，SLEEP(500) 将导致 SQL 语句一直运行。如果其中添加了修改、删除数据的恶意指令，那么将会造成更大的破坏。

3.传入非法参数

SQL 语句中传入的字符串参数是用单引号引起来的，如果字符串本身包含单引号而没有被处理，那么可能会篡改原本 SQL 语句的作用。 例如：

SELECT * FROM user_name WHERE user_name = $user_name

如果 user_name 传入参数值为 G'chen，那么最终的查询语句会变为：

SELECT * FROM user_name WHERE user_name ='G'chen'

一般情况下，以上语句会执行出错，这样的语句风险比较小。虽然没有语法错误，但可能会恶意产生 SQL 语句，并且以一种你不期望的方式运行。

4.添加额外条件

在 SQL 语句中添加一些额外条件，以此来改变执行行为。条件一般为真值表达式。例如：

UPDATE users SET userpass='$userpass' WHERE user_id=$user_id;

如果 user_id 被传入恶意的字符串“1234 OR TRUE”，那么最终的 SQL 语句会变为：

UPDATE users SET userpass= '123456' WHERE user_id=1234 OR TRUE;

如果执行以上语句，将更改所有用户的密码

三、SQL注入实例

String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";

--当输入了上面的用户名和密码，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
'’or 1 = 1 -- and password='’

"""
--分析SQL语句：
--条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；

--然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都--能正确执行，用户轻易骗过系统，获取合法身份。
--这还是比较温柔的，如果是执行
SELECT * FROM user_table WHERE
username='' ;DROP DATABASE (DB Name) --' and password=''
--其后果可想而知…
"""

四、如何避免SQL注入

1.过滤输入内容，校验字符串

过滤输入内容就是在数据提交到数据库之前，就把用户输入中不合法的字符剔除掉，可以使用编程语言提供的处理函数或自己的处理函数来进行过滤，还可以使用正则表达式匹配安全的字符串。

如果值属于特定的类型或有具体的格式，那么在拼接SQL语句之前就要进行校验，验证其有效性，比如对于某个传入的值，如果可以确定是整形，则要判断他是否为整型，在浏览器端（客户端）和服务器端都要进行验证。

2.参数化查询（绑定变量，使用预编译查询）

参数化查询目前被视为预防SQL注入最有效的方法，参数化查询是指在设计与数据库连接并访问数据时，在需要填入数值或者数据的地方，使用参数（Parameter）来给值

MySQL 的参数格式是以"?"字符加上参数名称而成，如下所示：

UPDATE myTable SET c1 = ?c1, c2 = ?c2, c3 = ?c3 WHERE c4 = ?c4

在使用参数化查询的情况下，数据库服务器不会将参数的内容视为SQL语句的一部分来进行处理，而是在数据库完成SQL语句的编译之后，才 套用参数运行，因此就算参数含有破坏性的指令，也不会被数据库所运行。

使用预编译的SQL语句语义不会发生改变，在SQL语句中，变量用问号?表示，黑客即使本事再大，也无法改变SQL语句的结构

简单总结，参数化能防注入的原因在于，语句是语句，参数是参数，参数的值并不是语句的一部分，数据库只按语句的语义跑，至于跑的时候是带一个普通背包还是一个怪物，不会影响行进路线，无非跑的快点与慢点的区别。

3.安全测试，安全审计

 除了开发规范，还需要合适的工具来确保代码的安全。我们应该在开发过程中应对代码进行审查，在测试环节使用工具进行扫描，上线后定期扫描安全漏洞。通过多个环节的检查，一般是可以避免 SQL 注入的。

有些人认为存储过程可以避免 SQL 注入，存储过程在传统行业里用得比较多，对于权限的控制是有一定用处的，但如果存储过程用到了动态查询，拼接 SQL，一样会存在安全隐患。

下面是在开发过程中可以避免 SQL 注入的一些方法。

 3.1.避免使用动态SQL

避免将用户的输入数据直接放在SQL语句中，最好使用准备好的语句和参数化查询，这样更安全。

3.2.不要将敏感数据保留在纯文本中

加密存储在数据库中的私有/机密数据，这样可以提供了另一级保护，以防攻击者成功的排出敏感数据

3.3.限制数据库的权限和特权

将数据库用户的功能设置为最低要求；这将限制攻击者在设法获取访问权限时可以执行的操作

3.4.避免直接向用户显示数据库错误

攻击者可以使用这些错误消息来获取有关的数据库信息。

四、SQL预编译

1.预编译语句是什么？

通常我们的一条sql在db接受到最终执行完毕返回可以分为下面三个过程：

        1.词法和语义的解析

        2.优化sql语句，制定执行计划

        3.执行并返回结果

这种普通语句被称为Immediate Statements

但是很多情况，我们的一条sql语句可能会反复执行，或者每次执行的时候只有个别的值不同（比如query的where子句值不同，update的set子句值不同,insert的values值不同）。
如果每次都需要经过上面的词法语义解析、语句优化、制定执行计划等，则效率就明显不行了。

所谓预编译语句就是将这类语句中的值用占位符替代，可以视为将sql语句模板化或者说参数化，一般称这类语句叫Prepared Statements或者Parameterized Statements
预编译语句的优势在于归纳为：一次编译、多次运行，省去了解析优化等过程；此外预编译语句能防止sql注入。
当然就优化来说，很多时候最优的执行计划不是光靠知道sql语句的模板就能决定了，往往就是需要通过具体值来预估出成本代价。

2.预编译语句

（1）建一张测试表t

Create Table: CREATE TABLE `t` (
  `a` int(11) DEFAULT NULL,
  `b` varchar(20) DEFAULT NULL,
  UNIQUE KEY `ab` (`a`,`b`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

（2）编译

通过 PREPARE stmt_name FROM perpare_stm 的语法来预编译一条sql语句

PREPARE  ins FROM 'INSERT INTO t SELECT ?,?';

(3)执行

通过 EXECUTE stmt_name [USING @var_name [,@var_name]...]的语法来执行预编译语句

SET @a=999,@b='hello';
EXECUTE ins USING @a,@b;

此时数据已经插入。

MySQL中的预编译语句作用域是session级，但我们可以通过max_prepare_stmt_count变量来控制全局最大的存储的预编译语句

SET @@global.max_prepared_stmt_count=1;
/*此时设置预编译最大条数为1，如果继续使用预编译，就会报错*/

（4）释放

如果我们想要释放一条预编译语句，则可以使用{DEALLOCATE | DROP} PREPARE stmt_name的语法进行操作

 DEALLOCATE prepare ins;

五、MyBatis如何预防SQL注入

观察两段代码区别：

select id, username, password, role
from user
where username = #{username,jdbcType=VARCHAR}
and password = #{password,jdbcType=VARCHAR}



select id, username, password, role
from user
where username = ${username,jdbcType=VARCHAR}
and password = ${password,jdbcType=VARCHAR}

mybatis中#和$的区别：

    　1、#将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号。
如：where username=#{username}，如果传入的值是111,那么解析成sql时的值为where username="111", 如果传入的值是id，则解析成的sql为where username="id".　
　　2、$将传入的数据直接显示生成在sql中。
如：where username=${username}，如果传入的值是111,那么解析成sql时的值为where username=111；
如果传入的值是;drop table user;，则解析成的sql为：select id, username, password, role from user where username=;drop table user;

        3、#能很大程度防止sql注入，$ 方式无法防止sql注入

        4、$方式一般用于传入数据库对象，例如传入表名.
　　 5、一般能用#的就别用$，若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止sql注入攻击。
　　6、在MyBatis中，“${xxx}”这样格式的参数会直接参与SQL编译，从而不能避免注入攻击。但涉及到动态表名和列名时，只能使用“${xxx}”这样的参数格式。所以，这样的参数需要我们在代码中手工进行处理来防止注入。

【结论】在编写MyBatis的映射语句时，尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止SQL注入攻击。

mybatis是如何做到防止SQL注入的

 　MyBatis框架作为一款半自动化的持久层框架，其SQL语句都要我们自己手动编写，这个时候当然需要防止SQL注入。其实，MyBatis的SQL是一个具有“输入+输出”的功能，类似于函数的结构，参考上面的两个例子。其中，parameterType表示了输入的参数类型，resultType表示了输出的参数类型。回应上文，如果我们想防止SQL注入，理所当然地要在输入参数上下功夫。上面代码中使用#的即输入参数在SQL中拼接的部分，传入参数后，打印出执行的SQL语句，会看到SQL是这样的：

select id, username, password, role from user where username=? and password=?

不管输入什么参数，打印出的SQL都是这样的。这是因为MyBatis启用了预编译功能，在SQL执行前，会先将上面的SQL发送给数据库进行编译；执行时，直接使用编译好的SQL，替换占位符“?”就可以了。因为SQL注入只能对编译过程起作用，所以这样的方式就很好地避免了SQL注入的问题。

【底层实现原理】MyBatis是如何做到SQL预编译的呢？其实在框架底层，是JDBC中的PreparedStatement类在起作用，PreparedStatement是我们很熟悉的Statement的子类，它的对象包含了编译好的SQL语句。这种“准备好”的方式不仅能提高安全性，而且在多次执行同一个SQL时，能够提高效率。原因是SQL已编译好，再次执行时无需再编译

资料来源：

web开发中防止SQL注入 - 申不二 - 博客园

mybatis是如何防止SQL注入的 - 淼淼之森 - 博客园

SQL注入详解 - myseries - 博客园 (cnblogs.com)

SQL注入是什么，如何避免SQL注入？ (biancheng.net)