Imagine o seguinte cenário: você está construindo uma aplicação web bacana que usa a Push API do navegador para enviar notificações para quem utiliza a nossa aplicação.
Tudo está indo bem, até que você se depara com uma sigla que pode virar seu maior pesadelo: CSRF, ou Cross-Site Request Forgery (que significa falsificação de requisições entre sites, em tradução livre).
Esse ataque sorrateiro pode fazer sua aplicação executar ações indesejadas sem que a pessoa usuária saiba, comprometendo toda a segurança do sistema. E quando a Push API entra em cena, a atenção precisa ser redobrada.
Neste artigo, vamos falar sobre o que é CSRF (ou XSRF, se preferir), como essa vulnerabilidade pode afetar sua aplicação, especialmente ao utilizar a Push API, e, claro, como você pode se proteger dessa ameaça.
Vamos explorar os pontos de atenção essenciais para garantir que suas notificações push não sejam uma porta de entrada para ataques.
Se você quer entender como evitar que seu sistema caia em armadilhas perigosas, continue com a gente, porque a seguir, vamos desmembrar tudo isso e muito mais.
O que é CSRF?
Para entender o que é CSRF, vamos começar com uma história real. Em 2008, um famoso site de redes sociais enfrentou um problema grave.
Um desenvolvedor mal-intencionado criou uma página na qual, ao visitar, as pessoas logadas na rede social executavam ações indesejadas sem perceber.
Isso incluía adicionar amigos, seguir contas e até enviar mensagens. Tudo isso acontecia sem que o(a) usuário(a) precisasse clicar em nada ou sequer saber que estava realizando essas ações.
Quando o(a) usuário(a) estava logado na rede social, o navegador dele armazenava um cookie de sessão, que era usado para identificar o(a) usuário(a) e autorizar ações em seu nome.
O atacante, sabendo disso, criou uma página maliciosa que fazia requisições ao site da rede social, mas sem que o(a) usuário(a) percebesse.
Como o navegador automaticamente enviava o cookie de sessão em cada requisição, o servidor da rede social pensava que essas requisições eram legítimas e feitas pelo próprio usuário(a).
Na prática, CSRF é um ataque que aproveita essa confiança do navegador e do servidor.
O atacante induz o usuário(a) a fazer uma requisição a um site onde ele já está autenticado, mas essa requisição faz algo que o usuário(a) não queria.
Por exemplo, no caso que contamos, adicionar amigos ou seguir contas sem permissão.
Isso é muito perigoso porque explora a maneira como navegadores e servidores funcionam, tirando proveito do fato de que o navegador envia automaticamente cookies de sessão em requisições.
E como essas requisições parecem legítimas para o servidor, ele as processa, acreditando que foram feitas pelo usuário(a).
Depois de entender o que é CSRF e o perigo que ele representa, a próxima pergunta natural é: como se proteger?
Felizmente, existem várias estratégias para evitar que sua aplicação seja vítima desse tipo de ataque. Em seguida, vamos dar uma olhada nas principais formas de proteção e como elas funcionam.
Tokens Anti-CSRF
Uma das maneiras mais comuns de se proteger contra CSRF é utilizando tokens anti-CSRF. O conceito é simples: para cada ação sensível que o(a) usuário(a) tenta realizar, como enviar um formulário, o servidor gera um token único e o envia ao cliente.
Esse token é armazenado no frontend e enviado de volta ao servidor junto com a requisição. Quando o servidor recebe a requisição, ele verifica se o token enviado corresponde ao que foi gerado. Se não bater, a requisição é rejeitada.
Por que isso funciona? O atacante não consegue obter o token válido, pois ele é gerado dinamicamente pelo servidor e enviado apenas para o cliente.
Mesmo que o atacante consiga fazer o navegador da pessoa usuária enviar uma requisição maliciosa, ele não terá o token correto, e o servidor vai bloquear a ação.
SameSite Cookies
Outra abordagem é configurar os cookies com a flag SameSite. Isso instrui o navegador a não enviar cookies de sessão em requisições que vêm de um domínio diferente do domínio do site. Existem três níveis para essa configuração: Strict, Lax, e None.
O nível Strict garante que os cookies só sejam enviados quando a pessoa usuária estiver navegando diretamente no site, bloqueando qualquer tentativa de envio de cookies a partir de requisições de outros sites.
O Lax é um pouco mais permissivo, permitindo o envio de cookies em alguns casos, como requisições GET que resultam em navegação no site original.
Já o None permite o envio de cookies para qualquer requisição, mas isso é menos seguro.
Essa técnica é útil porque impede que cookies de sessão sejam enviados em cenários onde CSRF poderia ocorrer, como quando a pessoa usuária clica em um link malicioso em um e-mail ou em outro site.
Conclusão
Agora que você tem uma boa noção de como se proteger contra CSRF, é importante entender como isso se conecta com o uso da Push API. Quando utilizamos a Push API para enviar notificações aos usuários(as), precisamos garantir que as requisições feitas no backend estejam seguras e livres de vulnerabilidades.
Como as notificações push podem acionar ações dentro da aplicação, garantir que essas ações sejam legítimas e seguras é super importante para manter a integridade da aplicação e proteger as pessoas usuárias dos ataques maliciosos.
Se você curtiu o assunto e quer se aprofundar no uso da Push API e aprender a implementar notificações push, você pode dar uma olhada no curso React: implemente notificações push e sincronização em background do Neilton. Esse curso vai te ajudar a dominar essas funcionalidades e a integrar tudo com segurança na sua aplicação. Vamos lá?
