请谈谈对SQL注入攻击的认识

2019年夏天，请谈我帮朋友排查一个电商网站的谈对数据异常。后台日志里有一条查询记录反复出现，入攻认识参数长得离谱：id=1' AND 1=1--。请谈当时我就知道，谈对这站已经被SQL注入盯上了。入攻认识更糟的请谈是，它还真能被注入——返回的谈对页面内容跟正常访问完全一致。攻击者用这个漏洞，入攻认识把用户表里的请谈手机号、密码哈希全拖走了。谈对

SQL注入的入攻认识本质不复杂。程序把用户输入的请谈内容直接拼进SQL语句里，数据库分不清哪部分是谈对代码、哪部分是入攻认识数据，于是用户输入的东西被当成命令执行了。比如登录验证写成SELECT * FROM users WHERE name='$name' AND pass='$pass'，攻击者在密码框里填' OR '1'='1，整条语句的条件就恒为真，直接绕过登录。这不是什么高深技术，理解原理只需要五分钟，但每年仍有大量系统栽在这上面。

为什么这种老掉牙的攻击方式至今还活着？我的观察是，问题往往出在“赶工期”三个字上。拼接SQL写起来最快，参数化查询要多写几行代码，ORM框架还要配置。项目上线压力一大，安全就被挤到角落。更隐蔽的情况是，有些代码用了预编译，但排序字段、表名这类不能参数化的地方，又退回去做字符串拼接。攻击者恰恰就盯着这些边角料。

注入的种类比很多人想的多。除了最经典的联合查询注入，还有报错注入——利用数据库报错信息回显数据；盲注——页面不显示结果，但通过真/假条件判断页面差异来逐字符猜解；时间盲注——连页面差异都没有，靠SLEEP(5)这类函数让响应延迟来推断。我见过一个案例，攻击者用时间盲注花了六个小时，一个字符一个字符地把管理员密码猜了出来。慢，但有效。

防御这件事，说来说去核心就一条：别让用户输入变成SQL代码。参数化查询（预编译语句）是目前最可靠的手段，数据库会先把语句结构定死，再把参数当纯数据传入，从根本上切断注入路径。如果用了MyBatis，#{ }是预编译，${ }是直接拼接——后者在能用户输入的地方出现，基本等于开门揖盗。存储过程也能防，前提是内部不动态拼SQL。至于转义特殊字符，我不太推荐作为主要防线，编码绕过的手法太多了，容易漏。

还有一层经常被忽略：数据库权限。很多应用连数据库用的是root或sa，一旦注入成功，攻击者能直接读文件、执行系统命令。给Web应用分配一个只拥有必要表读写权限的独立账号，哪怕被注入了，损失也能控制在有限范围内。这是纵深防御的思路，不指望某一层挡住所有攻击。

WAF有没有用？有用，但别把它当保险箱。我见过WAF被/*!50000union*/这种内联注释绕过，也见过攻击者用大小写混合、URL编码变形轻松穿过规则匹配。WAF适合挡掉批量扫描的脚本小子，真正盯着你站点的攻击者，绕过的办法多的是。根本还在代码本身。

最后说个真实感受。SQL注入不像缓冲区溢出那样需要精确计算偏移量，也不像反序列化那样依赖特定语言特性。它门槛低、危害大、修复成本其实也不高。一个团队如果连参数化查询都懒得用，那大概率其他安全漏洞也不会少。反过来，把注入防住了，至少说明开发流程里有人在乎安全这件事。这比任何安全报告都让人放心。