|
7 @; \: |( L4 Q# J( ` 楼主指的SQL注入在原理上被根绝是指使用预编译吧其实SQL注入并没有死透，主要原因有四：1.预编译不能解决所有SQL注入：比如表名/列名/排序动态传入的场景，原因是这些地方不能预编译，因此很多人还是直接拼接的，且囿于对预编译的信赖，从外到里没有过滤。
/ c8 c+ O: z8 A: Z7 f' I 2.可以预编译的地方也有可能出现问题：注入一般爆发在LIKE语句/IN语句中，因为这两个地方的预编译写法都有些特殊，很多开发者懒得去搞，就直接拼接了3.在SQL语句的写法上，直接拼接比预编译简单太多了，没有接触过信息安全的初学者写出来的代码很大可能存在漏洞；就算是有经验的程序员，在快速上线的压力下，也没有时间再去考虑信息安全的问题。
9 S4 d4 D" N, f, v" f" e) a! p5 c 4.有太多有漏洞的老代码来不及或不能换上预编译，只能靠WAF苟活，而WAF这种东西本身就是在用户体验与安全性之间的一种矛盾集合体，总有被绕过的可能性最后，其实我想说的是，就新开发的系统来说，SQL注入漏洞确实越来越少了，做到这一点的不是大家的安全意识增强，都知道使用预编译了，而是。
% w8 v! P. a& J" w) A: A& b 大量成熟的框架与组件，其本身自带有对安全性的考量，使开发者无感知的写出较为安全的代码SQL注入作为漏洞之王不会就此消失，漏洞从来都是环环相扣，褪去外网坚韧的防御，内网脆弱无比，拼接来自于人的懒惰，且永远不会缺席。
4 _# @. _; J- m5 ]
# u+ u" C q% {8 E/ Y3 |2 ? R& \* l9 R' |- ^7 `
$ S) C2 c& J# p: {, K3 [
; S) X. n& R$ O! ^+ W/ f+ r | 
