- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章SQL注入详解及防范方法由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.
SQL注入是比较常见的网络攻击方式之一,它不是利用操作系统的BUG来实现攻击,而是针对程序员编写时的疏忽,通过SQL语句,实现无账号登录,甚至篡改数据库.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
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注入漏洞的程序,都是因为程序要接受来自客户端用户输入的变量或URL传递的参数,并且这个变量或参数是组成SQL语句的一部分,对于用户输入的内容或传递的参数,我们应该要时刻保持警惕,这是安全领域里的「外部数据不可信任」的原则,纵观Web安全领域的各种攻击方式,大多数都是因为开发者违反了这个原则而导致的,所以自然能想到的,就是从变量的检测、过滤、验证下手,确保变量是开发者所预想的.
如果你的SQL语句是类似where id={$id}这种形式,数据库里所有的id都是数字,那么就应该在SQL被执行前,检查确保变量id是int类型;如果是接受邮箱,那就应该检查并严格确保变量一定是邮箱的格式,其他的类型比如日期、时间等也是一个道理。总结起来:只要是有固定格式的变量,在SQL语句执行前,应该严格按照固定格式去检查,确保变量是我们预想的格式,这样很大程度上可以避免SQL注入攻击.
比如,我们前面接受username参数例子中,我们的产品设计应该是在用户注册的一开始,就有一个用户名的规则,比如5-20个字符,只能由大小写字母、数字以及一些安全的符号组成,不包含特殊字符。此时我们应该有一个check_username的函数来进行统一的检查。不过,仍然有很多例外情况并不能应用到这一准则,比如文章发布系统,评论系统等必须要允许用户提交任意字符串的场景,这就需要采用过滤等其他方案了.
对于无法确定固定格式的变量,一定要进行特殊符号过滤或转义处理.
MySQL的mysqli驱动提供了预编译语句的支持,不同的程序语言,都分别有使用预编译语句的方法 。
实际上,绑定变量使用预编译语句是预防SQL注入的最佳方式,使用预编译的SQL语句语义不会发生改变,在SQL语句中,变量用问号?表示,黑客即使本事再大,也无法改变SQL语句的结构 。
通常我们的一条sql在db接收到最终执行完毕返回可以分为下面三个过程:
我们把这种普通语句称作Immediate Statements。 。
但是很多情况,我们的一条sql语句可能会反复执行,或者每次执行的时候只有个别的值不同(比如query的where子句值不同,update的set子句值不同,insert的values值不同).
如果每次都需要经过上面的词法语义解析、语句优化、制定执行计划等,则效率就明显不行了.
所谓预编译语句就是将这类语句中的值用占位符替代,可以视为将sql语句模板化或者说参数化,一般称这类语句叫Prepared Statements或者Parameterized Statements 。
预编译语句的优势在于归纳为:一次编译、多次运行,省去了解析优化等过程;此外预编译语句能防止sql注入.
当然就优化来说,很多时候最优的执行计划不是光靠知道sql语句的模板就能决定了,往往就是需要通过具体值来预估出成本代价.
注意MySQL的老版本(4.1之前)是不支持服务端预编译的,但基于目前业界生产环境普遍情况,基本可以认为MySQL支持服务端预编译.
下面我们来看一下MySQL中预编译语句的使用.
首先我们有一张测试表t,结构如下所示:
1
2
3
4
5
6
7
8
|
mysql> show
create
table
t\G
*************************** 1. row ***************************
Table
: 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
|
我们接下来通过 PREPARE stmt_name FROM preparable_stm的语法来预编译一条sql语句 。
1
2
3
|
mysql>
prepare
ins
from
'insert into t select ?,?'
;
Query OK, 0
rows
affected (0.00 sec)
Statement prepared
|
我们通过EXECUTE stmt_name [USING @var_name [, @var_name] ...]的语法来执行预编译语句 。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
mysql>
set
@a=999,@b=
'hello'
;
Query OK, 0
rows
affected (0.00 sec)
mysql>
execute
ins using @a,@b;
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql>
select
*
from
t;
+
------+-------+
| a | b |
+
------+-------+
| 999 | hello |
+
------+-------+
1 row
in
set
(0.00 sec)
|
可以看到,数据已经被成功插入表中.
MySQL中的预编译语句作用域是session级,但我们可以通过max_prepared_stmt_count变量来控制全局最大的存储的预编译语句.
1
2
3
4
5
|
mysql>
set
@@
global
.max_prepared_stmt_count=1;
Query OK, 0
rows
affected (0.00 sec)
mysql>
prepare
sel
from
'select * from t'
;
ERROR 1461 (42000): Can't
create
more than max_prepared_stmt_count statements (
current
value: 1)
|
当预编译条数已经达到阈值时可以看到MySQL会报如上所示的错误.
如果我们想要释放一条预编译语句,则可以使用{DEALLOCATE | DROP} PREPARE stmt_name的语法进行操作
1
2
|
mysql>
deallocate
prepare
ins;
Query OK, 0
rows
affected (0.00 sec)
|
原理是采用了预编译的方法,先将SQL语句中可被客户端控制的参数集进行编译,生成对应的临时变量集,再使用对应的设置方法,为临时变量集里面的元素进行赋值,赋值函数setString(),会对传入的参数进行强制类型检查和安全检查,所以就避免了SQL注入的产生。下面具体分析 。
因为Statement之所以会被sql注入是因为SQL语句结构发生了变化。比如:
1
|
"select*from tablename where username='"
+uesrname+
"'and password='"
+
password
+
"'"
|
在用户输入'or true or'之后sql语句结构改变.
1
|
select
*
from
tablename
where
username=
''
or
true
or
''
and
password
=
''
|
这样本来是判断用户名和密码都匹配时才会计数,但是经过改变后变成了或的逻辑关系,不管用户名和密码是否匹配该式的返回值永远为true,
因为Preparement样式为 。
1
|
select
*
from
tablename
where
username=?
and
password
=?
|
该SQL语句会在得到用户的输入之前先用数据库进行预编译,这样的话不管用户输入什么用户名和密码的判断始终都是并的逻辑关系,防止了SQL注入 。
简单总结,参数化能防注入的原因在于,语句是语句,参数是参数,参数的值并不是语句的一部分,数据库只按语句的语义跑,至于跑的时候是带一个普通背包还是一个怪物,不会影响行进路线,无非跑的快点与慢点的区别.
首先看一下下面两个sql语句的区别:
1
2
3
4
5
6
|
<
select
id=
"selectByNameAndPassword"
parameterType=
"java.util.Map"
resultMap=
"BaseResultMap"
>
select
id, username,
password
, role
from
user
where
username = #{username,jdbcType=
VARCHAR
}
and
password
= #{
password
,jdbcType=
VARCHAR
}
</
select
>
|
1
2
3
4
5
6
|
<
select
id=
"selectByNameAndPassword"
parameterType=
"java.util.Map"
resultMap=
"BaseResultMap"
>
select
id, username,
password
, role
from
user
where
username = ${username,jdbcType=
VARCHAR
}
and
password
= ${
password
,jdbcType=
VARCHAR
}
</
select
>
|
【结论】在编写MyBatis的映射语句时,尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数,要手工地做好过滤工作,来防止SQL注入攻击.
MyBatis框架作为一款半自动化的持久层框架,其SQL语句都要我们自己手动编写,这个时候当然需要防止SQL注入。其实,MyBatis的SQL是一个具有“输入+输出”的功能,类似于函数的结构,参考上面的两个例子。其中,parameterType表示了输入的参数类型,resultType表示了输出的参数类型。回应上文,如果我们想防止SQL注入,理所当然地要在输入参数上下功夫。上面代码中使用#的即输入参数在SQL中拼接的部分,传入参数后,打印出执行的SQL语句,会看到SQL是这样的:
1
|
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已编译好,再次执行时无需再编译 。
http://www.zzvips.com/article/212808.html 。
http://www.zzvips.com/article/221201.html 。
到此这篇关于SQL注入详解及防范方法的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持我.
原文链接:https://www.cnblogs.com/myseries/p/10821372.html 。
最后此篇关于SQL注入详解及防范方法的文章就讲到这里了,如果你想了解更多关于SQL注入详解及防范方法的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我正在使用 MongoDB作为我的数据库,并且作为新手后端开发人员,删除整个数据库/集合的轻松程度确实困扰着我。 只需输入 db.collection.remove()从该集合中删除所有记录! 我知道
我在项目中使用 Require.js。如果您正在定义一个模块,变量 define 将被添加到全局命名空间。 最近我有一个变量名冲突[但奇怪的是,只在 Safari 中],因为有一个 ID 为 defi
我是一名优秀的程序员,十分优秀!