O que é SQL injection (injeção de SQL)?
SQL injection, ou injeção de SQL, é um ataque em que o criminoso insere comandos de banco de dados por dentro de um campo comum do site (um login, uma busca, um endereço) que a aplicação repassa ao banco sem verificar. Assim ele engana o sistema para revelar, alterar ou apagar dados que jamais deveria expor. É um dos ataques web mais antigos e destrutivos, porque um único campo mal protegido pode entregar o banco de clientes inteiro.
Como a injeção de SQL funciona
A aplicação conversa com o banco de dados por meio de perguntas (consultas). A injeção acontece quando o que o usuário digita é misturado a essa pergunta sem tratamento: o texto do atacante deixa de ser um dado e passa a ser lido como comando. É a diferença entre preencher um formulário e reescrever a pergunta que o sistema faz ao banco.
Achar a entrada certa
O atacante procura um campo que chega até o banco: um formulário de login, uma caixa de busca, um parâmetro no endereço da página. Qualquer entrada que vire parte de uma consulta serve de porta.
Testar a brecha
Ele digita um caractere fora do comum, como uma aspa, para ver se a página quebra ou se comporta de forma estranha. Um erro do banco na tela é o sinal de que a entrada não é tratada.
Injetar o comando
Confirmada a brecha, ele insere um trecho de SQL. Um clássico é acrescentar uma condição sempre verdadeira para pular a verificação de senha, ou emendar uma consulta que puxa outras tabelas.
Colher ou destruir
Com o comando aceito, o banco obedece: copia a base de clientes inteira, altera registros, cria um acesso de administrador ou apaga dados. Um formulário virou uma porta dos fundos para o banco.
Fonte: OWASP (categoria A03:2021, Injeção).
Por onde a injeção de SQL entra
- Formulários de login e de cadastro, onde o que se digita vira parte de uma consulta.
- Caixas de busca e filtros, que montam perguntas ao banco a partir do texto do usuário.
- Parâmetros no endereço da página (a parte depois do ponto de interrogação na URL).
- Formulários de contato, comentários e qualquer campo que grave ou consulte dados.
- Interfaces de integração (APIs) e cabeçalhos, que também chegam ao banco por baixo dos panos.
Os tipos de injeção de SQL
- Injeção clássica (in-band) O resultado volta na própria página: o banco devolve os dados pedidos ou uma mensagem de erro que revela sua estrutura. É a forma mais direta e a mais fácil de explorar.
- Injeção cega (blind) O site não mostra dados nem erros, mas responde de formas diferentes a comandos verdadeiros e falsos, ou demora mais para responder. O atacante deduz a informação pergunta a pergunta, mais devagar e igualmente perigoso.
- Injeção fora de banda (out-of-band) Quando o retorno direto não é possível, o comando faz o banco enviar os dados por outro canal, como uma requisição de rede para um servidor do atacante. É mais rara e depende da configuração do ambiente.
O que está em jogo para o negócio
A injeção de SQL importa porque o alvo dela é o cofre: o banco de dados onde vivem clientes, pedidos, senhas e informação financeira. Uma exploração bem-sucedida não vaza um arquivo, vaza a base inteira, e com ela vem a exposição regulatória (LGPD no Brasil, GDPR na Europa, entre outras), a perda de confiança e o custo médio de US$ 4,44 milhões por violação no mundo (IBM, 2025). O mais desconfortável é a idade do problema: a injeção é a 3ª maior categoria de risco do OWASP Top 10 e está na lista há mais de vinte anos, ainda perigosa porque basta um campo esquecido para abrir o cofre. Não é uma ameaça exótica de fronteira; é uma falha conhecida que persiste por descuido de código.
Como se proteger da injeção de SQL
A injeção de SQL não se combate com desconfiança do usuário, e sim com disciplina de código. A boa notícia é que a defesa central é bem conhecida e definitiva:
- Use consultas parametrizadasÉ a correção de raiz. A consulta parametrizada separa o comando dos dados: o que o usuário digita é sempre tratado como texto, nunca como parte da instrução. Com isso, não há como o texto virar comando.
- Valide e trate toda entradaNunca confie no que chega de fora. Verifique formato, tamanho e tipo de cada campo, e recuse o que fugir do esperado. É a segunda camada, complementar às consultas parametrizadas.
- Aplique o menor privilégio no bancoA conta que a aplicação usa para falar com o banco não precisa ler tudo nem apagar nada. Limitar o que ela pode fazer reduz o estrago mesmo se a injeção passar.
- Adicione um firewall de aplicação web (WAF)O WAF filtra o tráfego da aplicação e bloqueia padrões conhecidos de injeção antes que cheguem ao banco. É uma camada extra, não um substituto da correção no código.
- Teste continuamenteVarredura automatizada e teste de invasão encontram esses campos esquecidos antes do atacante. A injeção some do ambiente quando é procurada de propósito, não quando se espera pelo incidente.
Na prática
Um único campo de busca, deixado sem tratamento, pode entregar o banco de clientes inteiro. Não é a quantidade de formulários que protege a empresa; é o cuidado com cada um deles. Por isso a defesa da injeção de SQL vive no código e no teste, não em pedir que o usuário se comporte.
Como a Zamak trata a injeção de SQL
A Zamak Technologies trata a injeção de SQL como o que ela é, uma falha de código que se previne e se testa, e atua ao lado da sua equipe de desenvolvimento, sem substituí-la: testa as aplicações em busca dessas brechas, aponta a correção na origem (consulta parametrizada, validação de entrada, menor privilégio no banco) e reforça o ambiente com uma camada de firewall de aplicação web. Em vez de descobrir a falha pelo vazamento, a sua empresa a encontra e fecha antes. É parte da Cibersegurança gerenciada do Método Zamak, e um bom ponto de partida é o diagnóstico de cibersegurança.