You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
+12-1Lines changed: 12 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -126,7 +126,7 @@ The research community continues to discover creative ways of abusing iframes to
126
126
console.log(victim.name); // → leaked value
127
127
```
128
128
129
-
***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:
129
+
***Nonce reuse via same-origin iframe** – CSP nonces are readable from the DOM by same-origin documents. If an attacker can inject or upload a *same-origin*HTML page and load it in an iframe, the child frame can read `top.document.querySelector('[nonce]').nonce` and mint new `<script nonce>`elements. This turns a same-origin HTML injection into full script execution even under `strict-dynamic` (because the nonce is already trusted). The following gadget escalates a markup injection into XSS:
@@ -191,7 +191,9 @@ Since **Chrome 110 (February 2023) the feature is enabled by default** and the s
191
191
192
192
* 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).
193
193
* 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.
194
+
* Storage is **partitioned by a top-level document nonce**: credentialless frames on the same page can share storage with each other, but it is cleared when the top-level document is discarded.
194
195
* Pop-ups spawned from a credentialless iframe get an implicit `rel="noopener"`, breaking some OAuth flows.
196
+
* Browsers are expected to **disable autofill/password managers** inside credentialless iframes, limiting credential theft via autofill in these contexts.
195
197
196
198
```javascript
197
199
// PoC: two same-origin credentialless iframes stealing cookies set by a third
As indicated in [this article](https://blog.slonser.info/posts/make-self-xss-great-again/) The API `fetchLater` allows to configure a request to be executed later (after a certain time). Therefore, this can be abused to for example, login a victim inside an attackers session (with Self-XSS), set a `fetchLater` request (to change the password of the current user for example) and logout from the attackers session. Then, the victim logs in in his own session and the `fetchLater` request will be executed, changing the password of the victim to the one set by the attacker.
233
235
236
+
Operational notes:
237
+
238
+
-`fetchLater` is still an emerging API with limited browser support; feature-detect before relying on it.
239
+
- The response is **not** available to JavaScript; body/headers are ignored once the deferred request is sent.
240
+
- CSP enforcement uses `connect-src` (not `script-src`) for deferred requests.
241
+
- Requests fire on page unload or when `activateAfter` expires (whichever happens first).
242
+
234
243
This way even if the victim URL cannot be loaded in an iframe (due to CSP or other restrictions), the attacker can still execute a request in the victim's session.
235
244
236
245
@@ -272,5 +281,7 @@ Check the following pages:
272
281
## References
273
282
274
283
*[PortSwigger Research – Using form hijacking to bypass CSP (March 2024)](https://portswigger.net/research/using-form-hijacking-to-bypass-csp)
284
+
*[PortSwigger Research – Bypassing CSP with dangling iframes (Jun 2022)](https://portswigger.net/research/bypassing-csp-with-dangling-iframes)
0 commit comments