Trasformare la Self‑XSS in Stored XSS: vecchie vulnerabilità su browser moderni

Con una recente ricerca, Vsevolod Kokorin (Slonser) ha dimostrato che le vulnerabilità note come Stored Self‑XSS – spesso considerate di scarso impatto perché sfruttabili solo nell’account attaccante – possono invece evolvere in Stored XSS reali, sfruttando tecnologie emergenti come gli iframe credentialless (Make Self-XSS Great Again).

Il dilemma classico

1. Lo script XSS va eseguito sull’account dell’attaccante, altrimenti non ha privilegi utili.
2. Ma, una volta loggati come attaccante, non si può più rubare la sessione della vittima.

La svolta degli iframe credentialless

Grazie all’attributo credentialless, un iframe carica la pagina della vittima senza accedere ai cookie o allo storage associati – pur mantenendo lo stesso origin. Questo significa avere due contesti distinti ma manipolabili:

• Un iframe normale che carica victim.domain con cookie attivi.
• Un iframe credentialless che carica lo stesso dominio senza credenziali.

Ecco la consegna: ambienti separati, stesso origin.

Da Self‑XSS a Stored XSS: lo scenario pratico

1. Iniezione e Self-XSS

Un payload XSS (es. in un campo username non sanitizzato) viene salvato nella dashboard/victim. Questo è il classico Stored Self‑XSS, eseguibile solo da chi ha accesso all’account.

2. Login CSRF verso l’attaccante

Grazie a un form CSRF sul login:

<form action="http://victim/login" method="POST">
  <input name="username" value="attacker_username<img…>" hidden>
  <input name="password" value="Super_s@fe_pwd" hidden>
  <script>document.forms[0].submit();</script>
</form>

l’attaccante induce la vittima (contenuta in un iframe credentialless) a eseguire il login con l’account dell’attaccante stesso.

3. Sincronizzazione dei contesti

Utilizzando due iframe (credentialless e “normale”), entrambi con lo stesso origin, il codice eseguito nell’iframe malicious può accedere ai cookie dell’iframe victim:

alert(window.top[1].document.cookie);

A quel punto si ottiene session cookie e si può eseguire codice arbitrario sul contesto della vittima.

Varianti: CAPTCHA, Clickjacking e fetchLater

• Self‑XSS + CSRF + CAPTCHA
  Si può automatizzare la raccolta del token con un WebSocket tra client e server dell’attaccante per completare il login di vittima-attaccante.
• Self‑XSS + Clickjacking
  Se non esiste CSRF, si può usare un overlay per incentivare l’utente a inserire credenziali dell’attaccante in realtà dirette al form di login del victim.
• **X‑Frame‑Options: Deny? No problem. fetchLater!**
  L’API fetchLater() (marzo 2025) permette di schedulare richieste in background, anche dopo la chiusura del tab.
  Con essa, basta creare richieste forgiate verso l’endpoint /change_rights e lasciarle partire quando la vittima tornerà autenticata.

Conclusioni e impatto

• Stored Self‑XSS non è più “di serie B”: con i moderni browser può diventare Stored XSS completo.
• Le strategie combinate (iframe credentialless, CSRF login, fetchLater) aprono nuovi scenari d’attacco con minima interazione utente.
• Implicazioni immediate per bug bounty e triage: una segnalazione spontanea di Self‑XSS dovrebbe far scattare controlli su login CSRF, CAPTCHA e supporto fetchLater.

Raccomandazioni per mitigare

• Bloccare gli iframe non autorizzati con Content-Security-Policy: frame-ancestors.
• Inserire CSRF token su tutti i form di login/privilegi elevati.
• Verificare e limitare l’uso di fetchLater, anche disabilitarla su strumenti sensibili.
• Effettuare penetration test mirati su Stored Self‑XSS: adesso hanno potenziale reale.

Un doveroso importante ringraziamento a Slonser per aver alzato l’asticella e reso più chiara la reale pericolosità di vecchie vulnerabilità rivisitate con nuove tecnologie browser.