Questão de Segurança da Informação — Segurança de sistemas de informação — FCC 2022
Segurança da Informação›Segurança de sistemas de informação
Código
fc063829
Banca
FCC
Órgão
TJ-CE
Ano
2022
Cargo
Analista Judiciário - Ciência da Computação - Sistemas da Informação
Para evitar os efeitos indesejáveis de ataques SQL Injection em aplicações web, uma recomendação correta de programação segura é
Anão utilizar ferramentas Object Relational Mapping (ORM) como Hibernate, NHibernate ou JPA.
Butilizar as propriedades security="true" e/ou encode="secure" nos campos de formulários HTML.
Crealizar a validação dos dados de entrada do lado do servidor por meio de whitelists.
Dvalidar a entrada de dados no cliente, evitando assim qualquer possibilidade de envio de instruções maliciosas ao servidor.
Eutilizar concatenação de valores nas consultas de dados ao invés de consultas parametrizadas.
Revelar gabarito e comentário▾
GabaritoC — realizar a validação dos dados de entrada do lado do servidor por meio de whitelists.
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 – Medidas de Programação Segura
Gabarito: letra C. Para prevenir ataques SQL Injection, a recomendação fundamental é validar rigorosamente as entradas do lado do servidor, utilizando whitelists (listas de permissões) para aceitar apenas dados esperados, conforme práticas de segurança em aplicações web.
A banca testa o conhecimento sobre as defesas contra SQL Injection, um dos ataques mais comuns em aplicações web. A alternativa correta reflete a boa prática de validação de entrada no servidor, enquanto as demais apresentam conceitos equivocados ou insuficientes.
Alternativa A — ❌ Incorreta
Ferramentas ORM (como Hibernate, JPA) não são, por si só, a causa de vulnerabilidades; elas podem auxiliar na prevenção quando usadas com consultas parametrizadas. A recomendação correta não é abandoná-las, mas sim utilizá-las adequadamente.
Alternativa B — ❌ Incorreta
Propriedades HTML como security="true" ou encode="secure" não existem como mecanismos de segurança para SQL Injection. São elementos inválidos e não oferecem proteção contra esse tipo de ataque.
Alternativa C — ✅ Correta ⟵ GABARITO
Validar os dados de entrada no servidor por meio de whitelists é uma prática essencial: define-se um conjunto de caracteres ou padrões permitidos, rejeitando qualquer entrada fora desse escopo. Isso impede que comandos SQL maliciosos sejam inseridos nas consultas.
Alternativa D — ❌ Incorreta
A validação apenas no cliente (navegador) é facilmente contornada pelo atacante, que pode alterar ou desabilitar o JavaScript ou enviar requisições diretamente. Toda validação deve ser replicada no servidor.
Alternativa E — ❌ Incorreta
A concatenação de valores em consultas SQL é exatamente o que torna a aplicação vulnerável a SQL Injection. A prática segura é usar consultas parametrizadas (prepared statements) ou stored procedures, que separam os dados do comando SQL.
NÃO CAIA NESSA!
A alternativa D pode parecer correta por mencionar "validação", mas a banca explora a confusão entre validação no cliente e no servidor. Lembre-se: a validação no servidor é a que realmente protege contra SQL Injection, pois o cliente não é confiável.
MNEMÔNICO
CID
CConfidencialidade (dados acessíveis só a quem é autorizado)IIntegridade (dados exatos, consistentes e não alterados indevidamente)DDisponibilidade (informação/sistemas acessíveis quando necessário)