ANÚNCIO

~/questoes/ciberseguranca

Qual é uma característica comum de pressupostos frágeis em controle de acesso?

Responda, confira o feedback e use o resultado para orientar sua revisão.
Aula de referência TryHackMe OWASP Top 10 2025: falhas de design de aplicação
Para fixar

Pressupostos Frágeis em Controle de Acesso

Conceito central

Pressupostos frágeis são decisões de design que assumem segurança sem implementar verificações explícitas. Um exemplo clássico é acreditar que usuários comuns nunca conseguirão alcançar URLs administrativas apenas porque não estão visíveis na interface, sem protegê-las com validações reais no servidor.

Por que essa resposta faz sentido

A alternativa está correta porque identifica exatamente o padrão de pressupostos frágeis: acreditar que a restrição funciona sem verificá-la de fato. Quando a aplicação não valida permissões no servidor, um atacante pode simplesmente digitar a URL administrativa diretamente ou modificar requisições para contornar essa falsa proteção.

Armadilhas comuns

  • Confundir pressupostos frágeis com implementações fracas de autenticação. Pressupostos frágeis são sobre lógica de autorização inadequada, enquanto autenticação é sobre verificar quem você é.
  • Pensar que ocultar recursos (como URLs administrativas) é o mesmo que protegê-los. Qualquer pessoa com ferramentas básicas pode descobrir URLs ou manipular requisições.
  • Acreditar que porque a interface não oferece acesso, o backend também nega automaticamente. O servidor sempre precisa validar, independentemente do que a interface mostra.

Entenda as alternativas

A

Descreve o cerne dos pressupostos frágeis: confiar em segurança por obscuridade sem controles reais. A aplicação parece segura porque usuários normais não veem o link administrativo, mas não há verificação de permissões implementada, permitindo acesso direto.

B

Tokens JWT com expiração curta é uma prática de segurança sólida para gestão de sessão, não um exemplo de pressupostos frágeis. Isso representa verificação explícita e renovação automática, que é o oposto do que pressupostos frágeis fazem.

C

Verificar permissões em cada operação sensível é exatamente o que você deve fazer para evitar pressupostos frágeis. Essa é uma prática defensiva correta, não uma característica de pressupostos frágeis.

D

Certificados SSL protegem a comunicação entre cliente e servidor (confidencialidade em trânsito), mas não resolvem problemas de controle de acesso ou pressupostos frágeis sobre quem pode fazer o quê dentro da aplicação.

Dica prática: Sempre implemente validações de permissão no servidor (backend), nunca confie apenas em restrições de interface. Use um padrão como: antes de qualquer operação sensível, verifique explicitamente se o usuário logado tem a permissão necessária para aquela ação, consultando seu papel ou privilégios armazenados.

Revise pensando: Se você conseguisse acessar diretamente uma URL administrativa digitando na barra de endereços, qual seria a causa raiz: falta de autenticação ou pressupostos frágeis em controle de acesso?