对于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注入，

存储过程也是一样的道理，因为可以重用执行计划。

另外，对于上面说的“重用执行计划”这个词不太明白，准备在下一次继续学习整理一下。