Analista de Sistemas – Administrador de Banco de Dados
Considerando a situação apresentada, é correto afirmar que um usuário malicioso pode
Aenviar um comando SQL qualquer através da string no lugar de atributoOrdem, executando uma operação CRUD na tabela.
Bdigitar uma string com um comando SQL que ele deseje executar e a servlet o executaria, podendo realizar qualquer ação no banco de dados e causar danos.
Cdigitar uma string que coincida com um atributo da tabela e modificá-lo, podendo alterar algum valor importante para o banco de dados, adulterando-o inadequadamente.
Denviar uma string qualquer no lugar de um valor significativo de atributoOrdem, mesmo que o formulário HTML usado para receber a entrada tentasse restringir os valores permitidos.
Edigitar uma string que coincida com um atributo da tabela e apagá-lo, podendo eliminar uma coluna da tabela e corromper o banco de dados.
Revelar gabarito e comentário▾
GabaritoD — enviar uma string qualquer no lugar de um valor significativo de atributoOrdem, mesmo que o formulário HTML usado para receber a entrada tentasse restringir os valores permitidos.
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: Bypass de validação client-side
Gabarito: letra D. A vulnerabilidade descrita é um clássico ataque de SQL Injection. O ponto central é que, mesmo que o formulário HTML tente restringir os valores permitidos (ex.: dropdown com nomes de colunas), o usuário malicioso pode burlar essa validação do lado do cliente enviando qualquer string diretamente na requisição HTTP. A alternativa D capta exatamente esse risco: o ataque independe das restrições impostas pelo formulário, pois o servidor não valida a entrada.
A banca testa a compreensão de que a segurança não pode se basear em validações client‑side. O invasor pode interceptar e modificar a requisição, inserindo comandos SQL arbitrários na cláusula ORDER BY.
Alternativa
Descrição do Ataque
Foco da Questão
Correção
A
Enviar comando SQL arbitrário via atributoOrdem, executando CRUD.
Possibilidade técnica de injeção.
❌ Incorreta – Não aborda o bypass da validação client‑side.
B
Digitar comando SQL que a servlet executaria, causando danos.
Execução de comandos arbitrários.
❌ Incorreta – Ignora a insuficiência da validação no formulário.
C
Digitar string que coincida com atributo da tabela para modificá-lo.
Necessidade de coincidência com nome de coluna.
❌ Incorreta – O ataque não depende de coincidência; qualquer string SQL pode ser injetada.
D
Enviar string qualquer no lugar de atributoOrdem, mesmo com restrições no formulário HTML.
Bypass da validação client‑side.
✅ Correta – Capta o risco de o invasor burlar as restrições do formulário.
E
Digitar string que coincida com atributo da tabela para apagá-lo (coluna).
Necessidade de coincidência e ação de apagar coluna.
❌ Incorreta – O ataque não exige coincidência; a injeção pode deletar dados, não colunas diretamente.
SQL Injection: Validação client-side (Burlável (requisição direta), Insuficiente); Ataque (Inserção de comando SQL, Na cláusula ORDER BY); Consequência (Operações CRUD arbitrárias, Acesso a dados não autorizados)
Alternativa A — ❌ Incorreta
Afirma que o usuário pode "enviar um comando SQL qualquer através da string no lugar de atributoOrdem, executando uma operação CRUD na tabela.” Embora tecnicamente possível (injetando um ; e outro comando), a alternativa é imprecisa: a vulnerabilidade principal reside no fato de que as restrições do formulário HTML (validação client-side) podem ser facilmente contornadas. A alternativa A não menciona esse ponto crítico, sendo, portanto, incompleta.
Alternativa B — ❌ Incorreta
Diz que “digitar uma string com um comando SQL que ele deseje executar e a servlet o executaria, podendo realizar qualquer ação no banco de dados e causar danos.” Novamente, é verdade que a injeção pode permitir comandos arbitrários, mas o foco da questão é mostrar que a validação no formulário (client-side) é insuficiente. A alternativa B ignora essa nuance e, por isso, está incorreta.
Alternativa C — ❌ Incorreta
Alega que “digitar uma string que coincida com um atributo da tabela e modificá-lo, podendo alterar algum valor importante para o banco de dados, adulterando-o inadequadamente.” Essa descrição é equivocada: o ataque não requer que a string coincida com um atributo existente; o invasor pode inserir qualquer string SQL, incluindo comandos de modificação. O erro está em supor que a injeção depende de um valor que “coincida” com o nome da coluna.
Alternativa D — ✅ Correta ⟵ GABARITO
Afirma corretamente que “enviar uma string qualquer no lugar de um valor significativo de atributoOrdem, mesmo que o formulário HTML usado para receber a entrada tentasse restringir os valores permitidos.” Essa alternativa capta a essência da vulnerabilidade: a validação no cliente (HTML) não é confiável; o servidor deve sempre validar a entrada. É exatamente o que ocorre quando a aplicação concatena diretamente o parâmetro atributoOrdem na consulta SQL.
Alternativa E — ❌ Incorreta
Declara que “digitar uma string que coincida com um atributo da tabela e apagá-lo, podendo eliminar uma coluna da tabela e corromper o banco de dados.” Erro semelhante ao da alternativa C: não é necessário que a string coincida com um atributo. Além disso, apagar uma coluna exigiria um comando DDL (ALTER TABLE ... DROP COLUMN), que é possível via injeção, mas a descrição é limitada e não reflete o cenário de bypass de restrições.
PEGA ESSA DICA!
Em questões de SQL Injection, lembre-se sempre de que o invasor pode contornar qualquer validação que ocorra apenas no lado do cliente (HTML/JavaScript). A segurança deve ser implementada no servidor, com validação rigorosa e uso de parâmetros preparados (“prepared statements”).