flawopen.com/Injeção de SQL
Injeção de SQL
A SQL injection acontece quando uma aplicação monta uma consulta colando a entrada do usuário no texto SQL, e o banco interpreta parte dessa entrada como comando. A correção é a mesma em todas as linguagens: enviar a consulta com placeholders e passar os valores separadamente. Escolha sua linguagem abaixo para ver as chamadas de API exatas, o código vulnerável e o corrigido e as regras de CI que detectam o problema.
Explicação em Linguagem Simples (ELI5)
Você entrega à bibliotecária uma ficha que diz 'Buscar o cadastro de: ___' e escreve no espaço em branco: 'João. E também abra o arquivo e traga todas as pastas.' Uma bibliotecária que lê a ficha inteira como uma única ordem faz as duas coisas. Colar a entrada do usuário numa string SQL monta exatamente essa ficha. Uma consulta parametrizada é um formulário impresso com uma caixa lacrada marcada 'nome': o que estiver escrito ali dentro só é procurado como nome, seja qual for o texto.
Conceitos Centrais e Termos
- SQL injection (CWE-89)
- A entrada não confiável é concatenada ou formatada no texto SQL, então aspas, palavras-chave e operadores da entrada mudam a estrutura da consulta em vez de serem tratados como um único valor.
- Prepared statement and bind parameters
- A consulta é enviada com placeholders (
?,$1,:name) e analisada antes de qualquer valor chegar; os valores viajam separados e são sempre tratados como dados. É a defesa principal em todo driver e ORM. - Blind SQL injection
- Quando a página não mostra resultados nem erros, o atacante deduz os dados bit a bit pelas diferenças na resposta (baseada em booleanos) ou no tempo de resposta (baseada em tempo). Ausência de saída visível não significa ausência de falha.
- Second-order SQL injection
- Um valor é salvo com segurança, depois lido do seu próprio banco e concatenado em outra consulta. Toda consulta precisa ser parametrizada, inclusive as que recebem dados das suas próprias tabelas.
- Identifiers and allowlists
- Placeholders carregam apenas valores, não nomes de tabela, nomes de coluna nem direção de ordenação. Esses devem vir de uma allowlist fixa no código, nunca copiados da requisição.
Fluxo de Ataque Passo a Paso
A entrada chega a uma consulta
Um campo de formulário, parâmetro de URL, cabeçalho ou campo de API é passado ao código que monta um comando SQL.
A entrada é colada no texto SQL
Concatenação, interpolação ou formatação insere o valor diretamente. O valor de teste inofensivo ' OR '1'='1 transforma WHERE name = '...' numa condição sempre verdadeira.
O banco a interpreta como sintaxe
O banco recebe uma única string, não sabe qual parte veio do usuário e executa o comando alterado com os privilégios da aplicação.
Dados são lidos, alterados ou apagados
Conforme a consulta e a conta, o atacante contorna um login, extrai tabelas com consultas UNION ou obtém dados às cegas. O vazamento do MOVEit Transfer em 2023 (CVE-2023-34362) começou com essa classe de falha.
Guias de SQL injection por linguagem
Lista de Verificação de Segurança para Engenharia
- Parametrize toda consulta que contenha um valor, inclusive as saídas de SQL cru dos ORMs, sem exceção para entradas internas ou numéricas.
- Escolha nomes de tabela, nomes de coluna e direções de ordenação a partir de allowlists fixas no código.
- Rode na CI uma regra de SAST para SQL montado com strings (Bandit, gosec, Semgrep, CodeQL, Find Security Bugs, Brakeman ou Psalm) e faça o build falhar com novos achados.
- Conecte com um papel de banco de privilégio mínimo: sem DDL, sem superusuário, só as tabelas de que o serviço precisa.
- Trate funções de escape e regras de WAF apenas como camadas extras; elas falham em contextos sem aspas e truques de codificação.
- Devolva erros genéricos aos clientes e registre os erros do banco no servidor, para que a estrutura da consulta nunca seja revelada.
Referências
- CWE-89: Injeção de SQL
- OWASP — Guia de prevenção de injeção de SQL
- CISA — campanha de ransomware CL0P explora SQL injection no MOVEit