Bloccare la pagina principale per rubare postmessage

Reading time: 3 minutes

Vincere RC con Iframes

Secondo questo writeup di Terjanq, i documenti blob creati da origini null sono isolati per motivi di sicurezza, il che significa che se mantieni occupata la pagina principale, la pagina 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 il genitore crei l'iframe, ma prima di far sì che la pagina genitore invi i dati sensibili (flag) tenerla occupata e inviare il payload all'iframe. Mentre il genitore è occupato, l'iframe esegue il payload che sarà un po' di JS che ascolterà il messaggio postmessage del 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 rivela.

Ma come potresti far sì che il genitore sia occupato 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 al genitore. Ad esempio, in quella sfida il genitore stava ascoltando i postmessages in questo modo:

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

quindi era possibile inviare un intero grande in un postmessage che sarà convertito in stringa in quel confronto, 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.