Full Report
The Same Origin Policy (SOP) is meant to prevent one website from requesting information on another website. In practice, data can be leaked from websites in other ways. A major one of these is timing of loading a resource. An original vector was described by Chris Evans against Yahoo! Mail, where you can search the inbox of a website to see if results are returned or not based on the amount of time it takes. Later, this was coined as XSSearch with hard statistics on timing. Based on timing, a list of attack methods, such as frame counting, is becoming increasingly popular due to "browser misfeatures". One of these methods that the author wants to bring to our attention is around browser caching. This can be used for timing attacks to understand if something was cached or not for the browser history. geographic information or general fingerprinting. Their variation is as follows: Delete the cache for a specific resource. Force the browser to render to a website as the user. Check if the browser cached the resource. They first check out Facebook for issues relating to this. According to them, URLs are signed, so it's not a simple cache or no cache problem. A good question to ask is " Does the image X get cached when the profile page is loaded?" By reviewing the cache, this could potentially be checked. Another variant of this on Facebook is checking for user access to some resource, such as a private group. In this case, it requires that something cachable be loaded in some cases, such as a legitimate search, but not in an illegitimate search. When searching Facebook messages, an extra pop-up appears to confirm before any JavaScript loads, preventing this attack. Facebook has some pretty neat protections against these types of attacks! How do we invalidate a cache entry? By making a POST request to the resource or issuing a Fetch API with a cache that returns an error from the server, such as a large HTTP referrer header. The final trick is quite simple: delete the cache, reload the page, and query the cache for the information. Crazy - the never-ending curse of caching. They end the post with some caveats on exploitation and a note of a Wiki page with all known Cross-Site leak techniques. Great post!
Analysis Summary
# Vulnerability: HTTP Cache Cross-Site Leaks (XS-Leaks)
## CVE Details
- **CVE ID:** N/A (General browser architectural flaw/side-channel)
- **CVSS Score:** N/A (Varies by implementation; typically categorized as Medium)
- **CWE:** CWE-203: Information Exposure Through Exception Timing; CWE-524: Use of Cache-able Resources after Session Expiry.
## Affected Systems
- **Products:** Major Web Browsers (Chrome, Firefox, Safari, Edge).
- **Versions:** All versions supporting standard HTTP caching and Fetch API at the time of publication (2019).
- **Configurations:** Any web application that loads different sub-resources (images, scripts, stylesheets) based on a user's state, permissions, or search results.
## Vulnerability Description
This vulnerability is a "Cross-Site Leak" (XS-Leak) that exploits the shared nature of the browser's HTTP cache. An attacker can determine if a user has previously visited a specific page or possesses certain data (like a specific friend or group membership) by checking if associated resources are present in the browser cache.
The specific "variation" described involves a three-step oracle:
1. **Cache Invalidation:** The attacker forces the browser to delete a specific resource from its cache (e.g., by making a POST request to the resource or a Fetch request with an intentionally oversized header).
2. **State Triggering:** The attacker forces the browser to render a target URL (via navigation or pre-rendering).
3. **Cache Querying:** The attacker checks if the resource was re-cached. If it was, the attacker knows the resource was loaded during the rendering, revealing the user's private state.
## Exploitation
- **Status:** PoC concepts available; known side-channel technique used in research.
- **Complexity:** Medium (Requires identifying state-specific resources and bypassing certain browser protections).
- **Attack Vector:** Network (Web-based/Cross-site).
## Impact
- **Confidentiality:** Medium. Allows attackers to leak private information such as search history, group memberships, geographic hints, or contact lists.
- **Integrity:** None.
- **Availability:** None.
## Remediation
### Patches
There is no single "patch" as this relies on the fundamental design of HTTP caching. However, browsers have moved toward **Cache Partitioning** (segmenting the cache by top-level origin) to mitigate this.
### Workarounds
- **SameSite Cookies:** Set cookies to `Strict` or `Lax` to prevent authenticated requests from being triggered by top-level navigations from malicious sites.
- **Cache-Control:** Use `Cache-Control: no-store` for sensitive resources to prevent them from hitting the disk or shared cache.
- **Resource Signing:** Use unique, rotating, or signed URLs for resources (as noted in Facebook’s implementation) so that an attacker cannot guess the exact URL to query.
- **User Interaction:** Require explicit user confirmation (e.g., a click) before executing sensitive search queries.
## Detection
- **Indicators of Compromise:** Unusual volumes of cross-site requests to specific static assets followed by timing or error-event probes.
- **Detection methods:** Web developers can use **Fetch Metadata** (`Sec-Fetch-Site`) to detect and block requests that do not originate from their own site.
## References
- [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html]
- [https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels]
- [https://scarybeastsecurity.blogspot.com/2009/12/cross-domain-search-timing.html]
- [https://web.dev/articles/http-cache-partitioning]