A01:2025 – Controle de Acesso Quebrado (Broken Access Control)

Contexto

Mantendo sua posição nº 1 no Top 10, foi constatado que 100% das aplicações testadas apresentavam alguma forma de controle de acesso quebrado. As CWEs notáveis incluídas são CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201: Exposure of Sensitive Information Through Sent Data, CWE-918 Server-Side Request Forgery (SSRF) e CWE-352: Cross-Site Request Forgery (CSRF). Esta categoria possui o maior número de ocorrências nos dados contribuídos e o segundo maior número de CVEs relacionadas.

Tabela de Pontuação

CWEs Mapeadas	Taxa Máx. de Incidência	Taxa Média de Incidência	Cobertura Máxima	Cobertura Média	Exploit Médio Ponderado	Impacto Médio Ponderado	Total de Ocorrências	Total de CVEs
40	20.15%	3.74%	100.00%	42.93%	7.04	3.84	1,839,701	32,654

Descrição

O controle de acesso aplica políticas para que os usuários não possam agir fora de suas permissões pretendidas. As falhas normalmente levam à divulgação não autorizada de informações, modificação ou destruição de todos os dados, ou à execução de uma função de negócio fora dos limites do usuário. Vulnerabilidades comuns de controle de acesso incluem:

Violação do princípio do menor privilégio (least privilege), comumente conhecido como "negar por padrão" (deny by default), onde o acesso deveria ser concedido apenas para capacidades, papéis ou usuários específicos, mas está disponível para qualquer pessoa.
Bypass de verificações de controle de acesso ao modificar a URL (manipulação de parâmetros ou navegação forçada), o estado interno da aplicação ou a página HTML, ou ao utilizar uma ferramenta de ataque que modifica requisições de API.
Permitir a visualização ou edição da conta de outra pessoa ao fornecer seu identificador exclusivo (IDOR – Insecure Direct Object References).
Uma API acessível com falta de controles de acesso para POST, PUT e DELETE.
Elevação de privilégio. Agir como um usuário sem estar logado ou obter privilégios além dos esperados para o usuário logado (ex: acesso de administrador).
Manipulação de metadados, como o reuso (replaying) ou adulteração de um token de controle de acesso JWT (JSON Web Token), um cookie ou campo oculto manipulado para elevar privilégios, ou abuso da invalidação de JWT.
Configuração incorreta de CORS que permite acesso à API a partir de origens não autorizadas ou não confiáveis.
Navegação forçada (force browsing ou adivinhação de URLs) para páginas autenticadas como um usuário não autenticado ou para páginas privilegiadas como um usuário comum.

Como Prevenir

O controle de acesso só é eficaz quando implementado em código confiável no lado do servidor ou em APIs serverless, onde o atacante não pode modificar a verificação de controle de acesso ou os metadados.

Exceto para recursos públicos, negue por padrão (deny by default).
Implemente mecanismos de controle de acesso uma única vez e reutilize-os em toda a aplicação, incluindo a minimização do uso de Cross-Origin Resource Sharing (CORS).
Os modelos de controle de acesso devem reforçar a propriedade do registro, em vez de permitir que os usuários criem, leiam, atualizem ou excluam qualquer registro.
Requisitos exclusivos de limites de negócio da aplicação devem ser impostos por modelos de domínio.
Desative a listagem de diretórios do servidor web e garanta que metadados de arquivos (ex: .git) e arquivos de backup não estejam presentes nas raízes web (web roots).
Registre (log) falhas de controle de acesso e alerte os administradores quando apropriado (ex: falhas repetidas).
Implemente limites de taxa (rate limits) no acesso a APIs e controladores para minimizar o dano causado por ferramentas de ataque automatizadas.
Identificadores de sessão com estado (stateful) devem ser invalidados no servidor após o logout. Tokens JWT sem estado (stateless) devem ter vida curta para minimizar a janela de oportunidade para um atacante. Para JWTs de longa duração, considere o uso de refresh tokens e siga os padrões OAuth para revogar o acesso.
Utilize conjuntos de ferramentas (toolkits) ou padrões bem estabelecidos que forneçam controles de acesso simples e declarativos.

Desenvolvedores e equipes de QA devem incluir testes funcionais de controle de acesso em seus testes unitários e de integração.

Exemplos de Cenários de Ataque

Cenário #1: A aplicação utiliza dados não verificados em uma chamada SQL que acessa informações da conta:

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

Um atacante pode simplesmente modificar o parâmetro 'acct' no navegador para enviar qualquer número de conta desejado. Se não for corretamente verificado, o atacante pode acessar a conta de qualquer usuário.

https://example.com/app/accountInfo?acct=notmyacct

Cenário #2: Um atacante simplesmente força a navegação para URLs alvo. Direitos de administrador são necessários para acessar a página administrativa.

https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

Se um usuário não autenticado conseguir acessar qualquer uma das páginas, trata-se de uma falha. Se um não-administrador conseguir acessar a página de administração, isso também é uma falha.

Cenário #3: Uma aplicação coloca todo o seu controle de acesso no front-end. Embora o atacante não consiga chegar a [https://example.com/app/admin_getappInfo](https://example.com/app/admin_getappInfo) devido ao código JavaScript executado no navegador, ele pode simplesmente executar:

$ curl https://example.com/app/admin_getappInfo

a partir da linha de comando.