Bloqueando a página principal para roubar postmessage

Reading time: 3 minutes

Ganhando RCs com Iframes

De acordo com este escrito de Terjanq, documentos blob criados a partir de origens nulas são isolados por benefícios de segurança, o que significa que se você mantiver a página principal ocupada, a página do iframe será executada.

Basicamente, nesse desafio um iframe isolado é executado e logo após ser carregado, a página pai vai enviar uma mensagem post com a flag.
No entanto, essa comunicação postmessage é vulnerável a XSS (o iframe pode executar código JS).

Portanto, o objetivo do atacante é fazer com que a página pai crie o iframe, mas antes de deixar a página pai enviar os dados sensíveis (flag), mantê-la ocupada e enviar o payload para o iframe. Enquanto a página pai está ocupada, o iframe executa o payload, que será algum JS que escutará a mensagem postmessage da página pai e vazará a flag.
Finalmente, o iframe executou o payload e a página pai para de estar ocupada, então ela envia a flag e o payload a vaza.

Mas como você poderia fazer a página pai ficar ocupada logo após gerar o iframe e apenas enquanto espera que o iframe esteja pronto para enviar os dados sensíveis? Basicamente, você precisa encontrar uma ação assíncrona que você possa fazer a página pai executar. Por exemplo, nesse desafio a página pai estava ouvindo postmessages assim:

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

então era possível enviar um número inteiro grande em um postmessage que será convertido em string nessa comparação, o que levará algum tempo:

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

E, para ser preciso e enviar esse postmessage logo após o iframe ser criado, mas antes de estar pronto para receber os dados do pai, você precisará brincar com os milissegundos de um setTimeout.