sqlmap不是验证抗注入能力的工具，而是模拟攻击者的探测器；它未报漏洞不等于代码安全，仅说明当前未打穿，需通过--level 3、--dbms、--string参数提升探测真实性，并人工核验反射内容、代码拼接逻辑及数据库函数限制，最终以全量参数化查询为唯一可靠防线。
sqlmap 不是“验证抗注入能力”的工具，而是模拟攻击者行为的探测器。它跑完没报漏洞，不等于你的代码安全——只说明它当前没打穿。真要验证抗注入能力，得让它打不进、打不深、打不稳。
为什么直接跑 sqlmap -u "xxx" 容易误判
默认命令只测 URL 参数，漏掉大量真实入口：Cookie、X-Forwarded-For、Referer、User-Agent 这些字段常被拼进日志或动态 SQL 里；--level 1（默认）根本不碰它们。
更麻烦的是，sqlmap 会把“页面返回空”“超时”“HTTP 500”都当作“可能可注入”，但实际可能是你后端做了拦截、限流或错误降级——它不会区分这是防护生效，还是单纯崩了。
必须加的三个参数才接近真实验证场景
-
--level 3：强制扫描所有 HTTP 头字段，包括自定义 header，很多业务逻辑从X-Api-Key或X-Tenant-ID取值拼 SQL，不扫头就等于绕过主战场 -
--dbms=mysql（或postgresql/mssql）：明确指定目标 DB 类型，否则sqlmap会用错语法试探（比如对 PostgreSQL 发 MySQL 的sleep()），导致漏报或假阳性 -
--string="expected_content"：告诉工具“正常响应里一定包含这段文字”，它才能准确判断布尔盲注是否生效；没这个，sqlmap靠响应长度/状态码猜，误差极大
扫完之后必须人工核验的三件事
自动化结果只是线索，不是结论：
- 看到
[CRITICAL] reflective value(s) found？先查响应体里那段“反射内容”是不是前端 JS 渲染的——后端根本没查库，只是把参数原样塞进 HTML，那不算 SQL 注入 -
--dump出来的数据，得反向确认：对应接口的代码里，是否真用了cursor.execute("SELECT * FROM users WHERE id = " + user_input)这类拼接？还是用了参数化查询？sqlmap不看源码，只看现象 - 如果某个参数扫出“基于时间的盲注”，但生产环境数据库禁用了
SLEEP()和BENCHMARK()，那这个结果实际不可利用——得换--technique=B（布尔盲注）再试一遍
真正能验证抗注入能力的底线动作
别只信 sqlmap 输出的“[INFO] heuristic test(s) …”——那是启发式猜测。最硬的验证方式只有一条：在你代码里找到所有拼 SQL 的地方，确认每一处都用了参数化查询（PreparedStatement、pg.query 绑定、cursor.execute(sql, params)），且没有 format、%、+ 拼接字符串的操作。 工具扫不出“写死的 SQL 字符串”，也发现不了 ORM 配置里 raw_query=True 这种后门。这些只能靠人眼+ grep。
