Impacto da injeção de SQL
A injeção de SQL (SQLi) permite que um invasor interfira nas consultas que um aplicativo faz em seu banco de dados [S1]. O impacto principal inclui acesso não autorizado a dados confidenciais, como senhas de usuários, detalhes de cartão de crédito e informações pessoais [S1].
Além do roubo de dados, os invasores muitas vezes podem modificar ou excluir registros do banco de dados, levando a alterações persistentes no comportamento do aplicativo ou à perda de dados [S1]. Em casos de alta gravidade, SQLi pode ser escalado para comprometer a infraestrutura de back-end, permitir ataques de negação de serviço ou fornecer um backdoor persistente nos sistemas da organização [S1][S2].
Causa raiz: manipulação de entrada insegura
A causa raiz da injeção SQL é a neutralização inadequada de elementos especiais usados em um comando SQL [S2]. Isso ocorre quando um aplicativo constrói consultas SQL concatenando entradas influenciadas externamente diretamente na cadeia de consulta [S1][S2].
Como a entrada não está devidamente isolada da estrutura da consulta, o interpretador do banco de dados pode executar partes da entrada do usuário como código SQL em vez de tratá-la como dados literais [S2]. Esta vulnerabilidade pode se manifestar em várias partes de uma consulta, incluindo instruções SELECT, valores INSERT ou instruções UPDATE [S1].
Correções e mitigações de concreto
Use consultas parametrizadas
A maneira mais eficaz de evitar a injeção de SQL é o uso de consultas parametrizadas, também conhecidas como instruções preparadas [S1]. Em vez de concatenar strings, os desenvolvedores devem usar mecanismos estruturados que imponham a separação de dados e código [S2].
Princípio do Menor Privilégio
Os aplicativos devem se conectar ao banco de dados usando os privilégios mais baixos necessários para suas tarefas [S2]. Uma conta de aplicação web não deve ter privilégios administrativos e deve estar restrita às tabelas ou operações específicas necessárias para sua função [S2].
Validação e codificação de entrada
Embora não seja um substituto para a parametrização, a validação de entrada fornece [S2] de defesa profunda. Os aplicativos devem usar uma estratégia de aceitação conhecida, validando se a entrada corresponde aos tipos, comprimentos e formatos esperados [S2].
Como FixVibe testa isso
FixVibe já cobre a injeção de SQL por meio do módulo scanner fechado active.sqli. As verificações ativas só são executadas após verificação e atestado de propriedade do domínio. A verificação rastreia endpoints GET de mesma origem com parâmetros de consulta, estabelece uma resposta de linha de base, procura anomalias booleanas específicas de SQL e relata apenas uma descoberta após a confirmação de tempo em vários comprimentos de atraso. As varreduras de repositório também ajudam a detectar a causa raiz antecipadamente por meio de code.web-app-risk-checklist-backfill, que sinaliza chamadas SQL brutas criadas com interpolação de modelo.