Today, I want to write an article about one of my own discovered vulnerabilities known as Cache Deception, which ultimately led to an Account Takeover.

If you are not familiar with caching and its vulnerabilities, I recommend reading this blog post: Web Cache Mechanism and Vulnerabilities.

So, let's dive into the vulnerability that resulted in the Account Takeover.

The website I was working on had user registration and login functionality. After login, a specific request was made that returned user information in the response. Additionally, the website used a JWT token for authentication, which was stored in cookies.

If you're not familiar with authentication and JWT, I suggest reading this article: Authentication Architectures.

Upon inspecting the response headers, I noticed the following header:

HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Cf-Cache-Status: DYNAMIC
Server: cloudflare
Cf-Ray: id-CDG

This indicated that the website was using Cloudflare as a CDN service, which also had caching capabilities.

Next, I examined the endpoint that displayed user information more closely and found that the JWT cookie was also being displayed in the response, like this:

window.data = {
"JWT": "JWT-TOKEN-HERE",
}

To check for the Cache Deception vulnerability, I appended a .css extension to the end of the URL to inspect the cache status. The URL looked like this: https://www.vulnerable-domain.com/some-path/123456/settings/profile.css

After sending the request, the response header showed the cache status:

HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Cf-Cache-Status: MISS
Vary: Accept-Encoding
Server: cloudflare
Cf-Ray: id-AMS

However, the status code of the page was still 200, and the user's JWT token was present in the response.

I repeated the request several times, and the response headers changed to this:

HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Cf-Cache-Status: HIT
Age: 15
Vary: Accept-Encoding
Server: cloudflare
Cf-Ray: id-CDG

With the change in cache status from MISS to HIT, I realized that the page and response were successfully cached. To make sure, I cleared my authentication cookies and sent another GET request to the same path without any cookies. I still saw my JWT token on the page.

This allowed me to take over the account, as I had the JWT token in my possession.

Conclusion

Cache Deception can be a severe security vulnerability, as it allows unauthorized users to access sensitive data and potentially leads to account takeover. In the case of the website I tested, improper cache configuration combined with the exposure of JWT tokens in responses posed a significant risk. This incident underscores the importance of secure cache settings and data handling in web applications. Website owners and developers should be vigilant in protecting sensitive information and implementing appropriate security measures to prevent Cache Deception vulnerabilities.