对于SQL注入的理解
从网上搜索的资料,结合自己的理解整理了一下,网友们在查看时若有发现问题,还请不吝指正,谢谢!
1、什么是SQL注入?
——官方说法:把SQL命令插入到web表单验证的输入框中,提交到服务器,以达到越过数据验证的目的。
——通俗说法:在浏览器的某个网页中,在身份验证框或者数据查询框中,通过输入sql命令,影响SQL语句字符串的拼接,从而使原本执行不通过的SQL语句可以执行通过。
2、如何进行SQL注入?
——拼接SQL字符串:
比如在网站的登录页面中,在用户名输入框中输入“or 1=1 --”,密码输入框中不输入,然后点击“登录”按钮,对于一些安全防护做的不太好的网站,可能就直接登进去了,应该叫做非法登录了。举例如下:
后台进行登录验证的代码如下:(网上截的图,主要看SQL字符串的拼接那块。)
验证用户登录的sql 如下:
select COUNT(*) from Users where Password = 'a' and UserName = 'b'
这段代码返回Password 和UserName都匹配的用户数量,如果大于1的话,那么就代表用户存在。
SQL注入:我们在用户名UserName输入框中,输入“b' or 1=1 --”(注意:“--”是SQL SERVER中的注释,其他数据库注释标识可能不同),
然后原来的SQL语句就变成了:select COUNT(*) from Users where Password = 'a' and UserName = 'b' or 1=1 --',
实际执行的SQL语句是:select COUNT(*) from Users where Password = 'a' and UserName = 'b' or 1=1,因为后面的注释了。
这样这个SQL语句就变成了恒成立的,所以只要Users表中有数据,执行结果就是大于等于1的。
这样SQL注入就成功了。
3、如何防止SQL注入?
————参数化查询。
具体方法:
后台代码如下:
这里我的理解是,通过参数化,把用户的输入信息中的单引号进行了转义,从而使每一个输入信息都作为一个单独的字符串,比如像上面的“b' or 1=1 --”经过参数化处理后,就变成了“b'' or 1=1 --”,那么就不会改变原来SQL语句的语义了。
可以看到参数化查询主要做了这些事情:
1:参数过滤,可以看到 @UserName='b'' or 1=1—'
2:执行计划重用
因为执行计划被重用,所以可以防止SQL注入。
最后,分析SQL注入的本质:
用户写了一段SQL 用来表示查找密码是a的,用户名是b的所有用户的数量。
通过注入SQL,这段SQL现在表示的含义是查找(密码是a的,并且用户名是b的,) 或者1=1 的所有用户的数量。
可以看到SQL的语意发生了改变,为什么发生了改变呢?,因为没有重用以前的执行计划,因为对注入后的SQL语句重新进行了编译,因为重新执行了语法解析。所以要保证SQL语义不变,即我想要表达SQL就是我想表达的意思,不是别的注入后的意思,就应该重用执行计划。
如果不能够重用执行计划,那么就有SQL注入的风险,因为SQL的语意有可能会变化,所表达的查询就可能变化。
任何动态的执行SQL 都有注入的风险,因为动态意味着不重用执行计划,而如果不重用执行计划的话,那么就基本上无法保证你写的SQL所表示的意思就是你要表达的意思。
这就好像小时候的填空题,查找密码是(____) 并且用户名是(____)的用户。
不管你填的是什么值,我所表达的就是这个意思。
最后再总结一句:因为参数化查询可以重用执行计划,并且如果重用执行计划的话,SQL所要表达的语义就不会变化,所以就可以防止SQL注入,如果不能重用执行计划,就有可能出现SQL注入,
存储过程也是一样的道理,因为可以重用执行计划。
另外,对于上面说的“重用执行计划”这个词不太明白,准备在下一次继续学习整理一下。