弱防护waf仅依赖关键词正则匹配，不校验语义、忽略编码变形，而sqlmap通过--tamper=space2comment等脚本替换空格、混淆大小写，精准击中其检测盲区，故一试即穿。
因为弱防护系统通常只做关键词匹配、不校验语义、忽略编码变形，而 sqlmap 的 payload 生成机制天然针对这些短板设计。
WAF 检测逻辑太简单，sqlmap 一试就穿
很多小型站点用的 WAF（比如某些云厂商免费版、自研中间件）只靠正则匹配 UNION、SELECT、AND 这类明文关键字。一旦遇到空格被替换成 /**/、大小写混写（SeLeCt）、或用 %09（Tab）代替空格，规则就直接失效。
常见错误现象：
- 请求返回
403或406，但手工构造一个id=1%20OR%201=1却能绕过 -
sqlmap -u "http://x?id=1"直接被拦截，加--tamper=space2comment就通了
实操建议：
- 先用
--batch --level=3 --risk=2快速试探基础检测强度 - 若失败，立刻加
--random-agent和--tamper=space2comment,lowercase - 别迷信
--level=5：高 level 会发更多请求，反而更容易触发频率封禁
sqlmap 的 payload 不是“写死的”，而是动态适配的
它不是把一套 SQL 语句硬塞进去，而是根据响应内容（报错信息、布尔差异、时间延迟）自动切换技术路径：布尔盲注、时间盲注、报错注入、堆叠注入……每种路径下 payload 的结构、编码、分段方式都不同。
使用场景：
- 目标返回 MySQL 报错（如
You have an error in your SQL syntax），sqlmap会优先走报错注入，用extractvalue()或updatexml() - 目标页面无报错、无回显，但响应时间有波动，它自动切到时间盲注，用
SLEEP(5)或BENCHMARK() - POST 表单字段被过滤？它能单独对
username字段注入，不影响其他参数解析
容易踩的坑：
- 没加
--threads=3，单线程跑时间盲注，等 10 分钟才出一个字符 - 误以为
--dbms=mysql能加速，其实如果服务端实际是 MariaDB，部分函数行为不一致，导致 payload 失效 - 忽略
--skip-static：静态资源（CSS/JS）响应体大、变化少，会被sqlmap当作噪声跳过，不必要地拖慢扫描
弱防护系统常忽略 HTTP 层细节，而 sqlmap 正好补上
很多防护只看 GET 参数或 POST body，却漏掉 User-Agent、Referer、X-Forwarded-For 这些 header 字段。更常见的是，后端用了 Nginx + PHP-FPM 架构，但 WAF 只检查了 Nginx 层，PHP 层仍原样解析 $_GET 和 $_SERVER['HTTP_X_FORWARDED_FOR']。
实操建议：
- 用
--headers="X-Forwarded-For: 127.0.0.1" --level=4强制让sqlmap把注入点扩展到 header - 发现
403但 UA 是sqlmap/1.8.12#stable？立刻加--random-agent或手动指定-A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" - 若目标支持 HTTPS 和 HTTP 并存，直接换
http://协议重试——不少 WAF 只部署在 HTTPS 入口
真正难绕过的不是规则本身，而是那些默认关闭、但开启后能精准识别语义的模块（比如基于 ML 的 SQL 行为建模、带上下文的 AST 解析）。普通 WAF 压根没开，或者开了也因性能原因只对登录页启用。所以 sqlmap 能“轻易”突破，本质是对手没真设防。
