一个十六岁的入漏少年坐在家里，对着一个购物网站的洞描下单接口，在URL末尾敲下了一串字符：' OR '1'='1。入漏服务器没有过滤，洞描数据库乖乖地把所有用户信息吐了出来。入漏这大概就是洞描SQL注入最经典的画面——不是黑客电影里那种花哨的键盘特效，只是入漏一个引号，一个简单的洞描逻辑判断，就让整个系统门户洞开。入漏

SQL注入的洞描本质，是入漏数据与代码的边界被抹掉了。你输入的洞描字符串，本该被当作数据存储或查询，入漏结果被数据库引擎当成可执行代码来解析。洞描这就像你往自动售货机里塞了一张写着"给我吐十罐可乐"的入漏纸条，售货机不但照做，还顺便把收银箱也打开了。问题不在售货机太蠢，而在设计者没想过有人会这么干。

我见过不少真实案例。某家银行的移动端App，转账接口有个备注字段，开发人员图省事，直接拼SQL字符串更新数据库。测试时没人会在备注里写'; DROP TABLE transactions; --，但有人真的这么干了。那一瞬间，整个交易记录表被清空。银行花了三天从备份恢复，期间客户余额全部显示为零，客服电话被打爆。讽刺的是，事后复盘发现，这个漏洞在代码评审时被提过两次，但都因为"业务优先级更高"被搁置了。

更隐蔽的是盲注。攻击者看不到数据库报错信息，只能通过页面是否正常加载来判断条件真假。比如一个搜索框，输入' AND SLEEP(5)--，如果页面延迟五秒才响应，就说明注入成功了。这种手法慢得像滴水穿石，但能一点点把数据库里的内容给"挤"出来——每次只问一个真假问题，像玩二十问游戏一样。我见过最极端的案例，攻击者花了整整两周，从某个政府网站里逐字符地挖出了一个完整的数据库结构。

防御手段其实不复杂。参数化查询是标配，让SQL语句和用户输入彻底分离，就像把乘客和驾驶员隔开，乘客再闹也碰不到方向盘。输入验证和输出编码作为辅助，但别指望它们能兜底——黑名单永远有漏网之鱼，白名单又容易误伤正常业务。真正要紧的是把"永远不信任用户输入"刻进开发流程里。

可为什么这漏洞到现在还满地都是？我猜是惰性使然。写SELECT * FROM users WHERE name = '" + input + "'比写预编译语句顺手多了，尤其赶工期的时候。代码审查又往往流于形式，检查的人盯着变量命名和缩进风格，没人真去模拟攻击者的思路。还有个现实问题：很多老旧系统跑着十几年前的代码，那时候没人教过框架里的ORM怎么用，全是手拼SQL的老江湖。

有个细节我印象很深。某次安全培训上，讲师让在座二十多个后端工程师现场写一段登录查询代码，结果有一半人直接用了字符串拼接。问他们为什么，答案几乎一致："内部系统，没人会攻击我们。"——这话我听了不下十遍，然后每次都能在搜索引擎里搜到对应的漏洞报告。

SQL注入不是什么高深技术，它就像一个存在了二十多年的老锁，钥匙人人都会配。问题是，很多房子到现在还在用这把锁，甚至压根没装锁。