How can you prevent HTTP response cache poisoning attacks on software applications?

1 What is HTTP response caching?

HTTP response caching is a mechanism that allows browsers and proxies to store copies of web pages and serve them faster to subsequent requests. This reduces the load on the server and improves the user experience. However, HTTP response caching also introduces some risks if not implemented correctly. An attacker can manipulate the cache by sending a request with a modified header, such as If-None-Match, If-Modified-Since, or Cache-Control, that forces the server to return a different response than expected. This response can contain malicious content, such as scripts, redirects, or cookies, that can affect the users who receive it from the cache.

2 How to detect HTTP response cache poisoning?

To detect HTTP response cache poisoning, you can use tools such as Burp Suite or Fiddler to inspect the headers and compare them with the original ones. Additionally, online services, such as Cache Poisoning Scanner or REDbot, can scan a URL and check for cache poisoning vulnerabilities. Signs of cache poisoning include inconsistent or mismatched ETag, Last-Modified, or Content-Length headers; missing or invalid Cache-Control, Pragma, or Expires headers; and unexpected or malicious content in the response body.

3 How to prevent HTTP response cache poisoning?

To prevent HTTP response cache poisoning, it is essential to implement the right cache control policies on both the server and client side. This involves setting the appropriate headers to instruct the cache how to handle the responses. For example, use Cache-Control: no-store or no-cache for sensitive or dynamic pages, Cache-Control: private for pages that should only be cached by the browser, Cache-Control: public for static pages unaffected by user input, Cache-Control: max-age or Expires to specify expiration time, ETag or Last-Modified to validate freshness, Vary to indicate which headers affect content, and Content-Security-Policy to restrict sources of scripts, styles, images, and other resources.

4 How to test HTTP response cache poisoning?

To test HTTP response cache poisoning, you can simulate the scenario where an attacker sends a request with a modified header that changes the response from the server and the cache. Tools like Burp Suite or Fiddler can be used to intercept and modify the requests and responses, while online services such as Cache Poisoning Tester or Cache Poisoning Attack Demo demonstrate how cache poisoning works. To test cache poisoning, you need to identify a page that is cached by the browser or a proxy, send a request with a normal header and observe the response, then send another request with a modified header such as If-None-Match: "fake" and observe the response. After comparing the responses for differences in the headers or content, repeat the steps with different headers and values to see how they affect the cache.

5 How to mitigate HTTP response cache poisoning?

If you discover that your application is vulnerable to HTTP response cache poisoning, immediate action must be taken to mitigate the impact and prevent further attacks. This includes invalidating the cache by changing the ETag, Last-Modified, or Content-Length headers of the affected pages, forcing a cache refresh by sending a request with Cache-Control: no-cache or Pragma: no-cache headers, disabling the cache by sending a response with Cache-Control: no-store or no-cache headers, notifying the users and advising them to clear their browser cache and cookies, reviewing your code and fixing any logic errors or vulnerabilities that allow the attacker to manipulate the headers or content, and implementing proper input validation and output encoding to prevent cross-site scripting (XSS) or other injection attacks.

6 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?