SQL Injection: o que é, como funciona, exemplos e como prevenir

Introdução

SQL Injection (SQLi) é uma vulnerabilidade de segurança que permite a um atacante interferir nas consultas SQL que uma aplicação envia ao banco de dados. Ao manipular entradas do usuário que são concatenadas diretamente em instruções SQL, o invasor consegue ler, modificar ou excluir dados aos quais não deveria ter acesso, e, em cenários críticos, comprometer completamente o servidor.

Mesmo depois de mais de duas décadas desde sua primeira documentação, SQL Injection permanece entre as vulnerabilidades mais exploradas do mundo. O OWASP Top 10 classifica Injection como parte da categoria A03:2021, Injection, reconhecendo que falhas de injeção continuam sendo um dos vetores mais recorrentes em violações de dados corporativos. Segundo o Verizon DBIR, ataques a aplicações web respondem por uma parcela significativa dos incidentes anuais, e SQL Injection e frequentemente o ponto de entrada.

Este artigo explica em profundidade o que é SQL Injection, como o ataque funciona na prática com exemplos de código, quais são os tipos existentes, qual o impacto real em organizações, como prevenir SQLi com técnicas comprovadas e como ferramentas de DAST autenticado, especificamente o WebAppScan da EcoTrust, detectam e evidenciam essa vulnerabilidade antes que ela seja explorada.

---

O que é SQL Injection, definição técnica

Leia também: DAST: o que é, como funciona e por que o teste autenticad...

SQL Injection é um tipo de ataque de injeção de código no qual o invasor insere ou "injeta" instruções SQL maliciosas em campos de entrada de uma aplicação (formulários, parâmetros de URL, cookies, cabecalhos HTTP) que são processados pelo banco de dados sem a devida sanitização.

A raiz do problema é simples: a aplicação constroi consultas SQL concatenando diretamente dados fornecidos pelo usuário com o código SQL, sem separar dados de instruções. Quando essa separação não existe, o banco de dados interpreta a entrada do atacante como parte legítima da consulta.

Exemplo simplificado de SQL Injection

Considere uma página de login que recebe usuário e senha e executa a seguinte consulta no backend:

SELECT * FROM usuários WHERE username = 'admin' AND password = 'senha123';

Se a aplicação concatena diretamente o valor digitado no campo de usuário, o atacante pode inserir:

admin' OR '1'='1' --

A consulta resultante seria:

SELECT * FROM usuários WHERE username = 'admin' OR '1'='1' --' AND password = '';

A condição '1'='1' e sempre verdadeira. O trecho -- comenta o restante da query. O resultado: o atacante autentica-se sem conhecer a senha.

Esse exemplo básico ilustra o princípio central do SQL Injection: a aplicação não distingue entre dados do usuário e instruções SQL.

---

Como SQL Injection funciona, passo a passo

Leia também: DevSecOps: o que é, pilares e como implementar segurança ...

O fluxo de um ataque de SQL Injection segue etapas relativamente previsíveis:

1. Reconhecimento: o atacante identifica campos de entrada que interagem com o banco de dados, formulários de login, barras de busca, filtros, URLs com parâmetros como ?id=1.

