Full Report
The Content Security Policy (CSP) is used to restrict what can be done on a web page. This is useful for defense-in-depth on issues, like XSS, as well as framing. The origin of resources and the types can be restricted as well. In this case, the author had an arbitrary file upload bug but couldn't exploit it because of the CSP not allowing unsafe-inline. Modern browsers will display accessed data as HTML, as long as the Content-Type lines up. This includes images, CSS files and more. If we can load data into an iFrame, then we can trick the page into loading the page for us. A lot of the time, the CSP is conditional; by loading it into an iFrame with a weird page, we can bypass the CSP. This works with weird looking images or JS files. The solution? Put the CSP on all requests. This will gunk things up, which is annoying though. The final payload is confusing to me though; it's using JavaScript to create an iFrame on the page to bypass the CSP. If you can execute JS already then why do you need to bypass the CSP? Regardless, interesting CSP bypass technique; put stuff in iFrames that is not meant to be in iFrames.
Analysis Summary
# Tool/Technique: Conditional CSP iFrame Bypass
## Overview
This technique involves bypassing Content Security Policy (CSP) restrictions—specifically those preventing `unsafe-inline` execution—by leveraging inconsistent CSP application across a web application. An attacker identifies pages or resources (such as images, CSS, or JS files) where the CSP is absent or less restrictive, and loads them within an iFrame to execute arbitrary code or exfiltrate data.
## Technical Details
- **Type:** Technique (Exploitation Bypass)
- **Platform:** Web Browsers
- **Capabilities:** Bypassing `script-src` restrictions, cross-site scripting (XSS) elevation, arbitrary file execution via upload bugs.
- **First Seen:** N/A (Standard web security bypass technique documented by Wallarm)
## MITRE ATT&CK Mapping
- **TA0001 - Initial Access**
- **T1189 - Drive-by Compromise**
- **TA0005 - Defense Evasion**
- **T1562 - Impair Defenses**
- **TA0002 - Execution**
- **T1059.007 - Command and Scripting Interpreter: JavaScript**
## Functionality
### Core Capabilities
- **iFrame Injection:** Uses JavaScript to dynamically create an iFrame targeting a internal URL that lacks a strict CSP.
- **Content-Type Exploitation:** Leverages the fact that modern browsers may render various file types (images, CSS) as HTML if accessed directly or in a specific context.
- **Exploiting Arbitrary File Uploads:** If an attacker can upload a file but cannot execute it due to the main page's CSP, they can reference that uploaded file inside an iFrame on a "weird" or unprotected page to trigger execution.
### Advanced Features
- **Conditional CSP Targeting:** Identifies specific application states or "weird" pages (error pages, legacy endpoints, or resource-specific URLs) where the security headers are dynamically omitted.
- **Polyglot Files:** Using files that are valid in two different formats (e.g., a valid GIF that also contains valid HTML/JS) to bypass type-checking while circumventing the CSP.
## Indicators of Compromise
- **File Names:** Look for uploaded files with mismatched extensions or double extensions (e.g., `image.jpg.html`).
- **Network Indicators:**
- Requests to unexpected endpoints returning `Content-Type: text/html` for non-HTML files.
- Presence of sensitive data in URL parameters of iFramed resources.
- **Behavioral Indicators:**
- Unexpected DOM modifications inserting `<iframe src="...">` tags pointing to internal static resources.
- Rapid succession of requests to the same resource with different file headers.
## Associated Threat Actors
- Broadly used by Web Application attackers and Bug Bounty hunters.
- Specific groups are not attributed in the provided context, as this is a general vulnerability class.
## Detection Methods
- **Behavioral Detection:** Monitoring for DOM mutations that create iFrames where the `src` attribute points to file upload directories or static resource paths.
- **WAF/DAST Scanning:** Security scanning for pages within a domain that lack the `Content-Security-Policy` header while other pages in the same origin possess it.
- **Header Analysis:** Auditing HTTP response headers to ensure `X-Content-Type-Options: nosniff` is present, which prevents browsers from "guessing" the content type and executing images as scripts.
## Mitigation Strategies
- **Global CSP Application:** Ensure the `Content-Security-Policy` header is applied to **all** requests, including error pages, static assets, and API endpoints.
- **Frame Busting:** Use the `frame-ancestors 'none'` or `'self'` directive in the CSP to prevent the site from being embedded in an iFrame.
- **Strict Content-Types:** Enforce `X-Content-Type-Options: nosniff` to prevent the browser from interpreting non-HTML files as executable content.
- **File Upload Security:** Store uploaded files on a separate, sandboxed domain (e.g., `user-content-google.com`) to isolate the execution context from the primary application domain.
## Related Tools/Techniques
- **Reflected XSS:** Often used as the initial entry point to inject the iFrame-creating script.
- **Clickjacking:** Related via the use of iFrames, though focused on UI manipulation rather than CSP bypass.
- **MIME Snubbing:** The underlying browser behavior that allows this technique to succeed.