Blocking main page to steal postmessage

Supporta HackTricks

Vincere RC con Iframes

Secondo questo writeup di Terjanq, i blob documenti creati da origini nulle sono isolati per motivi di sicurezza, il che significa che se mantieni occupata la pagina principale, la pagina dell'iframe verrà eseguita.

Fondamentalmente, in quella sfida un iframe isolato viene eseguito e subito dopo che è caricato, la pagina genitore invierà un messaggio post con il flag. Tuttavia, quella comunicazione postmessage è vulnerabile a XSS (l'iframe può eseguire codice JS).

Pertanto, l'obiettivo dell'attaccante è far sì che la pagina genitore crei l'iframe, ma prima di far sì che la pagina genitore invi i dati sensibili (flag) mantienila occupata e invia il payload all'iframe. Mentre la pagina genitore è occupata, l'iframe esegue il payload, che sarà un po' di JS che ascolterà il messaggio postmessage della pagina genitore e ruberà il flag. Infine, l'iframe ha eseguito il payload e la pagina genitore smette di essere occupata, quindi invia il flag e il payload lo ruba.

Ma come potresti far sì che la pagina genitore sia occupata subito dopo aver generato l'iframe e solo mentre aspetta che l'iframe sia pronto per inviare i dati sensibili? Fondamentalmente, devi trovare un'azione async che potresti far eseguire alla pagina genitore. Ad esempio, in quella sfida la pagina genitore stava ascoltando i postmessages in questo modo:

window.addEventListener('message', (e) => {
if (e.data == 'blob loaded') {
$("#previewModal").modal();
}
});

quindi era possibile inviare un big integer in un postmessage che sarà convertito in stringa in quella comparazione, il che richiederà del tempo:

const buffer = new Uint8Array(1e7);
win?.postMessage(buffer, '*', [buffer.buffer]);

E per essere precisi e inviare quel postmessage proprio dopo che l'iframe è stato creato ma prima che sia pronto a ricevere i dati dal genitore, dovrai giocare con i millisecondi di un setTimeout.

Support HackTricks

Last updated