SQL Injection: o que é e como corrigir
SQL injection é uma vulnerabilidade em que o texto digitado por um visitante é incluído em uma consulta ao banco de dados não como um valor, mas como parte de um comando. Como resultado, uma pessoa de fora pode ler, modificar ou excluir o que não deveria ter permissão para acessar.
Analogia para donos de sites
Imagine um arquivo e um formulário: "traga o processo número ___". Se alguém escrever no campo do número "...e leve também o armário inteiro e deixe a porta aberta", e o funcionário ler o formulário inteiro como uma instrução, ele vai executar. O problema não está no arquivo, mas no hábito de montar instruções a partir de texto de terceiros. A solução é um formulário em que o número do processo sempre continua sendo um número e nunca é lido como comando.
O que pode ser perdido
| O que acontece | No que isso resulta |
|---|---|
| Leitura de tabelas de terceiros | Vazamento de bancos de dados de clientes e pedidos, com notificações às pessoas e questionamentos de órgãos reguladores |
| Acesso a contas | Hashes de senhas de administradores, acesso ao painel administrativo, controle sobre o site |
| Gravação de código estranho no banco de dados | Infecção que volta mesmo depois da limpeza dos arquivos: veja código malicioso no site |
Como isso afeta o SEO
Não há aqui um fator de ranqueamento direto: o que pesa é a consequência. Por meio da injeção, conteúdo de spam e links ocultos para assuntos alheios ao site são gravados no banco de dados. O cenário típico é este: os mecanismos de busca passam a avaliar mal a temática do site, as posições caem, algumas páginas saem do índice e, quando o domínio entra em bases de sites inseguros, os navegadores exibem um aviso e o tráfego despenca.
Como aparece no relatório do Security Shield
O scanner envia uma consulta de teste inofensiva aos parâmetros encontrados e verifica se o site retorna uma mensagem de erro do banco de dados. Se retornar, aparece um alerta: "SQL Injection Indicator (DB Error)": gravidade alta, classe CWE-89, categoria OWASP A03:2021. A evidência mostra um trecho do erro, e a observação "requer verificação" significa que o serviço registra um sintoma, e não que invade o banco de dados.
O teste é executado apenas nos modos pagos e em um domínio verificado. O scanner olha de fora e vê somente os parâmetros que encontrou nas páginas: a ausência de um alerta não significa que não existam injeções em outro lugar. O que exatamente é verificado está no artigo sobre o Security Shield.
Um erro de banco de dados na resposta significa que texto de terceiros chegou à consulta. Passe ao desenvolvedor o endereço da página e o nome do parâmetro indicados no relatório. Escapar aspas manualmente e usar "listas negras" de palavras não resolve o problema.
Como corrigir
- Consultas parametrizadas. A solução principal: o texto da consulta é definido previamente e os valores são passados separadamente, como em um prepared statement. Assim, o conteúdo do campo fisicamente não consegue se tornar parte do comando.
- ORM ou camada de consultas do framework. As bibliotecas modernas fazem isso por padrão; os problemas surgem onde a consulta é montada manualmente como string.
- Permissões mínimas para o usuário do banco de dados. A conta do site quase nunca precisa de permissão para excluir tabelas e trabalhar com arquivos.
- Ocultar erros técnicos dos visitantes: a saída de depuração deve ir para os logs, não para a página.
- Atualizar o CMS e as extensões. Em sites comuns, a injeção costuma vir de um plugin vulnerável, e não do seu código.
Como evitar que aconteça de novo
Combine com o desenvolvedor que consultas montadas por concatenação de strings não passam na revisão. Um firewall na frente do site é uma medida temporária durante a correção, não um substituto para os prepared statements. Depois de corrigir, repita a varredura profunda. Também vale conferir com a auditoria do site, que mostrará páginas e links estranhos caso algo já tenha entrado no banco de dados.
