Analista de Sistemas – Administrador de Banco de Dados
A situação apresentada acima pode se configurar em
Auma vulnerabilidade comum em consultas SQL e não pode causar nenhum dano ao banco de dados, que possui mecanismos próprios para identificar esta fragilidade e impedir ações danosas aos dados.
Bum ataque do tipo SQL injection e, para evitá-lo, a aplicação deverá garantir que o valor da variável atributoOrdem seja um dos valores permitidos (nomes de atributos) antes de acrescentá-lo à string.
Cum ataque do tipo XSF ou falsa solicitação entre sites e, para evitá-lo, a aplicação não pode permitir quaisquer tags HTML na entrada de texto por parte dos usuários.
Dum ataque do tipo XSS ou scripting via SQL e, para evitá-lo, a aplicação não pode permitir que um formulário HTML utilize comandos select com campos preenchidos no site por parte dos usuários.
Eum ataque do tipo SQL injection e, para evitá-lo, a aplicação deverá garantir que o valor da variável atributoOrdem não coincida com nenhum nome de atributo antes de acrescentá-lo à string, de forma que a coluna da tabela não possa ser alterada nem apagada.
Revelar gabarito e comentário▾
GabaritoB — um ataque do tipo SQL injection e, para evitá-lo, a aplicação deverá garantir que o valor da variável atributoOrdem seja um dos valores permitidos (nomes de atributos) antes de acrescentá-lo à string.
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”.
SQL Injection em cláusula ORDER BY
Gabarito: letra B. A situação caracteriza um ataque de SQL injection, pois o valor da variável atributoOrdem é concatenado diretamente na consulta SQL sem validação. A prevenção adequada é a validação por lista de permissões (whitelist), já que não é possível usar consultas parametrizadas para identificadores como nomes de colunas.
A banca testa o conhecimento sobre os diferentes tipos de injeção SQL e as técnicas de prevenção específicas para cada caso. Embora o uso de PreparedStatement com parâmetros seja suficiente para valores de dados (como strings em cláusulas WHERE), ele não pode ser aplicado a identificadores (nomes de tabelas, colunas, direção ORDER BY). Nesse cenário, a única forma segura é verificar se a entrada corresponde a um dos valores esperados.
Alternativa
Tipo de Ataque
Prevenção Correta?
Descrição da Prevenção
A
Nenhum (vulnerabilidade inofensiva)
❌
Mecanismos próprios do SGBD impedem danos
B
SQL injection
✅ (Gabarito)
Whitelist: valor deve estar entre nomes de atributos permitidos
C
XSF (falsa solicitação entre sites)
❌
Remover tags HTML (prevenção de XSS)
D
XSS ou scripting via SQL
❌
Não permitir formulário HTML com select preenchido pelo usuário
E
SQL injection
❌
Garantir que valor não coincida com nome de atributo (blacklist)
SQL injection em ORDER BY: Causa (Concatenação direta de entrada, Identificador (coluna/direção)); Prevenção (Whitelist (valores permitidos), PreparedStatement (não funciona)); Consequências (Vazamento de dados, Destruição da base)
Alternativa A — ❌ Incorreta
Afirma que a vulnerabilidade é comum, mas que não causa danos porque o banco de dados possui mecanismos próprios. Isso é falso: a concatenação direta de entrada do usuário permite a injeção de comandos SQL arbitrários, podendo causar desde vazamento de dados até destruição da base. Não há mecanismo automático no SGBD que impeça esse tipo de ataque.
Alternativa B — ✅ Correta ⟵ GABARITO
Reconhece corretamente o SQL injection e indica a prevenção por whitelist (garantir que o valor esteja entre os nomes de atributos permitidos). Essa é a técnica recomendada quando a entrada deve ser um identificador, pois não é possível utilizar bind parameters.
Alternativa C — ❌ Incorreta
Confunde o ataque com XSF (Cross-Site Forgery), que é um tipo de ataque em aplicações web, não relacionado a manipulação de consultas SQL. A prevenção sugerida (remover tags HTML) é para XSS (Cross-Site Scripting), não para SQL injection.
Alternativa D — ❌ Incorreta
Associa o ataque a XSS ou scripting via SQL, denominação incorreta. XSS é uma vulnerabilidade no lado cliente (navegador), enquanto a questão trata de manipulação de consultas SQL no servidor. A prevenção de XSS (filtrar HTML) não é suficiente para evitar SQL injection.
Alternativa E — ❌ Incorreta
Embora identifique o SQL injection, a prevenção sugerida é garantir que o valor NÃO coincida com nenhum nome de atributo. Isso seria uma blacklist, que pode ser facilmente contornada (ex.: se o atacante digitar um valor que não seja nome de coluna, a consulta ainda será executada com esse valor arbitrário). A abordagem correta é a whitelist (lista de valores permitidos).
NÃO CAIA NESSA!
Muitos candidatos acreditam que o uso de consultas parametrizadas (PreparedStatement) resolve qualquer SQL injection. Porém, para nomes de colunas ou tabelas (identificadores), não é possível usar parâmetros; a solução é validar a entrada contra uma lista pré-definida. A alternativa E explora essa confusão ao propor uma blacklist, que é ineficaz.