13 août 2018
On Thursday, August 9th, research was published at Black Hat USA 2018 on cache poisoning attacks against websites deployed behind caching infrastructure [1]. These attacks could allow an attacker to inject arbitrary content into a victim’s cache.
Fastly service configurations that do not take into consideration the interaction between headers that backends use to select content may be vulnerable. This risk can be fully mitigated via a VCL patch or by modifying backend configurations.
If one or more of your backends uses the contents of the X-Forwarded-Host
, X-Rewrite-Url
or X-Original-Url
HTTP request headers to decide which of your users (or which security domain) it sends an HTTP response for, you may be impacted by this class of vulnerability. If your site’s Fastly configuration passes this header to your backend, and does not factor the contents of this header into the effective edge cache key (for example explicitly or via the Vary
HTTP response header), an attacker could potentially cause the edge to store a response with arbitrary content inserted to a victim’s cache.
An attacker might be able to poison a Fastly customer URL by sending an HTTP request to the site that causes the affected backend to respond with an attacker-controlled response. The malicious response object would be stored in the site’s cache at a poisoned URL. An attacker could then potentially lure a victim site user into browsing to the poisoned URL, where they would be served malicious content.
If your origin uses special values to select content for users or to otherwise select between security domains, we suggest that you consider the following mitigations:
For VCL guidance, consider setting the vulnerable headers to a known-safe value or unsetting the header. For example, the X-Forwarded-Host
header can be set to the value of the Host
header via the following VCL snippet:
set req.http.x-forwarded-host = req.http.host;
The X-Original-URL
header can be unset via the following VCL snippet:
unset req.http.x-original-url;
And X-Rewrite-URL
can be unset via the following VCL snippet:
unset req.http.x-rewrite-url;
Alternatively, these values could be included in your cache key [6] or Vary
header [7] to prevent caching of content across security domains. Please see our documentation [6] for guidance on manipulating your edge cache key.
Our support teams are standing by to assist with any questions or with implementing workarounds if you believe you may be at risk due to this exploit.
Customer inquiries can be directed to:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14773
https://hackerone.com/reports/487
[1] https://portswigger.net/blog/practical-web-cache-poisoning
[2] https://github.com/rails/rails/issues/29893
[3] https://www.drupal.org/SA-CORE-2018-005
[4] https://symfony.com/cve-2018-14773
[5] https://framework.zend.com/security/advisory/ZF2018-01
[6] https://docs.fastly.com/en/guides/manipulating-the-cache-key
[7] https://www.fastly.com/blog/best-practices-using-vary-header