Pular para o conteúdo principal

Questão de Segurança da Informação — Segurança na Internet — FEPESE 2023

Segurança da InformaçãoSegurança na Internet
Código
qq880227
Banca
FEPESE
Órgão
Prefeitura de Balneário Camboriú - SC
Ano
2023
Nível
Superior
Cargo
Especialista em Inteligência de Dados
São exemplos válidos do risco de Design Inseguro do OWASP:1. Não limitar o número de tentativas de login a um painel administrador, o que possibilita ataques de força bruta.2. Não conter proteções nativas com relação à transações automatizadas via bots, o que possibilita tentativas de uso de cartões de crédito roubados, por exemplo, em aplicações web de e-commerce.3. Não possuir uma URL padrão para administrar instâncias de aplicações web conhecidas, como CMS, o que dificulta o trabalho do administrador.Assinale a alternativa que indica todas as afirmativas corretas.
  1. ASão corretas apenas as afirmativas 1 e 2.
  2. BÉ correta apenas a afirmativa 1.
  3. CSão corretas apenas as afirmativas 1 e 3.
  4. DSão corretas apenas as afirmativas 2 e 3.
  5. ESão corretas as afirmativas 1, 2 e 3.
Revelar gabarito e comentário

GabaritoA — São corretas apenas as afirmativas 1 e 2.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

OWASP – Design Inseguro

Gabarito: letra A. Apenas as afirmativas 1 e 2 são exemplos válidos de risco de Design Inseguro segundo o OWASP Top 10 (2021). A afirmativa 3, na verdade, descreve uma prática de segurança (security by obscurity), não um risco de projeto.

A categoria Insecure Design abrange falhas na fase de projeto que deixam a aplicação vulnerável, como ausência de controles de segurança (ex.: rate limiting, proteção contra automação). A afirmativa 3 inverte o conceito: não ter uma URL padrão para administração (ex.: /admin) é uma medida que dificulta a descoberta do painel, o que reduz a superfície de ataque – portanto, não é um risco, mas sim uma proteção.

Afirmativa 1 – ✅ Correta

Não limitar o número de tentativas de login em um painel administrador é uma falha clássica de design inseguro: a aplicação deveria prever mecanismos de bloqueio ou atraso progressivo (rate limiting). A ausência disso permite ataques de força bruta.

Afirmativa 2 – ✅ Correta

Não conter proteções nativas contra transações automatizadas via bots (ex.: CAPTCHA, análise comportamental) é outro exemplo de design inseguro. Isso possibilita o uso fraudulento de cartões de crédito roubados em sites de e-commerce.

Afirmativa 3 – ❌ Incorreta

Não possuir uma URL padrão para administração de instâncias de aplicações conhecidas (como CMS) não é um risco de design inseguro. Pelo contrário, é uma prática recomendada de segurança: alterar o caminho padrão do painel administrativo dificulta que atacantes automatizados o encontrem. A afirmativa erra ao classificar essa prática como risco.

Conclusão: Apenas as afirmativas 1 e 2 estão corretas, o que corresponde à alternativa A.

Afirmativa

Descrição

É risco de Design Inseguro?

1

Não limitar tentativas de login em painel admin (força bruta)

✅ Sim

2

Não conter proteções contra bots (transações automatizadas)

✅ Sim

3

Não possuir URL padrão para administração de CMS

❌ Não (é segurança)

Link permanente: /questoes/qq880227