Pular para o conteúdo principal

Questão de Banco de Dados — Segurança — FCC 2025

Banco de DadosSegurança
Código
fc074950
Banca
FCC
Órgão
TRT - 15ª Região (SP)
Ano
2025
Nível
Médio
Cargo
Técnico Judiciário - Área Apoio Especializado - Especialidade Tecnologia da Informação
Durante o desenvolvimento de um sistema web, é necessário garantir que o software seja seguro e resistente a ataques. Para isso, utilizam-se as melhores práticas de desenvolvimento seguro baseadas em SDL, OWASP CLASP e sua evolução. Para proteger uma aplicação contra ataques de injeção SQL, é crucial
  1. AUtilizar prepared statements com parameterized queries para interagir com o banco de dados, de forma que o banco de ados faça a distinção entre código e dados, independentemente da entrada fornecida pelo usuário.
  2. Bremover todas as stored procedures do código, como recomendado pelo CLASP, pois estas são a principal fonte de ataque e deixam a aplicação vulnerável.
  3. Cimplementar criptografia simétrica para todas as conexões com o banco de dados e criar filtros personalizados no código para identificar entradas maliciosas após a execução da consulta.
  4. Dcriar uma rotina que faça um backup automático dos logs antes de executar qualquer consulta SQL, garantindo que qualquer tentativa de injeção possa ser rastreada, conforme recomenda o CLASP.
  5. Eutilizar funções eval () em JavaScript para processar dados do lado do cliente, garantindo que entradas SQL possam ser interpretadas de forma segura no servidor.
Revelar gabarito e comentário

GabaritoA — Utilizar prepared statements com parameterized queries para interagir com o banco de dados, de forma que o banco de ados faça a distinção entre código e dados, independentemente da entrada fornecida pelo usuário.

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

Proteção contra Injeção SQL

Gabarito: letra A. A melhor prática para evitar injeção SQL é utilizar prepared statements com parameterized queries, pois eles garantem que a entrada do usuário seja tratada como dado, não como código SQL. Essa é a recomendação central do OWASP e do SDL (Security Development Lifecycle).

A questão testa conhecimentos sobre desenvolvimento seguro, especificamente as práticas do OWASP CLASP. A banca espera que o candidato saiba que a separação entre código e dados é o princípio fundamental contra injeção SQL.

Proteção contra injeção SQL
  • 1Técnica principal
    • Prepared statements
    • Parameterized queries
    • SGBD distingue código de dados
  • 2Práticas incorretas
    • Remover stored procedures
    • Filtro após execução
    • Backup de logs
    • eval() no cliente
LEVEL · soulevel.com.br

Alternativa A — ✅ Correta ⟵ GABARITO

O uso de prepared statements com parâmetros (também chamados de consultas parametrizadas) faz com que o SGBD distinga automaticamente entre a estrutura SQL e os valores fornecidos pelo usuário. Mesmo que o usuário insira uma string maliciosa, ela será tratada como dado literal, neutralizando o ataque. É a técnica mais eficaz e recomendada por todas as principais referências de segurança (OWASP, CLASP, SDL).

Alternativa B — ❌ Incorreta

A afirmação de que se deve "remover todas as stored procedures" é falsa. Stored procedures, quando implementadas com parâmetros (como em CREATE PROCEDURE ... @param ...), também podem ser seguras e, na verdade, são uma das formas de defesa contra injeção SQL. O CLASP não recomenda removê-las; ao contrário, recomenda o uso de parâmetros em stored procedures. O erro está em considerar stored procedures como a principal fonte de ataque, o que não é verdade.

Alternativa C — ❌ Incorreta

Criptografia simétrica para conexões (como SSL/TLS) protege os dados em trânsito, mas não impede injeção SQL. Além disso, criar filtros personalizados no código para identificar entradas maliciosas após a execução da consulta é ineficaz, pois o ataque já teria ocorrido. A recomendação é filtrar/parametrizar antes da execução, não depois. A alternativa mistura conceitos de segurança de rede com prevenção de injeção.

Alternativa D — ❌ Incorreta

Backup de logs não previne ataques de injeção; serve apenas para auditoria e rastreamento posterior. O CLASP não indica essa prática como medida preventiva. A injeção SQL deve ser bloqueada antes da execução, não apenas registrada. Portanto, a alternativa está fora do escopo de prevenção.

Alternativa E — ❌ Incorreta

Usar eval() em JavaScript para processar dados SQL é extremamente perigoso. eval() executa qualquer código JavaScript, abrindo portas para ataques XSS e outras vulnerabilidades. Além disso, processar SQL no lado do cliente expõe a lógica do banco de dados e não é uma prática de segurança. Nunca se deve usar eval() para manipular comandos SQL.

Gabarito: letra A.

Link permanente: /questoes/fc074950