SQL injection (SQLi) ocorre quando uma entrada do usuario e interpretada como codigo SQL, permitindo leitura ou alteracao indevida do banco. A prevencao exige mais que uma unica correcao: envolve praticas de codigo, configuracao e monitoramento que atuam em camadas. Abaixo, as 7 praticas essenciais para reduzir a superficie de ataque.
1. Use consultas parametrizadas (prepared statements)
A parametrizacao separa o codigo SQL dos dados fornecidos pelo usuario. Em vez de concatenar strings, voce envia a consulta com placeholders e passa os valores separadamente. Isso impede que a entrada seja interpretada como instrucao, independentemente do conteudo. Bancos como PostgreSQL, MySQL e SQL Server suportam prepared statements nativamente. Em Java, use PreparedStatement; em Python, os parametros de cursor.execute(); em PHP, PDO com bindValue. Nenhuma outra pratica substitui essa barreira, que elimina a maioria dos vetores de SQLi.
2. Valide e higienize toda entrada do usuario
Mesmo com parametrizacao, a validacao reduz riscos residuais. Defina regras por campo: tipo esperado (numero, data, email), tamanho maximo e intervalo de valores. Rejeite entradas que nao atendam ao formato, em vez de tentar limpar o conteudo. Por exemplo, um campo de CPF deve aceitar apenas 11 digitos; qualquer outro valor e descartado. A higienizacao complementar, como remover caracteres de controle, protege contra falhas em bibliotecas ou em consultas nao parametrizadas legadas.
3. Aplique o principio do minimo privilegio no banco
A conta usada pela aplicacao nao deve ter permissoes de administrador. Crie usuarios dedicados com acesso apenas as tabelas e operacoes necessarias. Se a aplicacao so le dados, conceda somente SELECT. Isso limita o dano caso um ataque consiga executar instrucoes: um invasor nao podera apagar tabelas ou criar usuarios. Revise permissoes periodicamente, principalmente em ambientes que acumulam contas ao longo do tempo.
4. Evite concatenacao de strings em consultas dinamicas
Consultas montadas por concatenacao, mesmo com aspas escapadas, sao a causa classica de SQLi. A pratica de adicionar "escape de aspas simples" manualmente e fragil: codificacoes alternativas ou erros de codificacao podem burlar a protecao. Prefira construir consultas com ferramentas que parametrizam automaticamente. Se a dinamica for inevitavel, por exemplo em filtros com ordenacao, use uma lista branca de colunas e direcoes permitidas, nunca o valor bruto do usuario.
5. Utilize um ORM ou query builder com seguranca padrao
Frameworks como Hibernate (Java), Entity Framework (.NET), SQLAlchemy (Python) e Prisma (Node.js) geram consultas parametrizadas por padrao. Isso reduz erros humanos, pois o desenvolvedor nao escreve SQL cru. Porem, ORMs nao sao infaliveis: recursos como query bruta ou execucao de SQL nativo reintroduzem o risco. Ao usar essas funcionalidades, aplique as mesmas regras de parametrizacao manuais. A escolha do ORM depende da linguagem e da equipe, mas qualquer um deles e mais seguro que SQL puro concatenado.
6. Configure o WAF e monitore logs de banco
Um Web Application Firewall (WAF) pode bloquear requisicoes com padroes conhecidos de SQLi antes que cheguem ao servidor. Solucoes como Cloudflare ou ModSecurity oferecem regras predefinidas e atualizacoes constantes. Paralelamente, monitore logs do banco e da aplicacao para detectar tentativas: erros de sintaxe SQL em sequencia, queries anormais ou acessos fora do padrao. Alertas em tempo real permitem resposta rapida. Lembre-se: WAF e monitoramento reduzem o impacto, mas nao corrigem codigo vulneravel.
7. Realize testes de seguranca e revisao de codigo
Testes automatizados com ferramentas como OWASP ZAP ou sqlmap ajudam a identificar pontos de injecao antes da publicacao. Inclua casos de teste com entradas maliciosas (aspas, operadores logicos, comentarios SQL) em sua suite. A revisao de codigo por pares, com checklist de seguranca, captura falhas que ferramentas nao veem. Realize esses testes a cada alteracao relevante, nao apenas em auditorias anuais. A combinacao de automacao e revisao humana cobre tanto erros conhecidos quanto logicas complexas.
Qual pratica adotar primeiro?
Se voce esta comecando, implemente a parametrizacao em todas as consultas novas. E o passo de maior impacto e menor custo. Em seguida, ajuste as permissoes do banco e revise codigo legado. Para aplicacoes em producao, habilite um WAF e monitore logs enquanto o codigo e corrigido. Nenhuma pratica isolada e suficiente: a defesa em profundidade, com pelo menos tres das camadas acima, e o cenario recomendado.
FAQ
O que e SQL injection?
SQL injection e uma tecnica de ataque em que o invasor envia entradas maliciosas que sao interpretadas como parte de uma instrucao SQL. Isso permite ler, modificar ou apagar dados do banco, dependendo das permissoes da conta usada pela aplicacao.
Validar entrada elimina a necessidade de parametrizacao?
Nao. Validacao reduz a superficie de ataque, mas nao elimina o risco, pois regras podem ser imperfeitas ou esquecer casos limites. A parametrizacao e a unica barreira que impede a interpretacao de entrada como codigo, independentemente do conteudo.
ORMs previnem SQL injection automaticamente?
A maioria dos ORMs gera consultas parametrizadas por padrao, o que previne SQLi em uso normal. Mas recursos de SQL bruto ou consultas nativas exigem cuidado manual. Sempre que usar esses recursos, aplique parametros, nunca concatenacao.
Como detectar SQL injection em uma aplicacao existente?
Use ferramentas de teste como OWASP ZAP ou sqlmap para escanear endpoints em ambiente controlado. Monitore logs de erro e de banco por queries anormais. Uma revisao de codigo focada em concatenacao de strings e o metodo mais confiavel.
O que fazer se uma aplicacao ja sofreu um ataque SQLi?
Isole o servidor afetado, revise logs para identificar a extensao do acesso e altere credenciais do banco. Restaure dados de backup limpo, se necessario, e corrija a vulnerabilidade com parametrizacao antes de colocar no ar novamente.
WAF substitui boas praticas de codigo?
Nao. WAF bloqueia padroes conhecidos, mas nao entende o contexto da sua aplicacao. Ataques sofisticados ou codificacoes alternativas podem passar. Codigo seguro, com parametrizacao e validacao, e a defesa primaria; WAF e uma camada complementar.