What is Web Cache Deception?
Web Cache Deception is a vulnerability where an attack can trick the caching server into thinking that a sensitive dynamic page is a static cacheable resource.
Example
Imagine a website that provides access to LLM APIs to its users. The website provides a dashboard that shows users their API Keys, account details and other sensitive information.
Now…
What if the caching server caches the sensitive page since it thinks it is a static resource?
This could allow an attacker to get access to the cached resources and gain access to the victims sensitive information, including their API Key.
This all stems from incorrect caching configuration by a developer. However, we’re all human and mistakes will happen. Even if everything is configured correctly there can still be issues between components that provide the web application.
Why is Web Cache Deception Interesting?
This mainly arises from a discrepancy in the interpretation of the URL between the cache server and the origin server.
Example
Imagine the website has the following URL:
example.com/my-account
This provides sensitive information about the currently authenticated user.
The caching server has the following configuration.
Whenever a URL ends with .css treat it as a static resource.
This seems logical as CSS resources are static.
However, what happens when there is a discrepancy between the cache server and origin server?
How Hackers See It
An attacker notices that resources with .css are being cached.
Can I trick the caching server into caching a sensitive page?
Get Atharv Tripathi’s stories in your inbox
Join Medium for free to get updates from this writer.
They try to modify the URL.
example.com/my-account;abc.css
As the origin server will treat the ; as a path parameter and ignore any after it, it will see this as:
example.com/my-account
However, the cache server will see this as a static resource due to .css extension.
We now have a discrepancy.
Note: This depends on how the caching server/origin server handles semicolons.
What Happens Now?
The attacker gets the victim to click on the link containing the crafted URL.
The victim clicks on the link.
The victim sends an authenticated request to the crafted URL. The origin server will see this as /my-account and send back the victims sensitive account information. The cache server will think this is a static resource (ends with .css) and cache it. The attacker now makes a request to the crafted URL. If the cache server sends back the victims cached response without isolating the response per user then the attacker can get access to the sensitive information.
The attacker could have now accessed information that should not have been public.
Their API Key, account information or other sensitive information could now be in someone else’s hands.
How Can We Prevent This?
There are ways to prevent this vulnerability.
Use correct Cache-Control Headers: Sensitive authenticated resources should have Cache-Control: private, no-store set.
Correct Caching Configuration: Don’t cache all resources that end with .css/.js or other static file types. Ensure that the response is cacheable.
Ensure Consistent URL Interpretation: Ensure that the cache server and origin server both interpret and normalise URLs correctly. Pay particular attention to how delimiters, path parameters and URL encoding work.
Correct Cache Isolation: Ensure that responses per user cannot be accessed by other users.
Overall, Web Cache Deception is a good example of how a seemingly benign caching system can cause a major security issue if there is a discrepancy in how the URL is interpreted between components.
Remember, caching should speed up your application, not give everyone access to your users sensitive information.
Happy Hacking!
