Cibersegurança e segurança da informação

Broken Access Control: Como testar permissões numa aplicação

6 min de leituraPublicado: 5 de agosto de 2026

Representação visual profissional sobre o teste de Broken Access Control na área de Web e API PT

Resposta rápida

O teste de Broken Access Control é realizado apenas em laboratório ou num sistema autorizado. São verificados o Request/Response, o comportamento do servidor, Roles, State e o impacto, utilizando testes mínimos que não danificam os dados.

Os testes de segurança Web e API devem examinar os limites de confiança, permissões, entrada, State e lógica de negócios. Todos os testes neste artigo destinam-se a laboratórios, CTF ou sistemas para os quais foi dada autorização explícita. O presente artigo foca-se no teste de Broken Access Control e destina-se a estudantes de Web PT e desenvolvedores. O objetivo é fornecer um método de trabalho que possa ser aplicado em prática, numa entrevista profissional e num ambiente de trabalho, sem se limitar a uma definição de dicionário.

O principal desafio é que os dados são quase sempre parciais. Uma matriz de funções, identificadores de objetos e autorização do lado do servidor podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, vamos construir o teste em torno de uma questão de investigação, evidências necessárias e um critério claro para a conclusão.

O cenário prático no artigo é: matriz de permissões para uma aplicação de laboratório. Todos os exemplos são dados de laboratório ou descrições de processos. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, um Scope definido e a capacidade de parar o teste.

Modelo de Permissões

No teste de Broken Access Control, identidade e autorização são duas questões distintas: quem é o cliente e o que lhe é permitido fazer no recurso. São verificados Roles, Claims, Session, Object ownership e alterações ao longo do ciclo de vida, não se contentando com o facto de o utilizador estar 'logado'.

Uma matriz de teste inclui um utilizador anónimo, um utilizador normal, um proprietário de objeto, outro utilizador e um administrador. Para cada operação, são comparados a Response e o impacto no lado do servidor. A alteração de um identificador ou Header é apenas um meio de teste; a evidência é que o servidor aprovou ou rejeitou uma ação contrariamente à política.

Horizontal vs. Vertical

Para entender a diferença no contexto do teste de Broken Access Control, é importante comparar objetivos e não apenas ferramentas. Uma opção oferece largura ou velocidade, e outra oferece validação profunda ou contexto. A escolha correta depende da pergunta: é necessária descoberta, investigação, prova de impacto, contenção ou relatório.

Uma tabela de comparação profissional deve incluir pelo menos: tipo de entrada, nível de certeza, custo operacional, impacto possível, limitações e acompanhamento necessário. Em caso de dúvida, usa-se a abordagem menos invasiva e adiciona-se uma fonte complementar em vez de tirar uma conclusão demasiado ampla.

Testar Endpoints e Ações

O tópico 'Testar Endpoints e Ações' é uma parte central do trabalho no teste de Broken Access Control. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de uma ferramenta sem entender o objetivo.

Na prática, anote a matriz de funções, identificadores de objetos, autorização do lado do servidor, acesso horizontal/vertical, diferenças de resposta, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Evidência e Risco

O tópico 'Evidência e Risco' é uma parte central do trabalho no teste de Broken Access Control. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de uma ferramenta sem entender o objetivo.

Remediação e Reteste

Um teste profissional para Broken Access Control começa com condições de sucesso e falha. Definem-se um Caso positivo, um Caso negativo, um Caso limite e uma atividade legítima semelhante. Desta forma, podem ser identificados tanto False Negative quanto False Positive.

Num ambiente autorizado, usa-se uma ação mínima que prove a alegação sem causar danos. Guardam-se Input, Output, tempo e versão, e após a correção, realiza-se um Reteste no mesmo cenário e verifica-se também a Regressão em funções próximas.

Pontos de Teste Únicos

Neste tópico, recomenda-se construir antecipadamente um mapa de evidências focado. Os principais pontos de teste são: matriz de funções, identificadores de objetos, autorização do lado do servidor, acesso horizontal/vertical, diferenças de resposta, registos de auditoria. A lista não é um Checklist automático; cada item é selecionado porque pode ligar uma entidade, ação e tempo ou explicar um comportamento legítimo.

