How I Earned $650 by Exploiting Web Cache Deception

Introduction

In the world of cybersecurity, web cache deception is a sneaky yet powerful attack that can expose sensitive user information due to improper caching mechanisms. In 2024, I discovered and reported a Web Cache Deception Attack that led to user organization information disclosure, earning a $650 bounty. In this article, I will break down how I found the vulnerability, the technical details, exploitation, and remediation.

Reward

For discovering and reporting this vulnerability, I received a $650 bounty, highlighting the severity of web cache misconfigurations and their potential risks.

What is Web Cache Deception?

Web Cache Deception (WCD) is a vulnerability where a web server incorrectly caches sensitive data, making it publicly accessible. This typically occurs when certain URLs are cached improperly, allowing an attacker to retrieve private user-specific content.

A common scenario involves the server caching URLs with unexpected file extensions like .css, .jpg, or .js, even when they contain sensitive user-specific data.

portswigger.net article

How It Works:

1. A user accesses a sensitive endpoint, e.g., https://target.com/account/settings
2. An attacker manipulates the request to https://target.com/account/settings.css
3. If the server incorrectly caches this response, the attacker can access private information intended only for authenticated users.

The Discovery Process

During testing, I found an endpoint:

https://target.com/dashboard/data/endpoint/organizations.json

This endpoint was using web cache to store organization data related to the account.

Step 1: Testing for Cache Deception

I decided to test for cache deception or poisoning by adding a cache-buster parameter to the URL endpoint to check if it reset the Age response header. Each new cache-buster parameter (useless parameter) successfully reset the header, proving that cache deception was possible.

/endpoint/organizations.json?cacheBuster=123

Step 2: Storing Organization Data in Cache

I attempted to store the organization data in cache using:

https://target.com/dashboard/data/endpoint/organizations.json?Anyparam=123

After storing the data, I accessed the same endpoint with the same cache-buster parameter in another account and browser. I was successfully able to view the organization data of the previous account, proving that the cache stored data and allowed other accounts to retrieve it by manipulating cache-buster parameters.

Step 3: Expanding the Scope

Realizing the impact, I searched for additional vulnerable endpoints and found that every endpoint using the .json extension was vulnerable:

• /{appName}.json?uselessParam=hello
• /{{VictimsOrganizationName}}.json?uselessParam=hello
• {{organizationName}}/settings.json?uselessParam=hello
• /{AppName}/settings.json?uselessParam=hello
• /widget.json?uselessParam=hello
• /webhooks.json?uselessParam=hello

Reward Received