8. 安全考量

8. 安全考量

虽然严格来说不属于本规范范围, RFC 3629 [STD63] 第 10 节 ("Security Considerations") 适用于实现. 需要特别注意 RFC 3629 [STD63] 第 3 节 ("UTF-8 definition") 的最后一段; I-Regexp 实现可能需要缓解平台实现在这方面的限制.

如第 6 节所述, 更复杂的 regexp 库可能包含可利用的错误, 这些错误可能导致崩溃和远程代码执行. 还有一个问题是, 此类库通常具有难以预测的性能特征, 攻击者可以通过匹配由其控制且开销很高的 regexp 来使实现过载.

I-Regexps 的设计允许以能够抵御这两类威胁的方式实现; 在整个实现工作中都需要处理这一目标. 非检查型实现 (参见第 3.1 节) 很可能暴露其所用 regexp 引擎的安全限制; 如果该引擎在构建时已考虑安全性 (例如 [RE2]), 问题可能较小. 无论如何, 仍然 RECOMMENDED 使用检查型实现.

专门实现 I-Regexp 子集的实现, 如果足够谨慎, 通常可以设计为相对于输入在线性时间和空间内运行, 并检测何时不能做到这一点 (见下文).

现有 regexp 引擎在经过第 5 节讨论的调整后, 应能轻松处理大多数 I-Regexps, 但对于某些类型的 I-Regexps 可能消耗过多资源, 或因无法保证高效执行而直接拒绝它们. 注意, 同一 regexp 库的不同版本在这些情况下对过量资源消耗的脆弱程度可能不同.

具体而言, 范围量词 (如 a{2,4}) 对现有实现和专注于 I-Regexp 的实现都提出了特殊挑战. 因此, 实现可以在可组合性方面限制范围量词 (禁止 (a{2,4}){2,4} 等嵌套范围量词), 或在范围方面限制它们 (禁止 a{20,200000} 等非常大的范围), 或检测并拒绝范围量词导致的任何过量资源消耗.

用于评估来自不可信来源的 regexps 的 I-Regexp 实现, 需要在这些情况下保持健壮. 鼓励使用现有 regexp 库的实现者:

• 检查其文档, 查看是否可配置缓解措施, 例如资源消耗限制, 以及
• 记录因采用这些缓解措施而获得的自身健壮程度.