matriz de funções: Defina o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.
identificadores de objetos: Defina o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.
autorização do lado do servidor: Defina o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.
acesso horizontal/vertical: Defina o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.
diferenças de resposta: Defina o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.
registos de auditoria: Defina o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.

Quando um dos pontos focais não está disponível, a lacuna deve ser documentada e uma alternativa escolhida. Por exemplo, se o identificador de processo não for estável, pode-se usar tempo, Host, User e Parent; se o Payload for encriptado, usam-se Metadados, volume, frequência e contexto TLS/DNS.

Processo de Trabalho Recomendado

Defina o Scope e uma questão de trabalho sobre Broken Access Control.
Registe as fontes de dados e as evidências necessárias: matriz de funções, identificadores de objetos, autorização do lado do servidor, acesso horizontal/vertical.
Crie uma Baseline curta de comportamento normal ou resultado esperado.
Execute o teste mínimo num ambiente de laboratório e guarde tempo, entrada e saída.
Crie um Timeline ou uma tabela de comparação e separe facto de interpretação.
Realize um Pivot para outra fonte para verificar ou refutar a explicação inicial.
Conclua uma decisão, limitações, ação recomendada e critério de Reteste.

Cenário Prático

O cenário escolhido é uma matriz de permissões para uma aplicação de laboratório. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, definem-se dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve ser apresentado um produto que outro analista ou testador possa criticar: uma captura de ecrã ou Export da evidência, um Timeline curto, uma suposição inicial, uma evidência de validação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Fase	O que é executado	Produto
Preparação	Defina Scope, tempo e objetivo. Anote quais campos ou evidências da matriz de funções, identificadores de objetos, autorização do lado do servidor devem aparecer.	Plano de teste curto
Criação de dados	Execute uma ação segura e simulada relacionada com o teste de Broken Access Control, sem informações reais ou impacto num sistema de produção.	Evento/Request/Fluxo controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique fuso horário, identificadores e integridade.	Duas evidências relacionadas
Análise	Escreva o que cada evidência prova, o que não prova e qual é a explicação legítima possível.	Conclusão provisória
Conclusão	Escolha fechar, escalar, Finding ou Tuning; adicione recomendação e Reteste.	Produto documentado

Checklist Prático

Verifique e documente: Role e sessão.
Verifique e documente: Endpoint e método.
Verifique e documente: Request/Response.
Verifique e documente: Object identifier.
Verifique e documente: Server-side effect.
Verifique e documente: Control expected e remediation.
Indique o fuso horário, a versão da ferramenta e a hora da recolha.
Guarde os dados brutos antes de filtrar ou modificar.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina o proprietário e a ação de acompanhamento com uma data.

Erros Comuns

Verificar apenas o Status code.
Depender de alterações do lado do cliente.
Usar um Payload perigoso.
Não testar Roles diferentes.
Ignorar a lógica de negócios.
Reportar sem Request/Response limpos.

Resumo e CTA

Broken Access Control: Como testar permissões numa aplicação é um tópico que conecta conhecimento técnico com disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e retestada.

No curso de Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, logs e laboratórios. O passo seguinte natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portefólio profissional.

Perguntas frequentes

É permitido testar Broken Access Control num site público?

Não, sem autorização explícita do proprietário do sistema. Mesmo um teste que pareça simples pode alterar dados, ativar mecanismos de defesa ou ser considerado acesso não autorizado.

O que fazer quando faltam alguns dados?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não preencha campos por suposição nem apresente 'Unknown' como correto.

Quanto tempo as evidências devem ser mantidas?

O tempo depende da política, regulamentação, custo e tipo de evento. É importante definir antecipadamente a Retenção, Legal hold e a capacidade de exportar evidências num formato verificável.

Como praticar sem colocar em risco um sistema real?

Use máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina o Scope, Stop conditions e faça backup antes de iniciar o trabalho.