* 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)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
As recompensas do HackenProof são lançadas apenas quando os clientes depositam o orçamento de recompensa. Você receberá a recompensa após a verificação do bug.
**Cross-site request forgery** (também conhecido como CSRF) é uma vulnerabilidade de segurança na web que permite a um atacante **induzir os usuários a realizar ações que eles não pretendem realizar**.\
Isso é feito **fazendo um usuário logado** na plataforma da vítima acessar um site controlado pelo atacante e a partir daí **executar** código JS malicioso, enviar formulários ou recuperar "imagens" para a **conta da vítima**.
Para ser capaz de explorar uma vulnerabilidade CSRF, você primeiro precisa **encontrar uma ação relevante para explorar** (alterar senha ou email, fazer a vítima seguir você em uma rede social, dar a você mais privilégios...). A **sessão deve depender apenas de cookies ou do cabeçalho de autenticação básica HTTP**, nenhum outro cabeçalho pode ser usado para manipular a sessão. E finalmente, não deve haver **parâmetros imprevisíveis** na solicitação.
* [**Cookies SameSite**](hacking-with-cookies/#samesite): Se o cookie de sessão estiver usando essa flag, você pode não conseguir enviar o cookie de sites arbitrários.
* [**Compartilhamento de recursos entre origens**](cors-bypass.md): Dependendo do tipo de solicitação HTTP que você precisa fazer para explorar a ação relevante, você pode levar em consideração a **política CORS do site da vítima**. _Observe que a política CORS não afetará se você apenas quiser enviar uma solicitação GET ou uma solicitação POST de um formulário e não precisar ler a resposta._
* Solicitar a **senha** do usuário para autorizar a ação.
* http://mal.net?orig=http://example.com (termina com a URL)
* http://example.com.mal.net (começa com a URL)
* **Modificar** o **nome** dos **parâmetros** da solicitação POST ou GET
* Usar um **token CSRF** em cada sessão. Esse token deve ser enviado dentro da solicitação para confirmar a ação. Esse token pode ser protegido com CORS.
Talvez o formulário que você deseja explorar esteja preparado para enviar uma **solicitação POST com um token CSRF**, mas você deve **verificar** se um **GET** também é **válido** e se, ao enviar uma solicitação GET, o **token CSRF ainda está sendo validado**.
Nessa situação, o atacante pode **remover o parâmetro inteiro** que contém o token (não apenas o valor) para contornar a validação e realizar um ataque CSRF.
Algumas aplicações **não validam que o token pertence à mesma sessão** do usuário que está fazendo a solicitação. Em vez disso, a aplicação **mantém um pool global de tokens** que emitiu e aceita qualquer token que apareça nesse pool.\
Nessa situação, o atacante pode fazer login na aplicação usando sua própria conta, **obter um token válido** e, em seguida, **enviar esse token para o usuário vítima** em seu ataque CSRF.
Por exemplo, se estiver **usando o método PUT**, você pode tentar **usar o método POST** e **enviar**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Em uma variação adicional da vulnerabilidade anterior, alguns aplicativos **duplicam cada token em um cookie e em um parâmetro de solicitação**. Ou então, **definem um cookie csrf** e **verificam no backend se o token csrf enviado é o mesmo relacionado ao cookie**.
Quando a solicitação subsequente é validada, o aplicativo simplesmente verifica se o **token** enviado no **parâmetro de solicitação corresponde** ao valor armazenado pelo **cookie**.\
Nessa situação, o atacante pode novamente realizar um ataque CSRF **se o site conter alguma vulnerabilidade que permita definir seu cookie CSRF para a vítima, como um CRLF**.
Observe que se o **token csrf estiver relacionado ao cookie de sessão, esse ataque não funcionará** porque você precisará definir a sessão da vítima e, portanto, estará atacando a si mesmo.
De acordo com [**isso**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), para **evitar solicitações de pré-voo** usando o método **POST**, esses são os valores permitidos para o Content-Type:
No entanto, observe que a **lógica dos servidores pode variar** dependendo do **Content-Type** usado, portanto, você deve tentar os valores mencionados e outros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Como você já sabe, não é possível enviar uma solicitação POST com o Content-Type **`application/json`** via formulário HTML e, se você tentar fazer isso via **`XMLHttpRequest`**, uma solicitação de pré-voo é enviada primeiro.\
No entanto, você pode tentar enviar os dados JSON usando os tipos de conteúdo **`text/plain`** e **`application/x-www-form-urlencoded`** apenas para verificar se o backend está usando os dados independentemente do Content-Type.\
Você pode enviar um formulário usando `Content-Type: text/plain` definindo **`enctype="text/plain"`**
Se o servidor estiver aceitando apenas o tipo de conteúdo "application/json", você pode **enviar o tipo de conteúdo "text/plain; application/json"** sem acionar uma solicitação de pré-voo.
Você também pode tentar **burlar** essa restrição usando um **arquivo SWF flash**. Para mais informações, [**leia este post**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
A primeira parte deste [**writeup do CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que no código-fonte do [Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), um roteador é configurado para **tratar as requisições HEAD como requisições GET** sem corpo de resposta - uma solução comum que não é exclusiva do Oak. Em vez de um manipulador específico para lidar com as requisições HEAD, elas são simplesmente **enviadas para o manipulador GET, mas o aplicativo remove o corpo de resposta**.
Portanto, se uma requisição GET estiver sendo limitada, você pode simplesmente **enviar uma requisição HEAD que será processada como uma requisição GET**.
Se um **token CSRF** estiver sendo usado como **defesa**, você pode tentar **exfiltrá-lo** aproveitando uma vulnerabilidade de [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) ou uma vulnerabilidade de [**Dangling Markup**](dangling-markup-html-scriptless-injection/).
A técnica de Cross-Site Request Forgery (CSRF) explora a confiança que um site tem em um usuário autenticado para realizar ações indesejadas em seu nome. Uma das maneiras mais comuns de realizar um ataque CSRF é através de uma requisição POST de formulário.
- Utilizar tokens CSRF: Adicionar um token único e secreto em cada formulário e verificar sua validade no processamento da requisição POST.
- Verificar a origem da requisição: Validar se a requisição POST vem de um domínio confiável.
- Utilizar cabeçalhos HTTP: Configurar cabeçalhos HTTP, como o cabeçalho "Referer" ou "Origin", para verificar a origem da requisição.
- Implementar autenticação de dois fatores: Adicionar uma camada extra de segurança ao exigir uma segunda forma de autenticação para realizar ações sensíveis.
A técnica de CSRF é uma ameaça séria à segurança dos sites. É importante que os desenvolvedores implementem medidas de prevenção adequadas para proteger os usuários contra esse tipo de ataque.
Uma técnica comum para realizar um ataque de falsificação de solicitação entre sites (CSRF) é enviar uma requisição POST de formulário por meio de um elemento `<iframe>`. Isso permite que um invasor engane o navegador do usuário para que ele envie uma solicitação não autorizada em nome do usuário autenticado.
Para se proteger contra ataques CSRF, é recomendado implementar medidas de segurança, como o uso de tokens CSRF, que são valores únicos gerados pelo servidor e incluídos em formulários. Esses tokens são verificados pelo servidor para garantir que a solicitação seja legítima e não tenha sido gerada por um atacante.
Uma requisição POST Ajax é uma técnica usada para enviar dados para um servidor sem recarregar a página. Isso é feito usando a função `$.ajax()` do jQuery ou a classe `XMLHttpRequest` do JavaScript puro.
A requisição POST Ajax é frequentemente usada em ataques de falsificação de solicitação entre sites (CSRF), onde um invasor engana um usuário autenticado a executar ações indesejadas em um site sem o seu conhecimento.
Durante um ataque CSRF, o invasor cria um formulário malicioso em um site controlado por ele e o envia para a vítima. Quando a vítima visita o site malicioso, o formulário é automaticamente enviado para o site alvo, aproveitando a sessão autenticada da vítima. Isso permite que o invasor execute ações em nome da vítima, como fazer uma transferência de fundos, alterar senhas ou excluir dados.
Para se proteger contra ataques CSRF, os desenvolvedores devem implementar medidas de segurança, como tokens CSRF, que são valores únicos gerados pelo servidor e incluídos em formulários ou cabeçalhos de solicitação. O servidor verifica se o token é válido antes de processar a solicitação.
Os testadores de penetração podem explorar vulnerabilidades de CSRF em um site para demonstrar a sua existência e fornecer recomendações para corrigi-las.
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
A requisição POST multipart/form-data é um tipo de requisição utilizada para enviar dados binários, como arquivos, através de um formulário HTML. Essa técnica é comumente utilizada em aplicações web para o envio de arquivos de imagem, áudio, vídeo, entre outros.
Nesse tipo de requisição, os dados são divididos em várias partes, cada uma com seu próprio cabeçalho e conteúdo. Cada parte é separada por um delimitador, que é especificado no cabeçalho da requisição.
Para realizar um ataque de Cross-Site Request Forgery (CSRF) em uma requisição POST multipart/form-data, o invasor precisa enganar o usuário para que ele execute uma ação indesejada em um site legítimo. Isso pode ser feito através de técnicas como phishing, onde o invasor envia um e-mail falso ou cria um site malicioso que se passa pelo site legítimo.
Ao explorar uma vulnerabilidade CSRF em uma requisição POST multipart/form-data, o invasor pode realizar ações em nome do usuário autenticado, como enviar um arquivo malicioso para o servidor, alterar informações do usuário ou executar outras ações indesejadas.
Para proteger uma aplicação contra ataques CSRF em requisições POST multipart/form-data, é recomendado utilizar mecanismos de proteção, como tokens CSRF. Esses tokens são gerados pelo servidor e incluídos no formulário HTML. Ao enviar a requisição, o token é verificado pelo servidor para garantir que a requisição seja legítima e não tenha sido gerada por um atacante.
É importante que os desenvolvedores estejam cientes dessa vulnerabilidade e implementem as devidas medidas de segurança para proteger suas aplicações contra ataques CSRF.
In this technique, we will explore how to perform a Cross-Site Request Forgery (CSRF) attack using a multipart/form-data POST request.
Nesta técnica, exploraremos como realizar um ataque de Cross-Site Request Forgery (CSRF) usando uma requisição POST multipart/form-data.
#### Introduction
#### Introdução
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into submitting a malicious request. This attack occurs when a malicious website or application forces the victim's browser to make a request to a target website where the victim is authenticated.
Cross-Site Request Forgery (CSRF) é um ataque que engana a vítima a enviar uma requisição maliciosa. Esse ataque ocorre quando um site ou aplicativo malicioso força o navegador da vítima a fazer uma requisição para um site alvo onde a vítima está autenticada.
#### Exploiting CSRF with multipart/form-data POST request
#### Explorando CSRF com requisição POST multipart/form-data
1. Identify the target website that is vulnerable to CSRF.
1. Identifique o site alvo que é vulnerável a CSRF.
2. Analyze the target website's functionality and identify a form or action that performs a sensitive action, such as changing the user's password or making a financial transaction.
2. Analise a funcionalidade do site alvo e identifique um formulário ou ação que execute uma ação sensível, como alterar a senha do usuário ou realizar uma transação financeira.
3. Craft a malicious HTML page or email that includes a form with the target website's action URL and necessary input fields.
3. Crie uma página HTML ou e-mail malicioso que inclua um formulário com a URL de ação do site alvo e os campos de entrada necessários.
4. Include a hidden input field with the CSRF token value obtained from the target website.
4. Inclua um campo de entrada oculto com o valor do token CSRF obtido do site alvo.
5. Trick the victim into visiting the malicious page or clicking on the malicious email.
5. Engane a vítima para visitar a página maliciosa ou clicar no e-mail malicioso.
6. When the victim submits the form, the browser will automatically send the multipart/form-data POST request to the target website, performing the sensitive action.
6. Quando a vítima enviar o formulário, o navegador enviará automaticamente a requisição POST multipart/form-data para o site alvo, executando a ação sensível.
1. Implement CSRF tokens: Include unique tokens in each form or action that require user authentication. These tokens should be validated on the server-side to ensure that the request is legitimate.
1. Implemente tokens CSRF: Inclua tokens únicos em cada formulário ou ação que exija autenticação do usuário. Esses tokens devem ser validados no lado do servidor para garantir que a requisição seja legítima.
2. Use o atributo SameSite: Defina o atributo SameSite como "Strict" ou "Lax" nos cookies para evitar que sejam enviados em requisições de origem cruzada.
When an HTML form is submitted, the browser sends a POST request to the specified URL. This behavior can be exploited in a Cross-Site Request Forgery (CSRF) attack when an attacker tricks a user into submitting a form without their knowledge or consent.
Quando um formulário HTML é enviado, o navegador envia uma solicitação POST para a URL especificada. Esse comportamento pode ser explorado em um ataque de falsificação de solicitação entre sites (CSRF) quando um invasor engana um usuário para enviar um formulário sem o seu conhecimento ou consentimento.
To execute a CSRF attack from within an iframe, the attacker can create a hidden form on their malicious website that targets the vulnerable website. When the victim visits the malicious website, the hidden form is automatically submitted without their knowledge.
Para executar um ataque CSRF de dentro de um iframe, o invasor pode criar um formulário oculto em seu site malicioso que visa o site vulnerável. Quando a vítima visita o site malicioso, o formulário oculto é enviado automaticamente sem o seu conhecimento.
To prevent this type of attack, web developers can implement measures such as using anti-CSRF tokens, which are unique tokens embedded in forms to verify the authenticity of the request. Additionally, the `SameSite` attribute can be set to `Strict` or `Lax` in cookies to restrict their usage to the same site.
Para prevenir esse tipo de ataque, os desenvolvedores web podem implementar medidas como o uso de tokens anti-CSRF, que são tokens únicos incorporados em formulários para verificar a autenticidade da solicitação. Além disso, o atributo `SameSite` pode ser definido como `Strict` ou `Lax` nos cookies para restringir seu uso ao mesmo site.
Um ataque de falsificação de solicitação entre sites (CSRF) ocorre quando um invasor engana um usuário autenticado a executar ações indesejadas em um aplicativo da web no qual o usuário está autenticado. Para realizar esse ataque, o invasor precisa roubar o token CSRF do usuário e enviá-lo em uma requisição POST.
- Engenharia social: o invasor pode enganar o usuário para que ele clique em um link malicioso ou visite um site comprometido que execute um script para roubar o token CSRF.
- Cross-Site Scripting (XSS): se o aplicativo da web for vulnerável a XSS, o invasor pode injetar um script malicioso que rouba o token CSRF do usuário.
- Ataques de força bruta: o invasor pode tentar adivinhar o token CSRF por meio de tentativas repetidas.
Depois de obter o token CSRF, o invasor pode enviá-lo em uma requisição POST para executar ações indesejadas em nome do usuário autenticado. Isso pode incluir alterar informações do usuário, fazer compras não autorizadas ou realizar outras atividades maliciosas.
- Não clicar em links suspeitos ou visitar sites não confiáveis.
- Manter o software do navegador e do sistema operacional atualizado para corrigir quaisquer vulnerabilidades conhecidas.
- Usar extensões de navegador que bloqueiam scripts maliciosos e protegem contra ataques de XSS.
Ao estar ciente dos riscos e implementar medidas de segurança adequadas, os desenvolvedores e usuários podem reduzir significativamente a probabilidade de sucesso de um ataque CSRF.
Uma técnica comum de ataque CSRF (Cross-Site Request Forgery) envolve roubar o token CSRF de um usuário e usá-lo para enviar uma solicitação POST maliciosa em seu nome. Isso pode ser feito usando um iframe, um formulário ou Ajax.
Essas técnicas permitem que um atacante explore a confiança entre o usuário e o site legítimo, enganando o navegador do usuário para que execute ações indesejadas em seu nome. Para se proteger contra ataques CSRF, os desenvolvedores devem implementar medidas de segurança, como o uso de tokens CSRF exclusivos e a validação adequada das solicitações.
Uma técnica comum de ataque CSRF (Cross-Site Request Forgery) envolve roubar o token CSRF de um usuário e usá-lo para enviar uma solicitação POST maliciosa. Isso pode ser feito usando um iframe e um formulário.
1. Primeiro, o atacante cria um site malicioso que contém um iframe invisível. O atributo `src` do iframe é definido como o URL do site alvo que contém a funcionalidade vulnerável.
2. Em seguida, o atacante cria um formulário no site malicioso. O formulário é configurado para enviar uma solicitação POST para o URL vulnerável do site alvo. O token CSRF é incluído como um campo oculto no formulário.
3. Quando um usuário visita o site malicioso, o iframe invisível é carregado em segundo plano. Isso faz com que o navegador do usuário faça uma solicitação GET para o site alvo, o que resulta na obtenção do token CSRF válido.
4. Em seguida, o formulário malicioso é enviado automaticamente usando JavaScript. Isso faz com que o navegador do usuário envie uma solicitação POST para o URL vulnerável do site alvo, incluindo o token CSRF roubado.
5. O servidor do site alvo recebe a solicitação POST e, como o token CSRF é válido, processa a solicitação como se fosse legítima. Isso pode levar a ações indesejadas, como alterar informações do usuário, fazer compras não autorizadas ou executar outras ações maliciosas.
Para se proteger contra esse tipo de ataque, os desenvolvedores devem implementar medidas de segurança, como a inclusão de tokens CSRF exclusivos em todas as solicitações POST e a validação desses tokens no servidor. Os usuários também devem estar cientes dos riscos de visitar sites não confiáveis e manter seus sistemas atualizados com as últimas correções de segurança.
Um ataque de falsificação de solicitação entre sites (CSRF) é um tipo de ataque em que um invasor engana um usuário autenticado para executar ações indesejadas em um aplicativo da web no qual o usuário está autenticado. Um método comum para realizar um ataque CSRF é roubar o token de autenticação de um usuário e enviá-lo para um servidor controlado pelo invasor.
Neste exemplo, vamos explorar uma técnica em que o invasor usa dois iframes para roubar o token de autenticação de um usuário e enviá-lo para seu próprio servidor.
Ao usar essa técnica, o invasor pode roubar o token de autenticação de um usuário autenticado e usá-lo para executar ações indesejadas em nome do usuário, como fazer alterações em suas configurações, enviar mensagens em seu nome ou realizar transações financeiras.
Para se proteger contra ataques CSRF, os desenvolvedores devem implementar medidas de segurança, como o uso de tokens de autenticação exclusivos para cada solicitação e a validação desses tokens antes de executar ações sensíveis. Os usuários também devem estar cientes dos riscos de clicar em links ou abrir páginas suspeitas, especialmente quando já estão autenticados em um aplicativo da web.
Uma técnica comum para explorar vulnerabilidades de Cross-Site Request Forgery (CSRF) é roubar o token CSRF de um usuário autenticado e usá-lo para enviar uma solicitação POST maliciosa. Isso pode ser feito usando Ajax para obter o token CSRF e, em seguida, enviá-lo junto com os dados do formulário em uma solicitação POST.
Neste exemplo, o código JavaScript faz uma solicitação GET para obter o token CSRF do servidor. Em seguida, ele cria um objeto FormData e anexa o token CSRF e os dados maliciosos ao formulário. Por fim, uma solicitação POST é enviada para o servidor com o token CSRF e os dados do formulário.
É importante ressaltar que essa técnica só funcionará se o token CSRF estiver acessível por meio de uma solicitação Ajax. Além disso, o servidor deve aceitar solicitações POST com o token CSRF fornecido dessa maneira.
Os desenvolvedores devem implementar medidas de proteção adequadas, como a verificação do referenciador (Referer header) e a inclusão de tokens CSRF em formulários, para mitigar ataques de CSRF.
O Cross-Site Request Forgery (CSRF) é uma vulnerabilidade que permite que um atacante execute ações não autorizadas em nome de um usuário autenticado em um aplicativo da web. O Socket.IO é uma biblioteca JavaScript que permite a comunicação em tempo real entre o cliente e o servidor. Neste capítulo, discutiremos como o CSRF pode ser explorado em aplicativos que utilizam o Socket.IO.
O Socket.IO utiliza uma conexão persistente entre o cliente e o servidor para enviar e receber dados em tempo real. No entanto, essa conexão persistente também pode ser explorada por um atacante para realizar ataques CSRF.
O ataque CSRF com o Socket.IO ocorre quando um atacante engana um usuário autenticado a visitar um site malicioso que contém código JavaScript malicioso. Esse código JavaScript malicioso pode se conectar ao servidor Socket.IO legítimo e enviar comandos para executar ações indesejadas em nome do usuário autenticado.
Existem várias medidas que podem ser tomadas para mitigar o risco de CSRF em aplicativos que utilizam o Socket.IO:
1.**Verificação de origem**: O servidor Socket.IO pode verificar a origem das solicitações recebidas para garantir que elas provenham de um domínio confiável. Isso pode ser feito comparando o cabeçalho "Origin" da solicitação com uma lista de domínios confiáveis.
2.**Token CSRF**: Um token CSRF pode ser gerado pelo servidor e incluído em todas as solicitações enviadas pelo cliente. Esse token é então verificado pelo servidor para garantir que a solicitação seja legítima e não provenha de um ataque CSRF.
3.**Cookies seguros**: O uso de cookies seguros pode ajudar a mitigar o risco de CSRF. Os cookies seguros são enviados apenas por meio de conexões criptografadas (HTTPS), o que dificulta a interceptação por parte de um atacante.
4.**Política de mesma origem**: A política de mesma origem (Same Origin Policy) pode ser implementada para restringir o acesso a recursos do Socket.IO apenas a partir do mesmo domínio de origem. Isso impede que um site malicioso acesse a conexão Socket.IO de um usuário autenticado.
O CSRF com o Socket.IO é uma ameaça real em aplicativos da web que utilizam essa biblioteca para comunicação em tempo real. É importante implementar medidas de segurança adequadas, como verificação de origem, tokens CSRF, cookies seguros e política de mesma origem, para mitigar o risco de ataques CSRF bem-sucedidos.
O código pode ser usado para realizar um ataque de força bruta em um formulário de login usando um token CSRF (Também está utilizando o cabeçalho X-Forwarded-For para tentar contornar um possível bloqueio de IP):
As recompensas do HackenProof são lançadas apenas quando os clientes depositam o orçamento de recompensa. Você receberá a recompensa após a verificação do bug.
* 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)
* **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).
