Impacto
A falsificação de solicitação entre sites (CSRF) permite que um invasor engane o navegador da vítima para que execute ações indesejadas em um site diferente onde a vítima está atualmente autenticada. Como os navegadores incluem automaticamente credenciais de ambiente, como cookies, nas solicitações, um invasor pode forjar operações de alteração de estado — como alterar senhas, excluir dados ou iniciar transações — sem o conhecimento do usuário.
Causa Raiz
A causa fundamental do CSRF é o comportamento padrão do navegador de enviar cookies associados a um domínio sempre que uma solicitação é feita a esse domínio, independentemente da origem da solicitação [S1]. Sem a validação específica de que uma solicitação foi acionada intencionalmente a partir da própria interface de usuário do aplicativo, o servidor não consegue distinguir entre uma ação legítima do usuário e uma ação forjada.
Mecanismos de proteção CSRF do Django
Django fornece um sistema de defesa integrado para mitigar esses riscos por meio de middleware e integração de modelos [S2].
Ativação de Middleware
O django.middleware.csrf.CsrfViewMiddleware é responsável pela proteção CSRF e normalmente é habilitado por padrão [S2]. Ele deve ser posicionado antes de qualquer middleware de visualização que presuma que ataques CSRF já foram tratados [S2].
Implementação de modelo
Para quaisquer formulários POST internos, os desenvolvedores devem incluir a tag {% csrf_token %} dentro do elemento <form> [S2]. Isso garante que um token secreto exclusivo seja incluído na solicitação, que o servidor valida na sessão do usuário.
Riscos de vazamento de token
Um detalhe crítico de implementação é que {% csrf_token %} nunca deve ser incluído em formulários direcionados a URLs externos [S2]. Fazer isso vazaria o token CSRF secreto para terceiros, comprometendo potencialmente a segurança da sessão do usuário [S2].
Defesa em nível de navegador: cookies SameSite
Os navegadores modernos introduziram o atributo SameSite para o cabeçalho Set-Cookie para fornecer uma camada de defesa profunda [S1].
- Estrito: O cookie é enviado apenas em um contexto primário, o que significa que o site na barra de URL corresponde ao domínio do cookie [S1].
- Lax: O cookie não é enviado em subsolicitações entre sites (como imagens ou frames), mas é enviado quando um usuário navega para o site de origem, como seguindo um link padrão [S1].
Como FixVibe testa isso
FixVibe agora inclui proteção CSRF como uma verificação ativa bloqueada. Após a verificação do domínio, active.csrf-protection inspeciona formulários de mudança de estado descobertos, verifica entradas em formato de token CSRF e sinais de cookie SameSite e, em seguida, tenta um envio de origem forjada de baixo impacto e somente reporta quando o servidor o aceita. As verificações de cookies também sinalizam atributos fracos do SameSite que reduzem a profundidade da defesa contra CSRF.