michelangelus - Fotolia
How to configure browsers to avoid web cache poisoning
Web cache poisoning poses a serious threat to web browser security. Learn how hackers can exploit unkeyed inputs for malicious use with expert Michael Cobb.
Web caching is an important feature of HTTP. It reduces network traffic and the load on web servers while improving a site's perceived responsiveness by reducing latency -- but there are security risks involved, such as web cache poisoning.
A web cache sits between the user and the web server and caches the web server's responses to requests according to certain rules. Subsequent requests for the same content can then be fulfilled from the cache instead of sending the request all the way to the web server. For example, content delivery networks like the one from Cloudflare have caches located around the world, and many web applications and frameworks, such as Drupal, have a built-in cache.
When a cache receives a request for a resource such as a webpage, it needs to check whether it has a copy of the exact resource already saved that it can use. Or, if it needs to, the cache can forward the request to the web server.
As HTTP requests contain various pieces of data, such as User-Agent -- the user's browser type -- it's not possible to compare two requests byte for byte. Instead, caches use cache keys and a few specific components of an HTTP request to identify the requested resource. This is often just the path and query string, if present, and the Host header. The headers and cookies that are not included when generating the cache key are called unkeyed inputs.
Web cache poisoning
Web cache poisoning, whereby the cache is tricked into storing malicious content generated by a request that causes an unsafe response from the web server, has been previously deemed too complex to be a real threat. However, in a Black Hat 2018 session entitled "Practical Web Cache Poisoning: Redefining 'Unexploitable,'" James Kettle, head of research at PortSwigger Web Security, the company that makes Burp Suite, demonstrated how unkeyed inputs can be abused to take control of web caches and manipulate platforms such as Drupal and Mozilla's Firefox browser.
To speed up the task of identifying unkeyed inputs, Kettle developed an open source Burp Suite extension called Param Miner to automate the process. He then checked to see if the unkeyed inputs were reflected back in the response. If they are, and the page gets cached, then it's possible to make the caching system cache a response that contains user-controlled input that has not been validated and cleansed. This will then be served to anyone who requests that resource, giving attackers the opportunity to exploit other vulnerabilities.
Kettle pulled off some scary hacks that leveraged this attack vector, and they can be seen in the video of his presentation. These hacks included changing the X-Forwarded-Host header to inject a cross-site scripting payload into a cached response that executes arbitrary JavaScript against whoever views it.
To prevent websites from having their caches used as exploit delivery systems, web admins need to properly set the HTTP response header configuration files on their servers. Use the Vary HTTP response header to tell any HTTP cache which parts of the request header -- other than the path and the Host header -- to include when trying to find the right object.
Web developers should avoid using input from HTTP request headers and cookies where possible and validate and cleanse any inputs they use. They should also use the Param Miner extension to audit their applications to see if there are any unkeyed inputs that have been introduced by the frameworks or the third-party components they use and ensure they are handled properly.
Disabling caching on a web server isn't really a viable option for sites, so it's important that admins implement and check these controls on a regular basis.
