直接跑 sqlmap -u 会触发WAF或写库，必须先手动验证注入点、禁用高风险参数、使用代理拦截请求、正确处理POST与token、指定数据库类型、控制线程数、谨慎导出数据并明确授权。
直接跑 sqlmap -u 会触发WAF或写库，别这么干
未经准备就对生产环境执行 sqlmap -u "https://prod.example.com/api?id=1"，极大概率被WAF拦截、日志告警，甚至因 --risk=3 类参数导致数据库被误删/改。真实测试中，90% 的误操作源于跳过前置确认步骤。
- 先用浏览器或
curl手动验证注入点：在参数后加'（如?id=1'），看是否返回数据库错误（如MySQL error）、空白页或响应延迟——这是判断能否进阶自动化的唯一可靠依据 - 禁用高风险行为：默认不加
--risk时是 1，但只要目标没明确授权，一律显式加--risk=1 --level=1 - 避免直接连生产库：用
--proxy="http://127.0.0.1:8080"接 Burp，把所有请求先拦下来人工过一遍 payload
--data 和 -r 用错会导致 POST 请求失效
遇到表单提交、JSON 接口或带 CSRF token 的请求，硬套 -u 会失败——sqlmap 不会自动解析隐藏字段或重放 token。
- POST 参数用
--data="username=admin&password=123"，不是拼在 URL 后；若含空格或特殊字符，整个值必须用单引号包裹：--data='{"user":"test","pwd":"a b"}' - 更稳的方式是抓包导出
request.txt（含完整 headers + body），再用-r request.txt；注意删掉Content-Length行，否则sqlmap会因长度不匹配而发空 body - 含 token 的场景必须配
--fresh-queries，否则复用旧 token 导致 403
--dbms 不指定，盲注耗时翻 3–5 倍
当目标响应无报错（纯布尔/时间盲注）时，sqlmap 默认尝试所有数据库类型，每个 payload 都要试 MySQL、PostgreSQL、MSSQL……这不仅慢，还大幅增加被识别为扫描的几率。
- 从 HTTP 响应头（
X-Powered-By）、报错片段（psycopg2= PostgreSQL）、或登录页源码（mysqli）推断后端，再强制指定：--dbms=postgresql或--dbms=mssql - 若完全无法判断，至少加
--technique=BEU（布尔+报错+联合查询），关掉耗时的T（时间盲注）和S（堆叠注入） -
--threads=3是安全阈值，超过 5 线程容易触发服务器限流
导出数据前必须确认 --dump 是否真需要全表
--dump -T users 看似简单，但实际会触发大量 UNION SELECT 查询，对低配数据库可能造成连接阻塞；更危险的是，若表含敏感字段（如 password_hash），导出文件默认明文存本地，极易泄露。
- 先用
--columns -T users看字段名，确认是否真要全部导出；只取必要列：--dump -T users -C "id,username,email" - 加
--no-cast避免sqlmap自动转编码导致乱码，尤其处理中文或二进制字段时 - 导出文件默认在
output/下，路径不可控——用--output-dir="/tmp/sqlmap-out"指向临时目录，并测试完立即shred或rm -rf
sqlmap 当成黑盒命令来 run。它不会帮你判断业务逻辑是否允许读取某张表，也不会替你承担绕过 WAF 后触发风控的后果。每一条 --dump 或 --os-shell 命令，背后都该有对应授权书和变更窗口期。 
