SQLMap能绕过WAF，但前提是先确认WAF存在、类型及拦截位置；需通过响应码、响应头（如cf-ray）、日志缺失等判断是否被边缘拦截，再结合--level=3测HTTP头、--tamper精准匹配规则缺陷，而非盲目堆叠。
SQLMap 能否绕过 WAF，取决于你是否先确认了它的存在、类型和拦截粒度——不是堆 --tamper 就能过，而是得让工具“看清对手再出招”。
怎么快速确认目标真有 WAF 在工作？
很多人一上来就加 --random-agent 或一堆 --tamper，结果发现连报错都没触发。其实流量可能根本没到后端。
- 先用最简 payload 测试：运行
sqlmap -u "https://target.com/?id=1" --string="expected_content"，观察返回是否被截断、跳转、或直接 403/503 - 检查响应头：
X-CDN、cf-ray、X-WAF-Status、Server: yunjiasu这些都是 WAF 留下的指纹 - 看 Nginx/Apache access log：如果日志里压根没这条请求记录，说明请求在边缘（CDN/WAF）就被丢了，此时调
--delay或换tamper都无效
为什么 --level 3 和 --headers 常被忽略却很关键？
SQLMap 默认只测 URL 参数（--level 1），但真实漏洞常藏在 HTTP 头里——比如 X-Forwarded-For、Referer、自定义 Api-Key 字段。
-
--level 2才开始测 Cookie；--level 3才覆盖所有 header，且会自动尝试常见注入点 - 更精准的做法是显式指定：
--headers="X-Forwarded-For: 127.0.0.1' AND 1=1-- "，避免盲目扫 - 不加这些参数时，即使
id=1被拦死，X-Forwarded-For里藏的注入也可能畅通无阻
--tamper 不是万能开关，选错等于白忙
每个 tamper 脚本针对的是特定规则缺陷，乱用反而增加特征、加速被封。
-
space2comment对抗空格过滤，但若 WAF 检查注释符号/**/，它反而暴露更多 -
randomcase混淆大小写，对只过滤小写union的规则有效，但对正则[uU][nN][iI][oO][nN]无效 - 生产环境常见组合：
--tamper=apostrophemask,space2plus（把'变%27，空格变+），比单个脚本更难被规则匹配 - 别迷信“全量 tamper”：
--tamper=charencode,randomcase,space2comment容易触发 WAF 的多层规则联动，不如分阶段试
绕过失败时，第一反应不该是换 tamper，而是看响应体结构
很多所谓“绕过成功”，只是 SQLMap 报了 [CRITICAL] reflective value(s) found，但实际输出是前端 JS 渲染的字符串，根本没进数据库。
- 手动验证反射点：在浏览器中输入
?id=1' OR '1'='1，看页面是否原样回显该字符串（而非执行 SQL） - 盲注优先用
--technique=B（布尔型），而不是--technique=T（时间型）——后者依赖SLEEP()，而多数生产库禁用该函数 - 加
--dbms=mysql显式指定数据库类型，否则 SQLMap 会用错语法试探（比如对 MySQL 发 PostgreSQL 的pg_sleep()），导致误报或漏报
真正卡住的地方，往往不是技术选项不够多，而是没搞清 WAF 是在请求入口拦、还是在应用层改写、或是靠行为模型动态封 IP —— 这些差异直接决定该调 --delay、换 UA，还是放弃自动化、切手工注入。
