Injeção de SQL: como funciona e a defesa com parâmetros

A injeção de SQL (SQL injection) ocorre quando uma aplicação monta um comando SQL juntando texto digitado pelo usuário e o banco não consegue distinguir o que é dado do que é código. O resultado pode ser burlar um login, ler informações que não deveria ou alterar registros. É um ataque clássico de segurança da informação, cobrado tanto em informática quanto em provas de TI. O exemplo abaixo foi executado em um banco de teste local, com dados fictícios, e serve apenas para estudar a defesa.

O cenário: um login ingênuo

Suponha a tabela usuario, com duas linhas fictícias: maria (senha s3cr3ta) e joao (senha abc123). O código da aplicação monta a consulta assim, concatenando o que o usuário digitou:

SELECT login FROM usuario WHERE login = '<digitado>' AND senha = '<digitado>'

Com entradas legítimas, o comportamento é o esperado:

Login digitado	Senha digitada	Consulta final	Resultado
maria	s3cr3ta	... login='maria' AND senha='s3cr3ta'	maria entra
maria	x	... login='maria' AND senha='x'	ninguém

Quando a entrada vira código

O atacante digita no campo de login o texto maria' -- e qualquer senha. A consulta montada fica:

SELECT login FROM usuario WHERE login='maria' --' AND senha='x'

Os dois hífens iniciam um comentário em SQL: tudo à direita é ignorado, inclusive a verificação da senha. No teste, a consulta devolveu maria. O atacante entrou como maria sem saber a senha. Ele tomou a aspa simples do dado e a transformou em fechamento de texto, o que muda a estrutura da consulta.

Outra variação: o login x' OR '1'='1' -- produz a condição login='x' OR '1'='1', sempre verdadeira, e a consulta devolveu as duas contas. Um detalhe instrutivo: a versão sem os hífens (x' OR '1'='1) não devolveu nada no teste, porque o AND tem precedência sobre o OR e a condição da senha continuou valendo para o segundo termo. Isso mostra que o ataque depende do contexto e de como a consulta é montada, mas a causa raiz é sempre a mesma.

Por que acontece

A causa é misturar canais: o comando e o dado seguem juntos no mesmo texto. Quando o texto do usuário é interpretado como parte da sintaxe SQL, ele passa a mandar no banco. O problema não está no SQL, e sim na forma como a aplicação constrói a consulta. Essa falha entra na categoria geral de falhas de validação de entrada, que se aplica também a outros interpretadores, como comandos do sistema operacional.

A defesa principal: consulta parametrizada

Na consulta parametrizada (também chamada de instrução preparada), o comando é enviado ao banco com marcadores no lugar dos valores, e os valores seguem separados:

SELECT login FROM usuario WHERE login = ? AND senha = ?

O banco compila a estrutura antes de receber os dados, de modo que o conteúdo digitado é sempre tratado como valor, nunca como sintaxe. Repetimos os mesmos ataques contra a versão parametrizada:

Entrada no login	Resultado
maria' -- (senha x)	ninguém entra
x' OR '1'='1 (senha x)	ninguém entra
maria e s3cr3ta	maria entra

O texto malicioso foi comparado literalmente com os logins existentes e, claro, não bateu com nenhum. Quem constrói as consultas deve usar parâmetros em vez de concatenação, seja em código direto, seja em bibliotecas que geram SQL. Procedimentos armazenados (stored procedures) também ajudam, desde que não montem SQL por concatenação internamente.

Defesas complementares

Parametrizar é a defesa central, mas segurança é em camadas:

• Validação de entrada: aceitar apenas o formato esperado (um número de processo, por exemplo). Ajuda, mas não substitui a parametrização.
• Privilégio mínimo: a conta que a aplicação usa no banco deve ter só as permissões necessárias. Uma conta que não pode apagar tabelas limita o estrago. Veja também controle de acesso e medidas de segurança.
• Mensagens de erro genéricas: não mostrar ao usuário o texto de erro do banco, que revela estrutura interna.
• Senhas com hash: nunca guardar senha em texto puro, como na tabela simplificada do exemplo; o conceito de hash está em criptografia: chave simétrica, assimétrica e assinatura digital.
• Revisão de código e testes de segurança periódicos.
• Atualização do sistema gerenciador e das bibliotecas.

Firewalls de aplicação web podem bloquear padrões conhecidos, mas não corrigem a falha no código. Tratar isso como defesa única é erro.

Como a prova cobra

Questões típicas afirmam coisas como “a injeção de SQL explora falha de validação de entradas” (correto), “é eliminada com o uso de antivírus” (errado: antivírus protege a máquina, não corrige a aplicação) ou “a consulta parametrizada separa dados de comando” (correto). Outra variação é associar o ataque ao tipo errado: injeção de SQL não é malware nem ataque de negação de serviço, e sim exploração de falha na aplicação; os demais tipos estão em segurança da informação: ameaças, malware e golpes digitais.

Erros comuns

• Achar que o problema é a linguagem SQL e não a montagem do texto.
• Achar que trocar aspas ou “escapar caracteres à mão” é equivalente a parametrizar.
• Confiar só no filtro do navegador: validações no lado do cliente podem ser contornadas.
• Dar ao banco uma conta administrativa para a aplicação.
• Pensar que apenas campos de login são vulneráveis: qualquer entrada que chega ao SQL pode ser.

Fontes e atualização

O assunto é de segurança de software e não tem norma oficial brasileira específica; para o tratamento de incidentes e dados pessoais, consulte a Lei 13.709/18 (LGPD) no portal do Planalto, que trata de segurança no tratamento de dados. O exemplo foi executado em um banco de teste local e serve só para estudo. Confira o edital para o nível de detalhe cobrado.

Próximos passos

• Estude os comandos em SQL: DDL, DML, DCL e TCL.
• Revise a base em bancos de dados: chaves, normalização, SQL e transações.
• Veja as defesas de rede em firewall, IDS/IPS, VPN e MFA.