6. 安全考虑事项
6.1. HTTP 消息未被完整保护
本文档规定了一种数据完整性机制, 可保护 HTTP 表示数据或内容免受某些类型的损坏, 但不保护 HTTP 头部字段和尾部字段.
完整性字段并不旨在作为针对 HTTP 消息恶意篡改的通用保护. 在没有附加安全机制的情况下, 路径上的恶意行为者可以完全移除摘要值, 或者用一个根据被操纵的表示数据或内容计算出的新摘要值来替换它. 可以通过将本文档描述的机制与其他方法结合来缓解这种攻击, 如 Transport Layer Security (TLS) 或数字签名 (例如 HTTP Message Signatures [SIGNATURES]).
6.2. 端到端完整性
完整性字段可以帮助检测表示数据或内容的修改, 这些修改可能由实现错误, 不期望的 "transforming proxies" (see Section 7.7 of [HTTP]) 或数据跨越多个跳或系统边界时的其他动作引起. 即便是简单的端到端表示数据完整性机制也是有价值的, 因为用户代理可以在把资源交给 HTML 解析器, 视频播放器等进行解析之前, 先验证资源检索是否成功.
注意, 单独使用这些机制并不能提供跨多个跳的 HTTP 消息端到端完整性, 因为元数据可能在任何阶段被操纵. 保护元数据的方法见 Section 6.3.
6.3. 在签名中的使用
数字签名广泛地与校验和一起使用, 以提供对消息来源的确定识别 [FIPS186-5]. 此类签名可以保护一个或多个 HTTP 字段, 当完整性字段包含在这个集合中时还需要考虑其他事项.
对于完整性字段可与何种类型或格式的数字签名一起使用, 本文档不施加限制. 一种可能的方法是将其与 HTTP Message Signatures [SIGNATURES] 结合.
摘要明确依赖于 "表示元数据" (例如 Content-Type, Content-Encoding 等的值). 若签名保护完整性字段但不保护其他 "表示元数据", 通信就可能暴露于篡改. 例如, 行为者可以操纵 Content-Type 字段值并导致接收方摘要验证失败, 从而阻止应用访问该表示. 这类攻击会消耗两个端点的资源. 另见 Section 3.2.
在应用完整性字段时, 签名很可能被视为对抗性环境; 参见 Section 5. Repr-Digest 与签名结合时提供了一种有趣的可能性. 在没有内容可发送的场景中, 可以在消息中包含空字符串摘要, 若该摘要被签名, 则可以帮助接收方检测是否由于意外或有意操纵而添加了内容. 相反的场景同样受支持; 包含内容的完整性字段并签名它, 可以帮助接收方检测内容是否被移除.
对完整性字段的任何改写都可能影响签名验证. 此类改写的示例包括对摘要去重或组合不同字段值 (see Section 5.2 of [HTTP]).
6.4. 在尾部字段中的使用
在尾部节中发送完整性字段之前, 发送方应考虑到中介被明确允许丢弃任何尾部 (see Section 6.5.2 of [HTTP]).
当完整性字段用于尾部节时, 字段值会在内容之后被接收. 在尾部节之前急切处理内容会阻止摘要验证, 可能导致处理无效数据.
在尾部节中使用完整性字段的一个好处是允许在字节发送时进行哈希处理. 然而, 也可能设计出一种哈希算法, 要求以某种方式处理内容, 从而抵消这些好处. 例如, Merkle Integrity Content Encoding [MICE] 要求以逆序处理内容. 这意味着完整数据必须可用, 因而在头部节和尾部节中发送完整性字段的处理差异可以忽略不计.
6.5. Content-Encoding 内的变化
内容编码机制可以支持不同的编码参数, 这意味着相同的输入内容可能产生不同的输出. 例如, GZIP 支持多个压缩级别. 此类编码参数通常不会作为表示元数据传达. 例如, 不同的压缩级别都会使用相同的 "Content-Encoding: gzip" 字段. 其他示例包括编码依赖 nonce 或时间戳的情况, 如 [RFC8188] 中定义的 aes128gcm 内容编码.
由于内容编码内部可能存在变化, 除非持久化了完整内容, 否则完整性字段传达的校验和不能用于提供 "at rest" 完整性证明.
6.6. 算法敏捷性
哈希算法的安全属性并非固定不变. 算法敏捷性 (see [RFC7696]) 通过为实现提供从 IANA Hash Algorithms for HTTP Digest Fields 注册表中选择哈希算法的灵活性来实现; 参见 Section 7.2.
可以通过使用 Want-Content-Digest 或 Want-Repr-Digest 协商哈希算法 (see Section 4), 或通过发送多个摘要并让接收方从中选择, 来支持从弱算法迁移. 依赖摘要实现安全性的接收方会易受其愿意接受的最弱算法上的攻击. 建议端点注意, 发送多个值会消耗资源, 如果接收方忽略这些值, 这些资源可能被浪费 (see Section 3).
虽然算法敏捷性允许迁移到更强的算法, 但它并不阻止使用较弱算法. 完整性字段并不为哈希算法的降级或替换攻击 (see Section 1 of [RFC6211]) 提供任何缓解措施. 为防范此类攻击, 端点可以将其支持的算法集合限制为较强算法, 并使用 TLS 和/或数字签名来保护字段值.
6.7. 资源耗尽
完整性字段验证会消耗计算资源. 为避免资源耗尽, 实现可以限制要验证的算法类型, 验证次数或内容大小. 在这些情况下, 完全跳过验证或忽略更偏好算法的验证失败, 会留下降级攻击的可能性 (see Section 6.6).