Olá a todos! Como estão? Talvez estejam enjoando um pouco de artigos sobre falhas da WEB com foco em offensive, porém é algo que, para mim, falta bastante no BR, prometo que na próxima será abordado um writeup ou algo diferente :). Enfim, neste artigo serão abordados os temas de CSRF e, de forma bem rasa, XSS.
Cross-site request forgery (CSRF)
CSRF é uma vulnerabilidade WEB que permite um atacante induzir uma vítima a executar ações sem seu devido conhecimento, isso tudo é feito através de um único clique!
Qual o impacto de um ataque CSRF?
Em um ataque de CSRF, um atacante consegue fazer com que um usuário faça ações dentro de uma certa aplicação, um ótimo exemplo disso é um atacante mandar uma página, a qual vai executar o ataque e fazer a vítima, ao clicar em algum botão da página (muitas vezes, só de carregar a página já funciona), mandar dinheiro para a conta do banco do atacante.
Mas como? É simples!
Antes de explicar o ataque passo a passo, é importante ressaltar que há três condições para que o mesmo seja executado, as quais são:
- Uma ação relevante. A aplicação deve conter alguma ação relevante para o atacante executar. (Escalação de privilégio, transferência bancária, etc);
- Manipulação de sessão baseada em Cookie. Executar este ataque, envolve uma ou mais requisições HTTP, logo a aplicação terá que depender, exclusivamente, dos cookies da vítima, que executará todo o processo;
- Nenhum parâmetro imprevisível. Para funcionar, o atacante terá que obter o conhecimento de todos os parâmetros que interferem nas ações de um usuário na aplicação, para que, deste jeito, consiga passar todos os parâmetros necessários para determinada ação ser feita com êxito.
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
email=wiener@normal-user.com
O ataque funciona da seguinte forma:
- O atacante constrói uma página, a qual vai ter um form via POST (ou GET, depende da aplicação. Neste caso, considere a aplicação sendo um banco);
- Este form conterá todos os parâmetros e valores necessários em inputs para a vítima, ao clicar, enviar uma requisição para seu banco, na qual conterá a conta e o valor a ser transferido ao atacante, mas, para isto, a pessoa precisa estar logada.
Em apenas 2 passos você viu como é simples este ataque, não é? Porém, felizmente, as coisas não estão assim atualmente, graças as tecnologias e recursos criados para proteção dos usuários.
XSS vs CSRF
Aqui, será discutido a relação do CSRF com o XSS, se são a mesma coisa ou existem diferenças entre os dois. Também falaremos sobre CSRF tokens prevenirem ataques XSS.
Existe diferença?
A resposta é: sim! Claro que existe, XSS e CSRF são completamente diferentes, em relação ao tipo de exploração.
XSS (Cross-Site Scripting) permite um atacante executar códigos arbitrários de Javascript no navegador da vítima.
CSRF (Cross-Site Request Forgery) permite um atacante induzir a vítima a executar ações não intencionadas em determinada aplicação.
A criticidade do XSS, geralmente, é maior que a do CSRF:
- O CSRF somente se aplica a algumas ações que um usuário consegue fazer. Várias aplicações já conseguem se defender contra isso, mas, ainda assim, existem 1 ou 2 ações que podem estar expostas a ataques CSRF.
- CSRF pode ser descrito como uma vulnerabilidade “one-way”, nessa de induzir a pessoa a executar ações indesejadas, o atacante não consegue retirar informações das requisições feitas para o site alvo (devido a não possuir cookies ou informações passadas de forma direta ao atacante), ou seja, na maioria das vezes, ele só consegue mandar informações para o servidor do site alvo, e não receber. Já o XSS, é uma vulnerabilidade “two-way”, pelo fato dele ter uma comunicação com o navegador da vítima e o atacante receber as informações de forma direta.
CSRF token previne XSS?
Alguns ataques XSS podem, de fato, serem prevenidos por CSRF tokens. Considere um simples XSS refletido:
https://site-vuln.com/status?mensagem=<script>/+payload+xss...+/</script>
Agora, suponha que essa função vulnerável tenha token CSRF:
https://site-vuln.com/status?csrf-token=CIzNZ1lR4XbisJF39I8yWnEX7wX4WFoz&mensagem=<script>/+payload+xss...+/</script>
Alguns pontos importantes a serem considerados:
- Se uma vulnerabilidade de XSS refletido existir em qualquer outro lugar no site dentro de uma função que não seja protegida por um token CSRF, esse XSS poderá ser explorado do mesmo jeito.
- Se uma vulnerabilidade XSS explorável existir em qualquer lugar de um site, a vulnerabilidade poderá ser aproveitada para fazer com que um usuário execute ações, mesmo que essas ações sejam protegidas por tokens CSRF.
- Tokens CSRF não protegem contra ataques de XSS stored.
Construção de ataques CSRF
Beleza, agora que entendemos o que é um ataque CSRF e algumas coisas a mais, vamos para a construção de um.
Há 2 jeitos para fazer isto, o manual (mais demorado) e o automático (BurpSuite Pro). Vou demonstrar os 2 jeitos, lembrando que, ainda neste artigo, será resolvido um laboratório sobre o tema discutido.
Manual:
- Primeiro, identifique os parâmetros a serem passados nos inputs que serão criados em nossa página falsa;
- Identificados, basta acrescentá-los como “name” e “value” nas tags HTML dos inputs;
- Depois de acrescentados, basta adicionar o método de envio na tag “form”, que será POST, neste caso;
- Após tudo isto, basta carregar a página e clicar no input com o valor “Enviar”. Se tudo estiver correto, você conseguirá trocar o email de algum usuário.
Automático, vale ressaltar que isso funciona somente na versão Professional do BurpSuite:
- Primeiro, pegue a requisição em que você altera seu email;
- Agora, com a requisição em mãos, clique com o botão direito de seu mouse e vá até a opção “Engagement tools” — > “Generate CSRF Poc”;
- Feito isso, basta copiar o conteúdo para um arquivo html e repetir o último processo que foi feito no manual.
Algumas defesas contra CSRF
Atualmente, encontrar e explorar com sucesso as vulnerabilidades do CSRF geralmente envolve ignorar as medidas anti-CSRF do site de destino, pelo navegador da vítima ou por ambos. As defesas mais comuns que você encontrará são as seguintes:
- CSRF Tokens;
- SameSite Cookies;
- Referer-based validation.
Laboratório
Com todos esses conceitos já em mente, faremos um laboratório da portswigger.
Primeiramente, iremos logar com as credenciais nos fornecidas (wiener:peter). Após isso, iremos capturar a requisição de troca de email no burpsuite.
Com o BurpSuite Pro, você irá para a seguinte opção:
Depois, basta alterar o valor do email para verificar se está funcionando e clicar em “Test in browser”.
Como pode ver, caso tenha testado você mesmo, funcionou corretamente e sem problemas, isso significa que está vulnerável a CSRF.
A última coisa que teremos que fazer, será enviar este exploit para o servidor validar e constar que finalizamos o lab!
Colaremos o código gerado pelo burp no “Body” e, logo em seguida, em “Deliver exploit to victim”.
Pronto! Finalizamos este lab bem simples, porém que serve bastante de exemplo para entender os fundamentos de um ataque CSRF. Agora, a partir destes conhecimentos que você adquiriu ao longo deste artigo, poderá se aprofundar mais neste mundo!
Espero ter adicionado algum conhecimento para você, leitor 🙂
Agradeço a atenção, boa noite, boa tarde ou bom dia e até mais, TMJJJ!!
Referências
What is CSRF (Cross-site request forgery)? Tutorial & Examples | Web Security Academy
In this section, we’ll explain what cross-site request forgery is, describe some examples of common CSRF…portswigger.net
CSRF – RouterCheck
A Cross-Site Request Forgery or CSRF attack is a way that hackers may attempt to get information from sensitive sites…routercheck.com