sql漏洞扫描工具

去年一家做跨境电商的洞扫客户找我做应急响应，服务器上跑着某开源商城系统。描工攻击者没用什么高深手段，洞扫就是描工手工构造了一条 id=1 AND 1=2 UNION SELECT ... 的请求，把用户表整个拖走了。洞扫事后复盘，描工他们的洞扫代码里其实有过滤函数，但只过滤了单引号，描工没管 UNION 和注释符。洞扫这种半吊子防护，描工在真实攻击面前跟没锁门差不多。洞扫

SQL注入活了二十多年，描工依然排在 OWASP Top 10 里。洞扫原因不复杂——只要还有人手拼 SQL 字符串，描工这漏洞就灭不干净。洞扫而 sql 漏洞扫描工具的价值，就是在攻击者之前，把那些拼错的、漏过滤的、逻辑写歪的地方找出来。

这类工具到底在扫什么

很多人以为扫描器就是拿一堆 payload 往参数里塞，看报不报错。这只说对了一半。现代 sql 漏洞扫描工具大致分两种路子：一种基于报错和布尔盲注的探测，另一种基于时间盲注和堆叠查询。前者快，但遇到关闭了错误回显的站点就抓瞎；后者慢，可往往能挖出更隐蔽的问题。

我见过一个扫描器，对每个参数会依次尝试：单引号闭合、数字型注入、括号闭合、编码绕过。它甚至会根据响应时间的变化来判断 SLEEP(5) 是否被执行。这种工具跑起来噪音不小，WAF 日志里能刷出几千条告警。所以生产环境用的时候，得挑低峰期，或者干脆在测试环境先跑一遍。

工具的能力边界也很明显。它擅长发现“参数直接拼进 SQL”这种经典漏洞，但对二次注入、存储过程里的动态 SQL、以及 ORM 框架的误用，识别率就掉下来了。我试过几款主流工具扫一个用了 MyBatis ${ } 拼接的项目，只有一款报了出来，其余全漏。

一次真实的扫描记录

上个月帮朋友看一个内部管理系统。我用 sqlmap 跑了一遍，--level=3 --risk=2，半小时后它标出一个 sort 参数存在布尔盲注。手工验证：sort=name' AND '1'='1 返回正常，sort=name' AND '1'='2 返回空列表。后端代码是把 sort 直接拼到了 ORDER BY 后面。开发觉得“排序字段用户看不到，没事”，可攻击者能通过盲注逐字符猜出数据库名、表名，甚至管理员密码哈希。

修复方式倒是简单，白名单校验 sort 只允许 name、id、created_at 这几个值。但如果没有扫描器先发现，这个口子可能一直敞着。

工具选型和使用上的坑

sqlmap 名气最大，但别把它当唯一选择。商业工具里，Acunetix 和 Netsparker 对注入的检测更自动化，误报也少些，代价是贵。开源阵营里，jSQL Injection 的图形界面适合手工测试时辅助，而 NoSQLMap 专门对付 MongoDB 那类非关系型数据库的注入——对，NoSQL 也有注入，只是形态不同。

用扫描器最容易犯的错是“扫完就完”。工具报了个“可能存在注入”，你直接丢给开发，开发回一句“已修复”，然后呢？没有复测，没有回归。我习惯在修复后手动构造几条 payload 再打一次，确认真的堵上了。另外，扫描器跑出来的结果要结合代码看——它说 username 参数有问题，你得去翻对应的 DAO 层，看是预编译没生效，还是过滤逻辑写反了。

还有一点，别在没授权的情况下扫别人的站。扫描行为本身就会触发法律风险，这跟“我只是看看”是两码事。

它不能替代什么

扫描器能发现已知模式的注入，但发现不了业务逻辑层面的数据泄露。比如一个查询接口，参数做了预编译，可它没校验用户权限，A 用户能查 B 用户的订单。这种问题扫描器不报，可危害不比 SQL 注入小。

所以我的习惯是：扫描器当第一道筛子，快速过一遍常见漏洞；然后手工测权限、测越权、测异常输入。两者结合，才敢说这个系统“暂时没大问题”。工具是死的，攻击者的思路是活的。你依赖工具，工具就依赖规则；规则之外的东西，还得靠人。