不能在未经书面授权的生产环境直接运行sqlmap，因可能触发WAF熔断、打满数据库连接池、写入日志引发告警，甚至造成业务中断；正确做法是隔离靶场复现+流量镜像分析+白盒辅助验证三步闭环。
不能在未经书面授权的生产环境里直接跑 sqlmap —— 这不是技术问题，是法律和运维红线。真要评估，必须走「隔离靶场复现 + 流量镜像分析 + 白盒辅助验证」三步闭环，否则一次 --risk=3 --level=5 就可能触发 WAF 熔断、数据库连接池打满，甚至写入日志导致业务告警。
为什么不能对生产 URL 直接 -u 扫描
真实生产系统通常有以下防护层叠加，sqlmap 默认行为极易暴露或中断服务：
- WAF 会拦截高频报错/延时请求，
--level=5自动启用的AND (SELECT ...)类 payload 几乎必被封 IP - 数据库审计策略可能记录所有含
UNION SELECT或SLEEP(的语句，触发 SOC 告警 - 应用层有 SQL 防注入中间件（如 MyBatis 的
#{}vs${}混用），sqlmap无法区分上下文，盲目 fuzz 会误判“可注入” - 部分参数实际走缓存（如 Redis key 拼接），
sqlmap的数据库指纹识别会失败，但你不知道它失败在哪一层
替代方案：用流量镜像 + 请求重放做无感探测
真正可行的生产侧评估，核心是绕过“主动发包”，改用已有流量做被动分析：
- 从 Nginx/Apache 日志或网关（如 Kong、APISIX）导出 24 小时含 query 参数的 GET/POST 请求，过滤出
?id=、?user_id=等高危模式行，保存为prod_requests.txt - 用
sqlmap -r prod_requests.txt --batch --skip-static重放 ——--skip-static会跳过 CSS/JS/图片等静态资源，只测带参请求 - 加
--proxy=http://127.0.0.1:8080接 Burp，人工确认可疑响应（如 HTTP 500 但 body 含 MySQL 错误码），避免误报 - 禁用所有高风险技术：
--technique=BEU（只用布尔盲注、报错注入、联合查询），不加--os-shell或--sql-shell
如何用白盒信息缩小检测范围
如果有代码权限或设计文档，比黑盒扫快 10 倍且零风险：
- 搜项目里所有拼接 SQL 的地方：Java 看
Statement.execute(、String.format("SELECT * FROM user WHERE id = %s", id)；PHP 看mysql_query(、mysqli::query( - 重点盯框架未拦截的场景：
ORDER BY ${field}、LIMIT ${offset},${size}—— 这些位置sqlmap的--union-cols很难自动猜中，但人眼一扫就发现 - 检查 ORM 配置：MyBatis 的
<bind name="pattern" value="'%' + _parameter + '%'" />是安全的，但${value}直接拼接就是雷 - 把确认存在拼接风险的接口 URL 列成清单，再用
sqlmap -m risky_urls.txt --level=3 --risk=1精准打点
最常被忽略的一点：哪怕拿到 --dbs 结果，也别急着 --dump。生产库往往有脱敏中间件（如 Apache ShardingSphere 的加密列），sqlmap 读出来的可能是密文或空值，而你根本不知道它被拦在哪一层。
