O que é SQL Injection?

SQL Injection (SQLi) e uma vulnerabilidade que permite que um atacante manipule as consultas SQL executadas por uma aplicação web. Quando dados fornecidos pelo usuário são incluídos diretamente em uma query sem sanitização adequada, um atacante pode inserir código SQL que altera a logica da consulta, permitindo desde o desvio de autenticação até a exfiltração completa do banco de dados.

O conceito foi documentado publicamente pela primeira vez em 1998 por Jeff Forristal em uma edição da revista Phrack, mas existia em forma exploravel muito antes disso. Vinte e oito anos depois, SQL Injection continua figurando no OWASP Top 10 e sendo encontrado em auditorias de empresas de todos os portes, de startups a bancos globais.

Em 2026, o relatorio State of Software Security da Veracode indica que aproximadamente 30% das aplicações testadas tinham alguma forma de SQL Injection. O relatorio da Verizon Data Breach Investigations Report (DBIR) aponta que SQLi e um dos vetores mais usados em brechas de dados confirmadas.

Como funciona o ataque

O mecanismo básico e a interpolação de entrada do usuário diretamente em uma string SQL. Considere o exemplo clássico de login inseguro em PHP:

$query = "SELECT * FROM users WHERE email='" . $_POST['email'] . "' AND password='" . $_POST['password'] . "'";

Se o usuário digitar no campo de email: admin'-- e qualquer coisa no campo de senha, a query resultante será:

SELECT * FROM users WHERE email='admin'--' AND password='qualquercoisa'

O duplo hifem (--) inicia um comentario SQL, ignorando o restante da query incluindo a verificação de senha. O atacante autentica como administrador sem conhecer a senha.

Além do bypass de autenticação, técnicas mais avancadas permitem a exfiltração de dados usando operadores como UNION SELECT, que une o resultado da query original com resultados de outras tabelas. Com tempo suficiente, um atacante pode mapear completamente o schema do banco, extrair todas as senhas, emails e dados pessoais, e em alguns bancos até executar comandos no sistema operacional (como no MySQL com LOAD_FILE e INTO OUTFILE, ou no SQL Server com xp_cmdshell).

Quem foi afetado

A lista de incidentes causados por SQL Injection e uma das maiores da historia da segurança da informação. Em 2009, o caso Albert Gonzalez resultou no roubo de 130 milhoes de números de cartao de credito via SQLi contra as redes Heartland Payment Systems e TJX Companies, resultando em condenação a 20 anos de prisao. Em 2012, um grupo vazou 6,5 milhoes de senhas do LinkedIn via SQLi combinado com hash MD5 sem salt. Em 2016, a Joomla sofreu um zero-day de SQLi afetando versões 3.2 a 3.4, com exploração massiva em menos de 24 horas após a divulgação.

Casos mais recentes incluem a brecha do banco Scotiabank em 2019 (repositórios internos expostos contendo credenciais de banco de dados), e multiplos ataques contra sistemas de saude durante a pandemia, onde SQLi foi usado para acessar registros medicos de pacientes.

Como identificar SQLi

