Prevenção de Injeção SQL para Aplicações Web Modernas

A injeção SQL continua sendo uma das vulnerabilidades mais críticas em aplicações web. Atacantes a exploram para roubar dados, contornar autenticação e até executar comandos no sistema. Se sua aplicação constrói consultas SQL concatenando entrada do usuário, você está em risco. Este artigo explica como a injeção SQL funciona e fornece passos práticos para preveni-la em aplicações web modernas.

Como a Injeção SQL Acontece

A injeção SQL ocorre quando dados não confiáveis são interpretados como parte de um comando SQL. Por exemplo, considere um formulário de login que verifica credenciais com esta consulta:

SELECT * FROM users WHERE username = '$username' AND password = '$password';

Se um atacante inserir ' OR '1'='1 como nome de usuário e qualquer senha, a consulta se torna:

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

Isso retorna todos os usuários, contornando a autenticação. Técnicas semelhantes podem extrair dados, modificar registros ou excluir tabelas.

1. Use Prepared Statements (Consultas Parametrizadas)

Prepared statements separam o código SQL dos dados. O banco de dados recebe primeiro a estrutura da consulta, depois os parâmetros, então a entrada do usuário nunca é tratada como código SQL. Esta é a defesa mais eficaz.

Exemplo em PHP com PDO:

$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
$stmt->execute(['email' => $userInput]);
$user = $stmt->fetch();

Exemplo em Java com JDBC:

String sql = "SELECT * FROM users WHERE email = ?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, userInput);
ResultSet rs = stmt.executeQuery();

Sempre use consultas parametrizadas para todos os dados fornecidos pelo usuário, incluindo campos de busca, filtros e parâmetros de ordenação.

2. Valide e Sanitize a Entrada

Embora os prepared statements sejam primários, a validação de entrada adiciona defesa em profundidade. Valide que a entrada corresponde a padrões esperados (por exemplo, formato de e-mail, ID numérico) e rejeite qualquer coisa inesperada. Por exemplo, se um ID deve ser um inteiro, converta-o para int no seu código. Evite listas negras de caracteres como aspas—atacantes podem contornar tais filtros.

3. Use um ORM com Segurança

ORMs como Hibernate, Entity Framework e Sequelize normalmente usam consultas parametrizadas por padrão. No entanto, eles frequentemente permitem fragmentos de SQL bruto. Tenha cuidado com métodos que aceitam strings brutas:

• No Sequelize, evite sequelize.query('SELECT * FROM users WHERE name = \'' + name + '\''). Use substituições ou parâmetros vinculados em vez disso.
• No Hibernate, use parâmetros nomeados em HQL em vez de concatenação de strings.

Sempre verifique a documentação do seu ORM para construção segura de consultas.

4. Escape Dados Se Prepared Statements Forem Impossíveis

Em casos raros em que você precisa construir SQL dinâmico (por exemplo, nomes de tabelas dinâmicos), use a função de escape do driver do seu banco de dados. Para MySQL, mysqli_real_escape_string() escapa caracteres especiais. Mas lembre-se: escaping não é tão robusto quanto prepared statements e deve ser o último recurso.

5. Aplique Privilégio Mínimo às Contas de Banco de Dados

Não se conecte ao banco de dados como root ou com um usuário que tenha privilégios totais. Crie um usuário dedicado do banco de dados para sua aplicação com apenas as permissões necessárias (SELECT, INSERT, UPDATE, DELETE em tabelas específicas). Isso limita os danos se uma injeção ocorrer.

6. Use um Web Application Firewall (WAF)

Um WAF pode detectar e bloquear padrões comuns de injeção SQL. Embora não seja um substituto para codificação segura, ele fornece uma camada adicional. Muitos provedores de nuvem oferecem WAFs gerenciados que são fáceis de habilitar.

7. Testes de Segurança Regulares

Teste sua aplicação para vulnerabilidades de injeção SQL usando scanners automatizados ou testes de penetração manuais. Ferramentas como SQLMap podem ajudar a identificar problemas. Integre testes de segurança ao seu pipeline de CI/CD para detectar regressões precocemente.

Comparação de Técnicas de Prevenção

FAQ

Qual é a maneira mais eficaz de prevenir injeção SQL?

Usar prepared statements com consultas parametrizadas é o método mais eficaz. Isso garante que a entrada do usuário nunca seja interpretada como código SQL.

A validação de entrada sozinha pode prevenir injeção SQL?

Não. A validação de entrada é uma boa medida de defesa em profundidade, mas não deve ser confiada isoladamente. Atacantes às vezes podem contornar regras de validação, então sempre use prepared statements como defesa primária.

ORMs são automaticamente seguros contra injeção SQL?

ORMs geralmente são seguros quando usados corretamente, mas frequentemente permitem consultas SQL brutas que podem ser vulneráveis se você concatenar entrada do usuário. Sempre use consultas parametrizadas mesmo dentro de métodos de ORM.

Para segurança adicional, considere usar um formatador JSON para inspecionar e validar respostas de API com segurança sem executar código malicioso.