SQLMap需人工干预调优才能准确识别注入点：默认不扫描HTTP头和JSON字段，须用--headers、--data等参数显式指定；--level/--risk过高易触发WAF或语法错误，应按环境降级调整；Generic类型需手工验证响应差异与时间延迟。
SQLMap 能自动发现大多数经典 SQL 注入点，但对参数化查询、WAF 拦截、JSON 请求体、存储过程调用等场景会漏报或误报——它不是“开箱即扫”，必须人工干预调优。
如何识别 SQLMap 实际生效的注入点类型
SQLMap 默认只测试 GET 参数和 POST 表单字段，对 Cookie、User-Agent、Referer、X-Forwarded-For 等 HTTP 头部字段默认不扫描。遗留系统常把关键 ID 放在 Cookie 中（如 session_id=abc123 或 user_token=xyz），若不显式指定，SQLMap 会直接跳过。
- 用
--headers手动注入头部字段：sqlmap -u "http://oldapp.example.com/profile" --headers="Cookie: user_id=1*" -p user_id - 对 JSON 接口，必须加
--data并设--content-type="application/json"，否则 SQLMap 当作普通表单解析，payload 会被 URL 编码破坏结构 - 遇到
ORDER BY或GROUP BY后的注入点（如?sort=name ASC），需用-p sort显式指定，并加--skip-static避免误判静态字符串
为什么 --level 和 --risk 参数调高反而扫不出漏洞
--level 控制测试位置（1=仅 URL 参数，3=含 Cookie/Headers），--risk 控制 payload 激进程度（1=布尔盲注，3=堆叠注入）。但遗留系统常有以下限制：
- 数据库为 Oracle 或 DB2 时，
--risk 3的堆叠语句（如; SELECT 1）直接报语法错，应降为--risk 2专注时间盲注 - Web 层有简单正则过滤（如拦截
union select），--level 5会尝试大量编码变体，触发 WAF 封 IP；实际应先用--level 2 --risk 1确认基础布尔盲注可行，再针对性绕过 - 某些老框架（如 Struts1）对
%字符做双重解码，--level 3自动插入的%2527（即 URL 编码的%27）可能被解成'后又被过滤，需用--tamper=space2comment换 payload 变体
如何验证 SQLMap 报出的 “Generic” 类型注入是否真实可用
SQLMap 常把响应差异小的点标记为 Generic（泛型注入），这类结果假阳性率高。不能直接信，要手工验证：
- 复制 SQLMap 输出的
testable parameter(s)行，提取原始请求（含 headers、cookies），用curl手动发两个对比请求：...id=1和...id=1 AND 1=1，观察响应长度、状态码、HTML 注释是否一致 - 如果返回
500但页面内容无变化，可能是错误被静默吞掉——改用AND SLEEP(5)测时间差，用time curl -s ...看耗时是否翻倍 - 当 SQLMap 提示
Parameter 'id' is vulnerable. Do you want to exploit?，别急着按 Y：先运行sqlmap -u "...id=1" --technique=B --dump -T users -C username,password --batch，强制限定技术类型（B=布尔盲注），避免自动切换到不可靠的报错注入
遗留系统里，最麻烦的不是找不到注入点，而是找到后无法稳定利用——比如某处看似可注入，但每次请求都触发数据库连接池重置，导致时间盲注误差超过 ±3 秒；或者 WAF 对 information_schema 关键字做全匹配拦截，但放行 INFORMATION_SCHEMA（大小写敏感）。这些细节不会出现在 SQLMap 日志里，得看响应原始 body 和 timing 曲线。
