A01:2021 – Quebra de Controle de Acesso

Fatores

CWEs Mapeados	Taxa de Incidência Máxima	Taxa de Incidência Média	Exploração Média Ponderada	Impacto Médio Ponderado	Cobertura Máxima	Cobertura Média	Total de ocorrências	Total de CVEs
34	55.97%	3.81%	6.92	5.93	94.55%	47.72%	318,487	19,013

Visão Geral

Saindo da quinta posição, 94% dos aplicativos foram testados para alguma forma de controle de acesso quebrado com a taxa de incidência média de 3,81% e tem o maior número de ocorrências no conjunto de dados contribuído com mais de 318 mil. Notável Common Weakness Enumerations (CWEs) incluídas são CWE-200: Exposição de Informações Confidenciais a um Ator Não Autorizado, CWE-201: Exposição de Informações Confidenciais por meio de Dados Enviados e CWE-352: requisições forjadas entre sites.

Descrição

O controle de acesso impõe a política de modo que os usuários não possam agir fora de suas permissões pretendidas. As falhas normalmente levam à divulgação, modificação ou destruição de informações não autorizadas de todos os dados ou ao desempenho de uma função comercial fora dos limites do usuário. Vulnerabilidades comuns de controle de acesso incluem:

Violação do princípio de privilégio mínimo ou negação por padrão, onde o acesso deve ser concedido apenas para determinados recursos, funções ou usuários, mas está disponível para qualquer pessoa.
Ignorar verificações de controle de acesso modificando a URL (adulteração de parâmetros ou navegação forçada), o estado interno do aplicativo, a página HTML ou usando uma ferramenta de ataque que modifica as requisições de API.
Permitir a visualização ou edição da conta de outrem, mediante a disponibilização do seu identificador único (referências diretas não seguras a objetos).
Acessando API sem controles de acesso para POST, PUT e DELETE.
Elevação de privilégio. Agir como um usuário sem estar logado ou agir como um administrador quando logado como um usuário.
Manipulação de metadados, como reproduzir ou adulterar um token de controle de acesso JSON Web Token (JWT), um cookie ou campo oculto manipulado para elevar privilégios ou abusar da invalidação de JWT.
A configuração incorreta do CORS permite o acesso à API de origens não autorizadas / não confiáveis.
Força a navegação para páginas autenticadas como um usuário não autenticado ou para páginas privilegiadas como um usuário padrão.

Como Prevenir

O controle de acesso só é eficaz em código confiável do lado do servidor ou API sem servidor, em que o invasor não pode modificar a verificação de controle de acesso ou metadados.

Exceto para recursos públicos, negar por padrão.
Implemente mecanismos de controle de acesso uma vez e reutilize-os em todo o aplicativo, incluindo a minimização do uso de Cross-Origin Resource Sharing (CORS).
Os controles de acesso ao modelo devem impor a propriedade do registro em vez de aceitar que o usuário possa criar, ler, atualizar ou excluir qualquer registro.
Os requisitos de limite de negócios de aplicativos exclusivos devem ser impostos por modelos de domínio.
Desative a lista de diretórios do servidor da web e certifique-se de que os metadados do arquivo (por exemplo, o .git) e os arquivos de backup não estejam presentes nas raízes da web (web roots).
Registrar falhas de controle de acesso e alertar os administradores quando apropriado (por exemplo, falhas repetidas).
Limite de taxa o acesso da API e do controlador para minimizar os danos do conjunto de ferramentas de ataque automatizado.
Os identificadores de sessão com estado devem ser invalidados no servidor após o logout. Os tokens JWT sem estado devem ter vida curta, para que a janela de oportunidade para um invasor seja minimizada. Para JWTs de longa duração, é altamente recomendável seguir os padrões OAuth para revogar o acesso.

Os desenvolvedores e a equipe de QA devem incluir uma unidade de controle de acesso funcional e testes de integração.

Exemplos de Cenários de Ataque

Cenário #1: O aplicativo usa dados não verificados em uma chamada SQL que está acessando informações da conta:

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

Um invasor simplesmente modifica o parâmetro 'acct' do navegador para enviar o número de conta que desejar. Se não for verificado corretamente, o invasor pode acessar a conta de qualquer usuário.

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

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

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

Se um usuário não autenticado pode acessar qualquer página, é uma falha. Se um não administrador pode acessar a página de administração, isso é uma falha.