ENTENDENDO A VULNERABILIDADE CSRF

(O conhecido ataque de um clique)

A credencial do usuário é validada, um cookie é enviado na resposta da requisição HTTP. A partir desse momento, o navegador tem salvo no disco o cookie que te mantém autenticado.

2) Você recebe um e-mail (engenharia social) que te convence a clicar em um link que abre um site arbitrário.

O que é?

Cross Site Request Forgery ou apenas CSRF é uma vulnerabilidade conhecida em aplicações WEB que permite um atacante induzir um usuário legítimo a performar ações sem seu consentimento, contornando parcialmente a SOP(Same Origin Police) que é projetada para impedir que sites diferentes interfiram entre si.

Como o ataque funciona?

1- O atacante identifica uma ação relevante em determinada aplicação, ao qual a vítima tenha acesso ao estar logada, como por exemplo uma ação de troca de senha, e-mail ou qualquer outra ação que seja de interesse do atacante.

2- A requisição será identificada e interceptada pelo atacante, que irá modelar uma página na web simples, com os parâmetros modificados, como por exemplo o parâmetro de troca de senha, podendo conter apenas um botão ou então manter todo conteúdo oculto que será enviado para a vítima, geralmente usando técnicas de engenharia social, com a intenção de que ela acione o mesmo, em certos casos apenas o acesso a página vulnerável do atacante já é o suficiente para disparar a requisição maliciosa ao domínio original.

Muitas vezes parâmetros podem ser previsíveis, em muitos casos apenas o e-mail da vítima já é o suficiente para formar uma requisição de troca de senha.

3- Para que o ataque funcione, o atacante necessita que a vítima esteja conectada em sua conta original ao disparar a requisição maliciosa, que pode ter sido recebida em seu e-mail, sendo assim, no melhor dos casos, o browser irá incorporar o cookie do alvo a requisição que será processada pela aplicação como sendo legítima, da mesma forma em que é demonstrado na imagem abaixo:

Para entendermos o ataque de maneira mais prática, podemos observar a requisição de troca de e-mail a seguir, que possui as condições ideais para a exploração da vulnerabilidade:

POST /email/change HTTP/1.1
Host: websitevulneravel.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=F0sdvAzCeQ5gHgTvlyxHfs9

email=admin99@gmail.com            

Observe que esta requisição possui apenas um cookie simples para identificar o usuário, e a aplicação não requer nenhuma confirmação por parte do usuário para realizar a mudança, como por exemplo a confirmação de senha para efetuar este tipo de requisição, visto que este não é um parâmetro que pode ser advinhado. Com isso o atacante pode criar a seguinte página para ser enviada a vítima através de um e-mail ou link encurtado por exemplo:

<html>
  <body>
    <form action=”http://websitevulneravel.com/email/change” method=”POST”>
      <input type=”hidden” name=”email” value=”attacker@evil-corp.net” />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>         

Em casos em que a vulnerabilidade se encontra através de uma requisição do tipo GET, não se faz necessário o uso de um domínio externo para efetuar a requisição maliciosa visto que o conteúdo é adicionado na URL do website vulnerável, esta que pode ser encurtada para disfarçar o ataque. Atualmente existem diversas ferramentas capazes de detectar e forjar a requisição para o teste de CSRF automaticamente, a mais conhecida esta presente na versão PRO do Burp Suite que é capaz de detectar e gerar uma PoC(Proof of Concept) para o teste.

Como previnir meu Website contra CSRF?

Existem diversas maneiras de prevenção contra CSRF, a mais robusta é fazer o uso de Anti CSRF Tokens em requisições de maior relevância, porém não é um método infalível e existe a possibilidade de “bypass” no token, para evitar que isso aconteça o token precisa ser imprevisível, estar atrelado a sessão do usuário e ser estritamente validado antes que a solicitação seja executada, uma forma conhecida de bypass para estes tokens é mudar o conteúdo de alguns cabeçalhos como o “Content-Type” ou então mudar o tipo de requisição de POST para GET por exemplo, já que pode não estar sendo validado em todos os tipos de requisições aceitas.

Como boa prática de desenvolvimento, é importante que o desenvolvedor identifique estas alterações de maior criticidade em sua plataforma e utilize de confirmações por parte do usuário, como solicitar a senha que já esta sendo utilizada quando o usuário for mudar a senha.

Outras boas práticas são limitar o tempo de uso de um Cookie de sessão e verificar o Referer na requisição, porém esta pode ser facilmente modificada por parte do atacante. Também pode ser usado o atributo de cookie “SameSite” que irá prevenir o uso do Cookie de sessão em requisições oriúndas de outro domínio, sendo uma das maneiras mais modernas e de fácil aplicação. Para mais informações sobre:

https://portswigger.net/web-security/csrf/samesite-cookies                  

                   

https://portswigger.net/web-security/csrf/tokens