CWE-352

A aplicação web não verifica, ou não consegue verificar suficientemente, se uma requisição foi fornecida intencionalmente pelo usuário que a enviou, a qual poderia ter se originado de um ator não autorizado.

Consequências comuns

• Confidencialidade, Integridade, Disponibilidade, Não Repúdio, Controle de Acesso → Obter Privilégios ou Assumir Identidade, Contornar Mecanismo de Proteção, Ler Dados da Aplicação, Modificar Dados da Aplicação, DoS: Travamento, Encerramento ou Reinicialização

Mitigações

• Arquitetura e Design: Use uma biblioteca ou framework validado que não permita que essa fraqueza ocorra ou que forneça construções que tornem essa fraqueza mais fácil de evitar [REF-1482]. Por exemplo, use pacotes anti-CSRF, como o OWASP CSRFGuard. [REF-330] Outro exemplo é o controle de gerenciamento de sessão do ESAPI, que inclui um componente para CSRF. [REF-45]
• Implementação: Garanta que a aplicação esteja livre de problemas de cross-site scripting (CWE-79), porque a maioria das defesas contra CSRF pode ser contornada usando scripts controlados pelo atacante.
• Arquitetura e Design: Gere um nonce único para cada formulário, coloque o nonce no formulário e verifique o nonce ao receber o formulário. Certifique-se de que o nonce não seja previsível (CWE-330). [REF-332]
• Arquitetura e Design: Identifique operações especialmente perigosas. Quando o usuário realizar uma operação perigosa, envie uma requisição de confirmação separada para garantir que o usuário realmente pretendia realizar aquela operação.
• Arquitetura e Design: Use o método do "cookie enviado em dobro" (double-submitted cookie), conforme descrito por Felten e Zeller: quando um usuário visita um site, o site deve gerar um valor pseudoaleatório e defini-lo como um cookie na máquina do usuário. O site deve exigir que cada envio de formulário inclua esse valor tanto como um valor de formulário quanto como um valor de cookie. Quando uma
• Arquitetura e Design: Não use o método GET para nenhuma requisição que dispare uma mudança de estado.