As vulnerabilidades da web são abundantes e estão em constante aumento. Manter a segurança e a privacidade de seus usuários é mais importante do que nunca. Não abordar as vulnerabilidades da web pode levar a uma reputação arruinada e multas pesadas dos reguladores, e você também perderá a confiança de seus usuários.
Sites e aplicativos da web são vulneráveis a malware, spam e outros ataques – este artigo se concentra em um vetor de ataque específico – os ataques de Cross-Site Request Forgery (CSRF). Os ataques CSRF são particularmente preocupantes porque podem ocorrer sem o conhecimento do usuário. Eles também são difíceis de detectar por um desenvolvedor ou proprietário do site, porque as solicitações maliciosas parecem muito similares às solicitações legítimas.
Este artigo explora os ataques CSRF, como funciona e as medidas que você pode tomar para se preparar para um ataque CSRF.
Confira nosso guia em vídeo para entender tudo sobre os ataques CSRF
O que é um ataque CSRF?
Um ataque Cross-Site Request Forgery, também conhecido como ataque CSRF, engana um usuário autenticado a realizar ações não intencionais, enviando solicitações maliciosas sem que o usuário perceba.
Normalmente, um ataque CSRF envolve solicitações que alteram o estado do sistema, pois o atacante não recebe uma resposta. Exemplos de tais solicitações incluem excluir um registro, alterar uma senha, comprar um produto ou enviar uma mensagem. Todas essas ações podem ocorrer sem o conhecimento do usuário.
O atacante malicioso geralmente usa a engenharia social para enviar a um usuário desprevenido um link através de chat ou e-mail.
Quando o usuário clica no link, ele executa os comandos definidos pelo atacante.
Por exemplo, clicar em um link pode transferir fundos da conta de um usuário. Ou, pode alterar o endereço de e-mail do usuário, impedindo que ele recupere o acesso à conta.
Como funciona um ataque CSRF?
Fazer com que o usuário inicie uma solicitação que altera o estado do sistema enquanto está logado é o primeiro e mais crucial passo em um ataque CSRF. Com ataques CSRF, o atacante tem como objetivo fazer com que um usuário autenticado envie, sem saber, uma solicitação web maliciosa para um site ou aplicativo da web. Essas solicitações podem conter cookies, parâmetros de URL e outros tipos de dados que parecem normais para o usuário.
Para que um ataque CSRF seja bem-sucedido, as seguintes condições devem ocorrer:
- Um usuário autenticado deve estar logado em um aplicativo da web que utiliza cookies para o gerenciamento de sessão.
- Um atacante deve criar uma solicitação falsificada que altera o estado do sistema.
- As solicitações legítimas tratadas pelo servidor de destino não devem conter parâmetros imprevisíveis. Por exemplo, a solicitação não deve exigir uma senha como parâmetro para fins de verificação antes de iniciar a solicitação que altera o estado do sistema.
O método mais comum para realizar ataques CSRF é usar cookies em aplicativos com uma política de cookies SameSite fraca. Os navegadores da web incluem cookies automaticamente e frequentemente anonimamente, e eles salvam cookies usados por um domínio em qualquer solicitação web enviada pelo usuário para esse domínio.
A política de cookies SameSite define como o navegador, em contextos de navegação entre sites, trata o cookie. Se definido como “strict”, o cookie não é compartilhado em contextos de navegação entre sites, prevenindo ataques CSRF. Se definido como “none”, o navegador inclui o cookie em todos os contextos de navegação entre sites, deixando o aplicativo vulnerável a ataques CSRF.
Quando um usuário envia, sem saber, uma solicitação maliciosa através de um navegador web, os cookies salvos fazem com que a solicitação pareça legítima para o servidor. O servidor, então, responde à solicitação alterando a conta do usuário, modificando o estado da sessão ou retornando os dados solicitados.
Vamos examinar mais de perto dois exemplos de possíveis ataques CSRF, um com uma solicitação GET e outro com uma solicitação POST.
CSRF para uma solicitação GET
Primeiro, considere uma solicitação GET utilizada por um aplicativo web de banco financeiro, onde o ataque explora uma solicitação GET e uma entrega de hyperlink.
Suponha que o pedido GET de transferência de dinheiro seja algo parecido com isso:
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1Na solicitação genuína acima, o usuário solicita transferir $1.000 para uma conta com o número 547895 como pagamento por produtos comprados.
Embora essa solicitação seja explícita, simples e prática, ela expõe o titular da conta a um ataque CSRF. Isso ocorre porque a solicitação não requer detalhes que um atacante não possa saber. Portanto, para iniciar um ataque, um atacante só precisaria alterar os parâmetros dessa solicitação (o valor e o número da conta) para criar uma solicitação forjada executável.
A solicitação maliciosa seria eficaz em qualquer usuário do banco, desde que eles tenham sessões gerenciadas por cookies em andamento.
Aqui está como a solicitação forjada para transferir $500 para a conta de um hacker (aqui, número 654585) ficaria. Observe que o exemplo abaixo é uma versão altamente simplificada dos passos envolvidos em um ataque CSRF para fins de explicação.
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1Uma vez que isso estiver completo, o atacante deve descobrir uma maneira de enganar o usuário para enviar essa solicitação enquanto estiver conectado ao seu aplicativo do banco on-line. Uma das maneiras de fazer isso é criar um hiperlink inofensivo que chame a atenção do usuário. O link pode ser assim:
<a
href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.Dado que o atacante encontrou os endereços de e-mail corretos de seus alvos, eles podem enviar isso por e-mail para muitos clientes do banco. Aqueles que clicarem no link enquanto estiverem logados ativarão o pedido para enviar ao atacante $500 da conta logada.
CSRF para uma solicitação POST
Vamos ver como a mesma instituição financeira seria afetada por um CSRF se eles aceitassem apenas solicitações POST. Nesse caso, a entrega de hiperlink usada no exemplo de solicitação GET não funcionaria. Portanto, um ataque CSRF bem-sucedido exigiria que o atacante criasse um formulário HTML. A solicitação genuína para enviar $1.000 para um produto comprado ficaria assim:
POST /online/transfer HTTP/1.1
Host: xymbank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg
amount=1000
account=547895Essa solicitação POST requer um cookie para determinar a identidade do usuário, o valor que desejam enviar e a conta de destino. Os atacantes podem alterar essa solicitação para realizar um ataque CSRF.
O atacante só precisa adicionar um cookie genuíno a uma solicitação falsificada para que o servidor processe a transferência. Eles podem fazer isso criando um hiperlink de aparência inofensiva que leve o usuário a uma página da web de disparo que se parece com isso:
<html>
<body>
<form action="https://xymbank.com/online/transfer" method="POST">
<input type="hidden" name="amount" value="500"/>
<input type="hidden" name="account" value="654585" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>Já definimos os parâmetros de valor e conta no formulário acima. Quando um usuário autenticado visita à página, o navegador adiciona o cookie de sessão antes de encaminhar a solicitação para o servidor. O servidor, em seguida, encaminha $500 para a conta do hacker.
3 maneiras de reduzir os ataques CSRF
Existem vários métodos para prevenir e mitigar drasticamente possíveis ataques CSRF em seu site ou aplicativo da web, incluindo:
- Usando tokens CSRF
- Usando o cabeçalho de referer
- Escolhendo uma solução de hospedagem focada em segurança, como a Kinsta
Como prevenir ataques CSRF usando tokens CSRF
Um site seguro contra CSRF atribui a cada sessão um token único e o compartilha com o servidor e o navegador do cliente. Sempre que um navegador envia uma solicitação sensível, o servidor espera que ela contenha o token CSRF atribuído. Se o token estiver incorreto, o servidor descarta a solicitação. O token CSRF não é armazenado em cookies de sessão no navegador do cliente por motivos de segurança.
Potenciais vulnerabilidades dos tokens CSRF
Embora os tokens CSRF sejam uma excelente medida de segurança, esse método não é à prova de ataques. Algumas das vulnerabilidades que acompanham os tokens CSRF incluem:
- Bypass de validação – Alguns aplicativos ignoram a etapa de verificação se não encontrarem um token. Se um atacante ganhar acesso ao código que contém um token, eles podem removê-lo e executar com sucesso um ataque CSRF. Assim, se uma solicitação válida para um servidor se parece com isso:
POST /change_password
POST body:
password=pass123&csrf_token=93j9d8eckke20d433Um atacante precisa apenas remover o token e enviar a solicitação assim para executar o ataque:
POST /change_password
POST body:
password=pass123- Tokens agrupados – Alguns aplicativos mantêm um conjunto de tokens para validar sessões de usuários em vez de designar um token específico para uma sessão. Um atacante só precisa obter um dos tokens já presentes no conjunto para se passar por qualquer usuário do site.
Um atacante pode fazer login em um aplicativo usando sua conta para obter um token, como:
[application_url].com?csrf_token=93j9d8eckke20d433E, como os tokens estão agrupados, o atacante pode copiar e usar o mesmo token para fazer login na conta de um usuário diferente, como neste exemplo:
- Tokens copiados para o cookie – Alguns aplicativos copiam os parâmetros relacionados a um token em um cookie do usuário. Se um atacante ganhar acesso a esse cookie, eles podem facilmente criar outro cookie, colocá-lo no navegador e executar um ataque CSRF.
Assim, um atacante pode fazer login em um aplicativo usando sua conta e abrir o arquivo de cookie para ver o seguinte:
Csrf_token:93j9d8eckke20d433Eles podem, então, usar essas informações para criar outro cookie e completar o ataque.
- Tokens inválidos – Alguns aplicativos não correspondem os tokens CSRF a uma sessão de usuário. Em tais casos, um atacante pode fazer login genuinamente em uma sessão, obter um token CSRF semelhante aos exemplos acima e usá-lo para orquestrar um ataque CSRF em uma sessão da vítima.
Como prevenir ataques CSRF com o cabeçalho de referrer
Outra estratégia para prevenir ataques CSRF é o uso do cabeçalho “Referer”. No HTTP, os cabeçalhos “Referer” indicam a origem das solicitações. Eles são tipicamente utilizados para análise, otimização e registro de dados.
Você também pode habilitar a verificação dos cabeçalhos “Referer” no lado do servidor para prevenir ataques CSRF. O lado do servidor verifica a origem da solicitação e determina a origem de destino da mesma. Se elas corresponderem, então a solicitação é permitida. Se houver uma divergência, o servidor descarta a solicitação.
Usar cabeçalhos “Referer” é mais simples do que usar tokens porque não requer a identificação individual de usuários.
Potenciais vulnerabilidades do cabeçalho referer
Assim como os tokens CSRF, os cabeçalhos “Referer” também têm algumas vulnerabilidades significativas.
Em primeiro lugar, os cabeçalhos “Referer” não são obrigatórios, e alguns sites enviarão solicitações sem eles. Se o CSRF não tiver uma política para lidar com solicitações sem cabeçalhos, os atacantes podem usar solicitações sem cabeçalhos para executar ataques que alteram o estado do sistema.
Além disso, esse método se tornou menos eficaz com a recente introdução da política “Referer”. Essa especificação previne o vazamento de URLs para outros domínios, dando aos usuários mais controle sobre as informações no cabeçalho “Referer”. Eles podem optar por expor parte das informações do cabeçalho “Referer” ou desativá-lo adicionando uma etiqueta de metadados na página HTML, como mostrado abaixo:
<meta name="referrer" content="no-referrer">O código acima remove o cabeçalho “Referer” de todas as solicitações feitas a partir desta página. Fazendo isso, torna-se difícil para aplicativos que dependem dos cabeçalhos “Referer” prevenir ataques CSRF provenientes dessa página.
Como a Kinsta se protege contra-ataques CSRF
Como a Kinsta se Protege contra Ataques CSRF
Além de usar o cabeçalho “Referer” e tokens CSRF, há uma terceira e opção muito mais fácil: escolher um serviço de hospedagem seguro como a Kinsta para seus sites e aplicativos da web oferece uma barreira muito mais forte e segura entre os atacantes e seus usuários.
Além de recursos de segurança críticos, como backups automáticos, autenticação de dois fatores e protocolos SFTP via SSH, a integração da Kinsta com o Cloudflare fornece proteção de nível empresarial com proteção baseada em IP e firewall.
Especificamente, a Kinsta atualmente possui cerca de 60 regras personalizadas de firewall para ajudar a prevenir ataques maliciosos e lidar com vulnerabilidades severas não autenticadas em plugins e temas, incluindo regras específicas que procuram por vulnerabilidades CSRF.
Resumo
O Cross-Site Request Forgery (CSRF) é um ataque que engana usuários autenticados a iniciarem solicitações que alteram o estado do sistema sem que eles percebam. Esses ataques miram em aplicativos que não conseguem distinguir entre solicitações genuínas e forjadas que alteram o estado.
Os ataques CSRF são bem-sucedidos em aplicativos que utilizam cookies de sessão para identificar usuários logados e têm uma política de cookies SameSite fraca. Além disso, o servidor deve aceitar solicitações sem exigir parâmetros desconhecidos, como senhas. Os hackers podem executar ataques maliciosos usando tanto o método GET quanto o POST.
Para prevenir ataques CSRF, é comum utilizar tokens CSRF ou implementar a verificação do cabeçalho “Referer”. No entanto, ambas as medidas têm potenciais vulnerabilidades que podem comprometer sua eficácia se não forem cuidadosamente gerenciadas.
Optar por uma plataforma de hospedagem segura, como a Kinsta, aumenta a proteção contra-ataques CSRF em sites e aplicativos da web. Além disso, a integração da Kinsta com o Cloudflare adiciona uma camada extra de defesa, direcionada especificamente para certos ataques CSRF.
Deixe um comentário