2019年夏天，入攻某地方法院公布了一份判决书。控制被告姓李，网站是服务个刚满20岁的年轻人。他用一个叫sqlmap的入攻开源工具，在三个月内拿到了国内某知名电商平台的控制数据库权限。用户姓名、网站手机号、服务收货地址、入攻订单记录，控制全都能看。网站他甚至没写过几行代码，服务只是入攻把工具对准了一个存在SQL注入漏洞的搜索接口。

SQL注入这件事，控制听起来像是网站上个时代的老古董。但它的杀伤力从未减弱。核心原理很简单：网站用SQL语句跟数据库对话，比如“SELECT * FROM users WHERE id = 1”。如果程序员没做好过滤，攻击者把“1”换成“1 UNION SELECT username, password FROM admin”，数据库就会老老实实把管理员账号密码吐出来。

问题在于，很多开发者觉得“我用的框架会处理”。但框架不是万能盾牌。我见过一个真实案例：某CMS系统用了ORM（对象关系映射），但排序参数直接拼接到SQL里。攻击者提交`?order=id DESC; DROP TABLE logs--`，整个日志表瞬间消失。ORM只管值，不管结构。结构被污染，照样出事。

控制服务器不是夸张说法。数据库和操作系统之间没有铜墙铁壁。MySQL有个功能叫`LOAD_FILE()`，能读服务器上的任意文件。配合`INTO OUTFILE`，还能写文件。攻击者先注入，读出网站配置文件，找到数据库密码。再用`SELECT ... INTO OUTFILE '/var/www/html/shell.php'`写一个WebShell。最后访问那个文件，服务器就归他了。

2017年，某省公安厅官网被挂马。事后溯源发现，入口是一个十年前开发的旧查询页面。那个页面早就没人维护了，但还挂在公网上。攻击者用`AND 1=1`和`AND 1=2`对比返回页面差异，确认注入点存在。然后一步步拿下了数据库。整个过程不到两小时。一个没人管的旧接口，成了整台服务器的后门。

有人会说，现在有WAF（Web应用防火墙）。WAF确实能拦掉大部分自动化扫描。但手工注入呢？把`UNION SELECT`写成`UN/**/ION SEL/**/ECT`，把空格换成`%0a`，把关键词用十六进制编码。WAF的规则库更新速度，永远追不上攻击者的变形速度。更别说很多WAF只部署在边缘，内网横向移动时根本不起作用。

防御SQL注入，参数化查询是唯一可靠的路。不是“过滤特殊字符”，不是“转义引号”，是让SQL语句的结构和用户输入彻底分开。Java用PreparedStatement，Python用cursor.execute带参数，PHP用PDO。代码写对了，注入就没了。写不对，再多的WAF、再厚的防火墙，也只是给攻击者多绕几步路。

那个姓李的年轻人最后被判了三年。法庭上他说了一句话：“我只是输了个网址，点了下按钮。”这句话比任何技术分析都让人后背发凉。SQL注入的门槛，低到不需要懂编程。而它的后果，高到能赔上整个服务器。