Blocking main page to steal postmessage

Support HackTricks

Ganhando RCs com Iframes

De acordo com este escrito de Terjanq, blobs de documentos 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 é deixar a página pai criar 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 irá 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ê poderia 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 big integer em um postmessage que será convertido para 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.

Support HackTricks

Last updated