内容摘要：一个深夜，某电商平台的订单数据库突然多了几千条“test”记录。运维人员翻看日志，发现攻击者只是在搜索框里输入了一段 `' OR '1'='1`。就这么一行字符，整个用户表的账号密码差点被拖走。这不是

一个深夜，入攻某电商平台的击防订单数据库突然多了几千条“test”记录。运维人员翻看日志，范措发现攻击者只是入攻在搜索框里输入了一段 `' OR '1'='1`。就这么一行字符，击防整个用户表的范措账号密码差点被拖走。这不是入攻电影情节，SQL注入至今仍是击防OWASP Top 10里的常客，每年因它泄露的范措数据量以亿计。

SQL注入的入攻本质，是击防攻击者把SQL代码伪装成普通输入，骗过应用层，范措让数据库执行了设计之外的入攻命令。防范它的击防思路其实不复杂，核心就一句话：永远不要把用户输入直接拼进SQL语句。范措但现实里，很多开发者栽在“图省事”上。

最有效的第一道防线是参数化查询（Prepared Statement）。拿Java的JDBC举例，你写 `PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE name = ?")`，再用 `ps.setString(1, userInput)` 绑定参数。数据库会先把SQL结构编译好，再把用户输入当纯数据处理，注入代码根本没有执行机会。Python的 `cursor.execute("SELECT ... WHERE name = %s", (name,))`、PHP的PDO预处理，原理都一样。这条防线能拦住九成以上的注入尝试。

总有人反驳：“我用了参数化，但动态表名、排序字段还是得拼字符串。”确实，有些场景参数化覆盖不了。比如用户要按某个列排序，你没法把列名当参数传。这时候就得靠白名单校验——写死一个允许的列名数组，用户传什么先查表，不在白名单里直接拒绝。别想着黑名单过滤，攻击者的编码变种能绕晕你，`/*!50000union*/`、十六进制编码、注释符拆分，黑名单永远追不上。

第二道防线是最小权限原则。很多小团队图方便，应用连接数据库直接用root或sa账号。一旦注入成功，攻击者能删库跑路。正确做法是给应用单独建账号，只授SELECT、INSERT、UPDATE、DELETE权限，绝不能给DROP、ALTER这类DDL权限。有个真实案例：某内部系统被注入后，攻击者发现连接账号没权限读其他库，只能在一张表里折腾，最后只窃走了几条测试数据——权限卡住了损失边界。

光有权限还不够，得防“盲注”。攻击者看不到查询结果时，会通过页面响应时间或布尔值差异来逐字符猜数据。这时候错误信息处理就派上用场。生产环境里，数据库报错信息绝不能直接吐给前端。你想想，攻击者看到 `You have an error in your SQL syntax; ... near '1' LIMIT 1'`，等于拿到了数据库类型和语句结构的线索。统一封装异常，对外只返回“请求无效”这种模糊提示，对内才记录详细日志。

还有个细节容易被忽略——WAF（Web应用防火墙）。它不是万能药，但能当缓冲。比如阿里云盾、Cloudflare的SQL注入规则，能拦截大量扫描器的低级尝试。可别全指望它，规则总有绕过空间，而且WAF误报会烦死正常用户。我见过一个项目，WAF把用户昵称里的“or”全给拦了，导致叫“Orange”的人注册不了——这种过度防御比漏洞还闹心。

最后说点实际的。代码上线前用sqlmap这类工具做一次自动化扫描，能发现八成常见注入点。但工具扫不出业务逻辑里的问题，比如某个参数虽然用了参数化，但另一个接口却把同一参数拼进了动态SQL。所以人工代码审查不能省，重点盯那些用了字符串拼接的地方。

写代码时养成肌肉记忆：任何接触数据库的操作，先问自己“这个值能不能被用户控制？如果能，我有没有用参数化？”别信前端校验，那玩意儿改个请求就绕过了。数据泄露这种事，一次就够让公司上头条。你不想成为那个在搜索框里被输入 `'; DROP TABLE users;--` 然后对着空数据库发呆的人吧？