[EN] Massive Data Leak via Web Cache Deception

Censorship Note: All data (domains, paths, URIs, and variables) have been strictly anonymized using entirely fictional nomenclature (e.g., api.smart-home-platform.net). This report documents an indirect exfiltration of personal and IoT device information within a simulated environment to guarantee 100% privacy for the original enterprise.

This writeup details a critical Web Cache Deception (CWE-524) vulnerability discovered across the core API endpoints of an IoT/Smart Home device management platform.

Due to a severe misconfiguration between the Content Delivery Network (CDN) rules and the corporate origin server, an attacker was able to force the system to store any user's private information (emails, usernames, camera locations, and serial numbers) into the public cache, leaving it entirely exposed to the internet.

Vulnerability Analysis

In modern web architectures, CDNs are responsible for mitigating server load by statically storing "safe" and non-sensitive resources, such as images, CSS stylesheets, or JS scripts, to dispatch them rapidly to any visitor. Responses containing dynamic, user-personalized JSON should never be cached.

The discovered flaw lay in how the company's CDN categorized content. The CDN determined whether a request should be stored in the public cache strictly based on the final extension of the requested URL.

The attacker discovered that by appending ; .css to the end of any dynamic user-profile API request, the application server would process the request while ignoring the suffix, but the CDN—seeing the .css extension—would assume the final response was simply a stylesheet and permanently deposit it in its public cache, shared with the entire world.

A URL originally structured as: https://api.smart-home-platform.net/account/getDashboardLayout.json

Could be forced into massive caching if called as: https://api.smart-home-platform.net/account/getDashboardLayout.json;.css

The Attack Vector and Chain (PoC)

For the attacker to receive another user's data, they first needed to induce the victim to process that request under their own credentials.

To trigger the attack as stealthily as possible, the attacker chained this vulnerability with an Open Redirect present in the logout process of one of the company's subdomains.