Web Cache Deception (WCD) is an attack in which an attacker deceives a caching proxy into improperly storing private information sent over the internet and gaining unauthorized access to that cached data. It was proposed by Omer Gil, a security researcher in 2017.
What is web caching?
Web caching is the storing of data for reuse in the same browser.
It is one of the most beneficial technologies available to improve user experience and enables better performance standards for the users.
It is considered an essential internet infrastructure and one of the most popular CDN (Content Delivery Network).
The developers configure web caching functionality to their applications, which caches the web files that are frequently requested from the users so that when a user request one of those files the next time, it is directly served from the cache.
Thus, the server does not have to perform the same request repeatedly, which can prevent the server from being overloaded.
What can be cached?
We can cache public and static files that do not contain any sensitive information, such as:
General JavaScript files
Style sheets
Downloadable content
Media files
And the files with sensitive information or single user-specific information, such as assets, banking info, recent orders are not cached.
Although web caching reduces the load on web servers and improves the Internet user’s experience while browsing the web, web cache deception attack puts many Internet users at risk because of the widespread use of web caches and caching proxies deployed by CDN (Content Delivery Network) providers.
How does web cache deception attack work?
When the browser makes a request to a website, the connection usually passes through the CDNs (Content Delivery Network).
CDNs are a geographically distributed network of proxy servers and their data centers, which caches the local copies of web content to provide faster access to the users by reducing their network latency, and thus reducing the load on web servers.
Caching servers have no safeguards to authenticate users and prevent information, and it only stores non-user specific static or public content. And all the user-specific dynamic contents get routed to the main servers of the website or service a user interacts with.
The web caching deception (WCD) attack works by the technique of path confusion attack.
It manipulates the URL path by which the cache server is forced to store, and the sensitive data gets revealed as public content.
Web cache deception attack simulation
Let us consider having an application which is user specific and non-cached, and contains a profile section (https://www.example.com/my_profile).
And the attacker lures the victim to open the malicious crafted link (https://www.example.com/my_profile/test.css), where the file “test.css” does not exist on the web server.
Since it is a non-existent file, the application ignores the “test.css” part of the URL and loads the victim’s profile page. Also, the caching mechanism identifies the resource as a style sheet, and caches it.
Then the attacker sends a GET request to the cached page (https://www.example.com/my_profile/test.css), and the victim profile page will be returned.
The web cache deception attack works only when all the following conditions are met:
When
https://www.example.com/my_profile/test.cssis requested, the content ofhttps://www.example.com/my_profileshould be returned as the response.The web caching functionality is configured to cache files based on their extensions.
And the victim must be authenticated while accessing the maliciously crafted URL.
How to prevent web cache deception?
Web cache deception is easier to exploit and hence it belongs to the group of the most critical vulnerabilities.
The best part is that there are plenty of ways to implement security in the sensitive content of the website from being cached and from getting revealed to the unauthorized users.
The following are the most opted mitigation methodologies:
The cache server should run based on the cache-control headers set by your application, and only cache the files if their HTTP caching headers allow it.
Cache the files only depending upon their Content-Type header, rather than solely checking the file extensions.
The server should return HTTP-errors such as 302, or 404 based on the non-existent files being requested.
