生产环境禁用sqlmap主动扫描，应采用被动监听+语义分析：在nginx/apisix层采样sql日志，在orm/db中间件埋点捕获拼接行为，并用grep/awk快速定位高危代码，修复需区分场景并基于ast解析而非字符串替换。
生产环境不能直接跑 sqlmap 扫描
直接对线上服务发 sqlmap -u "https://api.example.com/user?id=1" 这类请求，极大概率触发 WAF 封禁、数据库慢查询告警，甚至因报错注入导致敏感信息泄露到响应体里。真实生产环境的检测必须绕过“主动打靶”逻辑，转为被动监听 + 语义分析。
可行路径是：在 Web 服务器或应用网关层（如 Nginx、APISIX）开启 SQL 关键字日志采样，再用轻量规则过滤出高风险模式；同时，在 ORM 层或 DB 中间件（如 MyBatis、Sequelize、SQLAlchemy）埋点，捕获原始 SQL 拼接行为。重点盯住这些信号：
-
query字符串中含' OR 1=1、UNION SELECT、CONCAT(、SLEEP(等组合 - 参数值未经过
bind_param或execute(...)调用，而是直接拼进query - HTTP 请求中
Referer或User-Agent出现明显 Base64 编码的 SQL 片段
用 grep + awk 快速筛出高危代码位置
不需要等完整 AST 分析工具上线，先用 shell 命令快速定位风险源。在 PHP/Java/Python 项目根目录执行：
grep -r "\.query.*'" --include="*.php" . | grep -v "prepare("
grep -r "String sql =.*\+.*;" --include="*.java" .
grep -r "f\".*{.*}.*\"" --include="*.py" . | grep -E "(cursor\.execute|connection\.execute)"
这些命令直击最常见漏洞写法：PHP 里没用 prepare() 却用了单引号拼接；Java 里字符串拼接赋值给 sql 变量；Python 里 f-string 插入变量后直接进 execute()。注意避开测试文件和框架自动生成代码（如 vendor/、target/、__pycache__/）。
修复必须区分场景：ORM 自动化绑定 ≠ 原生 SQL 手动转义
参数化不是万能胶水，不同场景修复方式差异很大：
- 用
PDO::prepare()或mysqli_prepare()的 PHP 项目：把"SELECT * FROM user WHERE id = '" . $_GET['id'] . "'"改成$stmt = $pdo->prepare("SELECT * FROM user WHERE id = ?"); $stmt->execute([$_GET['id']]); - MyBatis XML 映射：禁用
${}，强制改用#{}，并确认parameterType正确声明类型 - 遗留系统里硬编码的原生 SQL（如存储过程调用）：加一层白名单校验，比如
in_array($table_name, ['user', 'order', 'product'])，禁止任何动态表名 - 日志或调试语句中的 SQL 拼接：这类不进数据库，但可能被攻击者利用做二次注入，必须删掉或改用占位符 +
printf类函数
自动化修复脚本要防“越修越漏”
用正则批量替换 "' . \$var . '" 为 "? " 看似高效，实际会破坏嵌套逻辑。比如这段 PHP：
$sql = "SELECT * FROM user WHERE name LIKE '%" . $_GET['q'] . "%'";
如果盲目替换成 "SELECT * FROM user WHERE name LIKE '%?%'"，? 就不会被当成参数，而是字面量。正确做法是提取变量、补全通配符、再绑定：
$q = '%' . $_GET['q'] . '%';<br>$stmt = $pdo->prepare("SELECT * FROM user WHERE name LIKE ?");<br>$stmt->execute([$q]);
真正可靠的自动化修复，必须基于 AST 解析（如 PHP-Parser、javaparser），而非字符串替换。小项目可人工改，中大型系统建议接入 SonarQube + 自定义规则，把“拼接 SQL 字符串后调用 execute”设为 BLOCKER 级别问题，卡在 CI 流程里。
