Blocking main page to steal postmessage
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
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 é 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 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:
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:
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
.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)