SQL Injection

SQL Injection WordPress é uma classe de ataque na qual um invasor consegue inserir comandos SQL maliciosos em campos de entrada (formulários, query strings, headers) que são montados diretamente em queries ao banco de dados, sem tratamento. Quando o servidor executa a query, o atacante consegue ler dados restritos, alterar registros, criar usuários administradores ou até derrubar o site. O core do WordPress é robusto contra isso; plugins mal escritos continuam sendo a porta de entrada principal.

O que é SQL Injection

A lógica do ataque é simples. O programador, no plugin ou tema, escreve uma query montando string com input do usuário no meio. Algo como SELECT * FROM wp_posts WHERE id = $_GET[id]. O atacante manda uma URL com id=1 OR 1=1, e a query vira SELECT * FROM wp_posts WHERE id = 1 OR 1=1, que retorna todos os posts. Pequena mudança, efeito enorme.

Nas variantes mais perigosas, o atacante encadeia comandos. Em vez de só ler, executa um UPDATE para alterar a senha de um administrador, um INSERT para criar um novo usuário com role admin, ou um UNION para juntar resultados de outras tabelas e extrair dados sensíveis.

Quem busca o que é sql injection geralmente está auditando código próprio ou tentando entender um relatório de scan que apontou vulnerabilidade. Em ambos os casos, o caminho é o mesmo: identificar onde o input do usuário entra direto na query, e refatorar para usar prepared statements.

O ataque sql também é conhecido como SQLi, abreviação que aparece em CVEs e em ferramentas de scan. Em qualquer banco relacional (MySQL, PostgreSQL, SQL Server) o conceito vale, mudando só a sintaxe específica. No WordPress, o banco é MySQL ou MariaDB, e o vetor é o mesmo da especificação clássica.

Como SQLi afeta WordPress

O core do WordPress usa prepared statements desde o início via classe wpdb. Tudo que vem da função $wpdb->prepare() é protegido por construção. Por isso, ataques sqli wordpress raramente exploram o core direto. O problema mora em plugins.

Plugins mal escritos pegam $_GET, $_POST ou $_REQUEST e concatenam direto na query. Isso aparece muito em plugins gratuitos antigos no repositório, em códigos copiados de tutoriais sem entender o que está sendo feito, e em temas customizados de agências que terceirizaram o desenvolvimento. Cada um desses plugins é um ponto de entrada potencial.

Quando um plugin com SQLi vira CVE pública, atacantes automatizam a exploração. Bots vasculham a internet procurando sites com a versão vulnerável instalada e atacam em massa. É comum ver hospedagens compartilhadas com dezenas de sites comprometidos pela mesma falha em poucas horas, todos rodando o mesmo plugin desatualizado.

O resultado típico de um SQLi bem-sucedido é o site comprometido com usuário admin escondido, links de spam injetados nos posts, ou redirecionamento de tráfego para domínios maliciosos. Combine com proteção contra vulnerabilidades conhecidas e backups regulares para reduzir blast radius.

Prepared statements e proteção

A defesa padrão e única confiável é prepared statements. Em vez de montar a query como string concatenada, você passa a query com placeholders e os valores separados. O driver do banco aplica escape correto antes de executar, e nenhum caractere do input pode mudar a estrutura da query.

No WordPress, isso é feito via $wpdb->prepare(). A query usa %s para strings, %d para inteiros e %f para floats. O segundo argumento é a lista de valores que substituem os placeholders. Sem prepare(), nunca passe input do usuário direto em $wpdb->query() ou $wpdb->get_results(). Essa é regra absoluta.

Para queries onde a tabela ou coluna é dinâmica (não só os valores), prepare não basta, porque ele não escapa identificadores. Use whitelisting: defina uma lista fechada de tabelas/colunas válidas e confira o input contra essa lista antes de usar. Plugins que aceitam nomes de tabela como input do usuário são bandeira vermelha.

Combine prepared statements com sanitização de input e validação de tipo. Sanitização limpa caracteres óbvios. Validação rejeita valores fora do esperado. Prepared statement neutraliza o que sobrou. As três camadas em sequência cobrem praticamente todos os vetores conhecidos.

Como detectar vulnerabilidades SQLi

O primeiro passo é manter plugins e temas atualizados. A maioria dos SQLi explorados em sites WordPress são CVEs públicas conhecidas, com correção disponível há semanas ou meses. Plugin desatualizado é o vetor mais provável de invasão. Configurar atualizações automáticas para plugins maduros é mínimo de higiene.

Em seguida, use scanners. WPScan é a ferramenta clássica, gratuita para uso pessoal, com base de dados pública de CVEs em WordPress. Roda via linha de comando, varre o site e lista todos os plugins e temas detectados, marcando os que têm CVEs ativas. Para sites em produção, automatize a checagem em pipeline de CI ou cron diário.

Para auditoria de código próprio, use ferramentas de análise estática como PHPCS com o ruleset WordPress-VIP. Ele detecta padrões inseguros em PHP: $wpdb->query com input não escapado, falta de prepare(), uso direto de superglobais. Roda no editor e marca os pontos antes do código ir para produção.

Em runtime, um WAF (Web Application Firewall) bem configurado bloqueia tentativas de SQLi antes de chegarem ao PHP. Cloudflare, Sucuri e plugins como Wordfence e AIOS oferecem essa camada. Eles detectam payloads conhecidos pela assinatura e respondem com bloqueio. Combine com banco de dados bem isolado para reduzir impacto. Não esqueça da defesa cruzada com XSS.

Para times que precisam levantar a régua de proteção contra SQLi, XSS e a maioria das classes de vulnerabilidade WordPress conhecidas, a FULL Services entrega o AIOS (All-In-One Security) já licenciado e configurado dentro da stack profissional, com firewall de aplicação, regras pré-tunadas contra payloads de SQLi conhecidos e monitoramento ativo. O site roda em uma camada validada em produção desde o primeiro deploy.