Full Report
In bug bounty, it's just about finding the vulnerability - it's about exploiting the vulnerability to create as much impact as possible. In the author's situation, they found XSS on a simple static website that wasn't connected very well to the rest of the application. This meant that session hijacking, account takeovers, and sensitive API calls were unlikely to work. Their first exploit attempt was adding a login form to the page to trick the user into signing in and stealing the credentials. However, this requires too much interaction, making it a solid medium severity bug on its own. To add more impact, they create an iFrame sandwich. In most cases, an iFrame cannot access its parent frame's contents. One exception: it can if they're on the same domain or a subdomain. Since this subdomain was for maps and showed on the main website, it could access the contents of the page, bypass SOP, use cookies, etc. One question I had was how to get the main page to embed the vulnerable version of our page, since it is reflected XSS. To get around, the subdomain can be embedded into an attacker-controlled website where they specify the URL. But, this doesn't mean that the website's top-level site that we're trying to get data from is vulnerable, though. The other trick is getting the parent of the iFrame to have access to the other page. To do this, an important order of operations is done: Attacker website opens up the page to do the exploitation via window.open(). Attacker sets the window.location to be the target page. The parent window of the page opened in step 1 is STILL this window, even though we opened a new page. The page opened in step 1 contains an iFrame with the exploit payload in it targeting the subdomain page. The iFrame accesses the parent reference of the page, now on the website we want to exfilitrate data from. Cookies can be shown, the DOM edited... this is super powerful! The end of the article discusses the security team of the product and the security researcher. The researcher's job is to write a powerful and impactful exploit; the researcher bears the burden of proof. To the security team, the PoC is the minimum impact. Unfortunately, the security team deemed this out of scope since the subdomain was out of scope. They fixed the vulnerability though. Personally, if you affect an in-scope item with a vulnerability outside of the scope, you should be rewarded. Attackers do not care about "scope" - they care about impact. Fantastic blog post!
Analysis Summary
# Vulnerability: Reflected XSS Escalation via Same-Origin Iframe Sandwich Attack
## CVE Details
- CVE ID: N/A (Specific CVE not mentioned in the article, describes a technique applied to an undisclosed vulnerability)
- CVSS Score: N/A (Severity adjusted from Medium to potentially High based on impact; no official score provided)
- CWE: CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))
## Affected Systems
- Products: Static website/subdomain (e.g., `stores..uk`) embedded within a primary application/domain (e.g., `www..uk`).
- Versions: Not specified.
- Configurations: Requires the primary domain to embed the vulnerable subdomain within an iframe on an in-scope page (e.g., `/stores` endpoint).
## Vulnerability Description
The core vulnerability is a Reflected Cross-Site Scripting (XSS) flaw on a low-impact subdomain (e.g., a static map/store locator page). In isolation, this XSS was deemed Medium severity as sensitive functionality (session hijacking, API calls) was unavailable.
**Escalation Technique (Iframe Sandwich):**
The attacker escalates the impact by leveraging the Same-Origin Policy (SOP) exception: if an iframe's origin matches the parent frame's origin or a subdomain thereof, the attacker-controlled JavaScript within the nested iframe can access and manipulate the parent window's DOM, cookies, and session data.
The exploit sequence involves:
1. Attacker-controlled website opens the target page (e.g., `www..uk/stores`) using `window.open()`. The parent window context remains on the attacker's site despite opening a new window referencing the target.
2. The attacker navigates the newly opened window to the main target page which loads the vulnerable subdomain in an iframe.
3. The XSS payload executes within the vulnerable subdomain's iframe. Because the subdomain shares the origin (or is a subdomain) of the parent page (`www..uk`), the payload can reference the parent window (e.g., `window.parent`) and perform actions (read cookies, manipulate DOM) on the high-value main site.
This technique bypasses SOP restrictions to exfiltrate data from the top-level domain context.
## Exploitation
- Status: Proof of Concept (PoC) demonstrated internally by the researcher. The actual vulnerability was reported but found to be **Out of Scope** by the security team (due to the vulnerable component being out of scope, despite the impact on an in-scope component).
- Complexity: Medium to High, requiring coordination across multiple window contexts and specific timing/ordering operations (`window.open`, manipulating `window.location`, and referencing `window.parent` from the deeply nested iframe).
- Attack Vector: Network (Requires the victim to visit a malicious URL or click a link leading to the attacker-controlled site).
## Impact
- Confidentiality: High (If SOP is bypassed, cookies and sensitive data from the main domain can be stolen).
- Integrity: High (DOM of main site can be modified, allowing for unexpected behavior or further attacks).
- Availability: Low (The attack focuses on information disclosure and context hijacking, not denial of service).
## Remediation
### Patches
- No specific patch details were provided, as the report focuses on the exploitation technique. The underlying fix would involve correcting the Reflected XSS on the subdomain.
### Workarounds
- **Scope Restriction:** The security team's immediate action was considering the vulnerable component (subdomain) out of scope.
- **Content Security Policy (CSP):** Properly configured CSP headers on the main application (`www..uk`) could potentially restrict script execution or frame-ancestors, though the article implies the SOP bypass mechanism itself may circumvent basic framing restrictions if the origins match closely.
## Detection
- **Indicators of Compromise (IoC):** Suspicious redirection patterns involving `window.open()` followed by rapid frame context switching. Look for JavaScript attempting to access or write to `window.parent` from embedded, cross-origin content that should otherwise be sandboxed.
- **Detection Methods and Tools:** Web Application Firewalls (WAFs) focused on identifying payloads designed for frame manipulation or excessive DOM interaction originating from known untrusted sources. Monitoring network logs for data exfiltration initiated from the nested subdomain context targeting the main domain.
## References
- Affected technique discussed in: Critical Thinking Podcast, Episode 47 ("CSP Research, Iframe Hopping, and Client-Side Shenanigans").
- Author's original article: Cooper Young, "Exacerbating Cross-Site Scripting: The Iframe Sandwich" (defanged: `https://coopergyoung.com/exacerbating-cross-site-scripting-the-iframe-sandwich/`)