Pular para o conteúdo principal

Questão de Segurança da Informação — Ataques e ameaças — FCC 2026

Segurança da InformaçãoAtaques e ameaças
Código
gp007206
Banca
FCC
Órgão
AL-RR
Ano
2026
Cargo
Analista Legislativo - Analista de Segurança da Informação
Em uma Assembleia Legislativa, o sistema de acesso interno permite autenticação de servidores via endpoint POST /graphql,com limitação de 3 requisições por minuto por IP. Durante uma auditoria, verificou-se que um agente malicioso utilizou batchingde queries GraphQL para submeter múltiplas combinações de credenciais em uma única requisição, contornando o controleexistente. Considerando esse cenário e a necessidade de mitigar ataques de força bruta e credential stuffing, o controle quedeve ser utilizado é
  1. Aadotar assinatura criptográfica robusta nos JSON Web Tokens e ampliar seu tempo de expiração para o tempo de duraçãoda sessão, reduzindo assim a frequência de autenticação.
  2. Bregistrar eventos de autenticação malsucedida, implementar mecanismo de cache para respostas de autenticação inválidae acionar alertas automáticos para o SOC após volume elevado de tentativas oriundas de um mesmo endereço IP.
  3. Caplicar limitação de tentativas de autenticação no nível lógico da operação de login, contabilizando individualmente cadapar usuário-senha processado dentro de requisições compostas.
  4. Dreduzir o tamanho máximo permitido das requisições GraphQL para menos de 256 bytes, limitando a quantidade de operações incluídas em um único payload para menos de 3 requisições.
  5. Eexigir uso obrigatório de canal criptografado TLS para todas as requisições de autenticação realizadas pelos sistemasinternos e usar criptografia AES para as transações internas.
Revelar gabarito e comentário

GabaritoC — aplicar limitação de tentativas de autenticação no nível lógico da operação de login, contabilizando individualmente cada par usuário-senha processado dentro de requisições compostas.

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”.

Mitigação de força bruta e credential stuffing em GraphQL (batching)

Gabarito: letra C. O ataque descrito explora o batching de queries GraphQL para enviar múltiplas tentativas de autenticação em uma única requisição HTTP, burlando o limite de 3 requisições/minuto por IP. A solução é contabilizar individualmente cada par usuário-senha processado, ou seja, aplicar limitação de tentativas no nível lógico da operação de login, conforme descrito na alternativa C. As demais alternativas tratam de medidas de detecção, criptografia ou práticas inadequadas que não impedem o ataque.

O batching permite que o atacante agrupe várias consultas (no caso, tentativas de login) em um só pedido HTTP. Com isso, um rate limit por requisição (como 3 req/min) é facilmente contornado: ele envia uma única requisição com dezenas de tentativas. A mitigação correta é contar cada tentativa de autenticação, independentemente de quantas sejam agrupadas.

Alternativa A — ❌ Incorreta

Assinar JWT e ampliar seu tempo de expiração não mitiga força bruta: os tokens são emitidos após a autenticação, não durante. Além disso, prolongar a expiração aumenta a janela de reuso indevido em caso de comprometimento.

Alternativa B — ❌ Incorreta

Registrar eventos, fazer cache de respostas inválidas e acionar alertas são medidas de detecção e reação, não de prevenção. Elas não impedem que as tentativas ocorram; apenas permitem identificar o ataque depois de iniciado.

Alternativa C — ✅ Correta ⟵ GABARITO

Esta alternativa ataca diretamente o problema: mesmo com batching, cada par usuário-senha é contabilizado individualmente. Implementa-se um rate limiting no nível da operação de login (ex.: por usuário, por IP, mas contando cada tentativa). Isso neutraliza o contorno via agrupamento de queries.

Alternativa D — ❌ Incorreta

Reduzir o tamanho máximo das requisições a 256 bytes é impraticável (GraphQL queries legítimas podem ser maiores) e não resolve o problema: o atacante poderia simplesmente fracionar as tentativas em múltiplas requisições HTTP. A abordagem correta é contar tentativas, não limitar o payload.

Alternativa E — ❌ Incorreta

Exigir TLS e usar criptografia AES protege a confidencialidade e integridade dos dados em trânsito, mas não impede que um atacante envie tentativas de login repetidas. Força bruta e credential stuffing independem da criptografia do canal.

NÃO CAIA NESSA!

A banca explora a confusão entre controles de rede (rate limit por requisição IP) e controles de aplicação (rate limit por tentativa de login). O candidato pode achar que o problema já está resolvido com o limite de 3 req/min, mas o batching quebra essa proteção. A alternativa C é a única que corrige a lacuna no nível correto.

Gabarito: letra C.

Link permanente: /questoes/gp007206