sql参数化查询为什么能够防止sql注入

[Sean-little]

就是sql参数化查询为什么能够防止sql注入？网上说的是编译时不会把值放进去而是编译时是参数化的，等编译后再把值放进去，这样为什么就会防止注入？

[Tiger_Zhao]

只要知道参数化查询，编译执行计划时并没有用的参数，所以命令是确定的。
至于驱动程序怎么去执行，不用关心。

[Tiger_Zhao]

注入的实质就是追加命令，正常的命令是程序中的“常量”，能动手脚的只能是可输入的用户、密码这些可输入的“变量”。
拼接方式是常量、变量拼在一起编译，才可以在正常的命令后追加后门命令。
参数化的方式仅常量参与编译，就无法追加后门命令。

[Sean-little]

引用 1 楼 Tiger_Zhao 的回复:

注入的实质就是追加命令，正常的命令是程序中的“常量”，能动手脚的只能是可输入的用户、密码这些可输入的“变量”。 拼接方式是常量、变量拼在一起编译，才可以在正常的命令后追加后门命令。 参数化的方式仅常量参与编译，就无法追加后门命令。

是不是编译的时候，参数化就是用参数参与编译，这样就全是常量了。但是什么时候把参数的值传进去，能否详细讲一下编译后的执行过程？谢谢

[Sean-little]

引用 3 楼 Tiger_Zhao 的回复:

只要知道参数化查询，编译执行计划时并没有用的参数，所以命令是确定的。 至于驱动程序怎么去执行，不用关心。

大师，是否知道就是我最终还是得把参数的值传过去，传过去后还是不是替换掉参数，那么这样为什么就会不产生注入，上面讲的我还是没有理解为什么

[Tiger_Zhao]

编译后执行计划就确定了，传参数只是为了运行执行计划。
执行计划不变，就不会多出命令来。

[快乐起航2020]

坐等大神回答，同求

[Guimashisqll]

我的理解：普通的sql拼接，是等到 参数都过来之后 才能确定 sql语句的，比如最常见的，select COUNT(*) from Users where Password = 'a' and UserName = 'b' or 1=1—'，，，得等到 UserName 参数传过来，才会去 编译这条 sql语句（sql语句是编译后执行的），而这个时候， 这个拼接的sql 多了 or 选项，这是跟设计者本意相违背的。 参数化查询：是先编译 这样一条sql, select COUNT(*) from Users where Password = @psw and UserName = @uname (格式不一定对哈)，就跟函数的编译一样， 这样的话，以后'b' or 1=1—' 只能作为 UserName 的参数了，，，相当于你去查 " 'b' or 1=1—' " 这个用户，而不是 查 "b" 用户 或者 " 1=1 " 了。。。 相当于把 or 给屏蔽掉了。。。or 原来是sql的一项（普通的拼接），现在就是个 普通字符串参数（参数化查询）。 不知道我的理解对不对。。。

[维秀斯丢丢]

引用 7 楼 Guimashisqll 的回复:

我的理解：普通的sql拼接，是等到 参数都过来之后 才能确定 sql语句的，比如最常见的，select COUNT(*) from Users where Password = 'a' and UserName = 'b' or 1=1—'，，，得等到 UserName 参数传过来，才会去 编译这条 sql语句（sql语句是编译后执行的），而这个时候， 这个拼接的sql 多了 or 选项，这是跟设计者本意相违背的。 参数化查询：是先编译 这样一条sql, select COUNT(*) from Users where Password = @psw and UserName = @uname (格式不一定对哈)，就跟函数的编译一样， 这样的话，以后'b' or 1=1—' 只能作为 UserName 的参数了，，，相当于你去查 " 'b' or 1=1—' " 这个用户，而不是 查 "b" 用户 或者 " 1=1 " 了。。。 相当于把 or 给屏蔽掉了。。。or 原来是sql的一项（普通的拼接），现在就是个 普通字符串参数（参数化查询）。 不知道我的理解对不对。。。

我的理解也是这样的。执行计划还能检查语义是否和编译时相同。这就是双重防护了。