Aprenda e pratique Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
**Cross-Site Request Forgery (CSRF)** é um tipo de vulnerabilidade de segurança encontrada em aplicações web. Ela permite que atacantes realizem ações em nome de usuários desavisados, explorando suas sessões autenticadas. O ataque é executado quando um usuário, que está logado na plataforma de uma vítima, visita um site malicioso. Este site então aciona requisições para a conta da vítima através de métodos como executar JavaScript, enviar formulários ou buscar imagens.
1.**Identificar uma Ação Valiosa**: O atacante precisa encontrar uma ação que vale a pena explorar, como mudar a senha do usuário, email ou elevar privilégios.
2.**Gerenciamento de Sessão**: A sessão do usuário deve ser gerenciada exclusivamente através de cookies ou do cabeçalho de Autenticação Básica HTTP, pois outros cabeçalhos não podem ser manipulados para esse propósito.
3.**Ausência de Parâmetros Imprevisíveis**: A requisição não deve conter parâmetros imprevisíveis, pois eles podem impedir o ataque.
Você pode **capturar a requisição no Burp** e verificar as proteções CSRF e para testar do navegador você pode clicar em **Copiar como fetch** e verificar a requisição:
* [**Cookies SameSite**](hacking-with-cookies/#samesite): Este atributo impede que o navegador envie cookies junto com requisições de outros sites. [Mais sobre cookies SameSite](hacking-with-cookies/#samesite).
* [**Compartilhamento de recursos entre origens**](cors-bypass.md): A política CORS do site da vítima pode influenciar a viabilidade do ataque, especialmente se o ataque requerer a leitura da resposta do site da vítima. [Saiba mais sobre bypass de CORS](cors-bypass.md).
* **Verificando Cabeçalhos Referrer ou Origin**: Validar esses cabeçalhos pode ajudar a garantir que as requisições estão vindo de fontes confiáveis. No entanto, a elaboração cuidadosa de URLs pode contornar verificações mal implementadas, como:
* Usar `http://mal.net?orig=http://example.com` (URL termina com a URL confiável)
* Usar `http://example.com.mal.net` (URL começa com a URL confiável)
* **Modificando Nomes de Parâmetros**: Alterar os nomes dos parâmetros em requisições POST ou GET pode ajudar a prevenir ataques automatizados.
* **Tokens CSRF**: Incorporar um token CSRF único em cada sessão e exigir esse token em requisições subsequentes pode mitigar significativamente o risco de CSRF. A eficácia do token pode ser aumentada pela imposição de CORS.
Talvez o formulário que você deseja abusar esteja preparado para enviar uma **requisição POST com um token CSRF, mas** você deve **verificar** se um **GET** também é **válido** e se, ao enviar uma requisição GET, o **token CSRF ainda está sendo validado**.
As aplicações podem implementar um mecanismo para **validar tokens** quando eles estão presentes. No entanto, uma vulnerabilidade surge se a validação for completamente ignorada quando o token está ausente. Os atacantes podem explorar isso **removendo o parâmetro** que carrega o token, não apenas seu valor. Isso permite que eles contornem o processo de validação e realizem um ataque Cross-Site Request Forgery (CSRF) de forma eficaz.
Aplicações **que não vinculam tokens CSRF às sessões de usuário** apresentam um **risco de segurança** significativo. Esses sistemas verificam tokens contra um **pool global** em vez de garantir que cada token esteja vinculado à sessão iniciadora.
Essa vulnerabilidade permite que os atacantes façam requisições não autorizadas em nome da vítima, explorando o **mecanismo inadequado de validação de tokens** da aplicação.
Se a requisição estiver usando um método "**estranho**", verifique se a **funcionalidade** de **sobrescrita 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**_
As aplicações podem implementar proteção CSRF duplicando o token em um cookie e um parâmetro de requisição ou configurando um cookie CSRF e verificando se o token enviado no backend corresponde ao cookie. A aplicação valida requisições verificando se o token no parâmetro de requisição alinha-se com o valor no cookie.
No entanto, esse método é vulnerável a ataques CSRF se o site tiver falhas que permitam a um atacante definir um cookie CSRF no navegador da vítima, como uma vulnerabilidade CRLF. O atacante pode explorar isso carregando uma imagem enganosa que define o cookie, seguida pela iniciação do ataque CSRF.
Observe que se o **token csrf estiver relacionado com o cookie de sessão, este 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 requisições de pré-vôo** usando o método **POST**, estes são os valores de Content-Type permitidos:
No entanto, observe que a **lógica do servidor pode variar** dependendo do **Content-Type** utilizado, então você deve tentar os valores mencionados e outros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Ao tentar enviar dados JSON via uma requisição POST, usar `Content-Type: application/json` em um formulário HTML não é diretamente possível. Da mesma forma, utilizar `XMLHttpRequest` para enviar esse tipo de conteúdo inicia uma requisição preflight. No entanto, existem estratégias para potencialmente contornar essa limitação e verificar se o servidor processa os dados JSON independentemente do Content-Type:
1.**Use Tipos de Conteúdo Alternativos**: Empregue `Content-Type: text/plain` ou `Content-Type: application/x-www-form-urlencoded` definindo `enctype="text/plain"` no formulário. Essa abordagem testa se o backend utiliza os dados independentemente do Content-Type.
2.**Modifique o Tipo de Conteúdo**: Para evitar uma requisição preflight enquanto garante que o servidor reconheça o conteúdo como JSON, você pode enviar os dados com `Content-Type: text/plain; application/json`. Isso não aciona uma requisição preflight, mas pode ser processado corretamente pelo servidor se estiver configurado para aceitar `application/json`.
3.**Utilização de Arquivo SWF Flash**: Um método menos comum, mas viável, envolve usar um arquivo SWF flash para contornar tais restrições. Para uma compreensão mais profunda dessa técnica, consulte [este post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
As aplicações podem validar o cabeçalho 'Referer' apenas quando ele está presente. Para impedir que um navegador envie esse cabeçalho, a seguinte tag meta HTML pode ser usada:
A primeira parte de [**este CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que o [código-fonte do Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), um roteador, está configurado para **tratar 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 que lida com requisições HEAD, elas são simplesmente **enviadas para o manipulador GET, mas o aplicativo apenas remove o corpo da 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** abusando de uma vulnerabilidade de [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) ou uma vulnerabilidade de [**Dangling Markup**](dangling-markup-html-scriptless-injection/).
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)
O código pode ser usado para forçar um formulário de login usando um token CSRF (também está usando o cabeçalho X-Forwarded-For para tentar contornar um possível bloqueio de IP):
Aprenda e pratique Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).