2019年夏天，入渗某电商平台的入渗安全团队在例行巡检时发现一条异常查询日志：一个GET请求的参数里，id=1 AND 1=1，入渗紧接着下一行是入渗id=1 AND 1=2。两条请求返回的入渗页面内容一个正常，一个空白。入渗值班工程师当时就坐直了——有人在手工探测SQL注入点。入渗

SQL注入这事，入渗说穿了就是入渗攻击者把SQL代码塞进应用程序原本打算当数据处理的输入框里，让数据库误以为那是入渗命令。比如登录框，入渗后端拼的入渗SQL大概长这样：SELECT * FROM users WHERE username='admin' AND password='xxx'。你在密码栏填' OR '1'='1，入渗语句就变成SELECT * FROM users WHERE username='admin' AND password='' OR '1'='1'。入渗数据库一看，入渗'1'='1'永远为真，直接放行。就这么简单，也这么致命。

我见过一个真实案例。某地方政务系统，后台查询接口没做参数化，攻击者用UNION SELECT把数据库版本、当前用户、所有表名一步步拖出来。先猜列数，ORDER BY 1、ORDER BY 2……直到页面报错，确定有5列。然后UNION SELECT 1,version(),3,4,5，数据库版本直接回显在页面上。整个过程不到二十分钟，用的全是浏览器地址栏。更离谱的是，那个系统数据库账号权限是root，攻击者最后通过INTO OUTFILE往Web目录写了个webshell，服务器就这么没了。

手工注入慢，但精准。工具注入快，但动静大。sqlmap跑起来，默认会发大量请求，WAF日志瞬间爆掉。老手通常先手工确认注入类型——数字型还是字符型，报错注入还是盲注。盲注最磨人，页面不回显数据，只能靠AND SUBSTRING((SELECT database()),1,1)='a'这种布尔判断一个字符一个字符猜。猜一个库名，几百个请求就没了。时间盲注更狠，用IF(条件,SLEEP(5),0)，页面响应时间差5秒就是真。这种注入对网络延迟敏感，但隐蔽性极强，WAF很难从流量特征上直接拦。

防御的核心就一条：别拼SQL。参数化查询，让数据库把用户输入永远当数据，不当命令。Java用PreparedStatement，Python用cursor.execute("SELECT * FROM users WHERE id=%s",(user_id,))，PHP用PDO的bindParam。这是根治。存储过程如果内部还是拼字符串，照样中招。转义函数？不靠谱，宽字节注入、编码绕过，花样太多。WAF能挡一部分，但别当唯一防线——攻击者换个编码、加个注释/*!50000SELECT*/，规则可能就漏了。

还有个坑：ORM框架。很多人觉得用了Hibernate、MyBatis就安全了。MyBatis里写${ }而不是#{ }，照样拼接。Hibernate的HQL如果用字符串拼接，一样注入。框架只是工具，写代码的人图省事，漏洞就来了。

最后说个观察。SQL注入被谈了几十年，OWASP Top 10里从第一降到第三，又因为API接口大量涌现重新抬头。根因从来不是技术难防，是开发节奏太快，安全评审被跳过。一个参数化查询能解决的事，非要等数据被拖了才补。渗透测试报告里SQL注入的修复建议翻来覆去就那几句，但每次扫描，总有几个接口亮红灯。这事，说到底不是技术问题。