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

SQL Injection: prevenção por queries parametrizadas

Gabarito: letra A. A forma mais eficaz de evitar SQL Injection é utilizar queries parametrizadas, nas quais o código SQL é definido separadamente dos valores fornecidos pelo usuário, impedindo que entradas maliciosas sejam interpretadas como parte da instrução SQL. Essa técnica é amplamente recomendada por frameworks de segurança, como o OWASP, e é a base do desenvolvimento seguro de aplicações web.

O SQL Injection é um ataque que explora a falta de separação entre dados e comandos em consultas SQL. Quando uma aplicação concatena diretamente a entrada do usuário em uma string SQL, o atacante pode inserir comandos maliciosos que serão executados pelo banco de dados. Por exemplo, em um campo de login, o usuário poderia digitar ' OR '1'='1 e, se a consulta for montada por concatenação, o banco interpretaria a condição como sempre verdadeira, permitindo acesso sem senha válida.

A query parametrizada resolve esse problema ao tratar os valores como dados, não como parte do comando SQL. O banco de dados compila a estrutura da consulta primeiro e, depois, insere os parâmetros de forma segura, sem que eles possam alterar a lógica da instrução. Essa é a técnica mais recomendada e é suportada por praticamente todas as linguagens de programação e frameworks de acesso a banco de dados (como PDO no PHP, PreparedStatement no Java, e parâmetros em ADO.NET).

Além das queries parametrizadas, outras medidas complementares incluem a validação rigorosa de entrada (whitelist), o escape adequado de caracteres especiais e o uso de procedimentos armazenados com parâmetros. No entanto, a parametrização é a defesa mais robusta, pois elimina a possibilidade de injeção na raiz, independentemente do conteúdo da entrada.

A banca explora aqui a confusão entre medidas de segurança de rede e de aplicação. O SQL Injection é uma vulnerabilidade de código, não de infraestrutura. Portanto, medidas como antivírus, HTTPS ou a escolha de um SGBD pago não têm relação direta com a prevenção desse ataque. O candidato que não domina o conceito pode ser atraído por alternativas que parecem "seguras", mas que não atacam o problema real.

Guarde o critério decisivo: SQL Injection se previne no código da aplicação, separando dados de comandos. É exatamente essa separação que a alternativa correta descreve, e é a ausência dela que torna as demais incorretas.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa descreve com precisão a técnica de queries parametrizadas: o código SQL é definido de forma separada dos valores usados como parâmetros. Isso impede que a entrada do usuário seja interpretada como parte da instrução SQL, eliminando a vulnerabilidade de injeção. É a medida mais eficaz e amplamente recomendada por padrões de segurança, como o OWASP Top 10.

Alternativa B — ❌ Incorreta

Instalar um antivírus no servidor web protege contra malwares (vírus, worms, trojans), mas não tem relação com a prevenção de SQL Injection. O SQL Injection é uma vulnerabilidade de lógica de aplicação, explorada por meio de entradas malformadas, e não um malware que o antivírus detectaria. A banca usa essa alternativa para testar se o candidato confunde medidas de proteção de endpoint com segurança de código.

Alternativa C — ❌ Incorreta

O HTTPS (HTTP sobre TLS) garante a confidencialidade e integridade da comunicação entre cliente e servidor, protegendo contra interceptação e adulteração de dados em trânsito. No entanto, ele não protege a aplicação contra SQL Injection, pois a injeção ocorre no processamento da consulta no servidor, independentemente de a comunicação ser criptografada. Um atacante pode enviar payloads maliciosos por HTTPS normalmente. A alternativa confunde segurança de transporte com segurança de aplicação.

Alternativa D — ❌ Incorreta

Não utilizar JavaScript no website não tem relação com SQL Injection. O JavaScript é uma linguagem de client-side (executada no navegador), enquanto o SQL Injection explora vulnerabilidades no processamento server-side das consultas ao banco de dados. A ausência de JavaScript não impede que um atacante manipule parâmetros de requisições HTTP. Essa alternativa é um distrator que mistura tecnologias de front-end com segurança de back-end.

Alternativa E — ❌ Incorreta

A escolha entre SGBDs gratuitos ou pagos não influencia a prevenção de SQL Injection. A vulnerabilidade está na forma como a aplicação constrói as consultas, não no SGBD em si. Tanto SGBDs gratuitos (MySQL, PostgreSQL) quanto pagos (Oracle, SQL Server) podem ser alvo de injeção se a aplicação não usar parâmetros. A segurança depende do código da aplicação, não do custo do banco de dados.

Gabarito: letra A