Questão de Segurança da Informação — Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.) — FCC 2025

SQL Injection: a defesa correta é a separação entre código e dados

Gabarito: letra D. Para proteger uma aplicação contra injeção SQL, a medida mais eficaz é o uso de prepared statements com parameterized queries, pois o banco de dados passa a distinguir claramente o código SQL da entrada do usuário, tratando-a como dado — independentemente do conteúdo malicioso fornecido. Essa é a recomendação central das boas práticas de desenvolvimento seguro, incluindo o OWASP, e está alinhada ao princípio de manter dados separados de comandos e consultas.

A injeção de SQL (SQLi) é uma vulnerabilidade de segurança web que permite a um invasor interferir nas consultas que uma aplicação faz ao seu banco de dados. Isso pode permitir que o invasor visualize dados que normalmente não poderia acessar, incluindo informações de outros usuários, ou quaisquer outros dados que a aplicação possa acessar. Em muitos casos, um invasor pode modificar ou deletar esses dados, causando alterações persistentes no conteúdo ou comportamento da aplicação.

A vulnerabilidade surge quando os dados fornecidos pelo usuário não são validados, filtrados ou higienizados, e quando as consultas são dinâmicas ou chamadas não parametrizadas sem escape — ou seja, quando dados hostis são usados diretamente ou concatenados em comandos SQL. O atacante consegue inserir uma série de instruções SQL dentro de uma consulta (query) através da manipulação das entradas de dados de uma aplicação.

A prevenção mais robusta é justamente o uso de consultas parametrizadas, que mantêm os dados separados de comandos e consultas. Com prepared statements, o código SQL é definido primeiro, com placeholders para os valores; depois, os valores são enviados separadamente ao banco, que os trata como dados puros, jamais como parte executável do comando. Isso neutraliza a injeção mesmo que o usuário digite algo como ' OR '1'='1 — o banco interpretará isso como uma string literal, não como condição SQL.

Outras medidas complementares incluem a validação rigorosa de entrada (embora não seja uma defesa completa, pois muitos aplicativos exigem caracteres especiais), o escape adequado de caracteres especiais e o uso de LIMIT e outros controles SQL nas consultas para evitar divulgação em massa. No entanto, nenhuma dessas é tão eficaz quanto a parametrização, que ataca a raiz do problema: a indistinção entre código e dado.

A banca explora aqui a confusão entre medidas periféricas (criptografia, backup, remoção de stored procedures) e a defesa estrutural correta. Guarde o critério: a proteção contra SQLi depende de separar o código da entrada do usuário — é exatamente isso que as alternativas tentam distorcer.

Alternativa A — ❌ Incorreta

Implementar criptografia simétrica para todas as conexões com o banco de dados protege os dados em trânsito (confidencialidade), mas não impede que uma entrada maliciosa seja interpretada como código SQL. Além disso, criar filtros personalizados após a execução da consulta é inútil: o dano já teria ocorrido. A validação/filtragem deve acontecer antes da execução, e a criptografia não tem relação com a neutralização de injeção SQL.

Alternativa B — ❌ Incorreta

Criar uma rotina de backup automático dos logs antes de executar qualquer consulta SQL é uma medida de rastreabilidade e auditoria, mas não previne a injeção SQL. O CLASP recomenda atividades de segurança no desenvolvimento, mas não sugere backup de logs como defesa contra SQLi. A alternativa confunde detecção/rastreamento com prevenção — o backup pode ajudar a investigar um ataque depois, jamais a impedi-lo.

Alternativa C — ❌ Incorreta

Utilizar funções eval() em JavaScript para processar dados do lado do cliente é uma prática extremamente insegura e não tem relação com a proteção contra SQL injection. O eval() executa código arbitrário no navegador, o que pode introduzir vulnerabilidades de XSS, e não interfere na forma como o servidor monta consultas SQL. A segurança contra SQLi deve ser tratada no lado do servidor, na camada de acesso a dados, não no cliente.

Alternativa D — ✅ Correta ⟵ GABARITO

Utilizar prepared statements com parameterized queries é a defesa mais eficaz contra injeção SQL. O banco de dados recebe o comando SQL com placeholders e, em seguida, os valores separadamente, tratando-os como dados — o que impede que a entrada do usuário seja interpretada como parte do código. Essa técnica implementa exatamente o princípio de "manter os dados separados de comandos e consultas", citado como prevenção no OWASP. Independentemente da entrada fornecida, ela jamais será executada como SQL.

Alternativa E — ❌ Incorreta

Remover todas as stored procedures do código não é recomendado pelo CLASP e não é uma medida de segurança. Stored procedures, quando usadas corretamente com parâmetros, podem até reduzir o risco de SQLi, pois encapsulam a lógica de acesso a dados. A alternativa inverte a recomendação: o problema não é a stored procedure em si, mas a forma como as consultas são construídas (concatenação de strings). A remoção não elimina a vulnerabilidade e pode até piorar a situação se o código passar a usar consultas dinâmicas concatenadas.

Gabarito: letra D — a única alternativa que ataca a causa raiz da injeção SQL, separando código de dados por meio de prepared statements com parameterized queries.