# XS-Search/XS-Leaks
 (1) (2).png>)
\
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e automatizar facilmente fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo.\
Acesse hoje:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenha o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
## **Informações básicas**
XS-Search é uma técnica orientada para **exfiltrar informações de origem cruzada** abusando de **ataques de canal lateral**.
Existem diferentes elementos nesse tipo de ataque:
* **Web vulnerável**: é a web de onde queremos exfiltrar algumas informações
* **Web do atacante**: é a web que o atacante cria contendo o exploit e que a vítima acessa
* **Método de inclusão**: é o método usado para carregar a Web vulnerável a partir da Web do atacante (como window.open, iframe, fetch, tag HTML com href...)
* **Técnica de vazamento**: após acessar a web vulnerável, uma técnica será usada para diferenciar entre o status potencial da web com as informações obtidas do método de inclusão usado.
* **Estados**: os 2 possíveis estados que a web vulnerável pode ter dependendo da vítima que queremos diferenciar.
* **Diferenças detectáveis**: estas são as informações que o atacante tem que tentar decidir o status da web vulnerável
### Diferenças detectáveis
Para distinguir entre os 2 estados da página vulnerável, várias coisas podem ser observadas:
* **Código de status**. Um atacante pode distinguir **diferentes códigos de status de resposta HTTP** de origem cruzada (por exemplo, erros do servidor, erros do cliente ou erros de autenticação).
* **Uso de API**. Esta diferença detectável permite que um atacante detecte o **uso de APIs da Web** em páginas, permitindo que um atacante infira se uma página de origem cruzada está usando uma API da Web JavaScript específica.
* **Redirecionamentos**. É possível detectar se um aplicativo da web **navegou o usuário para uma página diferente**. Isso não se limita a redirecionamentos HTTP, mas também inclui redirecionamentos acionados por JavaScript ou HTML.
* **Conteúdo da página**. Essas diferenças detectáveis **aparecem no corpo da resposta HTTP** ou em sub-recursos incluídos pela página. Por exemplo, isso poderia ser o **número de quadros incluídos** (cf. XS-Leak no Gitlab) ou diferenças de tamanho de imagens.
* **Cabeçalho HTTP**. Um atacante pode detectar a presença de um **cabeçalho de resposta HTTP específico** e pode ser capaz de reunir seu valor. Isso inclui cabeçal
```html
```
Neste caso, se `example.com/404` não for encontrado, `attacker.com/?error` será carregado.
### Tempo de carregamento
* **Métodos de inclusão**: Elementos HTML
* **Diferença detectável**: Tempo (geralmente devido ao conteúdo da página, código de status)
* **Mais informações**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
* **Resumo**: A API \*\*\*\* [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) pode ser usada para medir quanto tempo leva para realizar uma solicitação. No entanto, outros relógios podem ser usados, como a [**API PerformanceLongTaskTiming**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming), que pode identificar tarefas em execução por mais de 50ms.
* **Exemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) outro exemplo em:
{% content-ref url="xs-search/performance.now-example.md" %}
[performance.now-example.md](xs-search/performance.now-example.md)
{% endcontent-ref %}
#### Tempo de carregamento + Tarefa pesada forçada
Essa técnica é como a anterior, mas o **atacante** também **forçará** alguma ação a levar um **tempo relevante** quando a **resposta for positiva ou negativa** e medirá esse tempo.
{% content-ref url="xs-search/performance.now-+-force-heavy-task.md" %}
[performance.now-+-force-heavy-task.md](xs-search/performance.now-+-force-heavy-task.md)
{% endcontent-ref %}
### Tempo de descarregamento / beforeunload
* **Métodos de inclusão**: Frames
* **Diferença detectável**: Tempo (geralmente devido ao conteúdo da página, código de status)
* **Mais informações**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
* **Resumo**: O relógio [SharedArrayBuffer](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) pode ser usado para medir quanto tempo leva para realizar uma solicitação. Outros relógios 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)
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) podem ser usados para medir o tempo que leva para buscar um recurso. Isso funciona porque o **`beforeunload`** é acionado quando o navegador faz uma **nova solicitação de navegação**, enquanto o **`unload`** é acionado quando essa **navegação realmente ocorre**. De
### Loop de Eventos Ocupado
* **Métodos de Inclusão**:
* **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/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
* **Resumo:** Mede o tempo de execução de um web locking o loop de eventos de uma thread e cronometrando **quanto tempo leva para o loop de eventos ficar disponível novamente**.
* **Exemplo de código**:
Uma das principais vantagens dessa técnica é sua capacidade de contornar o Isolamento de Site, pois a origem do atacante pode influenciar a execução de outra origem.
{% hint style="warning" %}
Em uma execução de tempo, é 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 %}
### Pool de Conexão
* **Métodos de Inclusão**: Solicitações JavaScript
* **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/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
* **Resumo:** Um atacante pode bloquear todos os soquetes, exceto 1, carregar a web de destino e, ao mesmo tempo, carregar outra página, o tempo até que a última página comece a carregar é o tempo que a página de destino levou para carregar.
* **Exemplo de código**:
{% content-ref url="xs-search/connection-pool-example.md" %}
[connection-pool-example.md](xs-search/connection-pool-example.md)
{% endcontent-ref %}
Os navegadores usam soquetes para se comunicar com servidores. Como o sistema operacional e o hardware em que ele é executado têm recursos limitados, **os navegadores têm que impor um limite**. Para explorar a existência desse limite, os atacantes podem:
1. Verifique qual é o limite do navegador, por exemplo, 256 soquetes globais.
2. Bloqueie 255 soquetes por um longo período de tempo, realizando 255 solicitações a hosts diferentes que simplesmente penduram a conexão.
3. Use o 256º soquete realizando uma solicitação à página de destino.
4. Realize uma 257ª solicitação a outro host. Como todos os soquetes estão sendo usados (nas etapas 2 e 3), essa solicitação deve esperar até que o pool receba um soquete disponível. Esse período de espera fornece ao atacante o tempo de sincronização da rede do 256º soquete, que pertence à página de destino. Isso funciona porque os 255 soquetes na etapa 2 ainda estão bloqueados, portanto, se o pool receber um soquete disponível, isso foi causado pela liberação do soquete na etapa 3. O tempo para liberar o 256º soquete está diretamente conectado ao tempo necessário para concluir a solicitação.
Para mais informações: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
### Pool de Conexão por Destino
* **Métodos de Inclusão**: Solicitações JavaScript
* **Diferença Detectável**: Tempo (geralmente devido ao conteúdo da página, código de status)
*
### Service Worker
* **Métodos de inclusão**: Frames
* **Diferença detectável**: Uso da API
* **Mais informações**: [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/)
* **Resumo:** Detecte se um service worker está registrado para uma origem específica.
* **Exemplo de código**:
Os service workers são contextos de script orientados a eventos que são executados em uma origem. Eles são executados em segundo plano de uma página da web e podem interceptar, modificar e **armazenar em cache recursos** para criar aplicativos da web offline.\
Se um **recurso armazenado em cache** por um **service worker** é acessado via **iframe**, o recurso será **carregado a partir do cache do service worker**.\
Para detectar se o recurso foi **carregado a partir do cache do service worker**, a **API de desempenho** pode ser usada.\
Isso também pode ser feito com um ataque de temporização (verifique o artigo para obter mais informações).
### Cache
* **Métodos de inclusão**: Fetch API
* **Diferença detectável**: Temporização
* **Mais informações**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
* **Resumo:** Detecte se um recurso foi armazenado em cache.
* **Exemplo de código**: [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 [API de desempenho](xs-search.md#performance-api), é possível verificar se um recurso está armazenado em cache.\
Para mais informações: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
### Duração da Rede
* **Métodos de inclusão**: Fetch API
* **Diferença detectável**: Conteúdo da página
* **Mais informações**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
* **Resumo:** É possível recuperar a duração da rede de uma solicitação da API `performance`.
* **Exemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
## Técnica de Mensagens de Erro
### Erro de Mídia
* **Métodos de inclusão**: Elementos HTML (Vídeo, Áudio)
* **Diferença detectável**: Código de status
* **Mais informações**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
* **Resumo:** No FF, é possível vazar com precisão o código de status de uma solicitação de origem cruzada.
* **Exemplo de código**: [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("Status: " + status + " (Error code:" + err.code + " / Error Message: " + err.message + ") ");
};
audioElement.onerror = errHandler;
}
```
A propriedade de mensagem da interface **`MediaError`** contém uma **string diferente para recursos que são carregados com sucesso**. Isso permite que um atacante infira o status de resposta para um recurso de origem cruzada.
### Erro de 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 SA, as mensagens de erro de CORS vazam a URL completa de redirecionamentos.
* **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 vaze o alvo de um redirecionamento que é iniciado por um site de origem cruzada.
O CORS permite que recursos da web publicamente acessíveis sejam lidos e usados a partir de qualquer site. Nos navegadores baseados em Webkit, é possível **acessar as mensagens de erro de CORS quando uma solicitação CORS falha**. Um atacante pode enviar uma solicitação habilitada para CORS para um site de destino que **redireciona** com base no estado do usuário. Quando o navegador nega a solicitação, a **URL completa do destino do redirecionamento é vazada** na mensagem de erro. Com esse ataque, é possível detectar redirecionamentos, vazar locais de redirecionamento e parâmetros de consulta sensíveis.
### Erro de 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 SA, as mensagens de erro de CORS vazam a URL completa de redirecionamentos.
* **Exemplo de código**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)
Um atacante pode vazar o tamanho das respostas de origem cruzada devido a **mensagens de erro verbosas**.
O atributo de integridade define um hash criptográfico pelo qual o navegador pode verificar se um recurso buscado não foi manipulado. Esse mecanismo de segurança é chamado de Subresource Integrity (SRI). É usado para verificação de integridade de recursos servidos por redes de entrega de conteúdo (CDNs). Para evitar vazamentos de dados, os recursos de origem cruzada devem ser **habilitados para CORS**. Caso contrário, a resposta não é elegível para validação de integridade. Semelhante ao vazamento de erro de CORS XS-Leak, é possível capturar a **mensagem de erro após uma solicitação de busca com um atributo de integridade falhar**. Um atacante pode forçadamente **disparar** esse **erro** em qualquer solicitação especificando um **valor de hash falso**. Em SA, essa mensagem de erro vaza o comprimento do conteúdo do recurso solicitado. Um atacante pode usar esse vazamento para detectar diferenças no tamanho da resposta, o que permite poderosos ataques XS-Leak.
### Violação/Detecção de CSP
* **Métodos de inclusão**: Pop-ups
* **Diferença detectável**: Código de status
* **Mais informações**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Arch
### Comprimento Máximo de URL - Lado do Cliente
* **Métodos de Inclusão**: Pop-ups
* **Diferença Detectável**: Código de Status / Conteúdo
* **Mais informações**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
* **Resumo:** Detecte diferenças nas respostas porque o comprimento da resposta de redirecionamento pode ser muito grande para uma solicitação que uma diferença possa 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 de URL do Chrome é de 2MB.
> Em geral, a _plataforma web_ não tem limites no comprimento de URLs (embora 2^31 seja um limite comum). O _Chrome_ limita os URLs a um comprimento máximo de **2MB** por razões práticas e para evitar problemas de negação de serviço na comunicação entre processos.
Portanto, se o **URL de redirecionamento respondido for maior em um dos casos**, é possível fazer com que ele redirecione com um **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 perceptível** é que se o **redirecionamento** foi **concluído**, `window.origin` lança 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 **`origin`** da janela permanece a do **pai**, que é uma informação **acessível**.
Todas as informações extras necessárias para atingir os **2MB** podem ser adicionadas por meio de um **hash** na URL inicial para que seja **usado 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:** Abusa do limite de redirecionamentos para detectar redirecionamentos.
* **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 invasor poderia tentar carregar sua página com **19 redirecionamentos** e finalmente **enviar a vítima** para a página testada. Se um **erro** for acionado, 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 invasor pode usar a propriedade length como um método de inclusão: para detectar navegações em JavaScript e HTML.\
**Verificando `history.length`**, fazendo um usuário **navegar** para uma página, **voltar** para ela **de volta** 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 invasor poderia usar o 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 aumentar, significa que a URL estava correta e teve tempo para **aumentar porque a URL não é recarregada se for a mesma**. Se não aumentar, significa que ele **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:** Ler o número de frames (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 página da web** aberta via `iframe` ou `window.open` pode ajudar a identificar o **status do usuário sobre essa página**.\
Além disso, se a página 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
### Busca de Tempo
* **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:** A API [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) 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/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
### Busca Cruzada de 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:** A API [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) pode ser usada para medir quanto tempo 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)
 (1) (2).png>)
\
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** com facilidade, usando 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" %}
## 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 em que, por qualquer motivo, você pode **injetar HTML, mas não pode injetar código JS**.
### Marcação Pendurada
{% content-ref url="dangling-markup-html-scriptless-injection.md" %}
[dangling-markup-html-scriptless-injection.md](dangling-markup-html-scriptless-injection.md)
{% endcontent-ref %}
### Carregamento Lento de Imagem
Se você precisa **exfiltrar conteúdo** e pode **adicionar HTML anterior ao segredo**, você deve verificar as **técnicas comuns de marcação pendurada**.\
No entanto, se por qualquer motivo você **PRECISAR** fazê-lo **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 estiver carregando:
```html
```
Portanto, o que você pode fazer é **adicionar muitos caracteres aleatórios** (por exemplo, **milhares de "W"**) para **preencher a página da web antes do segredo**. Fazemos isso para que a imagem não seja carregada no início.
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://vitima.com/post.html#:~:text=SECR`**
Onde post.html contém os caracteres lixo do atacante e a imagem de carregamento lento e, em seguida, 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. Então, você tem seu oráculo para exfiltrar o caractere secreto por caractere.
Alguns exemplos de código para explorar isso: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
Encontre **outro exemplo usando carregamento lento** 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 por meio de temporização **se algum conteúdo HTML existe**, isso porque se o seletor `main[id='site-main']` não corresponder, não é necessário verificar o restante dos **seletores**:
```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/" %}
[injeção de CSS](xs-search/css-injection/)
{% endcontent-ref %}
## Defesas
Nesta seção, você pode encontrar parte das mitigação recomendadas em [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf), no entanto, há mais mitigação em cada seção do wiki [https://xsleaks.dev/](https://xsleaks.dev/). Dê uma olhada lá para obter mais informações sobre como se proteger contra essas técnicas.
### Mitigações do Método de Inclusão
* **Elementos HTML**. Pode-se usar o **cabeçalho CORP para controlar se as páginas podem incorporar um recurso**. O CORP pode ser definido como mesma origem ou mesmo site e bloqueia qualquer solicitação de origem cruzada ou respectivamente de site cruzado para esse recurso. No **lado do cliente**, os navegadores baseados em Chromium usam o algoritmo **CORB** para decidir se as solicitações de recursos de origem cruzada devem ser permitidas ou negadas.
* **Frames**. A principal defesa para **impedir que elementos iframe** carreguem recursos HTML é o uso de **X-Frame-Options**. Alternativamente, a diretiva **frame-ancestors CSP** pode alcançar um resultado semelhante. Se a incorporação for negada, o método de inclusão não pode detectar uma diferença nas respostas.
* **Pop-ups**. Para restringir o acesso a `window.opener`, o cabeçalho de resposta HTTP **COOP** define três valores diferentes: unsafe-none (padrão), same-origin-allow-popups e same-origin. Esses valores podem ser usados para **isolar as guias de navegação e pop-ups** e, portanto, mitigar as técnicas de vazamento baseadas em pop-ups.
* **Solicitações JavaScript**. As solicitações JavaScript de origem cruzada são frequentemente usadas em ataques XS-Leak, porque um invasor tem controle refinado sobre a solicitação emitida. No entanto, como essas solicitações não são habilitadas para CORS, elas estão sujeitas às mesmas restrições que as solicitações enviadas por elementos HTML, como scripts ou imagens. Assim, o impacto dessa técnica de vazamento também pode ser **mitigado por CORP e CORB**.
Métodos mais genéricos:
* **Metadados de busca**. Esses cabeçalhos de solicitação permitem que os proprietários do servidor entendam melhor como o navegador do usuário causou uma solicitação específica. No Chrome, os cabeçalhos Sec-Fetch-\* são adicionados automaticamente a cada solicitação e fornecem metadados sobre a proveniência da solicitação. Por exemplo, Sec-Fetch-Dest: imagem foi acionado a partir de um elemento de imagem. As aplicações da Web podem então optar por bloquear solicitações com base nessas informações.
* **Cookies Same-Site**. O sinalizador Same-Site permite que os sites declarem **se um cookie deve ser restrito ao contexto de mesmo site ou de primeira parte**. Todos os principais navegadores suportam cookies Same-Site. No GC, os cookies sem o atributo agora são Lax por padrão. Para XS-Leaks, **os cookies Same-Site limitam drasticamente as possibilidades de ataque de vazamento**. Por outro lado, as técnicas de vazamento que dependem de **`window.open` ainda funcionam com `SameSite=Lax`**. Os sites que usam **outros métodos de autenticação**, como certificados do lado do cliente e autenticação HTTP, **permanecem vulneráveis**.
* **Desvinculação de Identificador de Origem Cruzada (COIU)**. COIU, também conhecido como Isolamento de Primeira Parte (FPI), é um recurso de segurança opcional que os usuários podem habilitar nas configurações avançadas do FF (about:config) e foi inicialmente introduzido no Tor Browser. Em uma visão abstrata, é um contexto de mesmo site estendido. Ele **vincula vários recursos** (por exemplo, cookies, cache, armazenamentos do lado do cliente) **à primeira parte** em vez de compartilhá-los entre todos os sites visitados. Se habilitado, o COIU diminui drasticamente a aplicabilidade do XS-Leaks, pois apenas os métodos que usam pop-ups ainda são possíveis para atender ao requisito de primeira parte da política.
* **Proteções de Rastreamento**. A Apple implementou um mecanismo de privacidade chamado **Prevenção de Rastreamento Inteligente (ITP)** no SA que visa combater o rastreamento entre sites limitando as capacidades de cookies e outras APIs da Web. Em versões mais recentes do SA, o ITP bloqueia todos os cookies de terceiros por padrão, sem exceções \[74]. Esse bloqueio impede todos os vazamentos que não são baseados em pop-ups. O FF adotou uma abordagem semelhante com a Prevenção de Rastreamento Aprimorada (ETP), mas eles apenas bloqueiam cookies de terceiros específicos pertencentes a provedores de rastreamento. No contexto do XS-Leaks, o ETP apenas mitiga as técnicas de vazamento que visam esses domínios de rastreamento.
* **Extensões do Navegador**. Usuários conscientes da segurança podem usar **extensões do navegador para impedir certos métodos de inclusão**.
### Mitigações de Técnicas de Vazamento
* **Manipulador de Eventos**. A **mitigação mais eficaz** nesta técnica de vazamento seria **negá-los todos**, mas isso quebraria a maioria das aplicações da Web na Internet. Portanto, propomos **reduzir o número de informações necessárias que podem ser coletadas dentro dos eventos**. Por exemplo, o evento de violação do CSP não deve conter a URL de destino de redirecionamento no campo blockedURI. Esse comportamento é implementado no FF e em versões mais recentes do GC - apenas o SA permanece vulnerável.
* **Mensagens de Erro**. Para mitigar XS-Leaks baseados na técnica de vazamento de mensagens de erro, existem dois requisitos principais. Primeiro, **as mensagens de erro não devem conter informações detalhadas**, semelhantes às mensagens do manipulador de eventos. Em segundo lugar, os navegadores devem **minimizar as ocorrências de mensagens de erro**. XS-Leaks, como Erro SRI, XFO do ContentDocument ou Redirecionamento de Busca, detectam se uma mensagem de erro é lançada ou não.
* **Limites Globais**. Corrigir as técnicas de vazamento que abusam dos limites globais é relativamente complexo porque eles dependem de restrições físicas. A recomendação geral é, portanto, **restringir os limites globais em uma pequena base por site**. Se o limite global for 1, como para a API de Pagamento, o invasor pode tentar silenciosamente ativar a interface do usuário de pagamento da Web a qualquer momento, o que só terá sucesso se a interface do usuário não estiver sendo usada simultaneamente por outra guia. Recomendamos acessar a API de Pagamento apenas quando um evento confiável