推荐用sqlmap配合代理日志回放进行SQL注入持续检测，优先导出HAR/Burp格式请求逐条扫描，禁用高危参数，结合静态分析识别危险拼接点，并以参数化查询为唯一安全实践。
SQL注入扫描该用什么工具做持续检测
生产环境不能靠人工肉眼审代码防注入，必须引入自动化扫描。推荐优先用 sqlmap --batch --level=3 --risk=2 搭配自建代理日志回放，而不是直接扫线上接口——它默认的 aggressive 模式容易触发 WAF 封禁或写入脏数据。
更稳妥的做法是把应用所有 HTTP 请求（含 POST body、URL 参数、Cookie）导出为 har 或 burp xml 格式，用 sqlmap -r request.txt --skip-static 逐条跑。静态资源路径（如 /static/、.js）必须加 --skip-static，否则浪费时间还可能误报。
- 别用
--os-shell或--sql-shell扫生产库，哪怕只是测试权限 - 扫描账号必须是最低权限 DB 用户，禁止用
root或sa - 若应用用了 ORM（如 Django 的
filter()、SQLAlchemy 的query.filter()），多数参数化查询已免疫，但手拼 SQL 的raw()或text()调用仍要重点标出
怎么识别代码里真正危险的 SQL 拼接点
不是所有字符串拼接都等于漏洞，关键看变量是否未经转义就进 SQL 字符串。典型高危模式包括："SELECT * FROM user WHERE id = " + user_id、f"WHERE name LIKE '%{keyword}%'"、str.format() 套入用户输入。
安全写法只有一种：参数占位符。MySQLdb 用 %s，psycopg2 用 %s 或 %(name)s，SQLite3 用 ? —— 这些由驱动层做类型绑定，根本不会进 SQL 解析器。
-
cursor.execute("SELECT * FROM t WHERE id = %s", [user_id])✔️ 安全 -
cursor.execute(f"SELECT * FROM t WHERE id = {user_id}")❌ 危险，哪怕 user_id 是 int 类型也绕不过 - ORM 中
User.objects.raw("SELECT * FROM auth_user WHERE id = " + str(id))❌ 绕过 ORM 保护
为什么 WAF 拦不住所有 SQL 注入
WAF 靠规则匹配关键字（如 UNION SELECT、sleep(1)）和异常响应码，但绕过手段太多：大小写混写（UnIoN SeLeCt）、编码（%252f 表示 /）、注释符拆分（UNI/**/ON SEL/**/ECT）、或用时间盲注（AND IF(1=1,SLEEP(3),0) 不触发关键词）。
更麻烦的是，WAF 对 JSON body、GraphQL 查询、HTTP/2 头部字段支持不一，有些连 Content-Type: application/json 里的 {"id": "1 OR 1=1"} 都不解析。
- 别把 WAF 当防火墙用，它只是最后一道沙袋，不是混凝土墙
- 真正有效的防护在应用层：输入校验（如 ID 必须是正整数）、输出编码（HTML context 用
html.escape()）、最小权限 DB 账号 - 扫描发现的漏洞，必须定位到具体代码行修复，不能只靠 WAF 规则临时拦截
定期扫描的频率和范围怎么定才不流于形式
每周全量扫一次开发环境 API 文档生成的 endpoint 列表（Swagger/OpenAPI），每次上线前必须扫本次变更涉及的接口；数据库权限变更、中间件升级（如从 MySQL 5.7 升到 8.0）后也要补扫——新版本语法特性（如 JSON_EXTRACT）可能带出旧逻辑没覆盖的注入面。
扫描结果不能只存报告，要自动写入 issue 系统并关联代码仓库 commit hash，超 48 小时未关闭的漏洞标记为阻塞项，CI 流水线卡住发布。
- 忽略
401/403接口——没认证就扫不到业务逻辑，纯属浪费资源 - 跳过已知无参接口（如
GET /health），除非它内部动态读取 query 参数 - 对 GraphQL 接口，必须用
graphql-introspection提取 schema 后，针对每个field的 resolver 参数生成测试用例，不能只扫根路径
最常被漏掉的是日志系统本身：如果错误日志把原始 SQL 语句打进了 ELK，攻击者通过 ORDER BY 报错就能反推表结构——这种“二次注入”不在常规扫描范围内，得靠代码审计盯紧 logging.info() 和 print() 里有没有拼接 SQL。
