SQLMap是SQL注入漏洞检测工具而非防护工具，需结合人工审计确认真实风险。它默认仅测GET/POST参数，需指定--level或--headers检测HTTP头；盲注推荐--technique=B更隐蔽；绕过WAF前须先验证其存在性；扫描后必须核查代码是否真实拼接SQL、列数是否匹配业务逻辑、动态执行语句是否被遗漏。
SQLMap 不是防注入工具，而是攻击模拟器
它本身不提供防护能力，只帮你验证现有系统是否已被 SQL 注入漏洞覆盖。用错定位，容易误以为“扫完没报错=安全”，其实只是当前 payload 没触发而已。
- SQLMap 默认只检测
GET和POST参数，忽略Cookie、User-Agent、Referer等头部字段，除非显式加--level 3或指定--headers - 默认测试等级（
--level 1）只测 URL 参数，--level 2加上 Cookie，--level 3才覆盖 HTTP 头 —— 很多真实漏洞藏在X-Forwarded-For或自定义 header 里 - 盲注场景下，
--technique=B（布尔盲注）比--technique=T（基于时间的盲注）更隐蔽，但耗时长；而生产环境常禁用 sleep 类函数，导致T技术失效，却漏掉B能打穿的情况
绕过 WAF 前先确认它真在工作
很多人一上来就堆 --random-agent、--tamper=space2comment，结果发现连基础报错都没触发 —— 因为 WAF 根本没生效，或者只拦了部分路径。
- 先用最简 payload 验证 WAF 存在性：
sqlmap -u "https://api.example.com/user?id=1" --string="User ID: 1"，观察返回是否被截断或返回 403/503 -
--identify-waf只能识别常见规则集（如 ModSecurity、Cloudflare），对定制化规则无效；真正有效的办法是看响应头有没有X-WAF-Status、Server: yunjiasu这类线索 - WAF 日志比 SQLMap 输出更可信：如果后端 Nginx access log 里根本没记录请求，说明流量在边缘就被拦了，此时再调 tamper 也没意义
如何让 SQLMap 结果反映真实风险等级
默认 --batch 模式会跳过交互确认，但也会跳过关键上下文判断，比如某个参数看似可注入，实则只用于日志拼接、不进数据库执行。
- 务必加
--dbms=mysql（或postgresql/mssql）明确目标，否则 SQLMap 可能用错语法试探，导致误报或漏报 - 用
--dump前先--tables，再--columns -T users，避免直接 dump 整库触发风控；有些系统对SELECT * FROM敏感，但对SELECT id,name FROM放行 - 遇到
[CRITICAL] reflective value(s) found提示，别急着记为高危 —— 反射型输出可能只是前端 JS 渲染，后端根本没查库，得结合代码或响应体结构人工验证
扫描完成后必须人工补位的三件事
SQLMap 给出的 [INFO] fetched data logged to 路径只是原始输出，不是风险结论。很多团队扫完就归档报告，结果上线新接口时复用旧逻辑，漏洞照旧。
- 检查所有被标记为
vulnerable的参数，确认其对应后端代码是否真的拼接 SQL —— ORM 的.filter(id=request.GET['id'])通常安全，但raw("SELECT * FROM user WHERE id = %s" % request.GET['id'])就危险 - 留意
UNION类型注入的列数限制：SQLMap 报8 columns，不代表业务 SQL 一定有 8 列，可能是它自动猜出来的，实际业务 SQL 可能只有 3 列，但 UNION 后多出的列填了NULL或0来对齐 - 临时表、CTE、存储过程里的注入点 SQLMap 极难发现，尤其是
EXEC(@sql)这类动态执行，必须靠代码审计补全
真正卡住人的从来不是工具会不会跑，而是哪条语句进了数据库、谁拼的、有没有进 prepared statement 流程。这些信息 SQLMap 不会告诉你，得翻代码、看 ORM 配置、查 query log。
