跳到主要内容

10. 安全考虑 (Security Considerations)

10.1. 服务器权威 (Server Authority)​

HTTP/2 依赖 HTTP/1.1 对 authority 的定义来判断服务器是否对提供某个给定响应具有权威性 (见 [HTTP] 的 Section 17.1). 这依赖于 "https" 方案的本地名称解析和 "https" 方案的已认证服务器身份 (如 [HTTP] Section 4.2.2 所定义). 用于建立权威性的替代服务 ([ALT-SVC]) 可能引入相当大的额外复杂性.

10.2. 跨协议攻击 (Cross-Protocol Attacks)​

在 TLS 中, HTTP/2 使用 Application-Layer Protocol Negotiation (ALPN) 扩展 [TLS-ALPN] 来协商协议的使用. 这会形成一个肯定信号, 表明服务器支持 HTTP/2, 并减少 HTTP/2 暴露于跨协议攻击的风险.

然而, 在明文环境中, 或在 TLS 中未使用 ALPN 时, HTTP/2 客户端连接前言 (Section 3.4) 可能与其他协议混淆. HTTP/2 连接前言通过选择不太可能成为其他协议有效起始序列的字节序列, 来尽量降低这种可能性.

HTTP/2 端点可访问的任何协议都可以被用来建立看起来像有效 HTTP/2 连接的连接. 因此, 服务器端端点收到的连接前言需要对该协议有效, 才能形成跨协议攻击.

客户端连接前言 (Section 3.4) 不足以确保协议不会被混淆, 但它提供了一定保护. HTTP/2 客户端实现可能还需要在应用 HTTP 语义之前执行额外检查. 特别是, 客户端需要确保初始响应是对客户端所发送消息的合法响应.

服务器可以通过向客户端原本希望发送到另一台服务器的目标服务器发送请求来攻击客户端. 如果接收服务器支持 HTTP/2 以外的 HTTP 方案, 该服务器可以读取并回显发送给另一台服务器的请求. 攻击者可以拦截并修改客户端收到的响应, 导致客户端把响应中的信息关联到一个并不属于它的请求响应上.

10.3. 中间节点封装攻击 (Intermediary Encapsulation Attacks)​

HTTP/2 字段编码允许表达在 HTTP/1.1 中无效或无法表达的字段名称和值. 包含无效字段名称或值的请求或响应会使对字段名称和值验证不足的实现变得脆弱. 攻击者可能利用中间节点封装请求或响应, 使无效消息看起来有效.

未完全验证请求和响应的 HTTP/2 到 HTTP/1.1 转换器, 可能允许恶意客户端走私字段值, 或创建具有误导性字段名称的字段.

10.4. 推送响应的可缓存性 (Cacheability of Pushed Responses)​

推送响应没有来自客户端的显式请求; 请求由服务器在 PUSH_PROMISE 帧中提供.

缓存推送响应可能存在问题. 根据用于建立连接的信息, 推送响应可能被意外提供给共享该连接但并未有意请求该资源的新客户端.

例如, 在使用 TLS 进行认证的情况下, 恶意客户端可能通过同一连接接收到关于已认证用户敏感信息的推送响应.

服务器 MUST 只在被推送的请求中包含可缓存的值 (见 [HTTP] 的 Section 9.2.3); 推送请求不包含请求内容的值. 推送响应通过包含 Cache-Control 头部字段并设置 no-cache 或 private 缓存响应指令 (见 [HTTP-CACHING] 的 Section 5.2.2.4) 来标记为不可缓存.

如果同一推送响应既可为可缓存响应提供, 又可为不可缓存响应提供, 客户端可能会使用可缓存响应错误地缓存该推送响应.

因此, 除非存在显式信号表明客户端正在缓存响应, 服务器 SHOULD 在推送流的 HEADERS 帧中包含值为 "no-cache" 的 Cache-Control 头部字段.

10.5. 拒绝服务考虑 (Denial-of-Service Considerations)​

HTTP/2 的使用引入了若干新的拒绝服务 (DoS) 机会.

10.5.1. 字段节大小限制 (Limits on Field Section Size)​

包含大量字段、长字段名称或长字段值的字段节可能导致实现消耗过多内存、CPU 时间, 或两者兼有.

实现 SHOULD 对其将接受的字段行总数和总大小以及将发送的字段行总数和总大小施加限制, 从而限制组成字段节的帧的总大小. 服务器可能希望维护字段行白名单, 客户端可能希望拒绝字段行, 但双方 SHOULD 记录并考虑可能妨碍互操作性的限制.

10.5.2. CONNECT 问题 (CONNECT Issues)​

CONNECT 方法可用于为不受信任的目标创建连接. CONNECT 的 TCP 连接不受控制, 它可能尝试连接端点或其他设备, 从而造成连接洪泛. 实现 SHOULD 对允许作为 CONNECT 目标的目的地设置限制, 并 SHOULD 记录这些限制.

10.5.3. 压缩的使用 (Use of Compression)​

HTTP/2 中字段块的压缩依赖算法和状态, 攻击者可以利用这些算法和状态造成拒绝服务.

