# XS-Search/XS-Leaks
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) 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 na AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras formas de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
## 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, obrigando 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](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**](https://xsinator.com/paper.pdf) Você pode **acessar a ferramenta em** [**https://xsinator.com/**](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**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) 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 técnicas a seguir 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()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) permite aos desenvolvedores obter medições de tempo de alta resolução.\ Existem um número considerável de APIs que os atacantes podem abusar para criar relógios implícitos: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), animações CSS e outros.\ Para mais informações: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/). ## Técnicas de Manipulador de Eventos ### Onload/Onerror * **Métodos de Inclusão**: Frames, Elementos HTML * **Diferença Detectável**: Código de Status * **Mais informações**: [https://www.usenix.org/conference/usenixsecurity19/presentation/staicu](https://www.usenix.org/conference/usenixsecurity19/presentation/staicu), [https://xsleaks.dev/docs/attacks/error-events/](https://xsleaks.dev/docs/attacks/error-events/) * **Resumo**: ao tentar carregar um recurso, se os eventos onerror/onload forem acionados com o recurso carregado com sucesso/sem sucesso, é possível descobrir o código de status. * **Exemplo de código**: [https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](https://xsinator.com/testing.html#Event%20Handler%20Leak%20\(Script\)) {% content-ref url="xs-search/cookie-bomb-+-onerror-xs-leak.md" %} [cookie-bomb-+-onerror-xs-leak.md](xs-search/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). Também existe uma versão sem script deste ataque: ```html ``` Neste caso, se `example.com/404` não for encontrado, `attacker.com/?error` será carregado. ### Tempo de Carregamento * **Métodos de Inclusão**: Elementos HTML * **Diferença Detectável**: Tempo (geralmente devido ao Conteúdo da Página, Código de Status) * **Mais informações**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) * **Resumo:** A [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **API** pode ser usada para medir quanto tempo leva para realizar uma solicitação. No entanto, outros relógios poderiam ser usados, como [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming) que pode identificar tarefas em execução por mais de 50ms. * **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) outro exemplo em: {% content-ref url="xs-search/performance.now-example.md" %} [performance.now-example.md](xs-search/performance.now-example.md) {% endcontent-ref %} #### Tempo de Carregamento + Tarefa Pesada Forçada Esta 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](xs-search/performance.now-+-force-heavy-task.md) {% endcontent-ref %} ### Tempo de descarregamento/beforeunload * **Métodos de Inclusão**: Frames * **Diferença Detectável**: Tempo (geralmente devido ao Conteúdo da Página, Código de Status) * **Mais informações**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events) * **Resumo:** O [relógio SharedArrayBuffer](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) pode ser usado para medir quanto tempo leva para realizar uma solicitação. Outros relógios poderiam ser usados. * **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events) O tempo necessário para buscar um recurso pode ser medido utilizando os eventos [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_event) e [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload\_event). 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 * **Métodos de Inclusão**: Frames * **Diferença Detectável**: Tempo (geralmente devido ao Conteúdo da Página, Código de Status) * **Mais informações**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks) * **Resumo:** A [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API pode ser usada para medir quanto tempo leva para realizar uma solicitação. Outros relógios poderiam ser usados. * **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks) Observou-se que na ausência de [Proteções de Enquadramento](https://xsleaks.dev/docs/defenses/opt-in/xfo/), 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 apenas 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`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) dentro do ` ``` ### #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 for acessado e carregar corretamente quando qualquer conteúdo for 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 contém o **conteúdo secreto** **dentro de um Iframe**. Você pode fazer a vítima procurar 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**, mas alterando apenas o **conteúdo** do **hash** dentro do URL. Por exemplo: 1. **URL1**: www.atacante.com/xssearch#tentativa1 2. **URL2**: www.atacante.com/xssearch#tentativa2 Se o primeiro URL foi **carregado com sucesso**, então, ao **alterar** a parte do **hash** do URL, o evento **onload** **não será acionado** novamente. Mas **se** a página apresentou algum tipo de **erro** ao **carregar**, então, o evento **onload** será **acionado novamente**. Assim, 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** estiver **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 tags **`