Questão de Segurança da Informação — Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.) — FCC 2025

Prevenção de SQL Injection: consultas parametrizadas

Gabarito: letra D. A técnica mais adequada para prevenir SQL Injection é o uso de prepared statements (consultas parametrizadas), pois separa os dados dos comandos SQL, impedindo que a entrada do usuário seja interpretada como parte da instrução. Essa é a recomendação central do OWASP para a categoria A03:2021 – Injeção.

A injeção de SQL (SQLi) é uma vulnerabilidade de segurança web que permite a um invasor interferir nas consultas que uma aplicação faz ao seu banco de dados. Isso ocorre quando dados fornecidos pelo usuário são concatenados diretamente em uma consulta SQL, sem validação ou escape adequado. O atacante pode, então, inserir comandos SQL maliciosos que serão executados pelo banco, permitindo visualizar, modificar ou deletar dados não autorizados.

A causa raiz da SQLi é a falta de separação entre código e dados. Quando a aplicação monta a consulta por concatenação de strings, o banco de dados não consegue distinguir o que é comando e o que é dado — tudo vira parte da instrução. A solução é usar consultas parametrizadas (prepared statements), nas quais a estrutura da consulta é definida previamente e os valores são passados como parâmetros separados. O banco de dados trata esses parâmetros como dados puros, nunca como código executável.

Na prática, em linguagens como Java (JDBC), Python (sqlite3), PHP (PDO) ou C# (ADO.NET), a consulta é escrita com placeholders (como ? ou :nome) e os valores são vinculados separadamente. Por exemplo, em vez de montar SELECT * FROM usuarios WHERE login = '" + usuario + "', usa-se SELECT * FROM usuarios WHERE login = ? e depois se vincula o valor do parâmetro. Assim, mesmo que o usuário digite ' OR '1'='1, o banco o trata como uma string literal, não como parte do comando.

Além das consultas parametrizadas, outras boas práticas incluem: validação de entrada (safelist) no servidor, escape adequado de caracteres especiais, uso de LIMIT para limitar a exposição de dados, e princípio do menor privilégio no acesso ao banco. No entanto, a opção preferida e mais eficaz é a API parametrizada, conforme o OWASP Top 10.

A banca explora aqui a confusão entre medidas de proteção de dados (hashing, variáveis de ambiente) e medidas de prevenção de injeção (parametrização). Hashing protege senhas, não consultas; variáveis de ambiente protegem credenciais, não a construção da query. A concatenação de strings é justamente a causa da vulnerabilidade, não a solução. E a análise estática de código é uma ferramenta de detecção, não de prevenção no código-fonte.

Guarde o critério decisivo: a prevenção de SQLi exige que os dados do usuário nunca sejam interpretados como código SQL — e isso só é garantido com consultas parametrizadas. É exatamente nesse ponto que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Hashing é uma técnica de proteção de dados sensíveis (como senhas), não de prevenção de injeção SQL. Aplicar hash aos dados enviados à consulta não impede que o atacante manipule a estrutura da query — e ainda poderia quebrar a funcionalidade, pois o banco precisaria comparar valores com hash. A confusão aqui é entre criptografia de dados e parametrização de consultas.

Alternativa B — ❌ Incorreta

Variáveis de ambiente são uma boa prática para armazenar credenciais (evitando hardcode), mas incluí-las diretamente nas consultas SQL não protege contra injeção. As credenciais são usadas para autenticar no banco, não para construir a query. A vulnerabilidade continua se a consulta for montada por concatenação. A banca mistura gestão de segredos com prevenção de injeção.

Alternativa C — ❌ Incorreta

A concatenação de strings é exatamente a causa da SQL Injection. Quando o código monta a consulta juntando strings com a entrada do usuário, o banco não distingue comando de dado, permitindo a injeção. Esta alternativa inverte o conceito: apresenta a prática vulnerável como solução. (Nota: o enunciado traz "usas", provável erro de digitação para "usar".)

Alternativa D — ✅ Correta ⟵ GABARITO

Prepared statements (consultas parametrizadas) são a técnica mais adequada e recomendada pelo OWASP para prevenir SQL Injection. Elas separam a estrutura da consulta dos dados, que são passados como parâmetros e tratados como valores literais pelo banco. Isso impede que a entrada do usuário seja interpretada como código SQL, eliminando a vulnerabilidade na raiz.

Alternativa E — ❌ Incorreta

A análise estática de código é uma ferramenta de detecção de vulnerabilidades, útil durante o desenvolvimento, mas não previne a ocorrência da falha no código-fonte. Ela pode encontrar trechos vulneráveis, mas a correção exige a adoção de práticas seguras, como a parametrização. Além disso, a alternativa diz "após o deployment", o que a torna ainda menos adequada — a análise deveria ocorrer antes da implantação.

Gabarito: letra D