1. VULNERABILITY INTRODUCED

Web Cache Deception is another technique for attacking caches. It’s different from the HTTP Cache Poisoning attack because no tainted data is saved in the cache and then served to users (which is what Cache Poisoning implies). During the Web Cache Deception attack, a malicious user gains unauthorized access to sensitive data of another user by exploiting ordinary cache behavior.
The following conditions should be met for the attack to succeed:
1. The web server returns the contents of the “root” page (https://codebashing.com/home/) when a nonexistent static file (like https://codebashing.com/home/somecss.css) is requested. (In other words, the URL is rewritten from route /home/somecss.css to /home/.)
2. Web cache disregards HTTP headers that define caching behavior and relies on file extensions (in our example – a CSS file).
3. A victim is authenticated while accessing a malicious URL.

2. EXERCISE BACKGROUND

The vulnerable application pane loads the online shopping application LotsOfGoods.me. It aggregates data from multiple off-line shops and presents it on a single platform. The user can buy goods from all those sellers right from the application.
Alice is a legitimate user of this application. She is a frequent buyer and often receives direct messages from sellers inside the application.

3. VULNERABILITY DETECTED

Bob is a malicious user of the application. Once he reads about the Web Cache Deception attack and decides to try it with the LotsOfGoods.me app. He is sure that the online shop like that should be extensively using caching for load balancing or decreasing the webpage’s loading time.
He crafts the URL that leads to the non-existing CSS file:
https://lotsofgoods.me/myaccount/profile/recentorder.css
Then he logs in to the application and requests this URL from the LotsOfGoods.me server.

4. VULNERABILITY EXPLOITED

As there is no such page on the server, it returns to Bob a predefined page – his profile page at https://lotsofgoods.me/myaccount/profile/.
Now Bob needs to check whether or not this page with his sensitive info is available to the arbitrary user that uses the same link.
Bob logs out of the app, opens the incognito mode window and enters the link:
https://lotsofgoods.me/myaccount/profile/recentorder.css

As you can see, Bob’s profile page was cached and is successfully loaded in the browser. This means that the application is vulnerable to the Web Cache Deception attack. Now Bob is ready to get access to sensitive data of other users!

5. SUCCESSFUL ATTACK

Bob creates a malicious message to Alice that contains the malicious link.
Alice usually ignores unsolicited correspondence requests, but in general, she doesn’t mind leaving feedback, so she decides to make the world a little bit better and review her recent purchases. She clicks the link.

6. MALICIOUS RESULT

From Alice’s perspective, nothing suspicious happened: the application redirected her back to her profile, so she considered that the link was broken.
Half an hour later Bob opens the link (https://lotsofgoods.me/myaccount/profile/revieworder.css) in the incognito mode window to check whether his attack was successful.

Bob sees there cached Alice’s profile page will all her sensitive data!

7. RECAP

So, let us quickly recap what had happened during the attack.
1. Bob lured the authenticated user (Alice) on a page with a nonexistent static resource (a CSS file in our case: https://lotsofgoods.me/myaccount/profile/revieworder.css).
2. The web server returned the contents of https://lotsofgoods.me/myaccount/profile/ page ignoring the filename and its extension.
3. Web cache disregarded HTTP headers that define caching behavior and cached the returned page (with all sensitive data of the logged on user) as a static file, based on its extension.
4. As a result, a subsequent request of the attacker to the https://lotsofgoods.me/myaccount/profile/revieworder.css showed the response for https://lotsofgoods.me/myaccount/profile/ with user’s sensitive data.

8. REMEDIATION

To prevent Web Cache Deception, make sure the following conditions are met:
1. Only static content is cached, and it is separated from the rest of the content.
2. In case a non-existent page (or file) is requested, 404 page is returned or a redirect to the home page is performed using the HTTP 302 response code.
3. Caching directives from HTTP headers are taken into consideration and not ignored.