Skip to main content

12. Security Considerations, IANA Considerations, and References

官方英文原文 (Official English Text)​

12.1. Security Considerations​

As with any compressed file formats, decompressor implementations should handle all compressed data byte sequences, not only those that conform to this specification, where non-conformant compressed data sequences should be rejected as invalid.

A possible attack against a system containing a decompressor implementation (e.g., a web browser) is to exploit a buffer overflow triggered by invalid compressed data. Therefore, decompressor implementations should perform bounds-checking for each memory access that result from values decoded from the compressed stream and derivatives thereof.

Another possible attack against a system containing a decompressor implementation is to provide it (either valid or invalid) compressed data that can make the decompressor system's resource consumption (CPU, memory, or storage) to be disproportionately large compared to the size of the compressed data. In addition to the size of the compressed data, the amount of CPU, memory, and storage required to decompress a single compressed meta-block within a brotli stream is controlled by the following two parameters: the size of the uncompressed meta-block, which is encoded at the start of the compressed meta-block, and the size of the sliding window, which is encoded at the start of the brotli stream. Decompressor implementations in systems where memory or storage is constrained should perform a sanity-check on these two parameters. The uncompressed meta-block size that was decoded from the compressed stream should be compared against either a hard limit, given by the system's constraints or some expectation about the uncompressed data, or against a certain multiple of the size of the compressed data. If the uncompressed meta-block size is determined to be too high, the compressed data should be rejected. Likewise, when the complete uncompressed stream is kept in the system containing the decompressor implementation, the total uncompressed size of the stream should be checked before decompressing each additional meta-block. If the size of the sliding window that was decoded from the start of the compressed stream is greater than a certain soft limit, then the decompressor implementation should, at first, allocate a smaller sliding window that fits the first uncompressed meta-block, and afterwards, before decompressing each additional meta-block, it should increase the size of the sliding window until the sliding window size specified in the compressed data is reached.

Correspondingly, possible attacks against a system containing a compressor implementation (e.g., a web server) are to exploit a buffer overflow or cause disproportionately large resource consumption by providing, e.g., uncompressible data. As described in Section 11.1, an output buffer of

S(N) = N + (3 * (N >> 16) + 5)

bytes is sufficient to hold a valid compressed brotli stream representing an arbitrary sequence of N uncompressed bytes. Therefore, compressor implementations should allocate at least S(N) bytes of output buffer before compressing N bytes of data with unknown compressibility and should perform bounds-checking for each write into this output buffer. If their output buffer is full, compressor implementations should revert to the trivial compression algorithm described in Section 11.1. The resource consumption of a compressor implementation for a particular input data depends mostly on the algorithm used to find backward matches and on the algorithm used to construct context maps and prefix codes and only to a lesser extent on the input data itself. If the system containing a compressor implementation is overloaded, a possible way to reduce resource usage is to switch to more simple algorithms for backward reference search and prefix code construction, or to fall back to the trivial compression algorithm described in Section 11.1.

A possible attack against a system that sends compressed data over an encrypted channel is the following. An attacker who can repeatedly mix arbitrary (attacker-supplied) data with secret data (passwords, cookies) and observe the length of the ciphertext can potentially reconstruct the secret data. To protect against this kind of attack, applications should not mix sensitive data with non-sensitive, potentially attacker-supplied data in the same compressed stream.

12.2. IANA Considerations​

The "HTTP Content Coding Registry" has been updated with the registration below:

+-------+-------------------------------------+------------+
| Name  | Description                         | Reference  |
+-------+-------------------------------------+------------+
| br    | Brotli Compressed Data Format       | RFC 7932   |
+-------+-------------------------------------+------------+

12.3. Informative References​

[HUFFMAN] Huffman, D. A., "A Method for the Construction of Minimum Redundancy Codes", Proceedings of the Institute of Radio Engineers, September 1952, Vol. 40, No. 9, pp. 1098-1101.

