Around a few days ago, I got some users information leakage due to web cache Deception Attack.
Before we jump into the POC, I want to explain these kinds of attacks and effects.
Web Cache Deception Attack is a type of attack where web app uses cache but it’s not validating properly which allows an attacker to craft cache leakage attacks.
In this scenario, web apps in the background often tend to use a proxy, CDN and other services to use cache functionality in which it reduces the time from the server or simply to reduce latency but not validating properly.
Suppose if there is a website like www.example.com/home.php and you tried an additional extension at the end of this URL like www.example.com/home.php/a.jpg, and if the website has cache functionality, it basically caches the website internal information and stores it into this above endpoint under their cache Directory, Extension can be anything like .css, .jpg, .js anything.
Once the user will visit and their info will be cached, then an attacker will just visit this same endpoint and Boom! user’s personal info can be leaked by visiting source code.
[Note: visit keypoints at the end of write-up :)]
Let’s jump to the main part
Last weak, while I was invited to a private program, I came across three different targets like (let’s just say)
So, you can register in example.com and log-in as well.
app.example.com was the main area to develop app and manage.example.com is another web app which basically uses in authenticating with Slack workspace and other services.
So, example.com was something like this (Sorry for Poor art 😐)
So, it was loading as example.com, but then I saw there was no cache control header or anything. Then I decided to give this a try.
[Note: Not all the time it’s vulnerable even if there is no cache control, see key points at the end of this write-up.]
So, I decided to visit endpoint like https://example.com/welcome.css
Notice in this 404 error page, it was still displaying go to your workspace, that means you can fetch some info.
Alright, After visiting this above URL, just visited the same endpoint in incognito mode.
But here comes the observation part, While I visited this endpoint in incognito mode, then for only 2–3 seconds it displayed me “Go to your Workspace” and then itself changes into login and signup area. It was totally a glimpse moment.
And I was like :
Maybe, as the session is not been cached properly and so for a glimpse of a moment, it showed me like “Go to your workspace” and changing itself into signup and login option but it has cached the info. So, let’s just visit the “view-souce:https://example.com/welcome.css” and see if there is any info has been cached and not.
So, yeah info has been cached and disclosed all the personal details.
1st part done
So example.com was over, So I tried to visit app.example.com, but no luck.
So, let’s go for manage.example.com
manage.example.com was just another web app where it allows the user to connect their slack workspace and also it can be used to retrieve info using API endpoint.
So, while I tried to visit manage.example.com and so, it redirects me to app.example.com, so there are some routing rules placed in the backend. It means manage.example.com can only be used for /api endpoints or /auth endpoints.
So, I just tried to simply inject any path like /a and it was showing me a response like this.
manage.example.com/a (error endpoint)
So, It means that this site has been depreciated in terms of frontend interaction.
But, then suddenly I saw the response header and there was no cache control header. But I was still confused like whether it’s going to work this time or not.
So, I tried to visit endpoint like manage.example.com/hello.css and response was the same as above.
But when I visited the same endpoint in incognito mode, it cached the info and displayed me the same view with active session mode.
So, I tried to visit the endpoint using view-source://manage.example.com/hello.css and this time, info has been cached in huge amount comparing to 1st part (example.com).