Security advisories

Cache Poisoning Leveraging Various X-Headers

August 13, 2018

Summary

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.

Detail

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.

Impact

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.

Mitigation

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:

Reconfiguring your origin server [2]

Applying corresponding security updates [3] [4] [5]

Stripping or normalizing these special values in VCL

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: