Controle de Acesso Quebrado A Vulnerabilidade Nº 1 da OWASP

Esta aplicação interativa explora a A01:2021-Broken Access Control, a falha de segurança mais prevalente e crítica em aplicações web modernas. Navegue pelas seções para entender, identificar e mitigar este risco fundamental.

Nº 1

Risco na OWASP Top 10 2021

94%

Das aplicações testadas apresentaram esta falha

Autorização

A essência do problema está em "o que você pode fazer"

Prevalência das Vulnerabilidades (Dados Ilustrativos)

Broken Access Control se destaca como a categoria com a maior incidência, afetando a grande maioria das aplicações.

Entendendo os Ataques

Falhas de controle de acesso se manifestam de duas formas principais: escalada vertical e horizontal. Explore os exemplos interativos abaixo para ver como elas funcionam.

Escalada de Privilégios Vertical (Subir na Hierarquia)

Ocorre quando um usuário comum obtém acesso a funcionalidades de um usuário com privilégios mais altos, como um administrador.

Exemplo: Navegação Forçada (Forced Browse)

Um usuário comum, após o login, digita uma URL de administrador diretamente no navegador.

https://app.exemplo.com/

O usuário tenta adivinhar o caminho para o painel de administração:

https://app.exemplo.com/

Resultado da Falha:

Se não houver uma verificação de permissão no backend para a rota `/admin`, o usuário obtém acesso total ao painel administrativo, podendo visualizar dados de todos os usuários, alterar configurações e mais.

O Manual do Defensor

Construir um controle de acesso robusto se baseia em princípios de segurança fundamentais. Estes são os pilares que devem sustentar sua arquitetura.

🛡️

Menor Privilégio (PoLP)

Conceda a cada usuário ou processo apenas as permissões mínimas necessárias para executar sua tarefa. Nada mais.

Negar por Padrão

Se uma permissão não for explicitamente concedida, o acesso deve ser negado. A segurança deve ser um opt-in.

🖥️

Validação no Servidor

Toda decisão de controle de acesso deve ser validada no backend. A segurança no cliente é apenas UX, não uma barreira real.

⚙️

Modelos de Acesso

Use modelos como RBAC (Baseado em Papéis) ou ABAC (Baseado em Atributos) para gerenciar permissões de forma escalável.

Análise por Tecnologia

Cada framework e linguagem tem suas próprias armadilhas e melhores práticas. Selecione uma tecnologia para ver vulnerabilidades comuns e como mitigá-las.

Como Encontrar Falhas

A identificação de falhas de acesso requer uma combinação de testes manuais e automação. Explore as principais técnicas abaixo.

Testes Manuais (Pentest)

É a forma mais eficaz, pois um humano entende a lógica do negócio.

  • Manipulação de IDs e Parâmetros (IDOR): Alterar sistematicamente todos os IDs em URLs e requisições para tentar acessar dados de outros usuários.
  • Navegação Forçada: Tentar acessar URLs que não são linkadas na UI, como `/admin`, `/backup`, ou arquivos como `.git/config`.
  • Adulteração de Tokens JWT: Decodificar o token, alterar o payload (ex: `role: 'user'` para `role: 'admin'`) e reenviá-lo, esperando que o servidor não valide a assinatura.
  • Manipulação de Cookies e Verbos HTTP: Alterar cookies de permissão no navegador ou tentar verbos HTTP diferentes (`PUT`, `DELETE`) em endpoints protegidos contra `GET`/`POST`.

Limitações do SAST & DAST

Ferramentas automatizadas falham em entender o contexto.

Broken Access Control é uma vulnerabilidade de lógica de negócio. Uma ferramenta DAST pode ver que `GET /faturas/123` e `GET /faturas/124` retornam `200 OK`, mas ela não sabe que o usuário logado só deveria ter permissão para ver a fatura 123.

Elas podem ajudar a encontrar a ausência de uma chamada de controle de acesso, mas não conseguem validar se a lógica, quando presente, está correta. São um complemento, não um substituto para testes manuais.

Revisão de Código Segura (Checklist)

A revisão de código por pares é uma das defesas mais eficazes. O que procurar:

  • Validação em TODA Requisição: Cada endpoint protegido tem uma verificação de autorização explícita?
  • Lógica Centralizada: A lógica de permissão está em um middleware/biblioteca reutilizável ou espalhada pela aplicação?
  • Uso de IDs: Queries ao banco de dados filtram pelo ID do objeto E pelo ID do usuário logado? (`WHERE id = ? AND owner_id = ?`)
  • Manipulação de JWTs: O código usa `jwt.verify()` (seguro) ou `jwt.decode()` (inseguro)?
  • Tratamento de Erros: Blocos `catch` negam o acesso por padrão?