打开扫描器报告的检测那一刻，红色告警直接糊在屏幕上：“目标URL存在SQL注入漏洞。到目”参数是注入id=1，Payload就一个单引号。漏洞网站返回了数据库报错信息，检测连表名都带出来了。到目这不是注入什么高深攻击，纯粹是漏洞开发忘了过滤。

我顺着URL手动测了一遍。检测原始请求是到目 http://example.com/product.php?id=1。把1换成 1'，注入页面立刻抛出一段MySQL语法错误。漏洞再换成 1 AND 1=1，检测页面正常；换成 1 AND 1=2，到目内容空了。注入布尔盲注确认。接着用 ORDER BY 猜列数，到第5列时报错，说明查询返回4个字段。整个过程不到三分钟，连工具都没开。

这种漏洞现在居然还能碰到，说实话有点意外。预编译语句普及了十几年，ORM框架满地跑，可实际渗透测试里，SQL注入仍然是中危起步、高危不封顶的常客。原因不复杂——老系统没人敢动，新系统赶工期直接拼SQL。我见过一个后台查询接口，参数用 base64 编码了一下，开发觉得“加密”了就安全，解码后照样拼接进 WHERE 子句。编码不是过滤，这道理讲一百遍还是有人踩坑。

报错注入是最省事的。数据库把错误信息直接吐回前端，攻击者连盲注都省了。updatexml 或者 extractvalue 配合 concat，一条语句就能把 database()、user()、version() 全带出来。我试过 id=1 AND updatexml(1,concat(0x7e,(SELECT database()),0x7e),1)，页面回显 ~test_db~。接着查表名，information_schema.tables 里捞出一堆，用户表叫 admin_user，密码字段是 md5 哈希。到这一步，离拿后台权限就差一个彩虹表。

盲注慢，但稳。时间盲注用 SLEEP(5)，页面响应延迟明显。我写了个简单脚本，按字符二分猜解，跑出管理员密码用了二十多分钟。这还是在网络稳定的情况下。真实攻击者不会这么温柔，sqlmap 挂上 --technique=BEUST，多线程一开，几分钟拖库。要是权限够大，--os-shell 直接拿服务器。很多运维觉得数据库只读账号就没事，可 LOAD_FILE 读敏感文件、INTO OUTFILE 写webshell，这些操作跟写权限挂钩，不是只读就能防住的。

修复方案没什么新意。参数化查询，绑定变量，别拼字符串。Java用 PreparedStatement，PHP用 PDO 的 prepare，Python用 cursor.execute 带占位符。框架层面，MyBatis的 #{ } 和 ${ } 区别讲烂了，还是有人用 ${ } 图方便。WAF能挡一部分，但绕过手法更新太快，注释符、大小写混写、内联注释、编码变形，总有一款能过。根本还在代码本身。

我习惯在报告里附上原始请求和响应截图，再把Payload列清楚。开发看了直接能复现，省得来回扯皮。有一次甲方运维说“我们用了云WAF，扫不出来”，我把请求发过去，他沉默了半天，回了句“确实能注入”。WAF不是免死金牌，它只是增加攻击成本，不是消除漏洞。

检测到SQL注入，别急着关报告。先确认是哪种类型，报错、布尔、时间还是联合查询。再看数据库权限，能不能读文件、能不能执行系统命令。最后给修复建议时，具体到文件和行号。安全这行，细节比结论重要。一个单引号能捅出多大篓子，取决于后面连着什么样的数据库。