sql注入检测易误报因规则过于宽泛且缺乏上下文识别；应结合语法特征、编码解析、业务场景动态调整，并通过日志反馈闭环优化规则。

为什么SQL注入检测规则容易误报

误报主要来自规则过于宽泛——比如把所有含 UNION SELECT 的请求都拦截，但真实业务里可能有合法报表导出、多表联合查询接口；又或者对 ' OR 1=1 -- 这类经典 payload 做字符串匹配，结果用户昵称里写了“OR”、商品描述含“1=1”，全被当成攻击。底层问题是：规则没区分上下文，也没考虑编码变形（如 %27OR%201%3D1）和正常业务语义。

用正则+语法特征组合替代纯关键字匹配

单纯查 ' 或 -- 必然误杀。真正有效的规则要同时满足多个条件：

• 请求中存在未编码的 SQL 注释符（--、#、/*），且出现在引号闭合后（说明已脱离字符串上下文）
• 出现 UNION、SELECT、INSERT 等 DML 关键字，且前后有空格或换行，不是作为字段名或注释内容出现
• 参数值中包含连续的数据库函数调用，如 @@version、user()、database()，且未被引号包裹
• URL 或 POST body 中存在明显编码混淆，如 %27%20OR%20%271%27%3D%271，但解码后符合注入结构

示例（Nginx WAF 规则片段）：

Free Ride - Unlimited free AI

一款AI工具，主要用于管理 OpenClaw 所使用的来自 OpenRouter 的免费 AI 模型。自动按质量对模型进行排序，配置回退机制以应对速率限制，并更新 opencla...，适合需要提升相关任务效率的用户。

下载

SecRule ARGS "@rx (?i)(?:^|[^a-zA-Z0-9_])((?:UNION\s+ALL\s+SELECT|SELECT\s+\*.*FROM\s+)|(?:(?:\-\-|#|\/\*)\s*[^\r\n]*$))" "id:1001,phase:2,block,msg:'Possible SQLi via syntax pattern'"

结合请求上下文动态调整敏感度

同一段 payload，在登录页和后台管理页的风险等级完全不同。规则必须分场景：

• 对 /api/login、/user/profile 这类认证相关接口，启用高敏感规则（如检测 OR 1=1 逻辑绕过）
• 对 /report/export、/dashboard/data 这类允许复杂查询的接口，禁用 UNION 检测，改用行为分析（如单次请求中 SQL 语句长度突增 300%）
• 对静态资源路径（/static/、/images/）直接跳过 SQL 注入规则
• 识别 Content-Type：若请求头是 application/json，则只检查 JSON value 字段，忽略 key 和结构体本身

用日志反馈闭环优化规则

规则上线后，不能只看拦截数，重点看被拦住的请求是否真含恶意意图：

• 记录所有触发规则的原始请求（脱敏后），每周抽样人工复核，标记误报样本
• 对高频误报 pattern（如某电商系统常传 size='L'），加白名单例外：SecRule ARGS:size "@streq 'L'" "id:1002,phase:2,pass,nolog,tag:whitelist"
• 发现某条规则误报率 >15%，自动降级为 log, no block，并告警通知安全团队
• 定期用历史流量重放测试：把过去 7 天的全部访问日志跑一遍规则，对比拦截率与人工标注结果

真正难的不是写一条能拦住攻击的规则，而是让规则在不干扰正常业务的前提下持续有效——这需要反复观察、收缩范围、引入上下文，而不是堆砌关键词。