SQLMap需人工调优才能精准识别注入点：默认不检测HTTP头与JSON字段，必须通过--headers、--data等参数显式指定；--level/--risk等级过高易触发WAF或语法错误，应根据目标环境适当降级；Generic类型需手工验证响应差异与时间延迟。
SQLMap 能够自动发现多数经典SQL注入漏洞，但对于参数化查询、WAF防护、JSON请求体、存储过程调用等复杂场景，容易出现漏报或误报——它并非“即开即用”的自动化工具，必须依靠人工干预与策略调优才能获得准确结果。
如何准确识别SQLMap实际检测到的注入点类型
首先需要纠正一个常见误解：许多人认为只需将目标URL提交给SQLMap即可完成扫描。实际上，SQLMap默认仅测试GET参数与POST表单字段，而像Cookie、User-Agent、Referer、X-Forwarded-For等HTTP头部字段，在默认配置下会被直接忽略。这在遗留系统渗透测试中尤为关键，因为老旧系统常将关键身份标识（如session_id=abc123或user_token=xyz）直接置于Cookie中。若未明确指定，工具将无法检测这些潜在的注入点。
- 此时需使用
--headers参数手动指定头部字段：sqlmap -u "https://oldapp.example.com/profile" --headers="Cookie: user_id=1*" -p user_id - 针对当前更普遍的JSON API接口，仅指定数据还不够，必须结合
--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级会使SQLMap尝试海量编码变体进行绕过，结果频繁触发WAF规则，导致源IP地址被迅速封禁。更务实的做法是，先使用--level 2 --risk 1等基础配置确认布尔盲注可行性，再针对性地设计绕过策略。 - 部分老旧框架（如Struts1）会对字符进行双重解码。当
--level 3自动插入%2527（即URL编码后的单引号%27）时，框架可能先将其解码为%27，再进一步解码为'，此过程若遭遇过滤机制，Payload便会失效。这种情况下，使用--tamper=space2comment等脚本切换Payload变体，成功率更高。
如何验证SQLMap报告的“Generic”类型注入点是否真实有效
SQLMap常将响应差异不明显的潜在注入点标记为Generic（泛型注入）。此类结果的误报率较高，若直接采信可能导致徒劳无功。因此，手工验证环节不可或缺：
- 从SQLMap输出日志中找到
testable parameter(s)行，复制完整的原始请求（包含headers与cookies）。随后使用curl手动发送两组对比请求：一组为正常参数...id=1，另一组为携带注入条件的...id=1 AND 1=1。仔细比对两者的响应长度、HTTP状态码，乃至HTML源码中注释等细微差异。 - 若请求返回
500错误但页面内容无明显变化，可能是应用程序静默处理了异常。此时可切换至时间盲注进行验证，例如发送AND SLEEP(5)，并通过time curl -s ...命令测量请求耗时，观察是否产生约5秒的延迟。 - 当SQLMap提示
Parameter 'id' is vulnerable. Do you want to exploit?时，切勿急于确认。更稳妥的做法是先执行如下命令：sqlmap -u "...id=1" --technique=B --dump -T users -C username,password --batch。其中--technique=B是关键，它强制工具使用布尔盲注技术，避免自动切换至可能不稳定的报错注入模式。
在遗留系统安全评估中，最棘手的往往不是发现注入点，而是发现后无法稳定利用。例如，某注入点看似可用，但每次请求都会触发数据库连接池重置，导致时间盲注误差超过±3秒，难以准确判断。又如，WAF规则对information_schema关键字进行全匹配拦截，但若改为大写INFORMATION_SCHEMA反而能够绕过（部分WAF对大小写敏感）。这些关键细节通常不会直接记录在SQLMap日志中。要捕捉它们，必须亲自查看原始响应内容，并细致分析请求耗时的波动曲线。
