# CSRF (Cross Site Request Forgery)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**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).
**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 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.
* 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 se 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 personalizado de token de cabeçalho
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 o **configuram um cookie csrf** e **verificam no backend se o token csrf enviado é o 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 configure seu cookie CSRF para a vítima como um CRLF**.
Nesse caso, você pode configurar o cookie tentando carregar uma imagem falsa e, em seguida, lançar o ataque CSRF, como neste exemplo:
```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
```
### 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).
### Bypassar 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
```
**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
```
**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" %}
## **Exemplos de Exploração**
### **Exfiltrando o Token CSRF**
Se um **token CSRF** estiver sendo usado como **defesa**, você pode tentar **exfiltrá-lo** abusando de uma vulnerabilidade [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) ou uma vulnerabilidade [**Dangling Markup**](dangling-markup-html-scriptless-injection.md).
### **GET usando tags HTML**
```markup
404 - Page not found
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
```
### 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
```
### Requisição POST de formulário por meio de iframe
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 `