Analista Judiciário - Área Apoio Especializado - Especialidade Tecnologia da Informação
Um Tribunal identificou que sua aplicação web foi explorada por uma vulnerabilidade de injeção SQL. Após a análise do incidente, o time de desenvolvimento decidiu implementar práticas que minimizam o risco de ocorrência dessas falhas no código-fonte. A técnica mais adequada para prevenir vulnerabilidades como a identificada no incidente é
Ausar mecanismos de hashing para proteger os dados enviados às consultas SQL.
Butilizar variáveis de ambiente para armazenar as credenciais de banco de dados e incluí-las diretamente nas consultas SQL.
Cusar concatenação de strings para gerar as consultas SQL.
Dutilizar parâmetros (prepared statements) para consultas SQL.
Eimplementar análise estática de código após o deployment.
Revelar gabarito e comentário▾
GabaritoD — utilizar parâmetros (prepared statements) para consultas SQL.
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”.
Prevenção de Injeção SQL
Gabarito: letra D. A técnica mais adequada para prevenir vulnerabilidades de injeção SQL é utilizar parâmetros (prepared statements) nas consultas ao banco de dados. Essa prática separa os dados da estrutura SQL, impedindo que entradas maliciosas alterem a lógica da consulta.
O contexto fornecido descreve que "o uso de variáveis de ligação (também conhecidas como parâmetros) protege contra ataques de injeção". Prepared statements vinculam valores a parâmetros de forma segura, evitando que o conteúdo seja interpretado como parte do comando SQL.
Alternativa A — ❌ Incorreta
Mecanismos de hashing (como SHA-256) são unidirecionais e servem para proteção de senhas ou integridade, não para prevenir injeção SQL. Eles não evitam que uma consulta maliciosa seja executada, apenas protegem dados armazenados.
Alternativa B — ❌ Incorreta
Armazenar credenciais em variáveis de ambiente e inseri-las diretamente na SQL é uma prática insegura. Além de expor senhas, a concatenação direta mantém a vulnerabilidade a injeção, pois o valor é interpretado como parte do código SQL.
Alternativa C — ❌ Incorreta
A concatenação de strings para montar consultas SQL é exatamente a causa da injeção SQL. Ela permite que um usuário insira caracteres especiais (como aspas simples) e modifique a estrutura da instrução, de modo que essa prática deve ser evitada.
Alternativa D — ✅ Correta ⟵ GABARITO
Utilizar prepared statements (comandos parametrizados) é a técnica recomendada. Neles, a consulta SQL é compilada com placeholders (ex.: ?), e os valores são vinculados separadamente. Assim, eles nunca são interpretados como parte do SQL, eliminando a possibilidade de injeção. O contexto menciona: "PreparedStatement stmt = conn.prepareStatement(...); stmt.setString(1, funcionario_id);".
Alternativa E — ❌ Incorreta
Análise estática de código identifica potenciais vulnerabilidades, mas após o deployment já é tarde; ela não previne a ocorrência no código-fonte durante o desenvolvimento. A prevenção deve ser adotada durante a codificação, e não apenas verificada depois.
PEGA ESSA DICA!
Lembre-se: concatenação de strings = porta aberta para SQL injection; prepared statements = barreira segura. Na prova, sempre que aparecer "parâmetros" ou "prepared statements", associe à prevenção de injeção SQL.