Ups! Uma falha de injeção SQL obrigou a lançar uma correção de emergência no núcleo do WordPress na semana passada.
A 17 de julho, o WordPress lançou uma versão de emergência para corrigir uma falha de execução remota de código sem autenticação no núcleo, acessível através de uma injeção SQL que um atacante anónimo pode explorar numa instalação padrão. O WordPress.org chegou mesmo a ativar as atualizações automáticas obrigatórias devido à gravidade da falha. A Searchlight Cyber, que comunicou a falha, estima que mais de 500 milhões de sites utilizem o WordPress. Se estiver afetado, atualize para a versão 7.0.2 e, para a ramificação mais antiga, para a versão 6.9.5.
A injeção de SQL, também conhecida como SQLi, é uma vulnerabilidade antiga com uma solução fácil, pelo que as pessoas assumem que já não existe. Mas, como nos foi recentemente lembrado, não é assim.
Injeção de SQL: das origens modestas até aos dias de hoje
A injeção de SQL e as suas soluções fazem parte das aulas de Introdução à Ciência da Computação. Lembro-me de ter aprendido sobre a injeção de prompt na universidade há mais de uma década e, sinceramente, é a única vulnerabilidade relacionada com aplicações de que me lembro de terem ensinado (acho que passaram para outros tópicos depois de abordarem este, ou talvez eu não tenha prestado atenção a partir daí).
A injeção SQL foi descrita publicamente em 1998 pelo investigador conhecido como «rainforest puppy». A solução que resolve a maioria dos problemas de SQLi — as instruções preparadas — foi descoberta cerca de um ano depois. Essa solução é mais antiga do que muitos engenheiros da empresa. Utilize consultas parametrizadas e trate as entradas do utilizador como dados. No entanto, mesmo com essa solução disponível, as injeções SQL continuam a ocorrer.
Com base nos dados da Base de Dados de Avisos do GitHub, filtrando os avisos por CWE e contabilizando por ano:
O número de alertas relativos a injeções SQL aumentou em cada ano completo entre 2023 e 2025, passando de 2 096 para 2 850. As três classes de injeção mais antigas — injeção SQL, injeção de comandos e percurso de caminho — continuam, no seu conjunto, a representar mais de um em cada dez de todos os casos comunicados.
A OWASP deslocou a injeção do terceiro para o quinto lugar no seu Top 10 de 2025, mas não porque os problemas tenham sido resolvidos. A categoria geral de injeção continua a registar mais CVEs do que qualquer outra, com mais de 60 000 casos relatados. Desse total, só a injeção SQL representou mais de 14 000. Nas análises realizadas por Mackenzie a repositórios de código fechado, 20 % dos projetos apresentavam pelo menos uma falha de injeção SQL na primeira análise.
Por que é que a injeção de SQL não desaparece de vez?
Em primeiro lugar, para esclarecer logo esta questão, as pessoas cometem erros ao escrever código. Acontece. Por isso, de vez em quando, vai escapar-se uma vulnerabilidade de SQLi. Mas os sistemas modernos que deveriam ajudar-nos não o fazem cem por cento das vezes e podem até levar-nos a cometer outros erros.
Por exemplo, as estruturas mais recentes dispõem de métodos que ajudam a prevenir a injeção de SQL. Os ORMs como o Django, o Hibernate e o ActiveRecord utilizam a parametrização por predefinição, o que leva muitas equipas a acreditar que o problema está resolvido. No entanto, se alguém recorrer a uma consulta em bruto ou utilizar um método não seguro, a proteção deixa de existir.
A vulnerabilidade CVE-2024-42005 do Django é um exemplo. Dois dos próprios métodos de consulta do Django, utilizados para ler campos de uma coluna JSON, inseriam diretamente no SQL os nomes dos campos que eram passados, sem os limpar; assim, um atacante que controlasse um nome poderia controlar parte da consulta, através de um método que as equipas consideravam seguro.
Por outro lado, o código muito antigo também constitui um problema, uma vez que o código legado perpetua estas falhas ao longo de décadas. As equipas recorrem a um WAF e partem do princípio (ou rezam para que) este detete tudo. Embora a correção já exista há mais de 25 anos, aplicá-la em todas as consultas, todos os pontos finais e todos os recantos do código legado, em todas as ocasiões, é um trabalho extremamente tedioso que nunca foi concluído na íntegra em todas as bases de código. Na forma como Mackenzie Jackson, o nosso CTO de campo, o enquadra, isto deixou de ser um problema técnico e tornou-se uma questão de cultura, processos e formação.
E, claro, a IA.
A IA também escreve SLQi
A esperança óbvia é que os assistentes de programação baseados em IA, treinados com exemplos de décadas, deixem de reproduzir um erro de 1998. Mas, como sabemos, a IA não escreve código perfeito.
Podemos analisar isto de forma quantitativa. O estudo «Asleep at the Keyboard» de 2021, realizado pela NYU e pela Cornell, gerou 1 689 programas a partir do GitHub Copilot em cenários comuns de vulnerabilidades e constatou que cerca de 40% eram vulneráveis, sendo a injeção de SQL e a injeção de comandos as mais frequentes. O próprio teste da Mackenzie situa-se na mesma ordem de grandeza. Ao submeter um prompt ao ChatGPT algumas centenas de vezes, cerca de 12% dos resultados eram suscetíveis a injeções, um valor próximo da taxa observada no código aberto.
Mas porquê? Os modelos aprendem com código público que contém estas falhas, pelo que as reproduzem com uma frequência semelhante. A IA lida melhor com a injeção de SQL do que com erros que dependem fortemente do contexto, como o cross-site scripting, em que o mesmo relatório constatou que a maioria dos resultados era insegura. A IA continua a melhorar, pelo que estes números estarão desatualizados dentro de seis meses, mas podemos esperar que a IA continue a escrever isto acidentalmente, tal como nós.
E agora, há cada vez mais programadores que se baseiam mais na intuição e menos na formação técnica a escrever código. É menos provável que reconheçam injeções de SQL (se é que sabem sequer que devem estar atentos a elas), pelo que mais código pode entrar na base de código da empresa sem que haja olhos experientes a verificar se esta questão foi devidamente tida em conta.
É por isso que é preciso ter uma rede de segurança
Mesmo que faça tudo corretamente, como utilizar consultas parametrizadas em todo o lado, listas de permissões em todas as entradas, etc… Ainda assim, vai precisar de proteção em tempo de execução. Uma sanitização perfeita em todos os pontos de acesso, para sempre, não existe. Um ataque SQLi pode até ocorrer numa dependência vulnerável que não controla (ou, por exemplo, no site predefinido de um fornecedor de alojamento web), o que está para além do que pode razoavelmente gerir.
Aikido é um firewall incorporado no aplicativo funciona no interior da mesma e monitoriza as entradas do utilizador à medida que estas avançam para um destino de dados, como uma consulta a uma base de dados ou a leitura de um ficheiro.
Quando uma carga útil de um ataque está prestes a atingir um destes locais, o Zen bloqueia-a imediatamente, com contexto suficiente da aplicação para distinguir um ataque de uma sequência de pesquisa que, por acaso, se pareça com um.
Também abrange falhas que surgem através das dependências, onde os seus próprios padrões de codificação não chegam. Considere-o como uma rede de segurança em tempo de execução para quando a codificação segura fica aquém, o que, na prática, acontece sempre. O Zen é um RASP, que identifica entradas perigosas ao nível do código. Isto difere de um WAF, que bloqueia entradas suspeitas ao nível da rede, o que é menos preciso, pelo que tem tendência a bloquear em excesso. Abordo este tema com muito mais pormenor na nossa publicação sobre WAF vs RASP vs ADR.
Uma firewall incorporado no aplicativo o Zen interpone-se entre o wp2shell e um site WordPress sem correção. O Zen foi concebido para bloquear a injeção SQL em que esta falha se baseia, pelo que um site que aguardasse a atualização continuava a dispor de uma defesa enquanto a correção era implementada.
Deteta injeções SQL no teu ramo de desenvolvimento
O tempo de execução é a rede de segurança, mas a prevenção é, naturalmente, a melhor solução. Idealmente, devemos identificar e eliminar todas as injeções SQL do código.
A análise estática, como SAST muitos casos de injeção de SQL, nomeadamente os mais simples, em que a entrada é inserida numa consulta sem uma instrução parametrizada. No entanto, não teria detetado este caso específico. O núcleo do WordPress é um dos softwares mais analisados que existem, e este bug não foi detetado. Neste caso, a injeção só se torna explorável quando um pedido em lote malformado desalinha a contabilidade interna do WordPress, fazendo com que o valor chegue à base de dados através de um caminho que ignora a limpeza. Trata-se de uma interação entre pedidos que um analisador estático não consegue percorrer. A deteção desta vulnerabilidade exigiu um modelo de ponta que executou quatro agentes durante seis horas.
A deteção diária é tarefa do seu scanner. O tipo de problema oculto e dependente da lógica requer, cada vez mais, uma IA para o descobrir antes que outra pessoa o faça, o que é o caso do Aikido pentest de IA e direcioná-la para o seu próprio código, tal como este investigador fez com o WordPress. Aikido pentest contínuo Aikido , o que o pode ajudar a verificar regularmente se existem novas vulnerabilidades SQLi que possam tentar passar despercebidas na revisão de código.
O Little Bobby Tables continua vivo e de boa saúde. Leva-o a sério e protege o teu código, mesmo as partes mais enfadonhas.
