8. 安全考量

8. 安全考量

本协议必须 (MUST) 按照 [RFC7525] 的建议使用 TLS 之上的 HTTP [RFC2818]. 这包括用户代理与推送服务之间的任何通信, 以及应用服务器与推送服务之间的通信. 因此所有 URI 均使用 https 方案. 这为订阅与推送消息提供针对外部方的机密性与完整性保护.

8.1. Confidentiality from Push Service Access (相对推送服务访问的机密性)

TLS 提供的保护无法防止推送服务查看内容. 若无额外防护措施, 推送服务可检查并修改消息内容.

使用本协议的应用必须 (MUST) 采用提供端到端机密性、完整性与数据源认证的机制. 发送推送消息的应用服务器与接收消息的用户代理上的应用往往只是同一应用的不同实例, 因此无需标准化协议来建立适当的安全上下文. 从用户代理向其应用服务器分发订阅信息也提供了便捷的密钥协商媒介.

对此需求, W3C Push API [API] 已采用 Message Encryption for WebPush [ENCRYPT] 来保护消息内容不被推送服务获知. 其他场景可通过类似策略解决.

Topic 头字段暴露的信息允许对同一主题的推送消息进行更细粒度的关联. 这可能被推送服务用于辅助对推送消息的流量分析.

8.2. Privacy Considerations (隐私考量)

推送消息机密性并不能保证通信双方身份及通信时间的隐私. 然而, 暴露的信息量可以被限制.

为推送资源提供的 URI 禁止 (MUST NOT) 提供任何依据来关联给定用户代理的通信. 禁止 (MUST NOT) 仅依据其内容关联任意两个推送资源 URI. 这使用户代理能够控制跨不同应用或随时间的关联. 当然, 这并不能阻止使用用户代理可能暴露的其他信息进行关联.

同样, 推送服务提供的用于标识推送消息的 URI 禁止 (MUST NOT) 提供允许跨订阅关联的信息. 同一订阅的推送消息 URI 可以 (MAY) 包含允许与该订阅或该订阅的其他推送消息关联的信息.

用户与设备信息禁止 (MUST NOT) 通过推送或推送消息 URI 暴露.

此外, 同一用户代理建立的推送 URI 或同一订阅的推送消息 URI 禁止 (MUST NOT) 包含允许与用户代理关联的信息.

注: 只要所得匿名集 ([RFC6973] 第 6.1.1 节) 足够大, 则无需完美. 推送 URI 必然标识推送服务或单一服务器实例. 也可能通过流量分析关联订阅.

用户代理必须 (MUST) 能够随时使用新标识符创建新订阅.

8.3. Authorization (授权)

本协议未定义推送服务如何确定是否允许用户代理创建订阅, 或是否可将推送消息投递给用户代理. 推送服务可以 (MAY) 选择基于任何可用的与 HTTP 兼容的授权方法授权请求, 其中存在多种选项 (包括实验性选项), 安全级别各异. 授权流程与任何相关凭据预期与用户代理中的推送服务 URI 一并配置.

授权使用推送消息订阅、推送与回执订阅资源的能力 URL (capability URLs) 进行管理 ([CAP-URI]). 能力 URL 仅基于知晓该 URL 而授予对资源的访问.

能力 URL 因其 "易于继续共享" 与 "易于客户端 API" 特性而被使用. 这些特性使得可以避免依赖推送服务与应用服务器之间预先安排的关系或额外协议.

能力 URL 充当不记名令牌 (bearer token). 知晓推送消息订阅 URI 意味着有权接收推送消息或删除订阅. 知晓推送 URI 意味着有权发送推送消息. 知晓推送消息 URI 意味着可读取并确认该特定消息. 知晓回执订阅 URI 意味着有权接收推送回执.

在路径组件中编码大量随机熵 (至少 120 位) 可确保难以成功猜出有效能力 URL.

8.4. Denial-of-Service Considerations (拒绝服务考量)

用户代理可通过将推送 URI 的分发限制给已授权应用服务器来控制有效推送消息的来源. 确保推送 URI 难以猜测可确保仅收到推送 URI 的应用服务器能使用它.

未被用户代理成功认证的推送消息不会被投递, 但这可能带来拒绝服务风险. 即使相对少量的推送消息也可能导致电池供电设备耗尽电量.

为应对此情况, W3C Push API [API] 已采用 Voluntary Application Server Identification [VAPID], 使用户代理能将订阅限制到特定应用服务器. 推送服务随后可识别并拒绝不需要的消息而无需联系用户代理.

持有有效推送 URI 的恶意应用可能利用推送服务的更大资源对用户代理发起拒绝服务攻击. 推送服务应当 (SHOULD) 限制向单个用户代理发送推送消息的速率.

当应用服务器超出向推送资源投递推送消息的速率限制时, 推送服务可以 (MAY) 返回 429 (Too Many Requests) 状态码 [RFC6585]. 推送服务还应当 (SHOULD) 包含 Retry-After 头 [RFC7231], 指明应用服务器在再次向推送资源发起请求之前应等待多久.

推送服务或用户代理也可以 (MAY) 终止接收过多推送消息的订阅 (第 7.3 节).

推送服务也能够拒绝为用户代理提供服务. 故意不投递消息难以与故障区分, 故障可能由瞬时网络错误、用户代理可用性中断或真实服务中断引起.

8.5. Logging Risks (日志风险)

服务器请求日志可能泄露与订阅相关的 URI 或同一用户代理的订阅相关 URI 之间的关系. 限制日志保留期并采用强访问控制机制可确保 URI 不会泄露给未授权实体.