8. Security Considerations (安全考虑)

任何数据压缩方法都涉及减少数据中的冗余。Zstandard 也不例外, 并且适用通常的预防措施。

永远不应将内容必须保密的消息与第三方生成的消息一起压缩。这种压缩可用于通过熵减少分析 (Entropy Reduction Analysis) 来猜测秘密消息的内容。例如, 这在压缩比信息泄漏简化攻击 (Compression Ratio Info-leak Made Easy, CRIME) [CRIME] 中得到了证明。

解码器必须展示检测和防止压缩帧中的任何类型数据篡改触发系统故障的能力, 例如读取或写入超出允许的内存范围。这可以通过实现语言或仔细的边界检查 (Bound Checking) 来保证。特别值得注意的是 Number_of_Sequences 值的编码, 该值会导致解码器读取到块头部 (甚至更远), 以及指示小于实际解压缩数据的 Frame_Content_Size, 试图触发缓冲区溢出 (Buffer Overflow)。强烈建议对解码器实现进行模糊测试 (Fuzz-test, 即提供无效、意外或随机输入并验证安全操作), 以测试和强化其检测错误帧并在没有任何不利系统副作用的情况下处理它们的能力。

攻击者可能提供格式正确但具有不合理内存要求的压缩帧。解码器必须始终控制内存要求并强制执行某些 (特定于系统的) 限制, 以保护内存使用免受此类场景的影响。

可以通过在各种相关内容载荷上训练字典来优化压缩。然后, 解码器必须可以使用此字典, 以便解压缩载荷。虽然本文档没有指定如何获取给定压缩载荷的字典, 但值得注意的是, 第三方字典可能与解码器产生意外交互, 导致可能的内存或其他资源耗尽攻击 (Resource-exhaustion Attacks)。我们期望在即将发布的关于字典获取和传输的 RFC 的安全考虑部分中更详细地讨论此类主题, 但出于谨慎起见, 现在强调此问题。

如第 3.1.2 节所述, 可以在可跳过帧 (Skippable Frames) 中存储任意用户元数据。虽然在数据解压缩期间会忽略此类帧, 但它们可以用作水印 (Watermark) 来跟踪压缩载荷的路径。

---