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 的相关要求, 请参见 [HTTP/1.1] 的第 6.3 节.

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

例如, 如果用户访问某个站点并且其浏览器缓存了其某些响应, 然后导航到第二个站点, 则该站点可以尝试加载它知道存在于第一个站点上的响应. 如果它们加载速度很快, 则可以假定用户已访问该站点, 甚至是其上的特定页面.

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

实现和部署缺陷 (通常由于对缓存操作的误解而导致) 可能导致缓存被认为是私有的敏感信息 (例如, 身份验证凭据), 从而将其暴露给未经授权的各方.

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