[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for Sequential Data Compression", IEEE Transactions on Information Theory, Vol. 23, No. 3, pp. 337-343, DOI 10.1109/TIT.1977.1055714, May 1977, https://www.cs.duke.edu/courses/spring03/cps296.5/papers/ziv_lempel_1977_universal_algorithm.pdf

[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, http://www.rfc-editor.org/info/rfc1951

[WOFF2] Levantovsky, V., Ed., and R. Levien, Ed., "WOFF File Format 2.0", W3C Candidate Recommendation, March 2016, http://www.w3.org/TR/WOFF2/

中文翻译 (Chinese Translation)​

12.1. Security Considerations (安全考虑)​

与任何压缩文件格式 (Compressed File Format) 一样，解压缩器实现 (Decompressor Implementation) 应处理所有压缩数据字节序列 (Compressed Data Byte Sequence)，而不仅仅是符合本规范的那些，其中不符合规范的压缩数据序列应被拒绝为无效 (Invalid).

对包含解压缩器实现的系统（例如 Web 浏览器）的可能攻击是利用无效压缩数据触发的缓冲区溢出 (Buffer Overflow)。因此，解压缩器实现应对从压缩流解码的值及其衍生物产生的每次内存访问 (Memory Access) 执行边界检查 (Bounds-Checking).

对包含解压缩器实现的系统的另一种可能攻击是向其提供（有效或无效的）压缩数据，这些数据可能使解压缩器系统的资源消耗 (Resource Consumption)（CPU、内存或存储）与压缩数据的大小相比不成比例地大。除了压缩数据的大小之外，在 brotli 流中解压缩单个压缩元块所需的 CPU、内存和存储量由以下两个参数控制：未压缩元块的大小（在压缩元块的开始处编码）和滑动窗口的大小（在 brotli 流的开始处编码）。在内存或存储受限的系统中，解压缩器实现应对这两个参数执行合理性检查 (Sanity-Check)。从压缩流解码的未压缩元块大小应与硬限制（由系统约束或对未压缩数据的某些期望给出）或压缩数据大小的某个倍数进行比较。如果确定未压缩元块大小过高，则应拒绝压缩数据。同样，当完整的未压缩流保留在包含解压缩器实现的系统中时，应在解压缩每个额外的元块之前检查流的总未压缩大小。如果从压缩流开始处解码的滑动窗口大小大于某个软限制 (Soft Limit)，则解压缩器实现首先应分配一个适合第一个未压缩元块的较小滑动窗口，然后在解压缩每个额外的元块之前，它应增加滑动窗口的大小，直到达到压缩数据中指定的滑动窗口大小.

相应地，对包含压缩器实现（例如 Web 服务器）的系统的可能攻击是利用缓冲区溢出或通过提供例如不可压缩数据 (Uncompressible Data) 来导致不成比例的大资源消耗。如第 11.1 节所述，输出缓冲区 (Output Buffer) 大小为

S(N) = N + (3 * (N >> 16) + 5)

字节足以容纳表示 N 个未压缩字节的任意序列的有效压缩 brotli 流。因此，压缩器实现在压缩可压缩性未知的 N 字节数据之前应分配至少 S(N) 字节的输出缓冲区，并应对写入此输出缓冲区的每次写入执行边界检查。如果其输出缓冲区已满，压缩器实现应恢复到第 11.1 节中描述的简单压缩算法 (Trivial Compression Algorithm)。对于特定输入数据，压缩器实现的资源消耗主要取决于用于查找后向匹配 (Backward Match) 的算法以及用于构造上下文映射 (Context Map) 和前缀编码 (Prefix Code) 的算法，而在较小程度上取决于输入数据本身。如果包含压缩器实现的系统过载 (Overloaded)，减少资源使用的一种可能方法是切换到更简单的后向引用搜索和前缀编码构造算法，或回退到第 11.1 节中描述的简单压缩算法.

对通过加密通道 (Encrypted Channel) 发送压缩数据的系统的可能攻击如下。攻击者可以反复混合任意（攻击者提供的）数据与秘密数据（密码、cookie）并观察密文 (Ciphertext) 的长度，从而可能重建秘密数据。为了防止这种攻击，应用程序不应在同一压缩流中混合敏感数据 (Sensitive Data) 与非敏感的、可能是攻击者提供的数据.

12.2. IANA Considerations (IANA 考虑)​

"HTTP Content Coding Registry"（HTTP 内容编码注册表）已使用以下注册进行更新:

+-------+-------------------------------------+------------+
| Name  | Description                         | Reference  |
+-------+-------------------------------------+------------+
| br    | Brotli Compressed Data Format       | RFC 7932   |
+-------+-------------------------------------+------------+

12.3. Informative References (参考文献)​

[HUFFMAN] Huffman, D. A., "A Method for the Construction of Minimum Redundancy Codes"（最小冗余编码的构造方法）, Proceedings of the Institute of Radio Engineers, September 1952, Vol. 40, No. 9, pp. 1098-1101.

[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for Sequential Data Compression"（顺序数据压缩的通用算法）, IEEE Transactions on Information Theory, Vol. 23, No. 3, pp. 337-343, DOI 10.1109/TIT.1977.1055714, May 1977

[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3"（DEFLATE 压缩数据格式规范 1.3 版）, RFC 1951, DOI 10.17487/RFC1951, May 1996

[WOFF2] Levantovsky, V., Ed., and R. Levien, Ed., "WOFF File Format 2.0"（WOFF 文件格式 2.0）, W3C Candidate Recommendation, March 2016

关键安全要点​

解压缩器安全:

  1. 缓冲区溢出防护: 对所有内存访问进行边界检查
  2. 资源消耗控制: 验证元块大小和窗口大小
  3. 渐进式内存分配: 从小窗口开始，逐步增加

压缩器安全:

  1. 输出缓冲区大小: 至少 S(N) = N + (3 * (N >> 16) + 5) 字节
  2. 过载保护: 切换到简单算法或回退
  3. 边界检查: 每次写入前验证

加密通道攻击:

  • CRIME/BREACH 类攻击: 通过观察压缩后密文长度推断秘密数据
  • 防护措施: 不在同一流中混合敏感和非敏感数据

IANA 注册:

  • HTTP Content-Encoding: br
  • 官方 MIME 类型标识符

来源 (Source): RFC 7932, Sections 12-14
官方文本 (Official Text): https://www.rfc-editor.org/rfc/rfc7932.txt

Last updated on