Compreendendo os ataques CSRF e bloqueando as vulnerabilidades CSRF

As vulnerabilidades da Web são desenfreadas e aumentam constantemente. 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 à ruína da reputação e multas pesadas dos reguladores, além de perder a confiança dos usuários.

Sites e aplicativos da web são vulneráveis ​​a malware, spam e outros ataques — este artigo se concentra em um desses vetores de ataque — ataques Cross-Site Request Forgery (CSRF). Os ataques CSRF são particularmente problemáticos porque podem ocorrer sem o conhecimento do usuário. Eles também são difíceis de serem detectados por um desenvolvedor ou proprietário de site porque as solicitações maliciosas parecem muito semelhantes às solicitações genuínas.

Este artigo explora um ataque CSRF, como ele funciona e as etapas que você pode seguir para se preparar para um.

O que é um ataque CSRF?

Um ataque de falsificação de solicitação entre sites, também conhecido como ataque CSRF, engana um usuário autenticado para que execute ações não intencionais, enviando solicitações maliciosas sem que ele perceba.

Normalmente, um ataque CSRF envolve solicitações de mudança de estado porque o invasor não recebe uma resposta. Exemplos de tais solicitações incluem excluir um registro, alterar uma senha, comprar um produto ou enviar uma mensagem. Tudo isso pode ocorrer sem o conhecimento do usuário.

O invasor mal-intencionado normalmente usa engenharia social para enviar um link a um usuário desavisado por meio de bate-papo ou e-mail.

Quando o usuário clica no link, ele executa os comandos definidos pelo invasor.

Por exemplo, clicar em um link pode transferir fundos da conta de um usuário. Ou pode alterar o endereço de e-mail de um usuário, impedindo-o de recuperar o acesso à conta.

Como funciona um ataque CSRF?

Fazer com que o usuário inicie uma solicitação de mudança de estado enquanto estiver conectado é a primeira e mais importante etapa em um ataque CSRF. Com ataques CSRF, o invasor visa fazer com que um usuário autenticado envie, sem saber, uma solicitação da Web maliciosa a um site ou aplicativo da Web. Essas solicitações podem consistir em 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 conectado a um aplicativo da web que usa cookies para gerenciamento de sessão.
• Um invasor deve criar uma solicitação forjada de mudança de estado.
• As solicitações genuínas tratadas pelo servidor de destino não devem conter parâmetros imprevisíveis. Por exemplo, a solicitação não deve esperar uma senha como parâmetro para fins de verificação antes de iniciar a solicitação de mudança de estado.

O método mais comum de concluir ataques CSRF é usar cookies em aplicativos com uma política de cookies SameSite fraca. Os navegadores da Web incluem cookies automaticamente e, muitas vezes, anonimamente, e salvam os cookies usados ​​por um domínio em qualquer solicitação da Web que um usuário envie a 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 estrito, o cookie não é compartilhado em contextos de navegação entre sites, evitando ataques CSRF. O navegador anexa o cookie em todos os contextos entre sites se estiver definido como nenhum. Isso deixa o aplicativo vulnerável a ataques CSRF.

Quando um usuário inadvertidamente envia uma solicitação maliciosa por meio de um navegador da Web, os cookies salvos fazem com que a solicitação pareça legítima para o servidor. O servidor responde à solicitação alterando a conta do usuário, alterando o estado da sessão ou retornando os dados solicitados.

Vamos dar uma olhada mais de perto em dois exemplos de vias de ataque CSRF, uma com uma solicitação GET e a outra com uma solicitação POST.

CSRF para uma solicitação GET

Primeiro, considere uma solicitação GET usada por um aplicativo da Web de banco financeiro, em que o ataque explora uma solicitação GET e a entrega de hiperlink.

Suponha que a solicitação GET para transferência de dinheiro seja mais ou menos assim:

 GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

Na solicitação genuína acima, o usuário solicita a transferência de $ 1.000 para uma conta com 547895 como pagamento pelos produtos adquiridos.

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 invasor possa não saber. Assim, para iniciar um ataque, um invasor precisaria apenas alterar os parâmetros dessa solicitação (o valor e o número da conta) para criar uma solicitação falsificada executável.

