Portswigger，开发出Web应用攻击平台 Burp Suite 的公司，再添超越前版缓存中毒的新技术。
网页缓存能减少时延，降低应用服务器负载，从而加速网页加载。有些公司使用Varnish之类软件托管缓存；有些则选择依靠Cloudflare这样的内容分发网络(CDN)，将缓存散布在多个地方。还有些流行网页应用和框架，比如流行内容管理系统Drupal，具备内置缓存。
网页缓存中毒通过发送能引发有害响应的请求实施，该请求会被保存在缓存中，进而影响其他用户。
新型缓存中毒主要关注利用HTTP头之类非用户键入的输入。其他不那么有效的小花招，比如“请求走私”也有成功的可能。
缓存中毒本身不是黑客的最终目的，而是用非键入性输入打开第二阶段漏洞利用(比如跨站脚本攻击(XSS))大门的途径。只要正确操作，网页缓存中毒可创建起一套机制，产生能执行任意JavaScript代码的特定响应，通过目标网站的网页缓存，来攻击试图浏览该网站上特定资源的用户。
虽然恶名昭彰，缓存中毒却非常容易实施。在策略对研究人员不太限制的网站上做的实验已经证明了这一点。
Mr. Robot 扩展
Mozilla Firefox 浏览器的SHIELD系统维护有一张recipe表，可供静默安装用于市场营销或研究目的的扩展，其与黑客剧集《机器人先生》合作推出的 Mr. Robot 扩展就曾在推送之列。研究人员表示，可以黑掉Mozilla的基础设施，并部分劫持该静默安装扩展的功能，理论上能够联合数百万Firefox浏览器组成僵尸网络。
仅Mozilla签名代码才能以这种方式推送的控制措施，某种程度上限制了攻击者的破坏力。但无论如何，Mozilla的这项功能留下了可引发问题的隐患。
虽然不能直接安装恶意插件并获取完整代码执行权，但黑客可以将数千万用户导引到其所选择的URL，形成分布式拒绝服务(DDoS)攻击。除此之外，如果结合恰当的内存破坏漏洞，所造成的影响将不可估量。
而且，某些后端Mozilla系统使用未签名recipe，有可能被黑客攻陷，当成深藏于系统基础设施里的立足点，还有可能供黑客获取到recipe签名密钥。另外，黑客还可重放旧recipe，大量安装有漏洞的旧扩展，或者将已停止自动推送的 Mr. Robot 扩展又安回去。
研究人员已将该问题报告给了Mozilla。24小时之内，Mozilla便修复了其基础设施。但关于该问题的严重性，该公司与研究人员之间存在分歧，只支付了1000美元的漏洞奖励。
通过下载并梳理GitHub上前2万个PHP项目的头名称，研究人员扩展了头字典，发现了另一个方面的问题。
能够重写请求路径的X-Original-URL和X-Rewrite-URL头暴露了出来。我先是注意到了这两个头会影响运行Drupal的目标，随后在深挖Drupal代码的过程中，我又发现了支持这些头的是流行PHP框架Symfony，而Symfony的代码又来自Zend。
其结果就是，大量PHP应用在不知不觉间支持了这些头。
这些头简直就是绕过网页应用防火墙(WAF)和安全规则的利器，还能为缓存中毒提供一条康庄大道。只要应用使用了缓存，攻击者就能利用这些头欺骗应用，让应用提供错误的页面。
攻陷Unity
被称为“本地路由中毒”的一种攻击方法，可以让攻击者替换掉本应访问的路径。最终结果就是，访问请求发出之后，试图访问 Unity for Education 的用户可能会对浏览到的页面大吃一惊。
还有其他相关安全漏洞可供黑客重写查询字符串，若与Drupal的开放重定向联合使用，黑客构建漏洞利用的基础就齐全了。
能够重写请求路径的X-Original-URL和X-Rewrite-URL头暴露了出来。我先是注意到了这两个头会影响运行Drupal的目标，随后在深挖Drupal代码的过程中，我又发现了支持这些头的是流行PHP框架Symfony，而Symfony的代码又来自Zend。
作为第二阶段攻击的嵌套缓存中毒也是有可能实现的。如果站点使用外部缓存(比如几乎所有的高流量Drupal网站)，就可以用内部缓存来对外部缓存下毒，并在过程中将任意响应转换成重定向。
研究人员演示的最终实践结果，是点击unity.com网站上的“下载安装文件”按钮，会下载到evil.net上的恶意软件。
5月份的时候，该漏洞就已通报给了Drupal、Symfony和Zend。安全更新已放出，用户最好安装一下。
Mozilla和Drupal是网页缓存中毒的典型例子，其他项目也有缓存缺陷，但对缓存中毒漏洞的通报响应不一：
Unity立即做了全面修复并支付了可观的漏洞奖励；Mozilla的修复动作也很快；但包括data.gov和Ghost在内的其他人就几个月都毫无动静，只是在即将公开的威胁下才勉强修复。
这些案例研究中有很多都在非键入性输入中利用了XSS之类的次级漏洞。需要强调的是，若没有缓存中毒，此类漏洞会因没有可靠的方法迫使其他用户在跨域请求中发送定制包头而没什么用处。或许这就是此类漏洞很容易被发现的原因吧。
如何防护
要么做测试，确保自家网站没有缓存中毒漏洞；要么限制缓存使用，避免潜在风险。
应对缓存中毒的最坚实防御，就是禁用缓存。对某些人而言禁用缓存或许不太现实，但很多开始采用Cloudflare之类服务以驱动DDoS防护或边界SSL应用的网站，最终都会因为默认启用缓存而陷入缓存中毒攻击的困境。
将缓存限制在纯静态响应上也很有效，只要你对自己定义为“静态”的东西足够警惕。
但显然，简单地将缓存堆到网站面前只会让网站从安全状态落入脆弱状态。
网页缓存中毒长期以来都是个艰涩难懂的漏洞，一个主要用于恐吓开发人员去乖乖修复没人能实际利用的“理论上”的威胁。但如今，网页缓存中毒远不只是理论上的漏洞，臃肿的应用和层层叠叠的服务器栈正密谋将其推到大众面前。
附上Drupal安全团队发言人的回应：
收到研究人员的漏洞报告后，Drupal安全团队发现了Drupal依赖栈中的某些Symfony和Zend框架代码存在问题。Symfony和Zend项目成员与我们合作，协同发布了有关这些问题的情况说明与解决方案。
论文原文地址：
相关阅读
都什么年代了，打开个Word文档还能中毒！Locky病毒疯狂传播
