自动化注入检测工具：它替我做了什么，又在哪几处会判错
网络安全实战 90 天 · Week 3 注入风险 | 难度 ★★ 入门 | 关键词：自动化检测 误报与漏报 扫描边界 检测报告 日志清理
手工一套流程走完要一个多小时，工具一条命令就能出结果。但工具给出的是「结论」，不是「事实」------这篇把它内部的判断逻辑拆开，重点看它在什么情况下会误判，以及出具报告前必须做哪些核对。全程只对自建靶场发起检测。
一、先明确一件事：工具做的是分类，不是证明
任何注入检测工具的核心都是同一套逻辑：给参数喂不同形状的输入，比较响应差异，按差异特征归类。它输出的「存在注入」本质是一个统计判断，判断依据是响应在若干次请求里的表现是否稳定复现。因此两类偏差必然存在：
| 偏差类型 | 产生原因 | 典型场景 |
|---|---|---|
| 误报 | 响应差异来自参数之外的变量 | 页面本身有随机内容、时间戳、广告位 |
| 漏报 | 差异存在但未达到工具的判定阈值 | 自定义过滤把差异压平、网络抖动盖过时间差 |
| 分类错 | 差异特征符合多种技术 | 同时具备报错与时间差特征时归错类别 |
说明 本文所有命令都指向本机 Docker 中的 DVWA 靶场（127.0.0.1）。在真实资产上运行任何自动化检测前，必须先确认在授权范围内，并控制请求速率，避免影响业务可用性。
二、准备：带上会话状态
工具不是浏览器，它拿不到登录态，必须把会话信息一起传进去。靶场还有一层安全级别开关，那个值同样要带上------否则工具面对的是加固后的分支，扫描结果会是「未发现」，而这个结论是假的。
bash
bash
sqlmap --version
# 浏览器 F12 → Application → Cookies，复制 PHPSESSID 与 security 两个值会话值形如 PHPSESSID=xxxx; security=low，两个都缺一不可。
2.1 这条坑值得单独说
会话值是有生命周期的，容器重启或主动退出就失效。扫描跑到一半突然开始返回登录页，九成是会话过期。这一点工具自己处理不了------它不会「重新登录一下试试」，这也是自动化在真实环境里最常见的失效原因：状态问题被误读成漏洞不存在。
三、基础检测
URL 里带 & 必须用引号包住，否则 shell 会把 & 当后台执行符，命令只跑前半截，看起来像什么都没发生。这个坑新手几乎都会踩一次。
bash
text
sqlmap -u "http://127.0.0.1/vulnerabilities/sqli/?id=1&Submit=Submit" \
--cookie="PHPSESSID=你的值; security=low"工具判定该参数存在注入，并且同时命中四种技术：布尔盲注、报错注入、时间盲注、联合查询。这个多技术输出很有参考价值------它说明该点的差异特征很典型，四种判定路径都成立。
四、逐级收窄
枚举的顺序和手工完全一致：库 → 表 → 列 → 数据。参数一层层缩范围，好处是每一步的请求量都可控。
bash
text
sqlmap -u "URL" --cookie="COOKIE" --dbs
sqlmap -u "URL" --cookie="COOKIE" --current-db
sqlmap -u "URL" --cookie="COOKIE" -D dvwa --tables
sqlmap -u "URL" --cookie="COOKIE" -D dvwa -T users --columns可用库有 dvwa、information_schema、mysql、performance_schema，当前库是 dvwa。dvwa 下两张表，用户表共 8 列，关键列是账号和口令。
五、数据导出与现场清理
指定列导出可以减少无关数据的落地量。工具还会自动拿内置字典去猜口令摘要------猜出来的直接显示明文，这是它比手工省事的地方，也是它最容易被误用成「批量破口令」的地方。
bash
text
sqlmap -u "URL" --cookie="COOKIE" -D dvwa -T users -C user,password --dump --batch
必做动作 工具默认把结果写入 ~/.local/share/sqlmap/output/ 下的会话日志，里面含完整请求与提取结果。测试结束必须清理这类落盘文件------这是自身测试痕迹管理，与目标侧无关，属于规范操作的一部分。另外 -C 参数后面每个列名之间不要留多余空格，否则会被解析成空列名，导出的表格会出现整列为空的情况。
六、无人值守模式的代价
--batch 让所有交互取默认值，配合全量导出可以一次跑完。省事，但代价是你不知道它中途做了哪些判断，也不知道那些判断有没有被误报带偏。
bash
text
sqlmap -u "URL" --cookie="COOKIE" --batch --dump-all我的做法是：自动化跑完之后，把关键几步单独再手工执行一遍，确认两边的判定类型和区间一致，才把结果写进报告。
七、误报与漏报的处理清单
| 现象 | 可能原因 | 核对动作 |
|---|---|---|
| 报「未发现注入」但人工感觉可疑 | 会话失效 / 安全级别不对 / 参数未进 SQL | 换有效会话重跑；手工对比两种输入的响应差异 |
| 报存在注入但手工复现不了 | 响应差异来自随机内容（时间戳、广告位、随机 ID） | 连续请求同一输入，看差异是否稳定复现 |
| 时间盲注判定的延迟不稳定 | 网络抖动 / 数据库负载波动 | 先测基线延迟，再提高延迟阈值重测 |
| 命中类型与手工结论不一致 | 多技术并存，工具归错类别 | 以手工能稳定复现的那一类为准 |
| 扫描极慢 | 在做盲注类检测，逐字符推断 | 限定检测技术，缩小范围 |
八、踩坑记录
| 坑点 | 症状 | 解决办法 |
|---|---|---|
| 扫不出注入 | 提示未发现注入 | 安全级别参数没带上，或会话已过期 |
| 命令只跑了一半 | 无输出直接回提示符 | URL 里的 & 没加引号，被 shell 截断 |
| 卡在交互提示 | 停在确认菜单不动 | 加 --batch 使用默认选项 |
| 扫描极慢 | 长时间无结果 | 在做盲注推断，限定检测技术 |
| 被过滤拦下 | 返回 403 或固定错误页 | 降低速率，或换检测策略，如实记录受阻 |
-
「未发现」不等于「不存在」。这是全文最需要记住的一条：工具没报，可能只是它没测到，或者测的时候状态不对。
-
「发现」也不等于「可利用」。判定的差异必须能稳定复现，否则只能记为待验证。
-
扫描速率要克制。生产环境上跑全量检测，可能直接把自己变成一次可用性事故。
九、小结
-
工具做的是分类判断，不是证明。任何结论都要回到手工复现这一步才算成立。
-
自动化最大的失效来源不是漏报，而是状态问题------会话失效、级别不对、参数变更，都会被读成「没有问题」。
-
会话状态、参数引号、交互模式这三个坑看似琐碎，实际占了新手失败原因的绝大多数。
-
报告里区分「工具报出」和「已复现」两档，是最基本的诚实。
下一篇进入盲注：当页面什么回显都没有的时候，怎么用「是 / 否」两个状态把数据一位一位问出来。