Web caching enables quicker and seamless browsing by downloading the copy of a file locally, thereby preventing future browser requests from getting redirected to the remote server. In a vulnerable application, threat actors inject specially crafted data into cache memory, causing the webserver to respond with a malicious HTTP response to the user. This form of attack is commonly known as web cache poisoning.
This article discusses a web cache poisoning attack, its impacts, various prevention strategies, and addresses commonly asked questions.
What is Web Cache?
Most web pages are typically accessed several times in a given period. When a client requests a visit to any web page, the webserver temporarily stores a copy of the webpage in its memory. Every subsequent incoming request for the same resource is served with the copy saved on memory, preventing the remote server from getting overloaded. A web cache is the copy of the server’s response that enables uicker delivery of web objects to the client. Physical store data closer to the user also minimizes network traffic and enhances a website’s performance.
How Does Web Caching Work?
The first time a user visits a web page, his request is served from the remote server. The web server receives the client request, retrieves the required information from the remote server, and converts the requested web page into an HTML file loaded onto the client browser. This response also gets stored for a fixed amount of time in the cache server. As the cache server resides between the user and the remote server, the next time a user requests to visit this page, the cache server sends the ready static files to the browser instead of processing the request from the remote server.
The cache server uses a “cache key” to determine whether the response is present in the cache memory or the request is to be handled by the remote server. The cache key is a predefined subset of the request’s components that typically includes the host header and request line. If the cache key of an incoming request matches that of a previous request, the request is handled by the cache server that serves a copy of the stored response.
Caching offers a multitude of benefits for modern websites, such as:
Reduced workloads for the webserver
Improved response throughput
Reduced network traffic
Predictable website performance
Caching mechanisms even include specifications for emptying cache memory when specific conditions are met. For instance, developers can configure the website to delete a cached version of the homepage and blog pages when a post is published, leaving all other pages unaltered.
Two primary forms of web caching include:
Server-Side Caching
In this caching, the server stores the static response within its memory. Since the web cache has the requested resource, it intercepts all subsequent requests and sends back the stored response instead of reprocessing the request again.
Client-Side Caching/Browser Caching
The first time a user visits a website, the server responds with several resources such as stylesheets, fonts, JavaScript files, etc. The browser downloads these resources along with the web page content. If client-side caching is enabled for the browser, a copy of these resources gets temporarily stored on the browser. The next time the user visits the website, the loading time is remarkably reduced as the web page resources are directly loaded from the browser’s cache.
What is Web Cache Poisoning Attack?
In a web cache poisoning attack, an attacker exploits vulnerabilities within the caching mechanism to store a modified and negative response in the cache entry, making the site serve malicious content to its visitors. To construct a successful web cache poisoning attack, a hacker typically attempts the following steps:
Identification and evaluation of unkeyed inputs – Unkeyed inputs are the parts of a request that the cache ignores while determining whether the resource requested has to be served from the cache. A hacker identifies vulnerable code that allows the injection of malicious headers into the HTTP response header field. This vulnerability is exploited to manipulate the unkeyed inputs and utilize these inputs to inject the poisoned response that is served to all users whose request for the resource matches with the cache key.
Evoking the harmful response requires the malicious actor to understand how the web server processes the unkeyed input to elicit a malicious response successfully. Web cache poisoning attacks are only possible when these inputs can be used to generate other responses dynamically or if the server reflects this input in its response without adequate validation or input sanitation.
Caching the malicious response – The success of a web caching attack depends on the successful storage of the harmful response in cache memory. Attackers need to indulge in various observations and trial & error mechanisms to examine the behavior of the cache. Responses may or may not get cached, depending on multiple factors such as status code, response headers, route, file extension, content type, etc. Once the response gets cached successfully, the exploit can be delivered to potential targets.
Considering numerous conditions to be met, a web cache poisoning attack is relatively challenging to perform. The impact of an attack typically depends on the successful storage of cached response and the traffic concerning the affected cache. Web cache poisoning is often combined with other attacks such as cross-site scripting payloads to enhance the consequences of the exploit. If an attacker successfully poisons a browser cache, the impact is merely on a few users. In contrast, server-side cache poisoning can potentially impact many subscribers without constant interaction with the hacker.
How to Protect Applications from Web Cache Poisoning Attacks
Some strategies to prevent web cache poisoning vulnerabilities on applications include:
Enable Caching for Purely Static Responses
Although it is tempting to disable caching entirely, this is not a recommended fix as cache allows to improve the performance of an application. While caching should be enabled, it is advised to keep it restricted only for purely static responses to prevent attackers from manipulating the server into obtaining a harmful response.
Disable Unkeyed Inputs
Developers should identify various inputs included in the HTTP response but are not part of the cache key. Attackers typically use these unkeyed headers to embed their malicious responses into the request bodies. To mitigate such attacks, web developers should remove unkeyed inputs from the cache layer, add a cache key or disable unkeyed inputs altogether.
Use a Vulnerability Scanner
A vulnerability scanner tests the entire web application to identify open endpoints that can accept harmful responses into the cache memory. A cache vulnerability scanner automatically uncovers flaws that can be used to inject harmful responses such as HTTP response splitting, allowing developers to patch them up before a hacker performs any exploits. Additionally, scanners detect malicious payloads residing in cache memory, enabling the elimination of harmful responses before they are served to users.
The Crashtest Security Suite ships with a vulnerability scanner to detect web cache poisoning threat vectors for JavaScript, APIs, and web applications with pinpoint accuracy. The platform offers actionable vulnerability reports that teams can share for faster assessment and remediation.
FAQs
What is the difference between DNS cache poisoning and web cache poisoning?
DNS cache poisoning affects the Domain Name Server. In a DNS cache poisoning attack, the attacker embeds invalid data into the cache of a DNS server. Each DNS query receives the wrong response, redirecting users to a different DNS entry. A DNS poisoning attack makes the DNS caching server log disallow IP addresses in the memory cache, making the DNS request recall the wrong site.
On the other hand, Web cache poisoning involves modifying request bodies to invoke a harmful response stored in the server or browser’s cache memory.
What is the difference between web cache poisoning and Cross-user defacement?
While both attack techniques often rely on HTTP response splitting, these types of attacks differ in the approach a harmful payload is delivered to the user. In web cache poisoning, the dangerous response resides in cache memory.
In cross-user defacement, the attacker makes a single request that manipulates the server into sending two responses. The second response typically contains a malicious response which is misinterpreted as a response to the subsequent request.
Where is cache data stored?
Cached files are temporarily stored in a device’s Random Access Memory (RAM) since it offers high-speed access. Web caches can likewise be stored on web proxies, interception proxies on Internet Service Providers, Content Delivery Networks, or Gateway Cache servers.
This article has already been published on https://crashtest-security.com/web-cache-poisoning/ and has been authorized by Crashtest Security for a republish.
Top comments (0)