一个登录框，洞注两个输入框，洞注一个按钮。洞注就这么点东西，洞注撑起了互联网的洞注半壁江山。但你可能不知道，洞注每天有无数个这样的洞注登录框，正被人用几行字符轻轻撬开。洞注

2017年，洞注某知名电商平台遭遇数据泄露，洞注上千万条用户信息被挂在暗网上叫卖。洞注事后调查发现，洞注攻击者用的洞注不是高科技，而是洞注最原始的SQL注入——在用户名输入框里填了句' OR '1'='1。就这么简单，洞注数据库的大门像没上锁的抽屉，一拉就开。

SQL注入的原理，说穿了不值一文钱。程序把用户输入直接拼进SQL语句，没做任何过滤。你输入什么，它就执行什么。好比你去餐厅点菜，服务员把你说的话原封不动抄给厨师，连"多加辣"这种备注都当成菜名报上去。结果呢？你说了句"把后厨门打开"，厨师还真就把门开了。

我见过最离谱的案例，是一个小网站的搜索框。攻击者输入' UNION SELECT username, password FROM users--，网页上直接列出了所有管理员的账号和明文密码。那网站还是某政府部门的下属单位。事后修补漏洞时，开发人员一脸委屈："我们用了参数化查询啊。"可仔细一查，只有部分接口用了，漏了搜索功能。

现实就是这么拧巴。很多开发者觉得SQL注入是老掉牙的漏洞，2000年就被人玩烂了。但根据OWASP Top 10近几年的报告，注入类漏洞始终稳居前三。为什么？因为代码是人写的，人会偷懒，会忽视边角料，会在赶工时把安全抛在脑后。尤其那些内部系统、老旧项目、外包代码，简直是SQL注入的重灾区。

说个我亲历的事。有次帮朋友排查一个后台管理系统，登录页面做得挺精致，但测试时随手输入' or 1=1 --，竟然直接跳转进了管理员界面。朋友脸都绿了，说这系统是花八万块找外包做的，验收时只看了功能演示，没人想过安全性。

这事给我的触动很大。技术本身不复杂，复杂的是人对技术的态度。SQL注入的修复方法早就烂大街了——参数化查询、ORM框架、输入白名单校验，随便哪个都能堵住漏洞。但架不住有人图省事，有人图快，有人压根不懂。

更麻烦的是，SQL注入的变种层出不穷。时间盲注、布尔盲注、报错注入、堆叠注入，每种都有对应的骚操作。防御者得面面俱到，攻击者只要找到一个突破口就够了。这种不对称，注定了安全是个持续对抗的过程，没有一劳永逸的解法。

写代码的手别太自信，你永远不知道自己哪行拼接字符串的代码，会成为别人打开数据库的钥匙。该做的过滤做扎实，该用的参数化别省，上线前拿工具扫一遍漏洞，这些基本动作花不了多少时间，但能省去日后无穷的麻烦。

毕竟，SQL注入这玩意儿，就像屋子里的蟑螂——你看见一只的时候，暗处可能已经藏了千百只了。