如何平衡误报与漏报？——解读CRS规则调整背后的思考逻辑

在网络安全防护中，**漏报（False Negatives）和误报（False Positives）**始终是一对难以调和的矛盾。作为知名的开源WAF规则集，**OWASP Core Rule Set（CRS）**在面对这类问题时，有一套成熟而严谨的决策流程。

本文将通过CRS近期对一起“SQL注入疑似漏报事件（Issue #4035）”的分析，带大家了解CRS是如何判断是否需要添加或修改规则，以及为什么有时选择“暂不处理”。

原文地址: https://coreruleset.org/20250415/false-negatives-false-positives-how-the-crs-team-decide-when-to-add-or-modify-rules-and-when-we-decide-not-to-add-them/

起因：一次未被拦截的SQL注入尝试

一位用户在CRS项目的GitHub上提交了Issue #4035，报告了数千条携带疑似SQL注入Payload的请求，并指出这些请求未能被ModSecurity和CRS拦截。
初看，这是一个典型的漏报问题（False Negative），需要引起足够重视。

项目新成员Michela Toscano 进行了复现测试，并编写了两条针对User-Agent头部的检测规则。在她的本地测试环境中，成功拦截了全部示例请求。

深入分析：简单添加规则并非总是好事

虽然初步规则似乎有效，但资深成员Christian Folini进行了更系统的测试后发现：

• 添加新规则确实提升了拦截率，但引发了大量误报（False Positives）。
• 进一步检查发现，这些请求中的“SQL语句”本身大概率只是无意义的垃圾数据，即使被服务器接收，也无法造成实际危害。
• 真正能够被利用的场景极其罕见，例如需要配合日志系统漏洞，且日志解析器如Logstash、Graylog出现处理缺陷。

综合评估后，CRS团队决定：暂不针对这类请求新增或修改现有规则。

为什么？CRS背后的决策逻辑

1. 风险权衡
   与引入大量误报相比，允许极小概率的漏报更符合整体用户利益。
2. 定位清晰
   CRS的定位是拦截通用攻击模式，而不是针对每一个具体Payload定制规则。
   若为每一种变种都单独加规则，规则集规模将不可控。
3. 资源优先级
   CRS团队是由志愿者组成的，必须把有限的时间投入到影响面更广、危害更实质的问题上。
4. 可扩展性保障
   CRS为用户提供了完善的自定义规则指导文档，鼓励有特殊需求的用户自己加固防护。

总结：CRS更倾向容忍小范围误报，追求整体安全性

CRS的设计哲学是：
“宁可增加少量合理误报，也要最大限度降低漏报风险。”

这也是CRS与大多数商业WAF产品不同之处——CRS强调的是为广大用户提供默认即安全的开源防护基础，而不是以零误报为目标（那通常意味着更高的漏报风险）。

未来，CRS可能仍会考虑对User-Agent相关规则进行优化，但前提是有充分证据表明这类攻击在现实中具有广泛且实际的危害性。