同一条拦截规则，放在不同业务入口上，可能一个能挡住攻击，另一个却会误拦正常请求。要回答“SQL注入请求拦截规则如何调优”，先分清问题来自入口范围太宽，还是检测阈值太敏感：前者优先考虑白名单，后者再评估阈值。两者不是互相替代，调整前都要保留拦截日志和回退方案。
先判断要收窄入口，还是放宽检测
白名单的重点是限定哪些请求可以按特定规则例外处理，例如某个明确的业务路径、参数名或请求类型。它能把例外控制在较小范围，适合接口用途清楚、参数结构稳定的场景；缺点是配置维护较细，业务改版或新增参数后，旧规则可能不再适用。白名单不应等同于整条路径放行，更不能因一次误报就关闭该入口的注入检测。
阈值调整则改变规则需要达到多强的风险信号才拦截。它适用于多条检测规则共同打分、误报来源分散的情况，修改后覆盖面较广，但也可能同时放过其他入口上的可疑请求。若只是一处固定入口的正常参数触发告警，优先做范围受限的例外通常比整体抬高阈值稳妥。
| 方法 | 更适合的情况 | 主要代价 |
|---|---|---|
| 白名单 | 误报集中在少数已确认的入口或参数 | 配置需要随接口变化维护 |
| 阈值调整 | 多个规则的风险评分普遍偏敏感 | 可能降低其他入口的拦截力度 |
按可回退的流程调优
- 先收集证据。在 WAF 日志中核对触发时间、规则编号、命中字段、处置动作和对应业务结果。对照正常请求与可疑请求，确认是业务输入导致误报，还是检测到真实风险；不要仅凭用户反馈直接放行。
- 划定最小范围。确认受影响的路径、参数和必要的请求条件。若误报只对应一个稳定参数，可建立只针对该组合的白名单例外；避免按来源地址或整站设置宽泛放行，以免把其他请求一并排除。
- 先观察，再小步修改。若产品支持仅告警或监控模式，可先观察一个有代表性的业务周期；常见做法是覆盖约一至两周，但发布周期、流量波动和低频功能会影响所需时长。证据表明是整体评分过敏时，才小幅调整阈值，每次只改一项，并记录旧值和原因。
- 回归并检查副作用。用已确认的正常业务请求验证误报是否消失，再用授权的安全测试用例验证拦截仍生效。灰度发布后持续查看误报、漏报线索和业务失败情况；若风险信号变弱或影响扩大，立即恢复原配置并重新分析。
规则之外，还要修复根因
WAF 属于边界防护，不能替代应用代码修复。开发侧应优先采用参数化查询，避免把用户输入直接拼进数据库语句；同时检查动态表名、排序字段等无法直接参数化的部分，使用明确的允许值映射。对已经确认的缺陷，可把有限范围的拦截规则作为虚拟补丁，但应安排代码修复和回归测试。
实际决定“SQL注入请求拦截规则如何调优”时，可按误报分布来选：单点、稳定、可明确定位的误报，先收紧白名单例外；多入口、同类规则持续误报，再审慎调整阈值。无论选哪种方式，都要记录变更、验证安全效果并保留回滚路径。
常见问题
白名单能不能直接放行整个接口？
不建议。应限定到确有误报的参数和必要条件，并保留其他检测规则。
调高阈值后误报减少，是否就算完成？
不算。还要验证可疑请求是否仍能触发拦截，并检查其他入口的告警变化。
低流量功能观察多久合适？
按其实际使用周期决定；一至两周可作为常见观察起点，若未覆盖关键流程，应延长观察或安排受控回归。
