跳到主要内容

8. 安全考虑 (Security Considerations)

本节旨在告知开发者, 信息提供者和用户, 与 HTTP 条件请求特有的已知安全问题.

Entity Tags 泄露 (Disclosure of Entity Tags)

entity-tag 经常以 "off-label" 方式使用, 例如用于多个中间节点之间的缓存同步, 或作为识别内容归档快照的手段. 理解给定资源的 entity-tag 如何生成通常是应用特定的, 并且往往是专有的. 如果暴露的 entity-tag 泄露了有关应用逻辑或中间节点缓存行为的信息, 就可能揭示如何绕过该应用的访问控制或操纵中间节点缓存.

源服务器应考虑某些 entity-tag 可能泄露在特定上下文中被视为敏感的信息. 示例包括:

  • 版本控制信息 (例如修订号, 分支名)
  • 从有访问限制的内容派生出的哈希或签名
  • 会揭示内部实现细节的模式

使用条件请求进行拒绝服务 (Denial of Service Using Conditional Requests)

虽然条件请求允许复用缓存表示, 从而降低网络带宽和处理开销, 但它们不足以防御拒绝服务攻击. 恶意客户端仍然可以针对不同资源发出大量条件请求, 或针对同一资源使用无效或不断变化的条件头字段发出大量条件请求, 从而压垮服务器的响应能力.

服务器应监控条件请求的使用情况, 并在检测到异常模式时考虑速率限制或其他防御措施.

协议元素长度 (Protocol Element Length)

服务器应对条件头字段值的大小和数量设置合理限制, 尤其是 If-MatchIf-None-Match 头字段中的 entity-tag, 因为 entity-tag 值没有标准长度约束. 极长的 entity-tag 或单个头字段中过多的 entity-tag 可能被用来耗尽服务器资源.