去年冬天，入漏一个做电商的洞修朋友半夜给我打电话，说后台数据库里多了几百条垃圾评论，复工每条评论都带着一段奇怪的入漏SQL片段。他以为只是洞修普通灌水，结果第二天发现用户表里的复工手机号字段全被替换成了乱码。攻击者用了一个最基础的入漏联合查询注入，从评论提交框里塞进去的洞修。这件事让我意识到，复工很多开发者对SQL注入的入漏认知还停留在“知道有这回事”的阶段，真到修复的洞修时候，要么一刀切把参数全转义，复工要么直接上WAF了事，入漏根本没搞清楚漏洞到底出在哪一行代码。洞修

修复SQL注入，复工第一步不是写代码，是找入口。我见过一个团队用工具扫出两百多个“疑似注入点”，结果人工复核发现其中一百八十个是误报——那些参数根本进不了SQL语句，只是被拼进了日志或者HTML里。真正有效的做法是盯着数据流：从HTTP请求参数开始，跟踪它经过的每一个函数，直到它进入数据库驱动。中间只要有一次字符串拼接，就是嫌疑点。比如PHP里$sql = "SELECT * FROM users WHERE id = " . $_GET['id'];，这种写法没有任何辩解余地，必须改。

参数化查询是修复的核心手段，但很多人用错了。Java的PreparedStatement、Python的cursor.execute带占位符、Node.js的mysql2用?占位，这些才是正路。我见过有人把参数化查询写成SELECT * FROM users WHERE name = '?'，把问号包在引号里——这等于没改，数据库会把问号当普通字符处理。正确写法是WHERE name = ?，引号由驱动自动处理。还有存储过程，如果里面用了动态SQL拼接，照样有注入，别以为套个存储过程就安全了。

工具能帮上忙，但别指望全自动。sqlmap适合验证漏洞存在性，不适合修复。静态代码扫描工具比如Semgrep、CodeQL，可以批量找出拼接SQL的模式，但误报率不低。我自己的习惯是：先用CodeQL跑一遍，把疑似点导出来，然后人工过一遍数据流。修复阶段，IntelliJ IDEA的“SQL注入检查”插件能在写代码时实时提示，比事后扫描强得多。另外，像OWASP ZAP这种动态扫描工具，可以在测试环境里模拟攻击，验证修复是否彻底。

有个细节容易被忽略：ORDER BY和LIMIT后面的参数。很多人觉得这两个位置没法用参数化查询，就直接拼接，结果留下注入点。MySQL的ORDER BY后面不能直接用占位符，但可以用白名单校验——比如只允许ASC或DESC，列名限定在预设的几个字段里。LIMIT的数字参数可以直接用整型转换，intval($_GET['limit'])比任何转义都可靠。

修复完之后，别急着上线。写几个测试用例：单引号、双引号、分号、注释符--、/* */，还有UNION SELECT这种组合。扔进输入框，看返回结果是否正常。如果页面报数据库错误，说明错误信息没屏蔽，这也是漏洞的一部分——攻击者靠报错内容就能推断表结构。生产环境必须关掉display_errors，日志里也别记完整SQL语句。

最后说个真实案例。某开源CMS的搜索功能，用了参数化查询，但排序字段是从URL里取的，开发者觉得“排序字段又不是用户数据”，直接拼进去了。结果攻击者构造?sort=id,(SELECT ...)，照样把数据拖走。修复方案很简单：把排序字段映射成白名单数组的索引。$allowed = ['id','title','date']; $order = $allowed[$_GET['sort']] ?? 'id';。三行代码，漏洞没了。工具再智能，也替代不了对数据流的理解。