一个登录框，第章输入 ' OR '1'='1' --，注入密码随便填，第章直接进后台。注入这不是第章电影桥段，是注入十年前某政府网站的真实漏洞。SQL注入到今天还没死绝，第章各种排行榜上它依然稳居前三。注入为什么？第章因为写代码的人总以为用户会乖乖填表单。

SQL注入的注入本质就一句话：用户输入的数据被当成了SQL代码执行。你本来想让用户输入名字，第章结果他输入了一段SQL语句，注入数据库分不清哪个是第章数据哪个是指令，照单全收。注入

看个例子。第章假设有个查询：

SELECT * FROM users WHERE username = '$name' AND password = '$pass'

正常用户输入 admin 和 123456，拼出来就是：

SELECT * FROM users WHERE username = 'admin' AND password = '123456'

没毛病。但如果用户名输入 admin' --，密码随便写，拼接结果变成：

SELECT * FROM users WHERE username = 'admin' --' AND password = '随便'

-- 在SQL里是注释符，后面的密码判断直接被注释掉了。数据库只查用户名是不是admin，密码压根不验证。登录成功。

这还只是最基础的。更狠的是 UNION 注入。比如商品页面有个 ?id=1，后端查询：

SELECT name, price FROM products WHERE id = 1

攻击者把id改成 -1 UNION SELECT username, password FROM users，页面直接把用户表里的账号密码显示出来。数据库辛辛苦苦存的数据，一个URL参数就全泄了。

有人觉得参数化查询能解决一切。确实，PreparedStatement 把数据和指令彻底分开，SQL注入基本没戏。但现实是，很多老系统还在用字符串拼接，有些ORM框架的 whereRaw 方法照样能注进去。我见过一个项目，前端用了React，后端是Spring Boot，看起来很现代，结果某个报表查询接口用了 String.format 拼SQL，照样被注穿。

还有一种情况容易被忽略：不是所有注入都发生在用户能看到的地方。比如 ORDER BY 后面的参数，很多开发者觉得“排序字段能有什么问题”，直接拼接。攻击者用 CASE WHEN 配合布尔盲注，一个字符一个字符地把数据库内容猜出来。没有回显，没有报错，但数据已经在慢慢泄露。

盲注这东西，写脚本跑起来很慢，但架不住数据有价值。我见过有人用盲注跑了一个星期，把某电商的用户表拖了下来。听起来不可思议，但SQL注入就是这样，只要有一个入口，剩下的就是时间问题。

再说个真实案例。某次渗透测试，目标网站有个搜索功能，输入单引号直接500错误。典型的注入点。但 UNION 被过滤了，SELECT 也被过滤了。怎么办？用 && 和 || 做布尔判断，配合 SUBSTRING 函数，照样把管理员密码跑出来了。过滤不彻底等于没过滤。

SQL注入的防御其实不复杂。参数化查询是第一选择，实在不行就用白名单校验，比如 ORDER BY 后面的字段只允许 name、price、date 这几个固定值。别用黑名单，黑名单永远有漏网之鱼。还有，数据库账号权限最小化，别用 root 连数据库，一个注入点就能 DROP TABLE 的滋味不好受。

最后说个观察。很多SQL注入漏洞不是因为技术难防，而是因为开发者觉得“这个参数用户改不了”。但用户改不了不代表攻击者改不了。Burp Suite 抓个包，什么隐藏参数都能改。安全这事情，永远别假设用户会按你的预期操作。