A07:2025 Falhas de Autenticação

Contexto

Falhas de Autenticação mantém sua posição em #7 com uma leve mudança no nome para refletir com mais precisão as 36 CWEs nesta categoria. Apesar dos benefícios de frameworks padronizados, esta categoria manteve sua classificação de 2021. CWEs notáveis incluídas são CWE-259 Use of Hard-coded Password, CWE-297: Improper Validation of Certificate with Host Mismatch, CWE-287: Improper Authentication, CWE-384: Session Fixation e CWE-798 Use of Hard-coded Credentials.

Tabela de pontuação

CWEs Mapeadas	Taxa Máx. de Incidência	Taxa Méd. de Incidência	Cobertura Máxima	Cobertura Média	Exploit Ponderado Médio	Impacto Ponderado Médio	Total de Ocorrências	Total de CVEs
36	15,80%	2,92%	100,00%	37,14%	7,69	4,44	1.120.673	7.147

Descrição

Esta vulnerabilidade está presente quando um atacante é capaz de enganar um sistema para reconhecer um usuário inválido ou incorreto como legítimo. Pode haver fraquezas de autenticação se a aplicação:

Permite ataques automatizados, como credential stuffing, onde o atacante possui uma lista vazada de nomes de usuário e senhas válidos. Recentemente, esse tipo de ataque foi expandido para incluir ataques de senha híbridos (também conhecidos como ataques de password spray), onde o atacante usa variações ou incrementos de credenciais vazadas para ganhar acesso — por exemplo, tentando Password1!, Password2!, Password3! e assim por diante.
Permite brute force ou outros ataques automatizados por scripts que não são bloqueados rapidamente.
Permite senhas padrão, fracas ou bem conhecidas, como o nome de usuário "admin" com a senha "admin" ou a senha "Password1".
Permite que usuários criem novas contas com credenciais que já se sabe terem sido comprometidas em vazamentos.
Permite o uso de processos de recuperação de credenciais e "esqueci minha senha" fracos ou ineficazes, como "perguntas baseadas em conhecimento", que não podem ser tornadas seguras.
Usa repositórios de dados de senhas em texto puro, criptografados ou com hashes fracos (veja A04:2025-Falhas Criptográficas).
Possui autenticação multifator (MFA) ausente ou ineficaz.
Permite o uso de fallbacks fracos ou ineficazes caso a autenticação multifator não esteja disponível.
Expõe o identificador de sessão na URL, em um campo oculto ou em outro local inseguro que seja acessível ao cliente.
Reutiliza o mesmo identificador de sessão após um login bem-sucedido.
Não invalida corretamente as sessões de usuário ou tokens de autenticação (principalmente tokens de Single Sign-On (SSO)) durante o logout ou após um período de inatividade.
Não valida corretamente o escopo e o público-alvo (audience) das credenciais fornecidas.

Como prevenir

Sempre que possível, implemente e force o uso de autenticação multifator (MFA) para prevenir credential stuffing automatizado, brute force e ataques de reutilização de credenciais roubadas.
Sempre que possível, incentive e habilite o uso de gerenciadores de senhas para ajudar os usuários a fazerem escolhas melhores.
Não envie ou implante o sistema com credenciais padrão, particularmente para usuários administradores.
Implemente verificações de senhas fracas, como testar senhas novas ou alteradas contra uma lista das 10.000 piores senhas.
Durante a criação de novas contas e alterações de senha, valide-as contra listas de credenciais conhecidas como vazadas (ex: usando haveibeenpwned.com).
Alinhe as políticas de comprimento, complexidade e rotação de senhas com as diretrizes do National Institute of Standards and Technology (NIST) 800-63b, seção 5.1.1 para Segredos Memorizados ou outras políticas de senha modernas baseadas em evidências.
Não force seres humanos a rotacionar senhas, a menos que você suspeite de uma violação. Se suspeitar de violação, force a redefinição de senha imediatamente.
Garanta que as rotas de registro, recuperação de credenciais e caminhos de API sejam endurecidos contra ataques de enumeração de contas, usando as mesmas mensagens para todos os resultados ("Nome de usuário ou senha inválidos.").
Limite ou atrase progressivamente as tentativas de login malsucedidas, mas tome cuidado para não criar um cenário de negação de serviço (DoS). Registre todas as falhas em logs e alerte os administradores quando ataques de credential stuffing, brute force ou outros forem detectados ou suspeitos.
Use um gerenciador de sessão seguro e nativo no lado do servidor que gere um novo ID de sessão aleatório com alta entropia após o login. Identificadores de sessão não devem estar na URL, devem ser armazenados de forma segura em um cookie seguro e invalidados após logout, inatividade e expiração absoluta (timeout).
Idealmente, use um sistema pronto e bem estabelecido para lidar com autenticação, identidade e gerenciamento de sessão. Transfira esse risco sempre que possível, comprando e utilizando um sistema testado e endurecido.
Verifique o uso pretendido das credenciais fornecidas; por exemplo, para JWTs, valide as claims aud, iss e os escopos.

Exemplos de cenários de ataque

Cenário #1: O credential stuffing — o uso de listas de combinações conhecidas de nomes de usuário e senhas — é agora um ataque muito comum. Mais recentemente, descobriu-se que atacantes "incrementam" ou ajustam senhas com base no comportamento humano comum. Por exemplo, alterando 'Winter2025' para 'Winter2026', ou 'ILoveMyDog6' para 'ILoveMyDog7'. Esse ajuste de tentativas de senha é chamado de ataque de credential stuffing híbrido ou ataque de password spray, e eles podem ser ainda mais eficazes do que a versão tradicional. Se uma aplicação não implementa defesas contra ameaças automatizadas (brute force, scripts ou bots) ou credential stuffing, a aplicação pode ser usada como um "oráculo de senhas" para determinar se as credenciais são válidas e obter acesso não autorizado.

Cenário #2: A maioria dos ataques de autenticação bem-sucedidos ocorre devido ao uso contínuo de senhas como o único fator de autenticação. Outrora consideradas melhores práticas, as exigências de rotação e complexidade de senhas encorajam os usuários tanto a reutilizar senhas quanto a usar senhas fracas. Recomenda-se que as organizações interrompam essas práticas conforme a norma NIST 800-63 e forcem o uso de autenticação multifator em todos os sistemas importantes.

Cenário #3: Os tempos de expiração de sessão (timeouts) da aplicação não estão implementados corretamente. Um usuário utiliza um computador público para acessar uma aplicação e, em vez de selecionar "logout", simplesmente fecha a aba do navegador e vai embora. Outro exemplo é quando uma sessão de Single Sign-On (SSO) não pode ser encerrada por um Single Logout (SLO). Ou seja, um único login autentica você no seu leitor de e-mails, sistema de documentos e sistema de chat, por exemplo. Mas o logout acontece apenas no sistema atual. Se um atacante usar o mesmo navegador após a vítima pensar que deslogou com sucesso, mas ainda estiver autenticada em algumas das aplicações, ele poderá acessar a conta da vítima. O mesmo problema pode ocorrer em escritórios e empresas quando uma aplicação sensível não foi devidamente encerrada e um colega tem acesso (temporário) ao computador desbloqueado.