一个登录框，入教输入 ' or 入教1=1 -- ，回车。入教如果运气好，入教你就进去了。入教这可能是入教很多人对SQL注入的第一印象——像变魔术，又像开盲盒。入教

SQL注入的入教本质，是入教把你的输入变成SQL代码的一部分。服务器本来想问数据库：“用户名叫什么？入教”结果你塞进去一段话，让服务器把问题改成了：“把所有用户都给我。入教” 这不是入教黑客技术多高深，而是入教开发者太信任用户输入了。我见过不少系统，入教防护像纸糊的入教窗户，一捅就破。

拿个实际例子说吧。某电商后台有个搜索框，本来SQL是这么写的：SELECT * FROM products WHERE name LIKE '%' + 用户输入 + '%'。你输入一个正常词，它正常查。但你输入 %' UNION SELECT username, password FROM admin -- ，好家伙，商品列表直接变成了管理员账号密码。这种老掉牙的漏洞，现在依然存在。不是开发者不知道，是项目赶工期、测试不认真、或者干脆觉得“没人会这么干”。

注入点不只藏在登录框里。URL参数、Cookie、HTTP头，甚至上传文件的文件名，都可能变成注入通道。我碰到过一个案例，某个系统把用户ID放在URL里：user.php?id=1024。开发者做了整数校验，但没做权限判断。你改成id=1024 OR 1=1，虽然不报错，但返回了所有用户的数据。这算不算注入？算。它没破坏数据库，但泄露了信息，危害更隐蔽。

真正让人头疼的是盲注。页面不显示任何数据库报错，你输入什么它都返回“查询成功”或“无结果”。但你通过观察响应时间的差异，比如输入AND SLEEP(5)，如果页面卡了5秒才加载完，说明你的条件生效了。然后一个字符一个字符地猜数据库内容。这种活儿很枯燥，但自动化工具跑起来，一个晚上就能把整个库拖走。

你说，用参数化查询不就行了？对，这是最有效的办法。把SQL语句的结构和数据分开，用户输入永远只是数据，不会被当成代码执行。但现实是，很多老系统是拼接字符串拼出来的，改造成本高，业务方不愿意动。于是就有了各种“补充防护”：过滤关键字、转义特殊字符、用WAF拦截。这些措施有效吗？有点用，但治标不治本。攻击者总能找到绕过的方法，比如用/**/注释代替空格，用十六进制编码代替明文，或者利用数据库本身的函数特性。

我见过最离谱的一次渗透测试，目标系统把所有常见关键字都过滤了，包括select、union、and。看起来挺安全，但开发忘了过滤information_schema这个库名。攻击者用from information_schema.tables照样能读出所有表名。过滤黑名单的思路，永远在跟攻击者玩猫鼠游戏，而且猫经常输。

SQL注入的根子，是对数据与代码边界的漠视。你写SQL的时候，默认用户输入是“听话的字符串”，但用户从来都不听话。他们会输入表情符号、乱码、甚至SQL注释符。真正安全的写法，从一开始就把输入当敌人看待。参数化查询不是银弹，但它至少让你不用手动跟每个引号较劲。

最后说个扎心的事实：很多漏洞报告提交上去，开发团队的第一反应不是“怎么修”，而是“怎么证明这不是我们的锅”。等拖到被黑、数据泄露、罚款上门，才开始翻代码。那时候，代价已经翻了几十倍。你愿意花十分钟写一条安全的SQL，还是花几个月处理泄露事故？答案不言自明，但现实中，很多人选了后者。