某个深夜，注入我盯着Burp Suite里那条被标红的漏洞请求记录，后背有点发凉。注入参数`id=1 and 漏洞sleep(5)`，响应延迟了整整五秒。注入这不是漏洞什么小众的遗留系统，而是注入某家银行内部使用的客户管理系统——是的，银行，漏洞防火墙、注入WAF、漏洞渗透测试报告都齐备的注入那种。

SQL注入从来不是漏洞新东西。1998年Rain Forest Puppy在Phrack杂志上公开讨论它时，注入距离现在快三十年。漏洞可它至今还躺在OWASP Top 10的注入榜单里，像个打不死的蟑螂。原因？开发者的记忆太短，而攻击者的工具太锋利。sqlmap一键跑完，连参数都懒得猜。

我见过太多“过滤了单引号就以为安全”的代码。他们把`'`替换成`\'`，却忘了数字型参数根本不需要引号。`where id=1`，你拿什么过滤？数字就是数字，注入点藏在类型转换里。更别提那些用拼接SQL的存储过程，数据库层的权限还开着`sa`账号——这等于把保险柜钥匙挂在门口，还贴了张“欢迎光临”的纸条。

有一次做代码审计，翻到一个老系统的登录接口。用户名和密码直接拼进SQL，没有参数化，没有转义。我输入`admin'--`，后端日志里清清楚楚地打印出完整的查询语句。那一刻我意识到，写这段代码的人可能根本不知道什么是预编译。他大概率是从某个论坛复制来的代码片段，改了两行变量名就上线了。

防御手段早就写在教科书里：参数化查询、ORM、存储过程白名单、最小权限原则。可现实是，很多团队连基本的输入校验都做不完整。他们更愿意把钱花在扫描器上，买一堆报告，然后让安全工程师逐条核对——而攻击者只需要一个没被扫到的角落。

最讽刺的是，SQL注入的利用门槛在降低，而检测难度在升高。现在的WAF能拦住`union select`，却拦不住`json_object`函数拼接。数据库厂商不断推出新特性，每个新函数都可能成为绕过的新跳板。我见过有人用PostgreSQL的`pg_sleep`配合`xmlagg`把数据带出来，整个请求看起来就像普通的XML解析。

写代码的人换了一茬又一茬，漏洞模式却还是老样子。框架越来越安全，可总有人为了“性能优化”手写原生查询。微服务拆得越来越细，每个服务都连着不同的数据库，权限模型却没人统一管理。你以为自己在写高并发架构，实际上给攻击者铺了一张四通八达的网。

别指望工具能救你。sqlmap扫不出二次注入，因为数据已经存在数据库里，等到下次查询时才触发。这种逻辑漏洞藏在业务流转里，静态扫描器看不见，动态扫描器测不到。它就像一颗延时地雷，埋在用业务逻辑精心伪装的土壤下。

我最后给那家银行的建议很简单：把所有SQL语句集中到一个数据访问层，强制走预编译，数据库账号换成只读和读写分离的专用账号。代码评审时，看到字符串拼接就直接打回。过程很痛苦，但比起某天凌晨三点收到威胁邮件说“你们库里二十万条客户数据我都有”，这点痛苦算个屁。

SQL注入死不了，它只是进化了。你今天修掉一个报错型注入，明天可能就冒出个时间盲注。唯一的办法是让写代码的人脑子里那根弦绷紧——每次拼SQL时，想想屏幕后面可能坐着个拿着sqlmap的十五岁少年。他不在乎你的业务多复杂，他只在乎你的参数能不能睡五秒。