一个登录框，入代用户名输入框里敲进去' or 入代'1'='1，密码随便打几个字符，入代点登录。入代如果后台没做任何过滤，入代你就进去了。入代不是入代以管理员身份，而是入代以“第一个用户”的身份——往往是管理员。

这不是入代什么高深魔术。SQL注入的入代本质，是入代程序把用户输入直接拼进了SQL查询语句。你输入的入代内容不再是“数据”，而是入代变成了“代码”的一部分。服务器端那段查询逻辑，入代本意是入代SELECT * FROM users WHERE username='xxx' AND password='yyy'，你输入的东西让语句变成了SELECT * FROM users WHERE username='' or '1'='1' AND password='zzz'。单引号被闭合，or后面的恒真条件让整条WHERE子句失去意义。数据库老老实实返回了第一行记录——通常是管理员。

我见过最蠢的案例不是小网站，是某银行内部系统。2017年做渗透测试时，一个查询交易记录的接口，参数是交易流水号，数字类型。开发人员图省事，直接写String sql = "SELECT * FROM transactions WHERE id = " + request.getParameter("id")。测试时我在id后面加了个;DROP TABLE transactions;--，数据库差点没保住。后来问他们为什么不用预编译，回答是“老系统，改起来麻烦”。

预编译（PreparedStatement）能解决大部分问题，原理很简单：把SQL结构提前固定，用户输入只作为参数传递，数据库引擎在解析阶段就区分开了代码和数据。但总有人觉得预编译“不够灵活”，动态拼接表名、排序字段时习惯性用字符串加法。表名和排序字段不能参数化，需要白名单校验。这个细节，国内很多开发手册里都没写清楚。

还有一类注入藏在搜索框里。用户输入百分号%和下划线_，如果没转义，LIKE查询会匹配到所有记录。这不算传统注入，但会造成信息泄露。有个电商平台，搜索商品时输入%，后台返回了整张商品表——包括未上架的、成本价字段。这个漏洞修起来就一行代码，但没人想到。

更隐蔽的是二次注入。数据入库时做了转义，但取出后再拼接进其他SQL语句时忘了处理。攻击者注册用户名时写入' OR 1=1 --，数据库存的是转义后的字符串，看似安全。可后来某功能把用户名直接拼进更新语句，注入就生效了。这种坑，光靠输入过滤防不住，必须在所有拼接点都用参数化。

别指望WAF（Web应用防火墙）能兜底。规则库永远滞后于新变种，绕过WAF的姿势比想象中多——用注释符/*!50000*/、用十六进制编码、利用MySQL的版本特性差异。我见过一个团队，上了三层WAF，结果被一个JSON_UNQUOTE()函数绕过，因为WAF没解析JSON格式的请求体。

真正有效的防护，说起来就三条：第一，所有SQL语句一律预编译，动态部分用白名单；第二，数据库账号按最小权限分配，应用账号不该有DROP、DELETE权限；第三，错误信息别直接回显给用户——数据库报错里往往带着表名和字段名，那是给攻击者递刀子。

写代码的人总觉得自己不会踩坑，但SQL注入这坑，年年都有人踩。OWASP Top 10里它从2013年的第一名降到2021年的第三名，不是因为它变少了，而是因为其他漏洞更严重了。但实际攻防演练中，SQL注入依然是打点的主力手段——因为老系统太多，因为开发换了一茬又一茬，因为总有人的代码是赶工赶出来的。

最后说个细节。你写代码时，把SQL语句打印到日志里方便调试，这习惯本身没错。但生产环境的日志如果没脱敏，用户输入的原样SQL就会留在日志文件里。哪天日志文件泄露了，等于把注入点直接标给攻击者看。这不算SQL注入，但算是给它递了地图。

(责任编辑：娱乐)