What is Web Cache Poisoning?
When a malicious actor takes advantage of the vulnerabilities in a web server and cache, they manipulate the system to deliver a harmful HTTP response to other users.
It involves 2 phases:
- The attacker needs to figure out a method to extract a response from the back-end server that unintentionally includes a potentially harmful payload.
- They must ensure that the manipulated response is cached and then delivered to the targeted victims.
How does a web cache work?
Handling individual HTTP requests separately would likely overwhelm the server, leading to increased latency and a subpar user experience.
Caching serves as a crucial solution to mitigate these issues. Positioned between the server and the user, the cache temporarily stores responses to specific requests.
When a comparable request is initiated, the cache promptly provides a duplicate of the stored response, reducing the server’s load and eliminating the necessity for backend interaction.
Cache keys
The cache examines incoming HTTP requests to determine if it can directly provide a stored response or if it must forward the request to the back-end server for processing.
Caches identify similar requests by comparing specific components, known as the “cache key.” Usually, this includes the request line and host header. Any request components not part of the cache key are termed "unkeyed."
If the cache key of an incoming request matches the key of a previous request, the cache considers them equivalent.
Consequently, it will deliver a duplicate of the cached response created for the initial request. This holds true for all subsequent requests sharing the same cache key until the cached response expires.
What is the impact of a web cache poisoning attack?
The impact of web cache poisoning hinges on two critical factors:
- Nature of Cached Content:
The extent of the impact is contingent on what the attacker successfully gets cached. The injected payload’s harmfulness determines the severity of the attack, and when combined with other attacks, it can escalate the overall impact. - Traffic on the Affected Page:
The impact is directly related to the volume of traffic on the affected page. The poisoned response is served only to users visiting the compromised page while the cache is tainted. Consequently, the impact can vary significantly, from minimal to extensive, based on the popularity of the affected page.
For instance, poisoning the cache of a major website’s home page could affect a large number of users without requiring further interaction from the attacker.
Constructing a web cache poisoning attack
- Identify and evaluate unkeyed inputs
In a web cache poisoning attack, the manipulation targets unkeyed inputs, particularly headers. Web caches disregard unkeyed inputs when determining whether to provide a cached response to the user. Exploiting this behavior allows for the injection of a payload, triggering a poisoned response that, if cached, gets served to all users sharing the matching cache key in their requests. The initial step in executing a web cache poisoning attack involves identifying supported unkeyed inputs by the server.
Uncovering unkeyed inputs can be done manually by introducing random inputs to requests and noting their impact on the response. The effects may range from directly reflecting the input in the response to triggering a completely different response. While tools like Burp Comparer can aid in comparing responses with and without injected input, this process often demands considerable manual effort, especially when identifying subtle effects that require detective work. - Obtain a harmful response from the back-end server
After identifying an unkeyed input, the subsequent step involves assessing how the website processes it.
Gaining a thorough understanding of this process is crucial for successfully triggering a harmful response. If an input is mirrored in the server response without proper sanitization or is employed in dynamically generating other data, it becomes a potential vulnerability for web cache poisoning. - Get the response cached
Manipulating inputs to elicit a harmful response is half the battle, but it doesn’t achieve much unless you can cause the response to be cached, which can sometimes be tricky.
The caching of a response can hinge on various factors, including the file extension, content type, route, status code, and response headers. Experimentation with requests on different pages is often necessary to understand how the cache responds. Once you determine the method to cache a response containing the malicious input, you are prepared to deploy the exploit to potential victims.
How to prevent web cache poisoning vulnerabilities
- HTTPS Implementation:
Encrypt traffic between client and server to prevent interception and modification. - Cache-Control Headers:
Control caching duration and revalidation to avoid serving outdated content. - Anti-Cache Poisoning Mechanisms:
Use unique cache keys or randomized tokens to prevent content reuse for different users. - User Input Validation:
Thoroughly validate and sanitize user input to prevent injection of malicious content. - Content Security Policy (CSP):
Implement CSP headers to restrict allowable content types, thwarting injection of harmful scripts. - Secure Cookies Usage:
Employ secure cookies to prevent interception or modification, hindering injection into the cache. - Monitoring and Auditing Logs:
Regularly monitor logs for suspicious activity, enabling timely detection and response to cache poisoning attacks.
