PedidosSemEstresse é uma aplicação Web destinada a digitalizar o processo de pedidos de serviços de um órgão da administração pública. A interface de PedidosSemEstresse utilizada pelos usuários faz chamadas a uma API RESTful e não utiliza facilidades de login único (single sign-on – SSO). Recentemente, o usuário interno João utilizou suas próprias credenciais com privilégios somente de execução de métodos GET para explorar vulnerabilidades e teve acesso direto a API RESTful. Assim, João fez chamadas a métodos POST com sucesso. Com base no OWASP Top Ten, a vulnerabilidade explorada por João é da categoria:
- A)Injection;
Injeção seria algo como SQL Injection ou command injection, quando dados maliciosos alteram a execução de comandos, o que não foi o caso aqui.
- B)Broken Access Control;
Correta: João burlou a regra de autorização e executou um método POST sem ter permissão para isso, caracterizando falha de controle de acesso.
- C)Software and Data Integrity Failures;
Falhas de integridade de software e dados envolvem adulteração de atualizações, dependências ou artefatos, o que não aparece no enunciado.
- D)Vulnerable and Outdated Components;
Componentes vulneráveis e desatualizados tratam de bibliotecas, frameworks ou serviços com falhas conhecidas, e não de permissão indevida de acesso.
- E)Identification and Authentication Failures
Falhas de identificação e autenticação envolvem problemas para provar a identidade do usuário, mas João já estava autenticado e o erro foi na autorização.
Gabarito: B
A questão descreve um caso clássico de quebra de controle de acesso. João tinha permissão apenas para executar métodos GET, mas conseguiu acessar a API diretamente e passou a fazer chamadas POST com sucesso. Em outras palavras, ele burlou a autorização que limitava o que o usuário podia fazer. Isso é exatamente o tipo de falha que o OWASP Top Ten chama de Broken Access Control. Pense assim: autenticar é provar quem você é; autorizar é dizer o que você pode fazer. Aqui, João já estava autenticado com suas credenciais, mas o sistema falhou em impedir que ele executasse uma ação fora do seu perfil de permissões. Quando a aplicação ou a API não valida corretamente o papel do usuário, o método, o recurso ou o objeto acessado, nasce a vulnerabilidade. No OWASP Top Ten, Broken Access Control é uma das categorias mais cobradas porque aparece em vários cenários: acesso direto a endpoints, manipulação de URLs, troca de IDs, uso de métodos HTTP indevidos e falta de checagem no backend. A regra de ouro é simples: não basta esconder botão na tela. O servidor precisa conferir a permissão de verdade. Por isso o gabarito é a letra B. João não sofreu um problema de senha, nem de componente desatualizado, nem de injeção. O problema foi que ele conseguiu fazer algo que seu perfil não permitia. O controle existia no papel, mas falhou na prática, e isso é o coração de Broken Access Control.