* 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**? Confira 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 do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do 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).
**Cross-site request forgery** (também conhecido como CSRF) é uma vulnerabilidade de segurança na web que permite que um invasor **induza usuários a executar ações que eles não pretendem executar**.\
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 e-mail, fazer a vítima seguir você em uma rede social, dar 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 ser capaz de enviar o cookie de sites da web arbitrários.
* [**Compartilhamento de recursos entre origens**](cors-bypass.md): Dependendo do tipo de solicitação HTTP que você precisa executar para explorar a ação relevante, você pode levar em conta 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._
* Peça a **senha** do usuário para autorizar a ação.
* Resolva um **captcha**
* Leia os cabeçalhos **Referer** 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)
* **Modifique** o **nome** dos **parâmetros** da solicitação Post ou Get
* Use 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, quando você envia uma solicitação GET, o **token CSRF ainda está sendo validado**.
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 invasor pode **remover todo o parâmetro** contendo o token (não apenas seu 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 neste pool.\
Nessa situação, o invasor pode fazer login na aplicação usando sua própria conta, **obter um token válido** e, em seguida, **alimentar esse token para o usuário vítima** em seu ataque CSRF.
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 um método PUT**, você pode tentar **usar um método POST** e **enviar**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Em uma variação adicional da vulnerabilidade anterior, algumas aplicações **duplicam cada token em um cookie e um parâmetro de solicitação**. Ou **definem um cookie csrf e verificam no backend se o token csrf enviado é o relacionado com o cookie**.
Quando a solicitação subsequente é validada, a aplicação simplesmente verifica se o **token** enviado no **parâmetro da solicitação corresponde** ao valor armazenado pelo **cookie**.\
Nessa situação, o invasor pode novamente realizar um **ataque CSRF se o site da web contiver alguma vulnerabilidade que permita que ele defina 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 [**isto**](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 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 flash SWF**. Para mais informações, [**leia este post**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
Se um **token CSRF** está 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 de [**Dangling Markup**](dangling-markup-html-scriptless-injection.md).
An Ajax POST request can be used to perform CSRF attacks. The attacker can create a form with a hidden input field that contains the CSRF token of the victim's session. Then, using JavaScript, the attacker can submit the form using an Ajax POST request to the vulnerable endpoint.
Uma requisição POST Ajax pode ser usada para realizar ataques CSRF. O atacante pode criar um formulário com um campo de entrada oculto que contenha o token CSRF da sessão da vítima. Em seguida, usando JavaScript, o atacante pode enviar o formulário usando uma requisição POST Ajax para o endpoint vulnerável.
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)
Uma vez que o token CSRF é armazenado no navegador do usuário, um atacante pode tentar roubá-lo usando técnicas como XSS ou CSRF. Depois de obter o token, o atacante pode enviar uma requisição POST maliciosa para o servidor, que será autenticada pelo token CSRF roubado. Isso pode permitir que o atacante execute ações maliciosas em nome do usuário legítimo.
Para roubar o token CSRF, o atacante pode usar técnicas como a injeção de JavaScript malicioso em uma página vulnerável ou a criação de um formulário falso que envia o token para um servidor controlado pelo atacante. Depois de obter o token, o atacante pode usá-lo para enviar uma requisição POST maliciosa para o servidor.
### **Roubar o Token CSRF e enviar uma solicitação Post usando um iframe, um formulário e Ajax**
Para realizar um ataque CSRF, é necessário obter o token CSRF válido do usuário alvo. Uma vez que o token CSRF é obtido, ele pode ser usado para enviar solicitações maliciosas em nome do usuário alvo.
Uma maneira de obter o token CSRF é usando um iframe para carregar a página de destino que contém o token. O token pode então ser extraído do código-fonte da página usando JavaScript e usado para enviar uma solicitação POST maliciosa.
Finalmente, o token CSRF também pode ser obtido usando uma solicitação AJAX para a página de destino que retorna o token. O token pode então ser usado para enviar uma solicitação POST maliciosa.
Em todos os casos, o objetivo é obter o token CSRF válido do usuário alvo e usá-lo para enviar solicitações maliciosas em nome do usuário.
### **Roubar o Token CSRF e enviar uma solicitação POST usando um iframe e um formulário**
Uma técnica comum de ataque CSRF é roubar o token CSRF de um usuário legítimo e usá-lo para enviar uma solicitação POST maliciosa. Isso pode ser feito usando um iframe e um formulário oculto.
O primeiro passo é obter o token CSRF do usuário legítimo. Isso pode ser feito usando um script malicioso que injeta um iframe em uma página legítima. O iframe aponta para a página que o atacante deseja atacar e inclui um formulário oculto que envia uma solicitação POST com o token CSRF roubado.
Quando o usuário legítimo visita a página legítima, o script malicioso é executado e o iframe é injetado na página. O formulário oculto é preenchido com os dados necessários para enviar a solicitação POST maliciosa, incluindo o token CSRF roubado. Quando o usuário envia o formulário, a solicitação POST é enviada para o servidor da página de destino, que acredita que a solicitação é legítima porque inclui o token CSRF correto.
Para se proteger contra esse tipo de ataque, os desenvolvedores devem garantir que seus aplicativos gerem tokens CSRF exclusivos para cada sessão do usuário e que esses tokens sejam incluídos em todas as solicitações POST. Além disso, os desenvolvedores devem garantir que seus aplicativos não permitam que solicitações POST sejam enviadas de origens não confiáveis.
Este método de ataque CSRF envolve a criação de dois iframes, um para enviar uma solicitação GET para obter o token de autenticação e outro para enviar a solicitação POST com o token roubado. O primeiro iframe é carregado com a URL da página que contém o token de autenticação e o segundo iframe é carregado com a URL da página que contém o formulário que será enviado com o token roubado.
O código HTML para criar os dois iframes é o seguinte:
if (event.origin === 'https://example.com' && event.source === sendFormFrame.contentWindow) {
var form = sendFormFrame.contentWindow.document.getElementById('form');
form.submit();
}
});
```
Este código carrega o primeiro iframe com a URL `https://example.com/get-token`, que deve retornar o token de autenticação em seu corpo HTML. Quando o iframe é carregado, o código JavaScript dentro do `onload` do iframe obtém o token do corpo HTML do iframe e o envia para o segundo iframe usando `postMessage`. O segundo iframe é carregado com a URL `https://example.com/send-form`, que contém um formulário que será enviado com o token roubado. Quando o segundo iframe recebe o token usando `postMessage`, o código JavaScript dentro do `window.addEventListener` do documento envia o formulário com o token roubado.
### **POSTSteal CSRF token com Ajax e enviar um post com um formulário**
Para realizar um ataque CSRF, é necessário obter o token CSRF válido do usuário alvo. Uma maneira de fazer isso é usando uma solicitação Ajax para obter o token e, em seguida, enviar um POST com um formulário contendo o token. O código abaixo mostra como fazer isso:
Este código envia uma solicitação GET para um endpoint que retorna o token CSRF válido. Em seguida, ele cria um formulário com um campo oculto contendo o token e envia um POST para o endpoint que aceita solicitações POST. O formulário é adicionado ao corpo do documento e enviado automaticamente.
Este ataque pode ser evitado usando tokens CSRF que expiram após um determinado período de tempo ou usando cookies HTTPOnly para armazenar o token CSRF.
Socket.IO é uma biblioteca JavaScript para aplicativos web em tempo real. Ele permite a comunicação bidirecional em tempo real entre o cliente e o servidor. No entanto, o Socket.IO pode ser vulnerável a ataques CSRF.
O Socket.IO usa cookies para autenticar usuários e manter a sessão do usuário. Se um invasor conseguir obter o cookie de autenticação de um usuário, ele poderá enviar solicitações maliciosas em nome do usuário autenticado.
Para explorar essa vulnerabilidade, o invasor pode criar um site malicioso que envia solicitações para o servidor Socket.IO usando o cookie de autenticação do usuário. Quando o usuário visita o site malicioso, as solicitações são enviadas automaticamente para o servidor Socket.IO sem o conhecimento do usuário.
Para evitar esse tipo de ataque, é importante usar tokens CSRF para proteger as solicitações do Socket.IO. O token CSRF é um valor aleatório que é gerado pelo servidor e incluído em cada solicitação. O cliente deve enviar o token CSRF junto com a solicitação e o servidor verifica se o token é válido antes de processar a solicitação.
Para implementar a proteção CSRF no Socket.IO, você pode usar a biblioteca `socketio-csrf`. Essa biblioteca adiciona suporte para tokens CSRF ao Socket.IO e é fácil de usar. Basta adicionar o middleware `csrf` ao seu aplicativo Socket.IO e a biblioteca cuidará do resto.
O código pode ser usado para forçar a entrada em um formulário de login usando um token CSRF (também está usando o cabeçalho X-Forwarded-For para tentar contornar uma possível lista negra de IP):
* Você trabalha em uma **empresa de cibersegurança**? Quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira 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 do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do 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).
