定位：只验证存在性
sqlmap 用一组构造请求比对响应差异，判断参数是否存在注入及其类型（布尔、时间、报错、联合查询等）。在评估场景里它的角色是取证与验证：确认可注入、留下最小证据、转交修复流程，而不是继续拿数据。取数、写文件与命令执行类功能一律禁用。
基本信息
| 用途 | 注入存在性与类型验证 |
|---|---|
| 关键参数 | --batch 非交互、--smart 快速判断、--level 与 --risk 控制强度 |
| 禁用项 | --dump、--os-shell、--file-read 等取数与执行功能 |
| 边界 | 仅授权 URL，限速，测试窗口内执行 |
| 证据 | 保留最小复现请求与响应，记录注入类型与位置 |
典型使用场景
- 参数化接口验证：确认查询参数是否可拼接，作为修复优先级依据
- 验证开发自查结论：开发声称已参数化，用最小请求复核是否真的生效
- 告警核实：安全设备报告的注入尝试，用受控方式确认是否真实可利用
- 复测：按原最小路径重放，确认修复后不再触发
- 风险沟通：给出注入类型与影响判断，供客户决策修复窗口
检测示例
检测示例
# 最低强度跑一遍，先确认是否存在注入点
sqlmap -u "https://example.com/item?id=1" --batch --level 1 --risk 1 --smart
# 带 Cookie 的认证场景：会话由客户提供并单次使用
sqlmap -u "https://example.com/item?id=1" --cookie="SESSION=REDACTED" --batch
# 记录注入类型与位置即可，不执行取数
# 需要 POST 参数时用 --data，仍保持同一强度
sqlmap -u "https://example.com/search" --data="q=1" --batch --level 1 --risk 1输出逐列读法
| 输出内容 | 含义 | 使用注意 |
|---|---|---|
| parameter | 被判定的注入参数 | 核对是否为业务参数而非测试残留 |
| Type | 注入类型 | 布尔与时间盲注对业务压力更大 |
| Payload | 触发判定用的载荷 | 只留最小样本，不批量枚举 |
| Title | 后端数据库线索 | 仅作参考，不作为精确版本结论 |
| back-end DBMS | 数据库类型判断 | 与资产台账交叉核对 |
注入验证可能触发锁表、慢查询与异常日志：在测试窗口执行并控制请求量，验证到可注入即停止。
提高 --level 与 --risk 会扩大测试面并明显增加请求量：只在明确需要且客户同意时逐步上调，不要一上手就用高强度。