SQL Injection no WordPress é tratado de forma séria e seu método de combate a esse tipo de ataque é compartilhado para que os desenvolvedores façam uso. O grande desafio da plataforma é garantir que desenvolvedores de plugin codifiquem e forma segura e protegida e consequentemente tenham uma maior segurança para WordPress.
Plugins WordPress renomados já tiveram suas experiências com o SQL Injection e muitos deles foram ágeis em liberar uma nova versão de software para corrigir o problema. Uma busca pelo assunto no WPScan Vulnerability Database demonstra a relevância do assunto.
Antes de prosseguirmos com o assunto, caso o assunto seja uma novidade ou que você tenha pouco conhecimento a respeito, é importante que a definição desse tipo de ataque fica clara.
A Injeção de SQL, mais conhecida através do termo americano SQL Injection, é um tipo de ameaça de segurança que se aproveita de falhas em sistemas que interagem com bases de dados via SQL. A injeção de SQL ocorre quando o atacante consegue inserir uma série de instruções SQL dentro de uma consulta (query) através da manipulação das entradas de dados de uma aplicação.
https://pt.wikipedia.org/wiki/Inje%C3%A7%C3%A3o_de_SQL
Portanto, ao falarmos de SQL Injection no WordPress estamos nos referindo a possíveis brechas no core ou em plugins em uso que estão permitindo a inserção de instruções SQL maliciosas para obtenção de informações no banco de dados.
O WordPress é seguro contra ataques do tipo de injeção de SQL. Toda sua comunicação com a base de dados em uso é realizado através da classe PHP wpdb. Essa classe foi baseada na ezSQL escrita e mantida pelo Justin Vincent e possui um método exclusivo para tratar e evitar ataques de SQL Injection chamado prepare.
Portanto, você deve sempre considerar o uso da última versão estável do WordPress onde, além de usufruir das melhorias e inovações adotadas na plataforma, fará uso de uma versão segura e contra os mais variados tipos de ataques, dentre eles o SQL Injection. Considere manter o WordPress atualizado e fique imune de injeção SQL em seu core.
Quando falamos em plugins WordPres podemos dividi-los em três categorias: os gratuitos, baixados do diretório de plugins da plataforma; os pagos, comprados de empresas desenvolvedoras; os desenvolvidos, criados por empresas ou profissionais para atender demandas e requisitos de projetos.
Se proteger de SQL Injection no WordPress é estender a preocupação do assunto para todo seu ecossistema. A atualização e, por conseguinte, o uso da versão mais recente do WP te garante imunidade, mas em relação aos plugins precisamos considerar outros fatores.
Baixe plugins somente do diretório oficial. Não caia na armadilha de baixar em qualquer lugar por aí. Não faça uso de plugins que não foram atualizados nos últimos dois anos. Faça uma busca por seu nome no WPScan Vulnerability Database e veja as ocorrências, e principalmente se elas foram corrigidas.
Se você é um desenvolvedor, analista de sistemas ou possui conhecimentos similares a esses profissionais conseguirá analisar em detalhes os códigos do plugin, se ele tem interação com o banco de dados e se há tratativas de segurança para evitar a SQL Injection no WordPress. Se este não for o seu caso, considere os passos descritos no parágrafo anterior antes de instalar e ativar um plugin.
Quando se tem uma equipe dedicada por trás de um plugin é mais garantido sua evolução, manutenção e correções quando vulnerabilidades são descobertas. Autores de plugins gratuitos quase nunca recebem doação que os estimulam seguir em frente com o projeto, ou permanecem muito atarefados que não conseguem dar devida atenção.
Para se certificar que plugins pagos estão livres de brechas e que não adicionarão a problemátia de SQL Injection no WordPress considere analisar ocorrências em seu nome no WPScan Vulnerability Database, seu changelog de versões, releases e blog.
Brechas estão sujeitas a acontecer com todos. Analise como a empresa lida com isso, se torna público o acontecido e apresenta uma solução ou se tentam jogar para debaixo do tapete. Nesse último cenário desconsidere o uso de seus plugins. Transparência é importante se tratando de segurança.
Se o plugin contratado para ser desenvolvido não tem interação com usuário e banco de dados, de uma forma geral, você está livre. Considere a análise de outras vulnerabilidades e não SQL Injection. Se possui interações temos alguns caminhos a considerar.
Confiar e acreditar que a empresa e/ou profissional possui conhecimento e deu devida atenção ao assunto, realizou testes e se certificou que não levará a possibilidade de SQL Injeciton no WordPress em uso pelo seu negócio.
Obtenha os códigos do plugin e faça uma busca pelo termo “prepare”. Se encontrado, refine a busca por algo assim “$wpdb->prepare(“. Essa ocorrência é um indício de uso do método prepare e que a classe wpdb foi utilizada. E como sua função é tratar instruções SQL precauções sobre o assunto foram tomadas.
Contrate uma nova empresa especializada em segurança e na análise de códigos para garantir a segurança da aplicação. A Conviso é especializada no assunto e possuem considerável conhecimento sobre WordPress.
O WordPress, em todas as suas interações com o banco de dados da aplicação, faz uso da classe wpdb e trata as entradas através do método prepare. Você deve fazer o mesmo ao desenvolver plugins e assim ficar livre de SQL Injection no WordPress.
Todo e qualquer dado captado do usuário deve ser tratado. Dado que será agregado a uma instrução SQL mais ainda. O método prepare faz uso de dois parâmetros. O primeiro é a instrução SQL com os placeholders desejados, o segundo são os dados a serem trocados pelos placeholders. O método considera o estilo das funções PHP sprintf() e vsprintf(). Desde a versão 3.5 do WordPress esse método força e considere o uso de dois parâmetros.
$sql = $wpdb->prepare( 'INSTRUÇÃO SQL', $variable );
$sql = $wpdb->prepare( 'INSTRUÇÃO $d SQL com %s placeholders %f', $integer, $string, $float);
Três tipos de placeholders são suportados: inteiros através do %d, strings através do %s e floats através do %f. O uso isolado do caractere “%” causará erro, se necessário como no caso da instrução LIKE considere escapá-lo fazendo seu uso duas vezes seguidas, assim “%%”.
$sql = $wpdb->prepare( "SELECT user_email FROM $wpdb->users WHERE ID = %d", $user_id ); $user_email = $wpdb->get_var( $sql );
No exemplo acima estamos selecionando o e-mail do usuário baseado na busca por seu ID de identificação na tabela de usuários do WordPress. Observe que na instrução SQL é feito o uso do placeholder %d, isso nos garante que seja agregado a essa instrução um valor inteiro obtido pela variável $user_id.
$sql = $wpdb->prepare( "SELECT post_title FROM $wpdb->posts WHERE post_parent = %d AND post_type = %s", array( $post_parent, $post_type ) ); $posts = $wpdb->query( $sql );
No exemplo acima estamos em busca dos títulos de páginas que possuem pais, por exemplo. Observe que na instrução SQL é feito o uso do placeholder %d e %s. Isso nos garante que seja agregado a essa instrução um valor inteiro obtido pela variável $post_parent e uma string através da variável $post_type.
Se proteger de SQL Injection no WordPress é garantir estar livre dessa brecha no core da plataforma, o que você consegue fazendo uso da versão mais recente. O ecossistema de plugins é grande, rico e fantástico com as soluções que agregam ao seu site, mas é preciso ser mais seletivo com suas escolhas tendo a segurança como fator determinante pela adoção, ou não, de determinados plugins.
Você adota alguma outra prática para ficar livre de SQL Injection no WordPress? Compartilhe conosco.
Rodrigo Vieira Eufrasio da Silva 
Junior 
