SQL Injection: o que é, como funciona e como se proteger

O que é SQL Injection

SQL Injection é uma das falhas mais antigas e ainda mais perigosas da web. Ela ocorre quando uma aplicação monta uma consulta ao banco de dados juntando texto fixo com entrada do usuário sem tratamento. Se o atacante conseguir escrever caracteres que o banco interpreta como parte do comando — e não apenas como dado —, ele passa a controlar o que a query faz.

Na prática, o navegador manda um campo de formulário (login, busca, filtro) e o backend responde executando SQL. Quando esse SQL é construído por concatenação de string, a fronteira entre comando e dado desaparece — e é exatamente essa fronteira que o SQLi cruza.

Como funciona, na prática

Imagine um login que verifica usuário e senha com uma query montada por concatenação. O código vulnerável faz algo como "SELECT * FROM users WHERE email = '" + email + "' AND senha = '" + senha + "'". O problema: o valor de email entra cru no meio do comando.

Agora o atacante digita no campo de e-mail o payload clássico ' OR '1'='1. A query final vira SELECT * FROM users WHERE email = '' OR '1'='1' AND senha = '...'. Como '1'='1' é sempre verdadeiro, a condição libera o retorno de linhas mesmo sem credencial válida — é o bypass de login em sua forma mais didática.

A versão segura da mesma consulta usa parâmetros em vez de concatenação: SELECT * FROM users WHERE email = ? AND senha = ?, passando os valores separadamente. Aqui o banco recebe o comando e os dados por canais distintos — o texto ' OR '1'='1 é tratado apenas como uma string de busca inofensiva, nunca como código. Essa separação é a diferença entre query concatenada (vulnerável) e query parametrizada (segura).

Tipos de SQL Injection

Impacto real

SQL Injection quase nunca é uma falha isolada e pequena — o banco costuma ser o coração da aplicação. Dependendo do contexto, um único ponto vulnerável permite:

• Vazamento de dados — ler tabelas inteiras de usuários, senhas (mesmo com hash), tokens, dados de cartão ou informações sujeitas à LGPD.
• Bypass de autenticação — entrar como qualquer usuário, inclusive admin, sem saber a senha.
• Alteração ou destruição — modificar saldos, apagar registros, corromper a integridade dos dados.
• RCE (execução remota de código) — em alguns bancos e configurações, o SQLi vira execução de comando no servidor (via funções de arquivo, extensões ou xp_cmdshell), levando ao comprometimento total.

Como se proteger

A boa notícia: SQL Injection é uma falha bem compreendida e totalmente evitável. A defesa é em camadas, mas uma delas resolve a raiz do problema:

1. Consultas parametrizadas / prepared statements — a defesa principal e não negociável. Separe comando de dado em toda query, sem exceção. É o que neutraliza o SQLi na origem.
2. ORM com bind de parâmetros — um ORM bem usado parametriza por padrão. Mas atenção: raw queries e trechos concatenados dentro do ORM voltam a ser vulneráveis (veja o FAQ).
3. Validação e allowlist de entrada — valide tipo, tamanho e formato; para valores que não podem ser parametrizados (ex.: nome de coluna em ORDER BY), use uma allowlist de valores permitidos, nunca a string crua do usuário.
4. Menor privilégio no usuário do banco — a aplicação deve conectar com um usuário que só pode o necessário (sem DROP, sem acesso a tabelas de sistema). Limita o estrago de um SQLi que passe.
5. WAF como camada extra — ajuda a barrar payloads conhecidos, mas é complemento, não substituto: WAF se contorna com encoding e variações. Nunca confie nele como única defesa.
6. Testes automatizados de segurança — inclua verificação de SQLi no pipeline, a cada deploy, para pegar regressões antes que cheguem à produção.

Por que confirmar importa (e não só listar)

Muita ferramenta passiva aponta SQL Injection só porque um parâmetro parece injetável ou porque a versão do framework tem CVE conhecida. O resultado é uma enxurrada de falso positivo — alertas que consomem o tempo do time e minam a confiança no scanner.

O Escudo Code trabalha diferente: ele explora de verdade. Quando suspeita de SQLi, tenta a injeção de forma controlada e só reporta o achado se conseguir confirmá-lo — com evidência concreta e severidade CVSS. São mais de 900 vulnerabilidades confirmadas dessa forma, com o motor validado em ambientes de teste públicos como OWASP Juice Shop e VAmPI. Você recebe o que é real, não uma lista teórica. Veja como testamos.

Leituras relacionadas

SQL Injection é a categoria de Injeção do OWASP Top 10. Se você trabalha com backend, veja também as vulnerabilidades comuns em APIs REST e entenda o que é um pentest e como ele encontra falhas como essa.