2. Teste de injeção: caracteres especiais como aspas simples ('), aspas duplas ("), ponto-e-virgula (;) ou operadores lógicos (OR, AND) são inseridos para verificar se a aplicação retorna erros de banco de dados ou se o comportamento muda.

3. Extração ou manipulação: uma vez confirmada a vulnerabilidade, o atacante refina o payload para extrair dados, alterar registros, escalar privilegios ou executar comandos no sistema operacional.

Exemplo em código Python vulnerável

# CÓDIGO VULNERÁVEL, nunca use em produção
import sqlite3

def buscar_usuário(username):
    conn = sqlite3.connect('app.db')
    cursor = conn.cursor()
    query = "SELECT * FROM usuários WHERE username = '" + username + "'"
    cursor.execute(query)
    return cursor.fetchall()

O valor de username e concatenado diretamente na string SQL. Se o atacante enviar ' UNION SELECT username, password FROM admins --, a consulta retornara dados da tabela admins.

Exemplo em PHP vulnerável

// CÓDIGO VULNERÁVEL, nunca use em produção
$username = $_GET['username'];
$query = "SELECT * FROM usuários WHERE username = '$username'";
$result = mysqli_query($conn, $query);

O mesmo princípio se aplica: sem sanitização, qualquer entrada maliciosa será interpretada como SQL.

---

Tipos de SQL Injection

Existem diversas variações de SQL Injection, cada uma com características e níveis de complexidade distintos. A tabela a seguir resume os principais tipos:

Classic (In-Band) SQL Injection

É a forma mais comum e direta. O atacante envia o payload e recebe o resultado na mesma resposta HTTP. Inclui as subvariações Error-Based e Union-Based.

Exemplo Union-Based:

' UNION SELECT table_name, NULL FROM information_schema.tables --

Esse payload lista todas as tabelas do banco de dados se o número de colunas da consulta original corresponder ao da UNION.

Blind SQL Injection (Boolean-Based)

Quando a aplicação não exibe dados nem erros, o atacante infere informações com base em respostas condicionais:

' AND (SELECT SUBSTRING(username,1,1) FROM admins LIMIT 1) = 'a' --

Se a página retornar normalmente, a primeira letra do nome de usuário e "a". O atacante repete o processo para cada caractere.

Time-Based Blind SQL Injection

Variação do blind onde o atacante usa funções de atraso:

' AND IF(1=1, SLEEP(5), 0) --

Se a resposta demorar 5 segundos, a condição e verdadeira. Essa técnica é lenta, mas funciona mesmo quando a aplicação não revela nenhuma diferença visual entre respostas.

Second-Order SQL Injection

O payload e armazenado no banco (por exemplo, no campo "nome" de um cadastro) e só é executado quando outro módulo da aplicação usa aquele dado em uma consulta SQL sem sanitização. Essa variação e particularmente perigosa porque a injeção é a execução ocorrem em momentos e contextos diferentes, dificultando a detecção.

---

Impacto real de SQL Injection, estatisticas e casos

SQL Injection não é um problema teórico. As consequências de ataques bem-sucedidos incluem:

• Vazamento massivo de dados: registros de clientes, credenciais, dados financeiros e informações pessoais sensíveis expostos.
• Alteração ou exclusão de dados: atacantes podem modificar saldos, permissões, registros medicos ou deletar tabelas inteiras.
• Comprometimento total do servidor: em configurações permissivas, SQL Injection pode levar a execução remota de comandos no sistema operacional via funções como xp_cmdshell (SQL Server) ou LOAD_FILE / INTO OUTFILE (MySQL).
• Danos regulatórios e financeiros: violações de LGPD, GDPR e PCI DSS resultam em multas, processos judiciais e perda de confiança.

Números que dimensionam o problema

• O OWASP classifica Injection como A03:2021, com mais de 274.000 ocorrências mapeadas nos dados que sustentam o ranking.
• Segundo análises do Ponemon Institute, o custo médio de um data breach ultrapassou USD 4,45 milhões em 2023.
• O relatório da Akamai sobre segurança de aplicações web indica que SQL Injection representa consistentemente uma das três categorias de ataque mais frequentes contra aplicações web.
• Casos históricos notaveis incluem o ataque ao Heartland Payment Systems (2008, 130 milhões de cartões comprometidos) é o breach da TalkTalk (2015, dados de 157.000 clientes expostos), ambos com SQL Injection como vetor primário.

---

SQL Injection é o OWASP Top 10, A03:2021 Injection

Na versão 2021 do OWASP Top 10, as falhas de injeção foram consolidadas na categoria A03:2021, Injection, que abrange SQL Injection, NoSQL Injection, Command Injection, LDAP Injection e outras variações.

Os critérios do OWASP para essa classificação consideram:

• Prevalência: injeção aparece em um grande número de aplicações testadas.
• Exploitability: em muitos cenários, a exploração e trivial e pode ser automatizada.
• Impacto: o comprometimento potencial inclui confidencialidade, integridade e disponibilidade dos dados.

A recomendação central do OWASP para prevenir Injection e clara: nunca concatenar dados do usuário diretamente em instruções SQL. Em vez disso, usar consultas parametrizadas, ORMs e validação rigorosa de entrada.

---

Técnicas de prevenção contra SQL Injection

A prevenção eficaz de SQL Injection exige uma abordagem em camadas. Nenhuma técnica isolada é suficiente; a combinação de múltiplas defesas reduz drasticamente a superfície de ataque.

1. Consultas parametrizadas (Prepared Statements)

A defesa mais eficaz é fundamental contra SQL Injection. Consultas parametrizadas separam o código SQL dos dados fornecidos pelo usuário. O banco de dados trata os parâmetros exclusivamente como dados, nunca como instruções.

Exemplo em Python (seguro):

import sqlite3

def buscar_usuário(username):
    conn = sqlite3.connect('app.db')
    cursor = conn.cursor()
    cursor.execute("SELECT * FROM usuários WHERE username = ?", (username,))
    return cursor.fetchall()

Exemplo em Java (seguro):

String query = "SELECT * FROM usuários WHERE username = ?";
PreparedStatement stmt = connection.prepareStatement(query);
stmt.setString(1, username);
ResultSet rs = stmt.executeQuery();

Exemplo em PHP (seguro com PDO):

$stmt = $pdo->prepare("SELECT * FROM usuários WHERE username = :username");
$stmt->execute(['username' => $username]);
$result = $stmt->fetchAll();

Em todos os casos, o placeholder (? ou :username) garante que o valor do usuário é tratado como dado literal.

2. Uso de ORM (Object-Relational Mapping)

Frameworks ORM como Django ORM, SQLAlchemy, Hibernate e Eloquent geram consultas parametrizadas automaticamente. Ao usar a API do ORM em vez de SQL bruto, o risco de injeção cai drasticamente.

# Django ORM, seguro por padrão
usuário = Usuário.objects.filter(username=username_input).first()

O ORM não é infalivel, consultas raw SQL dentro do ORM ainda podem ser vulneráveis. A regra e: sempre use a API nativa do ORM para operações de banco.

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

Aplique validação rigorosa em todas as entradas do usuário:

• Whitelist de caracteres permitidos: se o campo espera um número inteiro, rejeite qualquer entrada que contenha caracteres não numéricos.
• Limitação de comprimento: restrinja o tamanho máximo de campos de entrada.
• Tipagem forte: converta entradas para o tipo esperado antes de usa-las em consultas.

# Validação de tipo
try:
    user_id = int(request.args.get('id'))
except ValueError:
    return "ID inválido", 400

Validação de entrada é uma camada complementar, não um substituto para consultas parametrizadas.

4. Web Application Firewall (WAF)

Um WAF analisa o tráfego HTTP e bloqueia requisições que contenham padrões conhecidos de SQL Injection. WAFs operam com regras baseadas em assinaturas e, cada vez mais, com modelos de detecção baseados em comportamento.

Limitações importantes:

• WAFs podem ser contornados com técnicas de ofuscação (encoding, comentarios inline, case alternation).
• Falsos positivos podem bloquear tráfego legítimo.
• O WAF é uma camada de defesa em profundidade, não a defesa primária.

5. Princípio do menor privilegio no banco de dados

Configure as permissões do usuário de banco de dados utilizado pela aplicação com o mínimo de privilegios necessários:

• A conta da aplicação não deve ter permissão para DROP, ALTER ou executar stored procedures administrativas.
• Use contas separadas para operações de leitura e escrita.
• Nunca use a conta root ou sa para conexões de aplicação.

Mesmo que um atacante consiga injetar SQL, o dano será limitado se a conta do banco tiver permissões restritas.

6. Escaping de saida e tratamento de erros

• Nunca exiba mensagens de erro do banco de dados para o usuário final. Erros detalhados revelam informações sobre a estrutura do banco (nomes de tabelas, colunas, versão do SGBD) que facilitam o ataque.
• Configure a aplicação para registrar erros internamente e retornar mensagens genéricas ao usuário.

7. Revisão de código e testes de segurança

• Inclua revisão de segurança no processo de code review, especificamente buscando concatenação de strings em consultas SQL.
• Utilize ferramentas de análise estática (SAST) para detectar padrões vulneráveis no código-fonte.
• Execute testes dinâmicos (DAST) regularmente para identificar vulnerabilidades em aplicações em execução.

---

Como o DAST detecta SQL Injection

O DAST (Dynamic Application Security Testing) detecta SQL Injection testando a aplicação em tempo de execução, sem acesso ao código-fonte. O processo funciona da seguinte forma:

1. Crawling: a ferramenta DAST navega pela aplicação, mapeando todos os endpoints, formulários, parâmetros de URL, cookies e cabecalhos que aceitam entrada do usuário.

2. Fuzzing com payloads de injeção: para cada ponto de entrada identificado, a ferramenta envia uma serie de payloads projetados para provocar comportamentos indicativos de SQL Injection, erros de banco, diferenças condicionais de resposta, atrasos temporais.

3. Análise de resposta: a ferramenta compara a resposta da aplicação com a baseline (resposta normal) para determinar se a injeção teve efeito. Indicadores incluem:

   • Mensagens de erro SQL na resposta (Error-Based).
   • Diferença no conteúdo da página para condições true/false (Boolean-Based Blind).
   • Atraso mensurável no tempo de resposta (Time-Based Blind).
   • Dados inesperados na resposta (Union-Based).

4. Confirmação e evidência: ferramentas DAST avançadas confirmam a vulnerabilidade com múltiplos payloads e geram evidências que incluem a requisição HTTP vulnerável, a resposta do servidor e, em alguns casos, sugestões de correção.

A importância do DAST autenticado

A maioria das funcionalidades de uma aplicação web está protegida por autenticação. Um DAST não autenticado só testa a superfície pública, formulários de login, páginas de contato, buscas abertas. O DAST autenticado faz login na aplicação e testa toda a superfície interna: dashboards, formulários de configuração, endpoints de API protegidos, áreas administrativas.

SQL Injection frequentemente existe em funcionalidades internas que manipulam dados sensíveis, filtros de relatórios, buscas em paineis administrativos, endpoints de API que recebem IDs ou parâmetros de consulta. Sem autenticação, o DAST simplesmente não alcança esses pontos.

---

Como o EcoTrust WebAppScan detecta e evidência SQL Injection

O WebAppScan é o módulo de DAST autenticado da plataforma EcoTrust, uma plataforma de IA Agêntica para CTEM (Continuous Threat Exposure Management). Diferente de scanners DAST genéricos, o WebAppScan foi projetado para fornecer evidências completas e acionáveis para cada vulnerabilidade detectada.

Capacidades específicas para SQL Injection

• Crawl autenticado completo: o WebAppScan autentica-se na aplicação e mapeia todos os endpoints acessíveis, incluindo áreas protegidas por login, fluxos multi-step e APIs REST.

• Motor de injeção abrangente: testa todos os tipos de SQL Injection (classic, error-based, union-based, blind boolean, blind time-based) com payloads adaptados para os principais SGBDs (MySQL, PostgreSQL, SQL Server, Oracle, SQLite).

• Evidência completa com request/response: para cada SQL Injection confirmada, o WebAppScan apresenta:

  • A requisição HTTP vulnerável completa (método, URL, headers, body com o payload).
  • A resposta do servidor que confirma a vulnerabilidade (erro SQL, dados extraidos, atraso temporal).
  • Código de correção sugerido, orientando o desenvolvedor sobre como remediar a falha específica.

• Integração com o ciclo CTEM: os achados do WebAppScan alimentam diretamente o fluxo de gestão de exposição da EcoTrust. Cada SQL Injection detectada e correlacionada com ativos, priorizada por risco real e rastreada até a remediação.

Integração com outros módulos da EcoTrust

A detecção de SQL Injection pelo WebAppScan não opera de forma isolada. A plataforma EcoTrust integra os resultados com:

• VulScan: o módulo de scan de vulnerabilidades de infraestrutura pode identificar configurações de banco de dados expostas ou versões de SGBD com vulnerabilidades conhecidas que amplificam o risco de SQL Injection.

• GVul: o módulo de gestão de vulnerabilidades consolida os achados de WebAppScan e VulScan, permitindo que a equipe de segurança visualize, priorize e acompanhe a remediação de SQL Injection junto com todas as outras vulnerabilidades do ambiente.

Essa visão unificada é um diferencial da abordagem CTEM: em vez de tratar SQL Injection como um achado isolado de um scan, a plataforma contextualiza a vulnerabilidade dentro da postura de segurança da organização.

---

Checklist prático de prevenção contra SQL Injection

Para equipes de desenvolvimento e segurança, a seguinte lista resume as ações essenciais:

1. Substituir toda concatenação de strings em consultas SQL por consultas parametrizadas ou prepared statements.
2. Utilizar ORM para operações de banco de dados e evitar queries SQL raw.
3. Implementar validação de entrada com whitelist de caracteres e tipagem forte.
4. Configurar o princípio do menor privilegio nas contas de banco de dados da aplicação.
5. Desabilitar a exibição de erros detalhados do banco de dados em ambiente de produção.
6. Implantar um WAF como camada adicional de proteção.
7. Executar testes DAST autenticados regularmente com ferramentas como o WebAppScan da EcoTrust.
8. Incluir revisão de segurança no processo de code review, com foco em padrões de injeção.
9. Manter banco de dados e frameworks atualizados com os patches de segurança mais recentes.
10. Treinar a equipe de desenvolvimento em práticas de codificação segura e conscientização sobre OWASP Top 10.

---

FAQ, Perguntas frequentes sobre SQL Injection

O que é SQL Injection? SQL Injection é uma vulnerabilidade que permite a um atacante inserir instruções SQL maliciosas em campos de entrada de uma aplicação, interferindo nas consultas enviadas ao banco de dados. O ataque explora a falta de separação entre dados do usuário e código SQL.

Quais são os tipos de SQL Injection? Os principais tipos são: Classic (In-Band), que inclui Error-Based e Union-Based; Blind SQL Injection, que inclui Boolean-Based e Time-Based; Second-Order, onde o payload e armazenado e executado posteriormente; e Out-of-Band, que utiliza canais alternativos para exfiltração de dados.

Como prevenir SQL Injection? A prevenção mais eficaz é o uso de consultas parametrizadas (prepared statements) que separam dados de instruções SQL. Medidas complementares incluem uso de ORM, validação de entrada, princípio do menor privilegio no banco, WAF e testes DAST autenticados regulares.

SQL Injection ainda é relevante em 2026? Sim. Apesar de ser uma vulnerabilidade conhecida há mais de 20 anos, SQL Injection contínua figurando no OWASP Top 10 e sendo explorada em violações de dados significativas. A persistência se deve a aplicações legadas, falta de treinamento em codificação segura e testes de segurança insuficientes.

O que é OWASP A03 Injection? A03:2021, Injection e a terceira categoria do OWASP Top 10 (versão 2021), que engloba SQL Injection, NoSQL Injection, Command Injection, LDAP Injection e outras formas de injeção de código. A classificação reflete a alta prevalência é o impacto crítico dessas vulnerabilidades.

Qual a diferença entre SQL Injection e Cross-Site Scripting (XSS)? SQL Injection injeta instruções no banco de dados; XSS injeta scripts maliciosos no navegador do usuário. SQLi compromete dados no backend; XSS compromete a sessão e os dados do usuário no frontend. Ambos são vulnerabilidades de injeção, mas com vetores e alvos diferentes.

Como o DAST detecta SQL Injection? O DAST envia payloads de injeção nos campos de entrada da aplicação em execução e analisa as respostas para identificar indicadores de vulnerabilidade: erros de banco de dados, diferenças condicionais de conteúdo, atrasos temporais e dados inesperados na resposta.

Por que o DAST autenticado é importante para detectar SQL Injection? A maior parte das funcionalidades de uma aplicação web está protegida por autenticação. SQL Injection frequentemente existe em áreas internas (dashboards, relatórios, APIs protegidas) que um DAST não autenticado não consegue alcançar. O DAST autenticado testa toda a superfície da aplicação.

---

Para aprofundamento, consulte a referência oficial: OWASP — Open Worldwide Application Security Project.

Conclusão

SQL Injection permanece como uma das vulnerabilidades mais críticas e recorrentes em aplicações web. A combinação de facilidade de exploração, impacto devastador e persistência em ambientes corporativos torna a prevenção e detecção de SQLi uma prioridade absoluta para qualquer equipe de segurança.

A prevenção começa no código, com consultas parametrizadas, ORMs e validação rigorosa, e se estende para a infraestrutura com princípio do menor privilegio e WAFs. Mas a defesa só é completa quando inclui testes continuos que validem a segurança da aplicação em tempo real.

O WebAppScan da EcoTrust oferece exatamente isso: DAST autenticado que detecta SQL Injection em toda a superfície da aplicação, com evidências completas, requisição vulnerável, resposta do servidor e código de correção, integradas ao ciclo CTEM da plataforma. Isso significa que cada vulnerabilidade detectada e priorizada por risco real e rastreada até a remediação efetiva.

Conheça o WebAppScan e veja como a EcoTrust detecta SQL Injection com evidências completas.