Questão nº 50
Questão de Desenvolvimento de Sistemas · FGV CGU 2021 - Tarde (nº 50)
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 extratos WHERE id_cliente='" + request.getParameter("id") + "'";
```
Para mitigar o impacto dos riscos criados por esse tipo de vulnerabilidade, é possível utilizar:
- Aprotocolos como FTP ou SMTP para o transporte dos dados sensíveis da aplicação;
- Bfunções criptográficas fortes, como MD5 e SHA1, no mecanismo automático do banco de dados;
- Cframeworks ORM como o Hibernate e linguagens de consulta como a HQL (Hibernate Query Language);
- Dapenas dados fornecidos por usuários autenticados no processamento de consultas;
- Ecláusulas como LIMIT nas consultas para restringir os resultados retornados. (alternativa correta)
Resposta comentada
Gabarito Alternativa E
Conceito-chave: SQL Injection é uma falha onde o atacante "injeta" comandos maliciosos em uma consulta ao banco de dados, porque o sistema concatena texto digitado pelo usuário diretamente no código SQL. A criptografia do banco não protege contra isso, pois os dados são decriptados automaticamente quando a consulta é executada — o problema não é o armazenamento, e sim a forma como a consulta é montada.
- (A) Incorreta: Protocolos como FTP e SMTP não são seguros para dados sensíveis (FTP é texto puro, SMTP é para e-mail) e não corrigem a vulnerabilidade de SQL Injection, que ocorre na camada de consulta, não no transporte.
- (B) Incorreta: MD5 e SHA1 são funções de hash, não criptografia forte, e são inadequadas para proteger dados financeiros (são quebradas e não reversíveis). Além disso, o problema é a injeção de SQL, não a força do algoritmo de hash.
- (C) Incorreta: Frameworks ORM como Hibernate reduzem o risco de SQL Injection se usados com parâmetros vinculados (HQL com
:param), mas a alternativa não menciona isso — e o trecho do enunciado usa concatenação de string, que o ORM não corrige automaticamente se o desenvolvedor usarcreateQuerycom concatenação. - (D) Incorreta: Restringir a usuários autenticados não impede que um usuário legítimo (ou um atacante que roubou a sessão) injete SQL. Autenticação não valida a entrada do parâmetro.
- (E) Correta: Adicionar
LIMIT(ex.:LIMIT 1) limita o número de linhas retornadas, então mesmo que o atacante injete algo como' OR '1'='1, a consulta retornará apenas um registro, reduzindo drasticamente o vazamento de dados em massa. Não é a solução ideal (o certo é usar prepared statements), mas é a única alternativa que mitiga o impacto imediato do exemplo dado, conforme o gabarito oficial.
Armadilha da banca: A alternativa (C) é a mais tentadora, pois ORM/Hibernate podem ajudar, mas a banca quer que você perceba que o trecho de código usa concatenação direta de string — o que anula a proteção do ORM. A banca também testa se você sabe que LIMIT é uma cláusula SQL válida que limita o volume de dados expostos, mesmo que a injeção ocorra.
Fonte: FGV CGU 2021 - Tarde Auditor Federal de Finanças e Controle - Área Tecnologia da Informação (Caderno Tipo 1). Reproduzida para fins de estudo.