一个分号，两个单引号，三个注释符。就这么点东西，让多少网站一夜之间变成裸奔的数据库。我见过最蠢的一次注入，是在某个电商后台的搜索框里直接敲了 ' or 1=1 -- ，结果页面把整个用户表的密码哈希全列出来了。那哥们儿甚至没加密传输，用的是HTTP明文。

MySQL注入的本质，说白了就是你把用户输入当成了SQL代码来执行。别觉得这是低级错误，2023年OWASP Top 10里注入仍然排第三。很多程序员写代码时有个坏习惯——字符串拼接查询。就像这样：SELECT * FROM users WHERE name = '" + username + "'。看着挺正常对吧？但如果username传进来的是 ' OR '1'='1，整个查询就变成了 WHERE name = '' OR '1'='1'。恒真条件，直接绕过登录。

更狠的是联合查询注入。攻击者先拿 ORDER BY 试探列数，一个一个试。报错就说明列数不对，试到不报错为止。然后拿 UNION SELECT 把数据往页面上怼。我见过一个漏洞报告，攻击者用这种方法把information_schema里的所有表名都拉出来了，包括一个叫 admin_session 的表——里面存着所有管理员的session token。整个过程不到五分钟。

别以为参数化查询就万事大吉了。有些场景你绕不开字符串拼接，比如动态表名、动态列名、ORDER BY子句。这时候你得白名单校验，把允许的值列出来比对。还有宽字节注入，老代码用GBK编码的，一个 %bf%27 就能把转义符吃掉。这玩意儿现在还有，我去年审计一个老PHP系统就撞上了。

时间盲注更阴。页面不报错，不回显数据，你只能靠 SLEEP(5) 这种函数判断条件真假。一个一个字符猜数据库名，慢是慢点，但自动化工具跑起来也就是几个钟头的事。我见过有人用这种方式从一个政府网站里拖出了几十万条身份证号，就因为他能通过响应时间推断出每个字符的值。

防御手段其实不复杂。参数化查询是底线，存储过程里也得注意动态SQL。输入校验别只做前端，后端必须再验一遍。数据库账号权限最小化，别用root连应用。错误信息别直接抛给用户，那些详细的报错提示是给攻击者看的免费情报。日志里记录所有SQL操作，出了事能溯源。

但最关键的还是人。我见过太多团队，开发的时候图省事，上线以后出问题才想起来补。安全测试不是最后阶段的走过场，是每个迭代都要做的事。你自己写代码的时候，每次拼SQL字符串就停下来想想——这个输入如果是恶意构造的，会发生什么？养成这个习惯，比装十个WAF都管用。

说句实在话，MySQL注入这玩意儿，只要你写SQL就有机会踩坑。别觉得自己技术好就掉以轻心，GitHub上那些几万star的项目照样爆出过注入漏洞。安全是个持续对抗的过程，你今天堵上的洞，明天可能换个姿势又冒出来。保持敬畏，保持怀疑，把每次用户输入都当成潜在的炸弹来对待，你才能在攻防博弈里多活几轮。