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