Pular para o conteúdo principal

Questão de Segurança da Informação — Segurança de sistemas de informação — FGV 2022

Segurança da InformaçãoSegurança de sistemas de informação
Código
fg047183
Banca
FGV
Órgão
CGU
Ano
2022
Nível
Superior
Cargo
Auditor Federal de Finanças e Controle - Tecnologia da Informação
Considere um cenário típico de exposição de dados sensíveis: uma organização acredita estar segura ao utilizar a criptografia automática do seu banco de dados para encriptar dados financeiros sigilosos dos seus usuários, mas esquece que permite que esses dados sejam automaticamente decriptados nas operações de consulta.Um time de desenvolvedores sem experiência em desenvolvimento seguro trabalha em uma aplicação que acessa essa base de dados. Ao longo do desenvolvimento da aplicação, um tipo comum de vulnerabilidade é inserido em muitas das consultas realizadas, como no seguinte trecho:String consultaHTTP = "SELECT \* FROM extratosWHERE id_cliente='" + request.getParameter("id") + "'";Para mitigar o impacto dos riscos criados por esse tipo de vulnerabilidade, é possível utilizar:
  1. Aprotocolos como FTP ou SMTP para o transporte dos dados sensíveis da aplicação;
  2. Bfunções criptográficas fortes, como MD5 e SHA1, no mecanismo automático do banco de dados;
  3. Cframeworks ORM como o Hibernate e linguagens de consulta como a HQL (Hibernate Query Language);
  4. Dapenas dados fornecidos por usuários autenticados no processamento de consultas;
  5. Ecláusulas como LIMIT nas consultas para restringir os resultados retornados.
Revelar gabarito e comentário

GabaritoE — cláusulas como LIMIT nas consultas para restringir os resultados retornados.

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 Impacto em SQL Injection

Gabarito: letra E. A vulnerabilidade apresentada é um clássico SQL Injection: concatenação direta de parâmetro do usuário na query SQL. Para mitigar o impacto (não prevenir) desse tipo de falha, é possível utilizar cláusulas como LIMIT para restringir a quantidade de dados retornados em cada consulta, limitando o vazamento de informações sensíveis em caso de exploração.

A questão foca no conceito de defesa em profundidade: mesmo que a injeção ocorra, medidas adicionais reduzem o dano. Vamos analisar cada alternativa:

Alternativa A — ❌ Incorreta

Protocolos como FTP e SMTP não são seguros para transporte de dados sensíveis e não mitigam SQL Injection. FTP transmite dados em claro; SMTP é para e-mail, não para consultas.

Alternativa B — ❌ Incorreta

MD5 e SHA1 são funções hash, não criptográficas para reversão. Hash não encripta dados e não impede que uma consulta injetada devolva dados originais (se o hash for armazenado, o atacante pode obter hashes, mas não é mitigação adequada). Além disso, essas funções são consideradas fracas para segurança.

Alternativa C — ❌ Incorreta (mas tentadora)

Frameworks ORM como Hibernate e linguagens HQL previnem SQL Injection se usados com parâmetros. No entanto, a questão pede mitigação de impacto, não prevenção. Mesmo com ORM, se o desenvolvedor concatenar strings em HQL, a vulnerabilidade persiste. A banca quer um mecanismo que reduza o dano após a injeção ocorrer, não que evite a injeção.

Alternativa D — ❌ Incorreta

Autenticação não evita SQL Injection: um usuário autenticado pode injetar comandos maliciosos. A consulta ainda será executada com os privilégios do banco.

Alternativa E — ✅ Correta ⟵ GABARITO

Usar LIMIT nas consultas limita o número de registros retornados. Se um atacante explorar a injeção para extrair dados, cada consulta devolverá apenas um conjunto pequeno de linhas (ex.: 1 ou 10), dificultando a exfiltração massiva de dados. É uma medida de mitigação de impacto que, combinada com outras defesas (como validação de entrada e prepared statements), aumenta a segurança.

NÃO CAIA NESSA!

A alternativa C (ORM/HQL) parece correta, mas a questão pede especificamente mitigar o impacto, não prevenir. ORM previne a vulnerabilidade; LIMIT reduz o dano quando a falha já existe. Fique atento ao enunciado: "mitigar o impacto dos riscos criados por esse tipo de vulnerabilidade".

Gabarito: letra E – o uso de cláusulas LIMIT restringe os resultados e limita o vazamento de dados em caso de SQL Injection.

MNEMÔNICO
CID
CConfidencialidade (dados acessíveis só a quem é autorizado)IIntegridade (dados exatos, consistentes e não alterados indevidamente)DDisponibilidade (informação/sistemas acessíveis quando necessário)
Segurança da Informação - Princípios/Tríade CID

Link permanente: /questoes/fg047183