|
" x% N" f" y: [ SQL注入并不是一个在SQL内不可解决的问题，这种攻击方式的存在也不能完全归咎于SQL这种语言，因为注入的问题而放弃SQL这种方式也是因噎废食首先先说一个我在其他回答中也曾提到过的观点：没有（运行时）编译，就没有注入。
- d5 D0 D; V; l k3 e4 }& S, a SQL注入产生的原因，和栈溢出、XSS等很多其他的攻击方法类似，就是未经检查或者未经充分检查的用户输入数据，意外变成了代码被执行针对于SQL注入，则是用户提交的数据，被数据库系统编译而产生了开发者预期之外的动作。
8 F' `5 M5 h a; F! d* t. n4 s 也就是，SQL注入是用户输入的数据，在拼接SQL语句的过程中，超越了数据本身，成为了SQL语句查询逻辑的一部分，然后这样被拼接出来的SQL语句被数据库执行，产生了开发者预期之外的动作所以从根本上防止上述类型攻击的手段，还是避免数据变成代码被执行，时刻分清代码和数据的界限。 0 C1 a* f; J3 [7 l" n1 ?
而具体到SQL注入来说，被执行的恶意代码是通过数据库的SQL解释引擎编译得到的，所以只要避免用户输入的数据被数据库系统编译就可以了现在的数据库系统都提供SQL语句的预编译（prepare）和查询参数绑定功能，在SQL语句中放置。
; S6 `0 O1 y1 o r. T- T+ t+ R9 L 占位符?，然后将带有占位符的SQL语句传给数据库编译，执行的时候才将用户输入的数据作为执行的参数传给用户这样的操作不仅使得SQL语句在书写的时候不再需要拼接，看起来也更直接，而且用户输入的数据也没有机会被送到数据库的SQL解释器被。 ) N- H }# O4 a' D; D+ B" I1 U
编译执行，也不会越权变成代码至于为什么这种参数化的查询方式没有作为默认的使用方式，我想除了兼容老系统以外，直接使用SQL确实方便并且也有确定的使用场合多说一点，从代码的角度来看，拼接SQL语句的做法也是不恰当的。
5 x% i, P) J: k' N. y DELETEFROMplanetWHEREname=mercury;DELETEFROMplanetWHEREname=venus;DELETEFROMplanetWHEREname=earth;DELETE / {/ c: d% A9 `8 n% d
FROMplanetWHEREname=mars;我修改一下那个很经典的笑话：程序员不应该执行删除地球这样的SQL语句，而是写删除一个行星，然后将地球当作参数传入$stmt=$mysqli->prepare。
$ L Q3 N- W; F; S9 S0 n ("DELETE FROM planet WHERE name = ?");$stmt->bind_param(s,"earth");$stmt->execute();更多阅读：MySQL :: MySQL 5.1 Reference Manual :: 13.5 SQL Syntax for Prepared Statements / f, p7 D2 r8 Y0 X
Prepared statement
, k& W, F6 K/ J' _) i6 g" b1 {
' v3 L T3 k( W% ^
) _. e3 t& a0 y% z2 L! K) p, H. Q9 y
2 c3 C3 `3 E& G* f; j1 t# K! i
| 