A solicitação maliciosa seria eficaz em qualquer um dos usuários do banco, desde que eles tivessem sessões gerenciadas por cookies em andamento.

Veja como seria a solicitação forjada para transferir $ 500 para a conta de um hacker (aqui, número 654585 ). Observe que o exemplo abaixo é uma versão altamente simplificada das etapas envolvidas em um ataque CSRF para uma explicação.

 GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

Depois de concluído, o invasor deve descobrir uma maneira de induzir o usuário a enviar essa solicitação enquanto estiver conectado ao aplicativo de 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 invasor encontrou os endereços de e-mail corretos de seus alvos, eles podem enviar isso por e-mail para muitos clientes bancários. Aqueles que clicarem no link enquanto estiverem conectados acionariam a solicitação para enviar ao invasor $ 500 da conta conectada.

CSRF para uma solicitação POST

Vamos ver como a mesma instituição financeira experimentaria um CSRF se aceitasse 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 um invasor criasse um formulário HTML. A solicitação genuína para enviar US$ 1.000 por 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=547895

Essa solicitação POST requer um cookie para determinar a identidade do usuário, o valor que deseja enviar e a conta que deseja enviar. Os invasores podem alterar essa solicitação para realizar um ataque CSRF.

O invasor deve apenas adicionar um cookie genuíno a uma solicitação forjada para fazer o servidor processar a transferência. Eles podem fazer isso criando um hiperlink de aparência inofensiva que leva o usuário a uma página da Web de acionamento semelhante a esta:

 <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 o valor e os parâmetros da conta no formulário acima. Depois que um usuário autenticado visita a página, o navegador adiciona o cookie de sessão antes de encaminhar a solicitação ao servidor. O servidor então encaminha $ 500 para a conta do hacker.

3 maneiras de diminuir 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 do referenciador
• Escolhendo uma solução de hospedagem focada em segurança, como Kinsta

Como prevenir ataques CSRF usando tokens CSRF

Um site seguro CSRF atribui a cada sessão um token exclusivo e o compartilha com o lado do servidor e o navegador do cliente. Sempre que um navegador envia uma solicitação confidencial, o servidor espera que ela contenha o token CSRF atribuído. Se tiver o token errado, o servidor o descarta. O token CSRF não é armazenado em cookies de sessão no navegador do cliente para fins de segurança.

Vulnerabilidades potenciais de 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:

• Desvio de validação — Alguns aplicativos ignoram a etapa de verificação se não encontrarem um token. Se um invasor obtiver acesso ao código que contém um token, ele poderá remover esse token e executar com sucesso um ataque CSRF. Portanto, se uma solicitação válida para um servidor for semelhante a esta:

 POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433

Um invasor precisa apenas remover o token e enviá-lo assim para executar o ataque:

 POST /change_password POST body: password=pass123

• Tokens em pool — Alguns aplicativos mantêm um pool de tokens para validar as sessões do usuário em vez de designar um token específico para uma sessão. Um invasor só precisa obter um dos tokens já existentes no pool para representar qualquer um dos usuários do site.

Um invasor pode fazer login em um aplicativo usando sua conta para obter um token, como:

 [application_url].com?csrf_token=93j9d8eckke20d433

E como os tokens são agrupados, o invasor pode copiar e usar esse mesmo token para fazer login em uma conta de usuário diferente, pois você o usará novamente:

• Os CSRFs podem ser copiados por token para o cookie — Alguns aplicativos copiarão os parâmetros relacionados a um token no cookie de um usuário. Se um invasor obtiver acesso a esse cookie, ele poderá facilmente criar outro cookie, colocá-lo em um navegador e executar um ataque CSRF.

Portanto, um invasor pode fazer login em um aplicativo usando sua conta e abrir o arquivo de cookie para ver o seguinte:

 Csrf_token:93j9d8eckke20d433

Eles podem usar essas informações para criar outro cookie para concluir o ataque