攻击者可以发送带有精心构造字段的请求, 创建需要大量解码器资源的字段节. 这可以通过使用大量 Huffman 编码字符串, 或对动态表进行大量更新来实现. 在终止一个字段节后立即开始新的字段节 (例如, 空 DATA 帧后跟 HEADERS 帧), 也可能被用于限制可用的解码器资源.

类似攻击也可以通过激进使用字段节压缩状态来创建需要大量编码器资源的响应.

实现 SHOULD 对它们解压缩的字段大小设置限制.

10.5.4. 流量控制的使用 (Use of Flow Control)​

HTTP/2 中的流量控制允许攻击者限制对等方可发送的数据量. 窗口更新或流量控制窗口管理的实现可能导致流无法获得可用窗口, 从而无法取得进展.

10.5.5. 设置的使用 (Use of Settings)​

SETTINGS 帧可用于使对等方花费额外处理时间. 这可能通过无意义地更改设置、发送未更改任何设置的 SETTINGS 帧, 或频繁更改设置来实现.

其他限制值的 SETTINGS 参数也可能被用于消耗资源, 例如通过为 SETTINGS_HEADER_TABLE_SIZE 参数设置极小的值来禁用 HPACK 动态表.

端点 SHOULD 检测这些行为, 并将其视为 ENHANCE_YOUR_CALM 类型的连接错误 (Section 5.4.1).

10.5.6. 优先级的使用 (Use of Priorities)​

优先级可能被用于使对等方消耗过多资源. 频繁更改优先级树, 或优先级树中存在不合理的复杂性, 都可能导致 CPU 消耗过高.

10.5.7. 不使用 TLS 的 HTTP/2 (Use of HTTP/2 Without TLS)​

HTTP/2 可以在不使用 TLS 的情况下部署. 此模式对某些攻击具有与 HTTP/1.1 相同的脆弱性. 使用此操作模式的实现 SHOULD 应用适用于 HTTP/1.1 的保护.

实现还需要意识到, 许多 HTTP/2 特性在没有 TLS 时可能更容易受到攻击. 特别是, 缺少 TLS 提供的机密性保护和完整性保护意味着数据的加密或完整性存在风险.

10.6. 压缩的使用 (Use of Compression)​

当压缩与攻击者可控制的数据以及攻击者可观察传输大小的秘密数据结合时, 压缩可能允许攻击者恢复加密通信中的秘密内容.

HTTP/2 在多个位置提供压缩: 字段块使用 HPACK [COMPRESSION], DATA 帧内容可以使用内容编码 (见 [HTTP] 的 Section 8.4.1).

HPACK 被设计为使秘密泄露的利用更加困难; 然而, 在某些情况下可实现的实现选择或应用保护之间的权衡并不完美. 攻击可以利用多个请求之间字段压缩状态的复用. 实现和应用可以选择限制跨请求使用的压缩状态量来改进保护, 但代价是增加消息大小.

压缩 DATA 帧内容通常被认为更安全, 因为 DATA 帧内容在多个请求之间与攻击者控制数据混合的可能性较低. 然而, 压缩内容编码会组合来自不同源的信息. 虽然使用不同源标识符可以区分来自不同来源的信息 (见 [HTTP] 的 Section 11.5), 但压缩可能移除这些分隔, 如 [BREACH] 所述.

禁用或限制内容编码的压缩通常被认为足以缓解这些攻击, 但这可能不足以防止所有攻击.

10.7. 填充的使用 (Use of Padding)​

填充可用于隐藏帧和消息内容的确切大小. 填充可用于缓解依赖流量分析来推断消息信息的攻击; 这对 HTTP 尤为重要, 因为压缩消息的长度可能泄露其所包含内容的信息.

使用填充的一个例子是发送大量 HEADERS 和 DATA 帧, 且各帧之间有效载荷大小不同, 以隐藏消息的确切大小. 使用填充可以减少某些攻击 (例如 [BREACH]).

一般而言, 流量分析攻击的存在意味着为每个字段或帧填充到固定大小不足以提供保护. 为了高效并提供一定程度的保护, 填充 SHOULD 随机选择.

填充并不是隐藏消息大小的完美保护. 攻击者可能能够利用关于消息大小的统计属性, 这可能使攻击者无论消息是否填充, 都能以一定概率利用消息长度推断内容信息.

10.8. 隐私考虑 (Privacy Considerations)​

HTTP/2 的若干特征为观察者关联一组请求提供了机会. 这些特征包括设置值、字段块压缩上下文、流量控制窗口管理, 以及消息到达时间.

特别是, 包含用户身份信息的 HTTP 字段即使在使用不同服务器时, 也可能与其他通信相关联.

HTTP/2 不提供保护用户隐私的特定机制.

第 10 章完成!

References​

  • [HTTP] RFC 9110
  • [HTTP-CACHING] RFC 9111
  • [TLS-ALPN] RFC 7301
  • [ALT-SVC] RFC 7838
  • [COMPRESSION] RFC 7541
  • [BREACH] "BREACH: Reviving the CRIME Attack"
最后于 更新