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注入

观察两段代码区别:



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)

你可能感兴趣的:(sql,数据库)