A detecção manual começa com a inserção de apostrofes simples (') em campos de entrada. Se a aplicação retornar um erro de banco de dados como You have an error in your SQL syntax ou Unterminated string literal, o campo e potencialmente vulnerável.

Indicadores adicionais incluem: respostas diferentes ao inserir ' OR '1'='1 vs ' OR '1'='2 (comportamento booleano), atraso de tempo ao inserir '; WAITFOR DELAY '0:0:5'-- (no SQL Server) ou ' OR SLEEP(5)-- (no MySQL), e mensagens de erro que revelam o tipo de banco de dados em uso.

Para testes automatizados, o SQLMap e a ferramenta de referência. Ele detecta e explora automaticamente SQLi em dezenas de tipos de bancos de dados. Ferramentas comerciais como Burp Suite Pro e Acunetix também detectam SQLi com alta precisao. O TrustSiteMonitor inclui verificação de SQL Injection nas 26 fases de análise automatizada.

Como se proteger

A proteção definitiva contra SQL Injection e o uso de Prepared Statements (também chamados de Parameterized Queries). Nessa abordagem, a query SQL e enviada separadamente dos dados, sem possibilidade de os dados alterarem a estrutura da query.

Exemplo seguro em PHP com PDO: $stmt = $pdo->prepare('SELECT * FROM users WHERE email = ? AND password = ?'); $stmt->execute([$email, $password]);

Exemplo em Python com SQLAlchemy: result = db.execute(text('SELECT * FROM users WHERE email = :email'), {'email': email})

Exemplo em C# com Entity Framework: var user = context.Users.Where(u => u.Email == email).FirstOrDefault();

A segunda camada de defesa e o uso de ORMs (Object-Relational Mappers) como Hibernate, Sequelize, Prisma ou Entity Framework. Por padrão, ORMs usam queries parametrizadas em todas as operações, desde que você não use interpolação de strings direta em queries raw.

Terceira camada: principio do mínimo privilegio no banco de dados. O usuário de banco de dados usado pela aplicação não deve ter permissões de DROP TABLE, CREATE TABLE ou acesso a tabelas de sistema. Se um SQLi ocorrer, o impacto fica limitado ao que o usuário tem acesso.

Quarta camada: WAF (Web Application Firewall). Cloudflare, AWS WAF e soluções similares possuem regras específicas para detecção de SQLi baseadas em assinaturas conhecidas. Não substitui prepared statements, mas adiciona uma camada de detecção.

Comparação com evolução histórica

A evolução do SQL Injection ao longo de 25 anos reflete tanto a sofisticação dos atacantes quanto a resistencia da industria em adotar boas práticas. Nos anos 2000, a maioria dos ataques era baseada em UNION SELECT simples e gerava erros visíveis. Entre 2010 e 2020, técnicas de Blind SQL Injection se popularizaram: o atacante infere dados sem receber erros, usando respostas booleanas (páginas diferentes para verdadeiro/falso) ou atrasos de tempo. Em 2020 em diante, SQLi em APIs JSON se tornou prevalente, pois muitos desenvolvedores não percebem que parâmetros JSON em requisições POST são igualmente vulneráveis se interpolados em queries.

Análise técnica

O CVSS base score de um SQLi tipico e de 9.8 (Critical) para exploração sem autenticação que resulta em exfiltração de dados: vetor de ataque Network, complexidade Baixa, privilegios Nenhum, interação do usuário Nenhuma, escopo Inalterado, e impactos de Confidencialidade/Integridade/Disponibilidade Altos.

CVEs notáveis relacionados: CVE-2012-1823 (PHP CGI) permitia execução de código via SQLi. CVE-2019-0232 (Apache Tomcat CGI) combinava SQLi com Command Injection. CVE-2023-23752 (Joomla) permitia leitura de configurações de banco via SQLi não autenticado.

Impacto e consequencias

As consequencias de um SQL Injection bem sucedido variam de acordo com as permissões do usuário de banco, mas no pior caso incluem: exfiltração completa de todos os dados do banco (usuários, senhas, dados pessoais, financeiros), alteração ou exclusao de registros, bypass total de autenticação (acesso como qualquer usuário sem senha), em bancos menos restritivos execução de comandos no sistema operacional, e em alguns casos pivoting para outros sistemas internos.

Do ponto de vista legal e regulatório, um vazamento causado por SQLi pode resultar em multas de até 2% do faturamento global anual pelo GDPR europeu, até 2% do faturamento pelo LGPD brasileiro, além de processos civis de clientes afetados e danos reputacionais duradouros.

Dicas práticas e boas práticas

Checklist imediato contra SQL Injection:

1. Revise todas as queries SQL no código, especialmente as que concatenam strings com variaveis: pesquise por "SELECT" + "+ ou f"SELECT no código e elimine qualquer interpolação direta.

2. Ative o modo de log de erros detalhado apenas em desenvolvimento, nunca em produção. Mensagens de erro de banco expostas ao usuário são tanto um vetor de informação para ataques quanto um indicador de SQLi potencial.

3. Configure o usuário de banco de dados da aplicação com apenas as permissões necessarias: SELECT, INSERT, UPDATE, DELETE nas tabelas específicas. Nenhuma permissão de DDL (CREATE, DROP, ALTER).

4. Implemente WAF na frente da aplicação com regras OWASP Core Rule Set (CRS) habilitadas.

5. Rode o SQLMap contra seu próprio ambiente de staging periodicamente: sqlmap -u "https://staging.seusite.com/busca?q=teste" --batch --level=3

6. Para APIs: valide e sanitize parâmetros JSON com o mesmo rigor de parâmetros de formulario HTML.

7. Habilite o modo de parâmetros estritamente tipados no ORM: em TypeORM, use QueryBuilder parametrizado; em Prisma, evite o metodo queryRaw sem parâmetros.

Conclusao: o que fazer agora

A primeira ação prática e executar uma busca no repositório do seu projeto por todos os locais onde queries SQL são construidas. Em Node.js, busque por db.query(` ou pool.query(`. Em Python, busque por cursor.execute(f". Em PHP, busque por mysql_query(" e mysqli_query(. Cada ocorrencia com interpolação de variavel e um candidato a SQLi.

Para sistemas legados onde a migração para prepared statements seria extensa, considere um WAF como solução temporária enquanto o refactoring acontece, e priorize as rotas de autenticação e busca como as de maior risco.

Use o TrustSiteMonitor para identificar endpoints vulneráveis automaticamente: o scanner testa os 10 parâmetros mais comuns de cada página contra payloads de SQL Injection e reporta evidências concretas para orientar a correção.