sql注入漏洞检测工具

打开一个电商网站，入漏在搜索框里输入 ' OR '1'='1，洞检回车。测工如果页面返回了所有商品而不是入漏“未找到结果”，这个站点大概率存在 SQL 注入漏洞。洞检这不是测工什么高深攻击，一个没做输入过滤的入漏查询拼接就能造成这种后果。

SQL 注入的洞检本质很简单：应用程序把用户输入直接拼进 SQL 语句里，数据库分不清哪部分是测工代码、哪部分是入漏数据。攻击者构造特殊输入，洞检改变原 SQL 的测工执行逻辑，就能读走整张用户表、入漏绕过登录验证，洞检甚至执行系统命令。测工

为什么还需要专门的检测工具

手工测试一个参数可能只要几分钟，但一个中型 Web 应用有几百个接口、上千个参数。靠人力逐个试，不现实。检测工具的价值在于把重复的探测工作自动化，同时覆盖那些手工容易遗漏的角落——藏在 JSON body 里的参数、自定义 HTTP 头、Cookie 中的隐藏字段。

另一个现实问题是：很多开发者知道要防注入，但用的方法不对。比如只过滤了单引号，却没管双引号、反斜杠或数字型注入点。工具能系统性地测试各种绕过方式，比人脑穷举更靠谱。

工具大致分几类

第一类是代理型扫描器。 典型代表是 Burp Suite 的 Scanner 模块和 OWASP ZAP。它们工作在浏览器和目标服务器之间，拦截所有请求，然后对每个参数自动注入测试 payload。优点是覆盖全面，能跟着你的手动浏览路径走。缺点是流量大时容易卡顿，而且对 WebSocket 和某些前端加密的场景支持有限。

第二类是专用 SQL 注入工具。 sqlmap 是这里面最出名的。给它一个带参数的 URL，它会自动判断数据库类型、尝试多种注入技术（布尔盲注、时间盲注、报错注入、联合查询），最终帮你把数据拖出来。sqlmap 的 --batch 模式适合批量扫描，--technique 参数可以指定只用某几种注入方式，减少对目标的影响。

第三类是静态代码分析工具。 比如 Semgrep、CodeQL。它们不发送任何请求，直接扫描源码，找那些把用户输入拼进 SQL 字符串的位置。好处是零误报风险（对目标无影响），坏处是只能发现代码层面的问题，运行时动态拼接的场景容易漏掉。

实际用的时候会遇到什么

上周帮朋友看一个 Flask 写的后台。sqlmap 跑了一遍，报告说 id 参数存在时间盲注。但手工验证时发现，那个接口用了 SQLAlchemy 的 filter_by，理论上不该有注入。后来查出来是某个老接口用了 text() 直接拼字符串，sqlmap 扫的是那个废弃路由。工具报了漏洞，但定位需要人来看。

另一个常见问题是 WAF。目标站点挂了 Cloudflare 或 ModSecurity 之后，sqlmap 的默认 payload 会被拦截，返回一堆 403。这时候得换 --tamper 脚本，比如 space2comment 把空格替换成注释，或者 randomcase 随机大小写。但 tamper 脚本不是万能的，有些 WAF 会检测请求频率和参数长度，工具跑太快反而暴露。

还有误报。布尔盲注的检测依赖页面返回内容的差异。如果目标页面本身有随机广告或时间戳，工具可能把正常波动当成注入特征。所以扫描结果一定要手工复核，至少看一遍原始请求和响应。

检测之外的事

工具能告诉你“这里有洞”，但修洞是另一回事。参数化查询是根本解法，但老系统改造起来成本很高。有些团队用 ORM 之后以为万事大吉，结果在 order by 或 limit 后面拼了用户输入——这些位置参数化查询支持不好，照样出问题。

我的习惯是：开发阶段用 Semgrep 做静态检查，提交代码时卡一道；测试环境用 ZAP 做被动扫描，跟着功能测试走一遍；上线前用 sqlmap 对关键接口做一次定向探测。三层下来，大部分低级注入能拦住。剩下的，靠人看代码。

工具不会替你思考。它只是把重复劳动压缩了，让你有时间去看那些真正复杂的逻辑漏洞。