Injeção de SQL: Vulnerabilidades e Como Se Prevenir
O que é Injeção de SQL?
A injeção de SQL (SQLi) é uma das vulnerabilidades de segurança de aplicações mais críticas e prevalentes da atualidade. Ela permite que atacantes mal-intencionados assumam o controle do banco de dados de uma aplicação – possibilitando acesso não autorizado, exclusão de dados, alteração do comportamento da aplicação baseado em dados, e outras ações indesejadas – ao enganar a aplicação para que execute comandos SQL inesperados.
Quando uma aplicação utiliza dados não confiáveis, como informações inseridas em campos de formulários web, parâmetros de URL ou cookies, como parte de uma consulta ao banco de dados sem a devida validação, ela cria uma oportunidade para ataques de SQL Injection. O invasor pode então inserir seus próprios comandos SQL, que o banco de dados executará como se fossem parte da consulta legítima.
Apesar de serem relativamente fáceis de prevenir, as vulnerabilidades de SQLi continuam sendo uma das principais ameaças à segurança de aplicações web. Muitas organizações permanecem vulneráveis a violações de dados potencialmente devastadoras resultantes deste tipo de ataque.
Como os Atacantes Exploram Vulnerabilidades de SQLi
Os invasores fornecem entradas cuidadosamente elaboradas para enganar a aplicação, modificando as consultas SQL que ela envia ao banco de dados. Isto permite que o atacante:
- Controle o comportamento da aplicação baseado em dados do banco, por exemplo, enganando um sistema de login para permitir acesso sem uma senha válida
- Altere dados no banco sem autorização, criando registros fraudulentos, adicionando usuários, elevando privilégios de usuários existentes ou excluindo informações críticas
- Acesse dados sem permissão, manipulando consultas para retornar mais informações do que deveriam
- Execute comandos administrativos no banco de dados, como desligar o serviço, criar novos usuários do banco ou acessar o sistema de arquivos subjacente
Anatomia de um Ataque de SQL Injection
Um ataque de SQLi geralmente se desenvolve em três etapas distintas:
1. Reconhecimento e Sondagem
O invasor testa a aplicação enviando valores inesperados nos campos suspeitos e observa cuidadosamente as respostas. Isso pode incluir:
- Inserir caracteres especiais como aspas simples (')
- Adicionar operadores SQL como OR 1=1
- Inserir comentários SQL (-- ou /*)
- Provocar erros intencionais para analisar mensagens de erro do banco
2. Determinação da Vulnerabilidade
Baseado nas respostas, o invasor identifica:
- O tipo de banco de dados em uso (MySQL, Oracle, SQL Server, etc.)
- A estrutura da consulta original
- As tabelas e colunas disponíveis
- Como explorar a vulnerabilidade de forma eficaz
3. Exploração e Ataque
O invasor executa o ataque propriamente dito, fornecendo um valor cuidadosamente elaborado que será interpretado como parte do comando SQL, não apenas como dado. O banco de dados então executa o comando modificado pelo invasor.
Vale ressaltar que estas etapas podem ser facilmente automatizadas por ferramentas disponíveis publicamente, como sqlmap, tornando a exploração ainda mais acessível para atacantes com conhecimentos técnicos limitados.
Tipos Comuns de Ataques SQL Injection
Injeção Baseada em Erro
O invasor força o banco de dados a gerar erros que revelam informações sobre sua estrutura. Por exemplo:
' AND 1=CONVERT(int, @@version)--Injeção Baseada em União (UNION)
Utiliza o operador UNION para combinar resultados de consultas diferentes:
' UNION SELECT username, password FROM users--Injeção Cega (Blind SQL Injection)
Quando a aplicação não mostra resultados ou erros, o invasor faz perguntas verdadeiro/falso ao banco:
' AND (SELECT ASCII(SUBSTRING(username,1,1)) FROM users WHERE id=1) > 100--Injeção Baseada em Tempo
Uma variação da injeção cega que usa atrasos para inferir informações:
'; IF (SELECT COUNT(*) FROM users) > 100 WAITFOR DELAY '0:0:5'--Injeção de Segunda Ordem
O payload malicioso é armazenado no banco e executado posteriormente em outro contexto, tornando a detecção mais difícil.
Defendendo-se Contra Ataques de SQLi
Existem várias estratégias eficazes para evitar a introdução de vulnerabilidades SQLi em aplicações e limitar os danos que elas podem causar.
1. Use Consultas Parametrizadas (Prepared Statements)
Esta é a defesa mais eficaz contra SQL Injection. Consultas parametrizadas separam claramente os dados do comando SQL, garantindo que a entrada do usuário seja sempre tratada como dado, nunca como parte do comando.
2. Adote Validação de Entrada (Input Validation)
Implemente validação rigorosa de todos os dados fornecidos pelo usuário:
- Valide tipo de dados (números, strings, etc.)
- Use listas brancas (whitelists) de caracteres permitidos
- Estabeleça limites de tamanho para campos
- Valide formato usando expressões regulares
3. Implemente Stored Procedures
Stored procedures podem encapsular a lógica do banco de dados, mas cuidado: elas também podem ser vulneráveis se usarem SQL dinâmico internamente.
4. Pratique o Princípio do Menor Privilégio
- Cada aplicação deve ter credenciais de banco de dados próprias
- Essas credenciais devem ter apenas os direitos mínimos necessários
- Evite usar contas com privilégios administrativos (como 'sa' ou 'root')
- Considere usar contas diferentes para operações de leitura e escrita
5. Escape de Caracteres Especiais
Quando não for possível usar prepared statements (em sistemas legados, por exemplo), faça escape adequado de todos os caracteres especiais antes de incluí-los na consulta.
6. Use ORMs (Object Relational Mappers)
Frameworks como Hibernate, Entity Framework e outros abstraem a construção de consultas e geralmente implementam proteções contra SQLi quando usados corretamente.
7. Implemente WAF (Web Application Firewall)
Firewalls de aplicação web podem detectar e bloquear tentativas de SQL Injection, funcionando como uma camada adicional de defesa.
8. Realize Testes de Segurança Regularmente
- Use ferramentas de teste estático (SAST) para analisar o código-fonte
- Utilize ferramentas de teste dinâmico (DAST) para testar a aplicação em execução
- Considere testes de penetração manuais por especialistas
Exemplos de Ataques e Defesas
Exemplo 1: Obtendo Mais Dados do que o Esperado
Cenário Vulnerável:
Um desenvolvedor precisa mostrar os números de conta e saldos para o ID do usuário atual fornecido na URL. O código vulnerável em Java:
String accountBalanceQuery =
"SELECT accountNumber, balance FROM accounts WHERE account_owner_id = "
+ request.getParameter("user_id");
try {
Statement statement = connection.createStatement();
ResultSet rs = statement.executeQuery(accountBalanceQuery);
while (rs.next()) {
page.addTableRow(rs.getInt("accountNumber"), rs.getFloat("balance"));
}
} catch (SQLException e) {
// Tratamento de erro
}Em operação normal, o usuário com ID 984 acessa:https://bankingwebsite/show_balances?user_id=984
A consulta gerada é:
SELECT accountNumber, balance FROM accounts WHERE account_owner_id = 984O Ataque:
O invasor modifica o parâmetro "user_id" para:
0 OR 1=1Resultando na consulta:
SELECT accountNumber, balance FROM accounts WHERE account_owner_id = 0 OR 1=1Esta consulta retorna TODAS as contas e saldos do banco de dados, expondo informações confidenciais de todos os clientes.
Correção com Prepared Statement:
String accountBalanceQuery =
"SELECT accountNumber, balance FROM accounts WHERE account_owner_id = ?";
try {
PreparedStatement statement = connection.prepareStatement(accountBalanceQuery);
statement.setInt(1, Integer.parseInt(request.getParameter("user_id")));
ResultSet rs = statement.executeQuery();
while (rs.next()) {
page.addTableRow(rs.getInt("accountNumber"), rs.getFloat("balance"));
}
} catch (SQLException | NumberFormatException e) {
// Tratamento adequado de erro
// Não revelar detalhes do banco ao usuário
}Se o invasor tentar fornecer um valor que não seja um inteiro válido, Integer.parseInt() lançará uma exceção, ou o PreparedStatement tratará a entrada como dado, não como comando SQL.
Exemplo 2: Transformando um Usuário em Administrador
Cenário Vulnerável:
Um sistema de login com falha de segurança:
String userLoginQuery =
"SELECT user_id, username, password_hash FROM users WHERE username = '"
+ request.getParameter("user") + "'";
int user_id = -1;
HashMap<String, Boolean> userGroups = new HashMap<>();
try {
Statement statement = connection.createStatement();
ResultSet rs = statement.executeQuery(userLoginQuery);
if (rs.first()) {
user_id = rs.getInt("user_id");
String providedPassword = request.getParameter("password");
String storedHash = rs.getString("password_hash");
if (!hashOf(providedPassword).equals(storedHash)) {
throw new BadLoginException();
}
// Buscar grupos do usuário
String userGroupQuery = "SELECT group_name FROM group_membership WHERE user_id = " + user_id;
rs = statement.executeQuery(userGroupQuery);
while (rs.next()) {
userGroups.put(rs.getString("group_name"), true);
}
}
} catch (SQLException | BadLoginException e) {
// Tratamento inadequado
}O Ataque:
Um invasor que conhece a senha de João (ou apenas quer causar dano) fornece como nome de usuário:
john';
INSERT INTO group_membership (user_id, group_name)
SELECT user_id, 'Administrator' FROM users WHERE username='john'; --A consulta executada se torna:
SELECT user_id, username, password_hash FROM users WHERE username = 'john';
INSERT INTO group_membership (user_id, group_name)
SELECT user_id, 'Administrator' FROM users WHERE username='john'; --'O banco de dados executa ambas as consultas: primeiro autentica João (se a senha estiver correta) e DEPOIS adiciona João ao grupo "Administrator". O ataque pode até funcionar sem a senha correta, dependendo de como o código trata erros!
Correção Abrangente:
// Usando PreparedStatement para a consulta inicial
String userLoginQuery =
"SELECT user_id, username, password_hash FROM users WHERE username = ?";
try {
PreparedStatement statement = connection.prepareStatement(userLoginQuery);
statement.setString(1, request.getParameter("user"));
ResultSet rs = statement.executeQuery();
if (rs.first()) {
int user_id = rs.getInt("user_id");
String providedPassword = request.getParameter("password");
String storedHash = rs.getString("password_hash");
if (!hashOf(providedPassword).equals(storedHash)) {
throw new BadLoginException("Credenciais inválidas");
}
// Buscar grupos usando PreparedStatement
String userGroupQuery =
"SELECT group_name FROM group_membership WHERE user_id = ?";
PreparedStatement groupStmt = connection.prepareStatement(userGroupQuery);
groupStmt.setInt(1, user_id);
ResultSet groupRs = groupStmt.executeQuery();
HashMap<String, Boolean> userGroups = new HashMap<>();
while (groupRs.next()) {
userGroups.put(groupRs.getString("group_name"), true);
}
} else {
throw new BadLoginException("Credenciais inválidas");
}
} catch (SQLException e) {
// Log seguro do erro (sem expor detalhes ao usuário)
logger.error("Erro de banco de dados durante login", e);
throw new ApplicationException("Erro interno. Tente novamente mais tarde.");
} catch (BadLoginException e) {
// Mensagem genérica para o usuário
throw new ApplicationException(e.getMessage());
}Boas Práticas de Codificação para Prevenir SQL Injection
Em Java
// RUIM - Vulnerável
String query = "SELECT * FROM users WHERE username = '" + username + "'";
// BOM - PreparedStatement
PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE username = ?");
ps.setString(1, username);Em C#/.NET
// RUIM - Vulnerável
string query = "SELECT * FROM users WHERE username = '" + username + "'";
// BOM - Parameterized Query
SqlCommand cmd = new SqlCommand("SELECT * FROM users WHERE username = @username", conn);
cmd.Parameters.AddWithValue("@username", username);Em PHP
// RUIM - Vulnerável
$query = "SELECT * FROM users WHERE username = '" . $_POST['username'] . "'";
// BOM - Prepared Statement com PDO
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
$stmt->execute(['username' => $_POST['username']]);Em Python
# RUIM - Vulnerável
query = f"SELECT * FROM users WHERE username = '{username}'"
# BOM - Parâmetros com DB-API
cursor.execute("SELECT * FROM users WHERE username = %s", (username,))
# BOM - Com Django ORM
User.objects.filter(username=username)Ferramentas de Detecção e Prevenção
Ferramentas de Código Aberto
- sqlmap - Automatiza detecção e exploração de SQLi
- OWASP ZAP - Scanner de vulnerabilidades com módulos para SQLi
- BBQSQL - Ferramenta para SQL injection cega
Ferramentas Comerciais
- Veracode - Análise estática e dinâmica
- Acunetix - Scanner de vulnerabilidades web
- Burp Suite - Plataforma para testes de segurança
Checklist de Prevenção para Desenvolvedores
- [ ] Uso consistente de prepared statements/consultas parametrizadas
- [ ] Validação rigorosa de todas as entradas do usuário
- [ ] Princípio do menor privilégio aplicado a contas de banco de dados
- [ ] Escapamento adequado quando prepared statements não são possíveis
- [ ] Stored procedures revisadas para SQL dinâmico
- [ ] Tratamento adequado de erros sem vazamento de informações
- [ ] Codificação consistente de caracteres (UTF-8)
- [ ] Testes de segurança incluídos no pipeline de CI/CD
- [ ] Revisões de código focadas em segurança
- [ ] Manutenção do WAF atualizado com regras para SQLi
Conclusão
SQL Injection continua sendo uma ameaça significativa, mas é completamente prevenível com práticas adequadas de desenvolvimento seguro. A chave está em nunca confiar em dados fornecidos pelo usuário e sempre tratar entradas externas como potencialmente maliciosas.
A adoção de consultas parametrizadas, validação de entrada, princípio do menor privilégio e testes regulares de segurança forma uma defesa robusta contra este tipo de ataque. Lembre-se: a segurança não é um destino, mas uma jornada contínua de conscientização, educação e implementação de boas práticas em todas as fases do desenvolvimento de software.
Invista na capacitação de sua equipe, utilize as ferramentas adequadas e mantenha-se atualizado sobre as novas técnicas de ataque e defesa. A proteção contra SQL Injection não é apenas uma questão técnica, mas um compromisso com a segurança dos dados de seus usuários e a integridade de seu negócio.