• Tokens inválidos — Alguns aplicativos não correspondem a tokens CSRF para uma sessão de usuário. Nesses casos, um invasor pode genuinamente fazer login em uma sessão, obter um token CSRF semelhante aos acima e usá-lo para orquestrar um ataque CSRF na sessão da vítima.

Como prevenir ataques CSRF com o cabeçalho de referência

Outra estratégia para evitar ataques CSRF é usar o cabeçalho do referenciador. Em HTTP, os cabeçalhos do referenciador indicam a origem das solicitações. Eles são normalmente usados ​​para realizar análises, otimização e criação de log.

Você também pode ativar a verificação de cabeçalhos de referência no lado do servidor para evitar ataques CSRF. O lado do servidor verifica a origem da solicitação e determina a origem de destino da solicitação. Se eles corresponderem, a solicitação será permitida. Se houver uma incompatibilidade, o servidor descarta a solicitação.

Usar cabeçalhos referenciadores é muito mais fácil do que usar tokens porque não requer identificação individual do usuário.

Vulnerabilidades potenciais do cabeçalho do referenciador

Assim como os tokens CSRF, os cabeçalhos de referência têm algumas vulnerabilidades significativas.

Primeiro, os cabeçalhos referenciadores não são obrigatórios e alguns sites enviarão solicitações sem eles. Se o CSRF não tiver a política para lidar com solicitações sem cabeçalhos, os invasores podem usar solicitações sem cabeçalho para executar ataques de mudança de estado.

Além disso, esse método tornou-se menos eficaz com a recente introdução da política de referência. Essa especificação evita o vazamento de URL para outros domínios, dando aos usuários mais controle sobre as informações no cabeçalho do referenciador. Eles podem optar por expor parte das informações do cabeçalho do referenciador ou desativá-lo adicionando uma tag de metadados na página HTML, conforme mostrado abaixo:

 <meta name="referrer" content="no-referrer">

O código acima remove o cabeçalho do referenciador para todas as solicitações desta página. Fazer isso torna difícil para aplicativos que dependem de cabeçalhos de referência impedir ataques CSRF de tal página.

Como Kinsta Protege Contra Ataques CSRF

Além de usar o cabeçalho do referenciador e os tokens CSRF, há uma terceira opção muito mais fácil: escolher um serviço de hospedagem seguro como o Kinsta para seus sites e aplicativos da web fornece uma barreira muito mais forte e segura entre invasores e seus usuários.

Além dos recursos críticos de segurança, como backups automáticos, autenticação de dois fatores e protocolos SFTP sobre SSH, a integração Kinsta Cloudflare fornece proteção de nível empresarial com proteção baseada em IP e firewall.

Especificamente, Kinsta possui atualmente cerca de 60 regras de firewall personalizadas para ajudar a prevenir ataques maliciosos e lidar com vulnerabilidades graves não autenticadas em plugins e temas, incluindo algumas específicas que procuram vulnerabilidades CSRF.

Resumo

A falsificação de solicitação entre sites (CSRF) é um ataque que engana os usuários autenticados para que iniciem solicitações de alteração de estado involuntariamente. Eles visam aplicativos que não conseguem diferenciar entre solicitações de alteração de estado válidas e forjadas.

O CSRF só pode ser bem-sucedido em aplicativos que dependem de cookies de sessão para identificar usuários conectados e têm uma política de cookies SameSite fraca. Eles também precisam de um servidor que aceite solicitações que não contenham parâmetros desconhecidos, como senhas. Os hackers podem enviar ataques maliciosos usando GET ou POST.

Embora o uso de tokens CSRF ou a aplicação da verificação do cabeçalho do referenciador possa impedir alguns ataques CSRF, ambas as medidas têm vulnerabilidades potenciais que podem tornar suas medidas preventivas inúteis se você não for cuidadoso.

A migração para uma plataforma de hospedagem segura como a Kinsta protege seus sites ou aplicativos da web contra ataques CSRF. Além disso, a integração de Kinsta com Cloudflare impede ataques CSRF específicos.