Questão de Tecnologia da Informação · FGV BANESTES 2021 (nº 50)

SQL Injection acontece quando o site monta uma consulta ao banco de dados juntando texto digitado pelo usuário sem checar se esse texto é seguro. O invasor pode digitar comandos SQL escondidos em campos de formulário ou na URL, e o banco executa como se fosse parte da consulta original. A defesa principal é nunca confiar no que o usuário envia — toda entrada precisa ser validada ou tratada como dado, não como comando.

• (A) Incorreta: Expressões regulares podem filtrar padrões, mas não são uma forma de cifrar variáveis; cifrar não impede injeção, pois o banco receberia o texto cifrado e não o comando malicioso — e o ataque ocorre antes, na montagem da consulta.
• (B) Incorreta: Concatenar input do usuário com SQL é exatamente a causa do problema, não a solução; isso abre a porta para o atacante fechar aspas e adicionar comandos próprios.
• (C) Incorreta: Colocar aspas simples ao redor do input ajuda em casos simples, mas não é seguro: o atacante pode escapar a aspa com \' ou usar comentários (--) para anular o resto da consulta. É uma proteção frágil, não uma prevenção real.
• (D) Incorreta: Mostrar mensagens de erro do banco no HTTP ajuda o invasor a entender a estrutura do banco (tabelas, colunas) e refinar o ataque; erros devem ser genéricos e logados internamente.
• (E) Correta: Validar todas as entradas (formulários, parâmetros de URL, cookies, headers) é a prática fundamental: aceitar apenas o que é esperado (tipo, tamanho, formato) e usar consultas parametrizadas ou prepared statements — assim o input é tratado como dado, nunca como código SQL executável. Essa é a defesa padrão do OWASP.

Armadilha da banca: a letra (C) é a mais tentadora, porque parece técnica e plausível. Mas a banca quer que você perceba que aspas simples são um paliativo — o atacante conhece truques de escape (\', \), e em bancos como MySQL ou SQL Server há funções que ignoram aspas. A única forma robusta é validar e parametrizar, como manda a letra E.