Full Report
Facebook has an extra security mechanism after logging in to ensure the user is valid. This could be a captcha, MFA but is commonly referred to as a chcekpoint. This is implemented within an iframe that is a sandboxed URL. When implementing this, the outside domain URL is shared with the sandbox URL. Since this could be within some OAuth flow, the code for OAuth could be leaked inside of this iframe. So, if we could communicate with this iframe we could potentially steal oauth codes to takeover accounts. By chance, the author already had an XSS with the domain www.fbsbx.com. Since the domain is a sandbox, it's actual by design though. On a particular page, it's possible to upload HTML files on this domain. To steal the URL passed to the iframe we need to have a relation to the two windows. First, we need access to the Facebook checkpoint page. Next, we need a window with the XSS on the Facebook sandbox referenced as well. To do this, we can open the first window in a new tab from our malicious website. For the second one, we can create an iframe on this page with the sandbox within it. The iframe for the sandbox and the window with the login code with the page have the same origin. Hence, they are able to read the some of the same information! In particular, the location.href can be stolen to get the code. The one other complication to this is that we need to force the account into this checkpoint state. So, we can use a login CSRF and a logout CSRF to do the trick. However, if we do this to Facebook directly then we won't get anything out of it. So, the trick is to do this to a OAuth provider, like Gmail. To perform the attack, do the following steps: Logout CSRF Login CSRF Open up the Gmail OAuth provider with a redirect to Facebook with window.open(). This will redirect to Facebook's checkpoint page with a code in the iframe. Wait a few seconds for all of the interactions to happen. Access the frames information using the XSS to get the Google OAuth code. Start the password recovery process on Facebook.com and connect via Gmail. Use the code and state in order to login to Google. The deep understanding of client side security of this hacker always amazes me. On top of this, just having an XSS in the pocket was awesome. I wonder if there's a good place to find all of the client side security things? If you see one, please let me know!
Analysis Summary
Based on the provided context description, here is the summarized vulnerability report. Note that because this summary is derived from a descriptive narrative rather than a formal CVE announcement, specific CVE IDs, severity scores, and patch versions are unavailable and marked as such.
# Vulnerability: Cross-Window Communication Leakage Leading to OAuth Account Takeover via Checkpoint Iframe
## CVE Details
- CVE ID: N/A (No official ID provided in the context)
- CVSS Score: N/A (Severity is implicitly High due to Account Takeover potential)
- CWE: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) / CWE-611 (Improper Restriction of Resource Locations in a URL)
## Affected Systems
- Products: Facebook login/authentication flow, specifically systems utilizing an embedded 'checkpoint' iframe for validation during login or OAuth processes.
- Versions: Not specified, affects the architectural implementation involving shared URLs between the main domain and the sandboxed checkpoint iframe.
- Configurations: Any configuration where the main domain URL context is shared with a sandboxed iframe URL (e.g., during OAuth flows), and where an XSS vulnerability exists on the sandboxed domain (`www.fbsbx.com` in this case).
## Vulnerability Description
The vulnerability arises from a complex interaction involving Facebook's security checkpoint mechanism (often implemented in an iframe pointing to a sandboxed URL like `www.fbsbx.com`), an existing Cross-Site Scripting (XSS) vulnerability on that sandboxed domain, and the manipulation of OAuth flows.
The core issue is that the main window context (which might be within an OAuth redirect flow holding sensitive codes) shares visibility/communication channels with a sandboxed iframe used for the checkpoint. Crucially, the attacker leveraged an existing XSS on the sandboxed domain (`www.fbsbx.com`, which allowed HTML uploads) to gain control over that frame.
By orchestrating Login CSRF and Logout CSRF actions to force an account into the checkpoint state during an external OAuth provider (e.g., Gmail) redirection to Facebook, the attacker could:
1. Open the Google OAuth process, redirecting it to Facebook with the use of `window.open()`, which loads the checkpoint page containing the sensitive OAuth code exchange in the inner iframe context.
2. Because the main window (hosting the attacker's controlled XSS on the sandbox domain) and the checkpoint iframe shared origin context (due to specific implementation details around the sandboxed/authentication domains), the attacker's malicious script could read sensitive information, specifically `location.href`, from the frames object to steal the OAuth code.
3. This stolen code, combined with the state, was then used in a subsequent step to complete the login/authorization on the OAuth provider, effectively hijacking the process and gaining account control on the target platform (Facebook/Google linked account).
## Exploitation
- Status: PoC available (The author details a clear, multi-step exploitation chain).
- Complexity: Medium/High (Requires chaining multiple security flaws: CSRF for flow manipulation, an existing blind XSS on a highly privileged domain, and precise timing/window management).
- Attack Vector: Network (Requires the victim to interact with the attacker's controlled initial page/redirection).
## Impact
- Confidentiality: High (Theft of session tokens or authentication codes leading to ATO).
- Integrity: High (Unauthorized access and potential modification of user accounts).
- Availability: Low (The service itself is nominally available, but integrity is compromised).
## Remediation
### Patches
- Patches are not specifically detailed in the provided context description.
- **Inferred Mitigation:** The fix would focus on removing cross-origin communication capabilities between the main application window and the authentication/checkpoint iframes **unless explicitly necessary and properly validated (e.g., secure use of `postMessage`)**, and fixing the underlying XSS on the sandboxed domain (`www.fbsbx.com`).
### Workarounds
- Avoid relying on window navigation or direct frame interaction between top-level contexts and nested sandboxed contexts unless strict origin checks are enforced.
- Users should be cautious when completing multi-step authentication/OAuth redirects involving embedded security checkpoints.
## Detection
- Detection would involve monitoring for unusual cross-window communication attempts or post-message usage that attempts to read `location.href` from iframes associated with authentication endpoints.
- Suspicious sequence of Logout CSRF followed immediately by a Login CSRF coupled with an external OAuth trigger could be an indicator.
## References
- Youssef Sammouda (sam0) personal blog: hXXps://ysamm.com/ (The context describes one of the findings discussed on this site, though the exact linked article for this specific vulnerability is not explicitly named in the provided snippet.)