WEB安全第五课 HTTP协议之五缓存机制

小执念 · 2016-5-29 19:40

出于性能和带宽的考虑，HTTP客户端和一些中转性质的系统，都会对HTTP响应进行缓存以便重用。在早期互联网时代，这件事看起来还算简单，但随着Web承载的敏感信息、用户相关信息越来越多，更新也越来越频繁，缓存的问题也日益变得步步惊心。

WEB安全第五课 HTTP协议之五缓存机制 120_120216114821_1.jpg

      RFC2616的13.4节里说，如果没有其他服务器端指令，客户端可以默认对若干GET请求的HTTP响应码（比较知名的如“200 OK”和“301 Moved Permanently”）进行缓存。这些响应甚至可以不限时长地一直缓存下去，只要请求方法和目标URL与之前一致就行，即使其他参数（如Cookie的值）不一样，也可以重用缓存。而使用HTTP授权方式的请求则不能使用缓存，但其他授权认证方式，如Cookie，则未在规范里明确限定。

      当响应被缓存以后，客户端一般都会在重用前判断一下是否需要验证和重载内容，当然大多数时候并不需要主动这么做。服务器往往根据一些条件判断型的请求头，来确认是否需要进行内容刷新，如If-Modified-Since请求头（它后面的值就是上一次缓存该页面的时间），又比如If-None-Match(后面跟着一个不透明的ETag值，这个值代表的是上次访问该文件时，服务器端推送过来的文件标识符）。

      服务器端将根据请求头里发过来的条件，如果ETag标识符与上次相比没有变化，则响应一个“304 Not Modified”（没有变化）代码，表示无需刷新，又或者根据需要再完整地返回一次该资源的副本。

      注意:通过Date/If-Modified-Since和ETag/If-None-Match这两组响应/请求头的搭配，再结合使用Cache-Control:private响应头，就能方便而隐秘地获得浏览器在一段时间内的访问规律和使用习惯。同样地，也可以将一个独一无二的字符串标记嵌到可缓存的JavaScript文件里，然后在访问该文件时，如果请求头里包含了缓存条件，一律答复“304 Not Modified(没有变化）”，也能达到同样的效果。

      相比，浏览器会缓存什么信息、什么时候被缓存、会缓存多久等问题，用户几乎完全没有控制权。#382:

      由于隐式的缓存机制会带来许多问题，因此服务器几乎总是倾向于使用显式的HTTP缓存指令。为了实现由服务器端控制的缓存机制，HTTP/1.0里提供了Expires响应头，设定到什么时候，被缓存的副本即告失效；如果这个值正好等于服务器提供的Date响应头，则表示这个响应不能再被缓存了。

      但除了这条简单的规则之外，Expires和Date之间的联系就没有更详细的说明了：所以也不清楚Expires值是和缓存服务器的系统时间相比呢(如果客户端和服务器的时间不一致，就可能有这问题），还是根据Expires与Date两数字相减的具体差值来说的（这种方式相对更可靠些，但如果缺少了Date值，这种方式则可能无法正常工作）。Firefox和Opera采用后一种做法，而其他浏览器则选择前一种。对大多数浏览器来说，如果Expires的值是无效的，则干脆不使用缓存，但这点并不可靠，不能依赖于这个处理。

      HTTP/1.0客户端还有一个Pragma:no-cache请求头，代理服务器如果收到这个请求头，就会重新再抓取一遍被请求的资源副本，而不是返回已有的缓存内容。某些HTTP/1.0代理服务器还会接受非标准的Pragma:no-cache响应头，然后对使用这个响应头的文件也不会进行缓存。

      HTTP/1.1的处理则不同，它使用新增的Cache-Control做为缓存指令，这种方式的可用性更高。这个头域有4种域值：public(可以公开被缓存的文档）、private(代理服务器不得缓存的文档）、no-cache(这个命名看上去比较让人误解，意思是响应的文档可以被缓存但不能重用）0和no-store(绝对不需要被缓存）。Public和Private缓存指令可以搭配max-age和must-revalidate两个确定因子一起使用，前者决定旧副本的存活时间，后者则可以按照条件判断型的请求头来确定是否需要重用内容。

      遗憾的是，Web服务器往往需要同时返回HTTP/1.0和HTTP/1.1的缓存指令，因为某几种古老的商用代理服务器软件不能正确识别Cache-Control指令。为了可靠地禁止HTTP缓存，Web服务器可能需要返回全部以下响应头：

      Expires:[当前日期时间]
      Date:[当前日期时间]
      Pragma：no-cache
      Cache-Control:no-cache,no-store

      当这些缓存指令之间有冲突时，会出现什么状况很难预测：有的浏览器倾向于认为HTTP/1.1协议里的缓存设置和Cache-Control里的no-cache设置的优先级都较高，即使在no-cache后面还错误地跟着个public值也还是以no-cache为准；而另一些浏览器则刚好相反。

      HTTP缓存的另一个风险和不安全网络环境有关系，例如不加密的Wi-Fi网络，黑客可以通过拦截对某些URL地址的请求，向受害者返回被篡改过并可以长期缓存的请求内容。然后这种受到污染的浏览器缓存如果在受信任的网络上被重用，被注入的内容可能就出人意料地重新浮现出来了。

      更邪恶的是，受害者甚至无需直接访问目标网站：攻击者可以精心选择一些敏感域，然后在其他的上下文环境中再引用这些域的内容。这样，被攻击者即使没有访问最早的那个目标网站，攻击者也能达到目的。目前对这个问题还没有很好的解决方法，反正在星巴克咖啡店上网之后，清空浏览器缓存也许是个好主意。#361:

WEB安全第五课第六节：HTTP协议之六 Cookie语义

[# 网络安全] WEB安全第五课 HTTP协议之五缓存机制

相关帖子

管理员

[# 网络安全] WEB安全第五课 HTTP协议 之五 缓存机制

相关帖子

管理员

[# 网络安全] WEB安全第五课 HTTP协议之五缓存机制