Blocking main page to steal postmessage
Last updated
Last updated
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 iframe verrà eseguita.
Fondamentalmente in quella sfida un iframe isolato viene eseguito e subito dopo che è caricato, la pagina genitore invierà un post messaggio 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) mantienila occupata e invia il payload all'iframe. Mentre il genitore è occupato, l'iframe esegue il payload che sarà qualche 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:
quindi era possibile inviare un big integer in un postmessage che sarà convertito in stringa in quel confronto, il che richiederà del tempo:
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
.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)