跳到主要内容

9. 安全考虑 (Security Considerations)

9.1. 变更端口 (Changing Ports)​

使用替代服务至少意味着会在替代端口上访问某个源的资源. 因此, 如果攻击者能够注入替代服务并在被宣告的端口上监听, 就能够劫持该源. 在某些服务器上, 用户能够控制共享端口上可用的一些个人页面, 同时也能够在较低权限要求的端口上接受请求, 这是常见情况.

例如, 如果攻击者能够向某些页面添加 HTTP 响应头字段, 就可以使用 Alt-Svc 头字段将整个源的流量重定向到同一主机上的另一个端口; 如果该端口受攻击者控制, 攻击者就可以伪装成 HTTP 服务器.

第 2.1 节中的要求缓解了这一风险.

在服务器侧, 还可以通过限制宣告替代服务的能力, 以及限制谁可以在该主机上打开端口进行监听, 来降低这一风险.

9.2. 变更主机 (Changing Hosts)​

当使用替代服务导致主机发生变化时, 攻击者就有机会劫持到某个源的通信.

例如, 如果攻击者能够成功将 "evil.example.com" 关联为替代服务, 使用户代理把发往 "innocent.example.org" 的所有流量发送到 "evil.example.com", 攻击者就可以伪装成该源. 这可以在本地完成 (缓解措施见第 9.1 节), 也可以远程完成, 例如由中间方实施中间人攻击.

这正是第 2.1 节要求客户端获得合理保证的原因: 替代服务必须受整个源控制并对整个源有效. 例如, 出示该源的证书可以证明替代服务被授权为该源处理流量.

注意, 这种保证的强度只取决于用于认证替代服务的方法. 特别是使用 TLS 认证时, 已知存在一些利用方式可使攻击者的证书看起来是合法的.

替代服务还可能被用来维持这种攻击. 例如, 中间方可以对目标的 TLS 保护通信实施中间人攻击, 然后将所有流量指向一个新鲜生命周期很长的替代服务, 使用户代理即使不再经过该中间方, 仍然把流量发送给攻击者.

实现 MUST 像处理到源的直接连接一样, 对替代服务执行任何证书固定 (certificate pinning) 校验, 例如 [RFC7469]. 实现还可以选择增加其他要求, 规定哪些证书可被替代服务接受.

9.3. 变更协议 (Changing Protocols)​

当使用替代服务导致 ALPN 协议发生变化时, 到源的新连接的安全属性可能不同于到该源的"正常"连接, 因为协议标识符本身就隐含了这种差异.

例如, 如果某个 "https://" URI 宣告的协议不使用某种形式的端到端加密 (最可能是 TLS), 这就违反了该 URI 方案所隐含的安全预期. 因此, 客户端不能盲目使用替代服务, 而应评估所提供的选项, 确保满足规范、实现和最终用户的安全要求与预期.

9.4. 使用替代服务跟踪客户端 (Tracking Clients Using Alternative Services)​

选择替代服务意味着连接到一个由服务器提供的新主机名. 服务器可以通过使用唯一名称来跟踪客户端请求. 当使用 "persist" 标志时, 这种跟踪甚至可能跨多个网络跟随用户.

希望防止请求被关联的客户端可以决定不为多个请求使用替代服务, 尤其是这些请求在其他情况下本不允许被关联时.

在用户代理中, 当清除特定于源的数据时, MUST 删除任何替代服务信息. 典型情况是清除 cookie [RFC6265] 时.

9.5. 关于请求方案的混淆 (Confusion regarding Request Scheme)​

一些服务器端 HTTP 应用会基于连接上下文对安全性作出假设; 例如, 将通过端口 443 提供服务等同于使用 "https://" URI 及其隐含的各种安全属性.

这不仅影响连接本身的安全属性, 也影响连接另一端客户端的状态. 例如, Web 浏览器在许多方面都会以不同方式处理 "https://" URI 和 "http://" URI, 并不只是协议处理不同.

由于替代服务的用途之一是允许连接迁移到不同协议和端口, 这些应用可能会对给定连接的安全属性产生混淆, 从而把本应发送到安全上下文 (例如 "https://" URI) 的信息 (例如 cookie 和内容) 发送给并未将其视为安全上下文的客户端.

服务器可以通过使用协议显式携带的 URI 方案作为安全上下文指示来缓解这一风险, 而不是依赖其他连接属性. 例如, HTTP/2 中的 ":scheme", 或 HTTP/1.1 中请求目标的 "absolute form" ([RFC7540] 第 8.1.2.3 节和 [RFC7230] 第 5.3.2 节).

当协议没有显式携带方案时 (HTTP/1.1 over TLS 通常如此), 服务器可以通过两种方式缓解这一风险: 假定所有请求都处于不安全上下文, 或避免为不安全方案 (例如 HTTP) 宣告替代服务.

最后于 更新