Questão de Banco de Dados — Segurança em Banco de Dados — FCC 2026

Segurança em Banco de Dados: Prevenção de SQL Injection e Otimização de Consultas

Gabarito: letra A. A prática correta é adotar Prepared Statements (consultas parametrizadas), pois essa técnica separa o código SQL dos dados de entrada do usuário, prevenindo ataques de injeção de SQL e, ao mesmo tempo, permite que o banco de dados reutilize planos de execução otimizados para melhor desempenho. Essa é uma técnica amplamente recomendada na literatura de segurança de banco de dados, como em Elmasri & Navathe, que destaca o uso de variáveis de ligação (parâmetros) como proteção contra injeção e melhoria de desempenho.

A injeção de SQL é uma das ameaças mais comuns a sistemas de banco de dados. Ela ocorre quando o atacante insere código SQL malicioso por meio de campos de entrada do usuário, que é então concatenado diretamente em uma consulta SQL, alterando a semântica original da instrução. Por exemplo, em uma consulta de autenticação como SELECT * FROM usuarios WHERE nomeusuario = 'jaime' AND senha = 'senhajaime', um atacante pode manipular a entrada para ' OR 'x'='x, transformando a condição em WHERE nomeusuario = 'jaime' AND (senha = 'senhajaime' OR 'x' = 'x'), o que sempre retorna verdadeiro e permite o acesso não autorizado. Esse é o tipo mais comum de ataque de manipulação de SQL.

A técnica de Prepared Statements (ou consultas parametrizadas) resolve esse problema ao separar a estrutura do comando SQL dos dados fornecidos pelo usuário. Em vez de concatenar a entrada diretamente na string SQL, o desenvolvedor define a consulta com placeholders (como ? em JDBC) e, em seguida, vincula os valores a esses parâmetros. O banco de dados trata esses valores como dados, não como parte do código SQL, tornando impossível a injeção de comandos maliciosos. Além disso, como a estrutura da consulta é pré-compilada, o SGBD pode reutilizar o plano de execução para chamadas subsequentes, melhorando o desempenho, especialmente em consultas executadas repetidamente.

Outras técnicas de proteção incluem a filtragem de entrada (validação e escape de caracteres especiais), mas essa abordagem é menos confiável, pois há muitos caracteres de escape possíveis. A segurança da função também é importante, restringindo funções de banco de dados que podem ser exploradas. No entanto, a abordagem mais robusta e recomendada é o uso de consultas parametrizadas.

A banca explora a confusão entre técnicas de segurança e desempenho. É comum o candidato achar que Stored Procedures são inerentemente seguras ou que concatenar strings é eficiente, mas ambas as premissas são falsas. A chave é entender que a separação entre código e dados é o que garante a segurança contra injeção SQL, e que a reutilização de planos de execução é um benefício adicional das consultas parametrizadas.

Guarde esse critério: a alternativa correta deve combinar segurança (prevenção de injeção) e desempenho (reutilização de planos de execução) por meio da parametrização. As demais alternativas falham em pelo menos um desses aspectos.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta alternativa está correta porque descreve com precisão os dois benefícios das Prepared Statements: a separação entre código SQL e dados de entrada, que previne injeção de SQL, e a reutilização de planos de execução, que otimiza o desempenho. A técnica é amplamente recomendada em segurança de banco de dados, como visto no contexto, que menciona o uso de variáveis de ligação (parâmetros) como proteção contra injeção e melhoria de desempenho.

Alternativa B — ❌ Incorreta

Concatenar strings de entrada do usuário diretamente na consulta SQL é exatamente o que permite ataques de injeção de SQL. Essa prática é insegura e não oferece nenhum benefício de desempenho. O erro aqui é acreditar que concatenar é "comum e eficiente", quando na verdade é uma vulnerabilidade crítica.

Alternativa C — ❌ Incorreta

Stored Procedures podem ser seguras se usarem parâmetros, mas a alternativa afirma que elas previnem injeção de SQL se os parâmetros forem concatenados em texto dentro da procedure — o que é falso. Concatenar parâmetros dentro de uma procedure ainda é vulnerável a injeção. Além disso, a afirmação de que são "compiladas e executadas mais rapidamente que comandos SQL dinâmicos" é uma generalização: o desempenho depende de vários fatores, e a reutilização de planos de execução também ocorre com consultas parametrizadas.

Alternativa D — ❌ Incorreta

Manter permissões de superusuário para a aplicação é uma prática de segurança extremamente inadequada. O princípio do menor privilégio exige que a aplicação tenha apenas as permissões necessárias para suas operações. Conceder acesso de superusuário aumenta o risco de danos em caso de comprometimento da aplicação, além de violar boas práticas de segurança.

Alternativa E — ❌ Incorreta

Usar Views para simplificar consultas complexas é uma boa prática, mas conceder acesso direto às tabelas subjacentes para operações de INSERT e UPDATE sem restrições é inseguro. Isso viola o princípio do menor privilégio e pode permitir que usuários não autorizados modifiquem dados sensíveis. A alternativa confunde a simplificação de consultas com a concessão de acesso irrestrito.

Gabarito: letra A