Pular para o conteúdo principal

Questão de Banco de Dados — Segurança em Banco de Dados — INSTITUTO AOCP 2023

Banco de DadosSegurança em Banco de Dados
Código
qa542773
Banca
INSTITUTO AOCP
Órgão
CODEBA
Ano
2023
Cargo
Ana Por ( )
No contexto de técnicas de desenvolvimento seguro, qual das seguintes práticas é altamente recomendada para prevenir a vulnerabilidade de injeção de SQL em aplicações web?
  1. AArmazenar todas as credenciais no código fonte.
  2. BUtilizar strings concatenadas para construir consultas SQL.
  3. CLimitar o número de requisições HTTP por minuto.
  4. DUtilizar técnicas de hashing para armazenar senhas.
  5. EEmpregar consultas preparadas (ou "prepared statements") quando interagindo com bancos de dados.
Revelar gabarito e comentário

GabaritoE — Empregar consultas preparadas (ou "prepared statements") quando interagindo com bancos de dados.

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”.

Injeção de SQL: prevenção em aplicações web

Gabarito: letra E. A prática altamente recomendada para prevenir injeção de SQL é empregar consultas preparadas (prepared statements), que separam a estrutura da consulta dos dados fornecidos pelo usuário, impedindo que a entrada seja interpretada como parte do comando SQL. Essa técnica é amplamente reconhecida como a defesa mais eficaz contra esse tipo de ataque.

A injeção de SQL é uma vulnerabilidade de segurança que ocorre quando dados fornecidos pelo usuário são incorporados diretamente em uma consulta SQL sem a devida sanitização ou parametrização. O atacante pode manipular a entrada para alterar a estrutura da consulta, obtendo acesso não autorizado a dados, contornando autenticação, executando comandos remotos ou até mesmo causando negação de serviço. O contexto de segurança de banco de dados destaca que a proteção contra injeção de SQL pode ser obtida aplicando-se certas regras de programação, sendo o uso de variáveis de ligação (parâmetros) uma das principais técnicas.

As consultas preparadas funcionam da seguinte forma: a aplicação envia ao banco de dados um modelo de consulta com espaços reservados (placeholders) para os valores, e depois envia os valores separadamente. O banco de dados compila o modelo uma única vez e, em seguida, vincula os valores aos parâmetros, tratando-os como dados, não como parte do comando SQL. Isso impede que caracteres especiais, como aspas simples, sejam interpretados como delimitadores de string ou que comandos maliciosos sejam executados. Por exemplo, em Java com JDBC, utiliza-se PreparedStatement para criar a consulta com ? como marcador de posição e depois se usa setString para vincular os valores.

A alternativa E é a única que descreve corretamente essa técnica de prevenção. As demais alternativas ou representam práticas inseguras ou abordam medidas de segurança que não são específicas para prevenir injeção de SQL. A banca explora a confusão entre diferentes conceitos de segurança, como armazenamento de senhas, limitação de requisições e a própria construção de consultas SQL. É fundamental distinguir a prevenção de injeção de SQL de outras práticas de segurança, como hashing de senhas ou rate limiting, que protegem contra outras ameaças.

A pegadinha desta questão está em reconhecer que a injeção de SQL é uma vulnerabilidade específica de construção de consultas, e não um problema de autenticação, armazenamento de credenciais ou disponibilidade. O candidato que confunde as práticas de segurança pode ser induzido a escolher uma alternativa que trata de outro aspecto da segurança da informação. A técnica de consultas preparadas é a resposta direta e objetiva para a prevenção dessa vulnerabilidade.

  1. 1Envia modelo com placeholders
  2. 2Banco compila o modelo
  3. 3Envia valores separadamente
  4. 4Valores tratados como dados
LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

Armazenar credenciais no código fonte é uma prática extremamente insegura e não tem relação com a prevenção de injeção de SQL. Essa prática expõe as credenciais a qualquer pessoa com acesso ao código, violando o princípio da confidencialidade. A injeção de SQL é uma vulnerabilidade de construção de consultas, não de armazenamento de credenciais.

Alternativa B — ❌ Incorreta

Utilizar strings concatenadas para construir consultas SQL é exatamente a prática que torna a aplicação vulnerável à injeção de SQL. Ao concatenar a entrada do usuário diretamente na string da consulta, o atacante pode inserir comandos SQL maliciosos. Essa é a causa raiz da vulnerabilidade, não uma medida de prevenção.

Alternativa C — ❌ Incorreta

Limitar o número de requisições HTTP por minuto é uma técnica de mitigação de ataques de negação de serviço (DoS), não de prevenção de injeção de SQL. Essa medida pode ajudar a proteger a disponibilidade do serviço, mas não impede que um atacante explore a vulnerabilidade de injeção de SQL em uma única requisição.

Alternativa D — ❌ Incorreta

Utilizar técnicas de hashing para armazenar senhas é uma prática recomendada para proteger as credenciais dos usuários, mas não previne a injeção de SQL. O hashing protege as senhas em caso de vazamento de dados, mas não impede que um atacante manipule uma consulta SQL para acessar ou modificar dados no banco.

Alternativa E — ✅ Correta ⟵ GABARITO

Empregar consultas preparadas (prepared statements) é a prática altamente recomendada para prevenir injeção de SQL. Essa técnica separa a estrutura da consulta dos dados fornecidos pelo usuário, tratando a entrada como dado e não como parte do comando SQL. O contexto de segurança de banco de dados destaca o uso de variáveis de ligação (parâmetros) como uma técnica de proteção contra ataques de injeção, além de melhorar o desempenho.

Sistemas de banco de dados (Elmasri & Navathe):

"O uso de variáveis de ligação (também conhecidas como parâmetros) protege contra ataques de injeção e também melhora o desempenho."

Gabarito: letra E

Link permanente: /questoes/qa542773