WEB安全第五课 HTTP协议 之五 缓存机制 |
出于性能和带宽的考虑,HTTP客户端和一些中转性质的系统,都会对HTTP响应进行缓存以便重用。在早期互联网时代,这件事看起来还算简单,但随着Web承载的敏感信息、用户相关信息越来越多,更新也越来越频繁,缓存的问题也日益变得步步惊心。
![]() 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安全第五课第六节:
帖子热度 8064 ℃
|
|
畅游在词汇的海洋里 也难以找到恰如其分的感激之语 来表达感激之情,你是论坛的一盏明灯 期市里的一棵夜明珠 永放异彩你的帖子一定会让许多的有识之士获益匪浅 .让我们一起祝愿楼主文成武德仁义英明泽被苍生 一统江湖 天长地久 日月同辉!
|