8. Security Considerations (安全考虑因素)

8. Security Considerations (安全考虑因素)

虽然在技术上超出了本规范的范围, RFC 3629 [STD63] 的第 10 节 ("安全考虑因素" (Security Considerations)) 适用于实现。需要特别注意 RFC 3629 [STD63] 第 3 节 ("UTF-8 定义" (UTF-8 definition)) 的最后一段。I-Regexp 实现可能需要缓解平台实现在这方面的限制。

如第 6 节所述, 更复杂的正则表达式库可能包含可利用的错误 (Exploitable Bugs), 这可能导致崩溃和远程代码执行 (Remote Code Execution)。还存在一个问题, 即此类库通常具有难以预测的性能特征 (Performance Characteristics), 导致通过与攻击者控制的昂贵正则表达式进行匹配来使实现过载的攻击。

I-Regexp 的设计允许以能够抵御这两种威胁的方式进行实现。这一目标需要在整个实现工作中得到解决。非检查实现 (见第 3.1 节) 可能会暴露它们使用的任何正则表达式引擎的安全限制, 如果该引擎是在考虑安全性的情况下构建的 (例如, [RE2]), 这可能不太成问题。无论如何, 仍然推荐检查实现 (Checking Implementation)。

专门实现 I-Regexp 子集的实现可以在小心的情况下被设计为通常在输入的线性时间和空间 (Linear Time and Space) 中运行, 并在不会出现这种情况时进行检测 (见下文)。

现有的正则表达式引擎应该能够轻松处理大多数 I-Regexp (在第 5 节讨论的调整之后), 但对于某些类型的 I-Regexp 可能会消耗过多资源, 或者完全拒绝它们, 因为它们无法保证有效执行。(请注意, 同一正则表达式库的不同版本对于这些情况可能或多或少容易受到过度资源消耗的影响。)

具体来说, 范围量词 (Range Quantifiers) (如 a{2,4}) 为现有实现和专注于 I-Regexp 的实现都提供了特殊挑战。因此, 实现可能会限制范围量词的可组合性 (Composability) (禁止嵌套范围量词, 如 (a{2,4}){2,4}) 或范围 (禁止非常大的范围, 如 a{20,200000}), 或者检测并拒绝范围量词引起的任何过度资源消耗。

用于评估来自不受信任来源的正则表达式的 I-Regexp 实现需要在这些情况下具有鲁棒性 (Robust)。鼓励使用现有正则表达式库的实现者:

• 检查其文档以查看是否可以配置缓解措施 (Mitigations), 例如资源消耗限制, 并且
• 记录因采用此类缓解措施而产生的自身鲁棒性程度。