PostMessage Vulnerabilities
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)
PostMessage usa a seguinte função para enviar uma mensagem:
Note que targetOrigin pode ser um '*' ou uma URL como https://company.com. No segundo cenário, a mensagem só pode ser enviada para aquele domínio (mesmo que a origem do objeto window seja diferente). Se o caractere curinga for usado, as mensagens podem ser enviadas para qualquer domínio, e serão enviadas para a origem do objeto Window.
Como explicado em este relatório, se você encontrar uma página que pode ser iframed (sem proteção X-Frame-Header
) e que está enviando mensagens sensíveis via postMessage usando um caractere curinga (*), você pode modificar a origem do iframe e vazar a mensagem sensível para um domínio controlado por você.
Note que se a página pode ser iframed, mas o targetOrigin está definido para uma URL e não para um caractere curinga, esse truque não funcionará.
addEventListener
é a função usada pelo JS para declarar a função que está esperando postMessages
.
Um código semelhante ao seguinte será usado:
Note que neste caso a primeira coisa que o código está fazendo é verificando a origem. Isso é terrivelmente importante, principalmente se a página for fazer qualquer coisa sensível com as informações recebidas (como mudar uma senha). Se não verificar a origem, atacantes podem fazer com que as vítimas enviem dados arbitrários para esses endpoints e mudem as senhas das vítimas (neste exemplo).
Para encontrar ouvintes de eventos na página atual, você pode:
Pesquisar o código JS por window.addEventListener
e $(window).on
(versão JQuery)
Executar no console das ferramentas de desenvolvedor: getEventListeners(window)
Ir para Elements --> Event Listeners nas ferramentas de desenvolvedor do navegador
Usar uma extensão de navegador como https://github.com/benso-io/posta ou https://github.com/fransr/postMessage-tracker. Essas extensões de navegador irão interceptar todas as mensagens e mostrá-las para você.
O atributo event.isTrusted
é considerado seguro, pois retorna True
apenas para eventos gerados por ações genuínas do usuário. Embora seja desafiador contornar se implementado corretamente, sua importância nas verificações de segurança é notável.
O uso de indexOf()
para validação de origem em eventos PostMessage pode ser suscetível a contornos. Um exemplo que ilustra essa vulnerabilidade é:
O método search()
de String.prototype.search()
é destinado a expressões regulares, não a strings. Passar qualquer coisa que não seja uma regexp leva a uma conversão implícita para regex, tornando o método potencialmente inseguro. Isso ocorre porque em regex, um ponto (.) atua como um curinga, permitindo contornar a validação com domínios especialmente elaborados. Por exemplo:
A função match()
, semelhante a search()
, processa regex. Se a regex estiver mal estruturada, pode ser suscetível a contornos.
A função escapeHtml
é destinada a sanitizar entradas escapando caracteres. No entanto, ela não cria um novo objeto escapado, mas sobrescreve as propriedades do objeto existente. Esse comportamento pode ser explorado. Particularmente, se um objeto puder ser manipulado de tal forma que sua propriedade controlada não reconheça hasOwnProperty
, o escapeHtml
não funcionará como esperado. Isso é demonstrado nos exemplos abaixo:
Falha Esperada:
Contornando a escapada:
No contexto dessa vulnerabilidade, o objeto File
é notavelmente explorável devido à sua propriedade name
somente leitura. Essa propriedade, quando usada em templates, não é sanitizada pela função escapeHtml
, levando a potenciais riscos de segurança.
A propriedade document.domain
em JavaScript pode ser definida por um script para encurtar o domínio, permitindo uma aplicação mais relaxada da política de mesma origem dentro do mesmo domínio pai.
Ao incorporar uma página da web dentro de um iframe sandboxed usando %%%%%%, é crucial entender que a origem do iframe será definida como nula. Isso é particularmente importante ao lidar com atributos de sandbox e suas implicações na segurança e funcionalidade.
Ao especificar allow-popups
no atributo sandbox, qualquer janela pop-up aberta de dentro do iframe herda as restrições de sandbox de seu pai. Isso significa que, a menos que o atributo allow-popups-to-escape-sandbox
também seja incluído, a origem da janela pop-up é igualmente definida como null
, alinhando-se com a origem do iframe.
Consequentemente, quando uma pop-up é aberta sob essas condições e uma mensagem é enviada do iframe para a pop-up usando postMessage
, ambas as extremidades de envio e recebimento têm suas origens definidas como null
. Essa situação leva a um cenário onde e.origin == window.origin
avalia como verdadeiro (null == null
), porque tanto o iframe quanto a pop-up compartilham o mesmo valor de origem null
.
Para mais informações leia:
Bypassing SOP with Iframes - 1É possível verificar se a mensagem veio da mesma janela em que o script está ouvindo (especialmente interessante para Content Scripts de extensões de navegador para verificar se a mensagem foi enviada da mesma página):
Você pode forçar e.source
de uma mensagem a ser nula criando um iframe que envia o postMessage e é imediatamente deletado.
Para mais informações leia:
Bypassing SOP with Iframes - 2Para realizar esses ataques, idealmente você poderá colocar a página da vítima dentro de um iframe
. Mas alguns cabeçalhos como X-Frame-Header
podem prevenir esse comportamento.
Nesses cenários, você ainda pode usar um ataque menos furtivo. Você pode abrir uma nova aba para a aplicação web vulnerável e se comunicar com ela:
Na página a seguir, você pode ver como poderia roubar um dado sensível de postmessage enviado para um iframe filho ao bloquear a página principal antes de enviar os dados e abusar de um XSS no filho para vazar os dados antes que sejam recebidos:
Blocking main page to steal postmessageSe você puder iframe uma página da web sem X-Frame-Header que contém outro iframe, você pode mudar a localização daquele iframe filho, então, se ele estiver recebendo um postmessage enviado usando um wildcard, um atacante poderia mudar a origem daquele iframe para uma página controlada por ele e roubar a mensagem:
Steal postmessage modifying iframe locationEm cenários onde os dados enviados através de postMessage
são executados por JS, você pode iframe a página e explorar a poluição de protótipo/XSS enviando o exploit via postMessage
.
Um par de XSS muito bem explicados através de postMessage
pode ser encontrado em https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html
Exemplo de um exploit para abusar da Poluição de Protótipo e então XSS através de um postMessage
para um iframe
:
Para mais informações:
Link para a página sobre poluição de protótipo
Link para a página sobre XSS
Link para a página sobre poluição de protótipo do lado do cliente para XSS
Para praticar: https://github.com/yavolo/eventlistener-xss-recon
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)