7. 安全考虑 (Security Considerations)

本节旨在告知开发者, 信息提供者和用户与 HTTP 缓存特有的已知安全问题. 更一般的安全考虑见 "HTTP/1.1" ([HTTP/1.1] 第 11 节) 和 "HTTP Semantics" ([HTTP] 第 17 节).

缓存暴露了额外的攻击面, 因为缓存内容是恶意利用的有吸引力目标. 由于缓存内容会跨 HTTP 请求持久存在, 针对缓存的攻击可能在用户认为信息已从网络中移除很久之后仍泄露这些信息. 因此, 需要将缓存内容作为敏感信息加以保护.

特别是, 由于私有缓存限于单个用户, 它们可被用于重建用户活动. 因此, 用户代理向最终用户提供对它们的控制非常重要, 例如允许用户删除部分或全部源服务器的已存储响应.

7.1 缓存投毒 (Cache Poisoning)

在缓存中存储恶意内容会扩大攻击者的影响范围, 进而影响多个用户. 当攻击者利用实现缺陷, 提升的权限或其他技术将响应插入缓存时, 就会发生这种"缓存投毒 (cache poisoning)"攻击. 当共享缓存被用于向许多客户端分发恶意内容时, 这种攻击尤其有效.

缓存投毒攻击的一个常见途径是利用代理和用户代理之间的消息解析差异; 相关要求见 [HTTP/1.1] 第 6.3 节.

由于缓存的主要用途之一是优化性能, 其使用可能会"泄露"有关先前请求过哪些资源的信息.

例如, 如果用户访问某个站点, 且浏览器缓存了其中一些响应, 随后导航到第二个站点, 该站点可以尝试加载它知道存在于第一个站点上的响应. 如果这些响应加载很快, 就可以推断用户访问过该站点, 甚至访问过该站点上的特定页面.

这种"时序攻击 (timing attack)"可以通过向缓存键添加更多信息来缓解 (例如引用站点的身份, 以防止上述攻击). 这有时称为"双重键控 (double keying)".

实现和部署缺陷 (通常源于对缓存操作的误解) 可能导致敏感信息 (例如认证凭据) 被缓存, 从而暴露给未授权方.

注意, Set-Cookie 响应头字段 [COOKIE] 不会抑制缓存; 带有 Set-Cookie 头字段的可缓存响应可以 (且通常会) 用于满足对缓存的后续请求. 希望控制这些响应缓存方式的服务器, 建议发送适当的 Cache-Control 响应头字段.