Bloqueando la página principal para robar postmessage

Ganando RCs con Iframes

Según este escrito de Terjanq, los documentos blob creados desde orígenes nulos están aislados por beneficios de seguridad, lo que significa que si mantienes ocupada la página principal, la página del iframe se va a ejecutar.

Básicamente, en ese desafío se ejecuta un iframe aislado y justo después de que se carga, la página padre va a enviar un post mensaje con la bandera.
Sin embargo, esa comunicación de postmessage es vulnerable a XSS (el iframe puede ejecutar código JS).

Por lo tanto, el objetivo del atacante es dejar que la página padre cree el iframe, pero antes de que la página padre envíe los datos sensibles (bandera) mantenerla ocupada y enviar el payload al iframe. Mientras la página padre está ocupada, el iframe ejecuta el payload que será algún JS que escuchará el mensaje postmessage de la página padre y filtrará la bandera.
Finalmente, el iframe ha ejecutado el payload y la página padre deja de estar ocupada, por lo que envía la bandera y el payload la filtra.

Pero, ¿cómo podrías hacer que la página padre esté ocupada justo después de generar el iframe y solo mientras espera que el iframe esté listo para enviar los datos sensibles? Básicamente, necesitas encontrar una acción asíncrona que puedas hacer que la página padre ejecute. Por ejemplo, en ese desafío, la página padre estaba escuchando postmessages así:

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

así que era posible enviar un número entero grande en un postmessage que será convertido a cadena en esa comparación, lo que tomará algo de tiempo:

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

Y para ser preciso y enviar ese postmessage justo después de que se crea el iframe pero antes de que esté listo para recibir los datos del padre, necesitarás jugar con los milisegundos de un setTimeout.