Entrevista com o Code Risk – Um serviço gratuito de análise de código-fonte para plugins WordPress
Publicados: 2018-10-17Vulnerabilidades em plugins do WordPress têm sido a causa de mais hacks de sites do que vulnerabilidades no núcleo do WordPress. Uma das razões pelas quais isso está acontecendo é a falta de recursos. O software sempre terá vulnerabilidades, embora o código principal do WordPress seja examinado por milhares de pessoas. Além disso, a fundação tem recursos alocados para garantir que o código seja o mais seguro possível.
Por outro lado, muitos desenvolvedores de plugins não têm os recursos disponíveis para garantir que o código de seus plugins seja seguro, especialmente se for um plugin pequeno. Embora tudo isso vá mudar, como explica Hendrik Buchwald nesta entrevista. Hendrik é engenheiro de software, pesquisador de segurança e cofundador da RIPS Technologies.
O que a RIPS Technologies faz?
A RIPS Technologies é uma empresa de alta tecnologia com sede em Bochum, Alemanha. Fornecemos análises de segurança automatizadas para aplicativos PHP como instalação de software local ou serviço de nuvem altamente escalável. Nossos algoritmos inovadores de análise de código, especificamente dedicados à linguagem PHP, podem identificar vulnerabilidades de segurança complexas em aplicativos modernos como nenhuma outra solução. Nossa missão é fornecer aos desenvolvedores e profissionais de segurança a análise de segurança mais precisa e eficiente possível.
Qual você diria que é o erro de segurança mais comum que os desenvolvedores cometem e quais são as 3 principais vulnerabilidades que você vê nos plugins do WordPress?
Sem surpresa, os problemas mais comuns são vulnerabilidades de cross-site scripting (XSS) que ocorrem sempre que a entrada do usuário é impressa sem a devida higienização na página de resposta HTML. Por um lado, esses problemas aparecem com frequência porque a saída de dados é a operação mais comum de aplicativos PHP e, portanto, mais afetada por violações de segurança do que outras operações. E segundo, dada a diversidade de contextos HTML e suas armadilhas na sanitização, essas questões são facilmente apresentadas. As vulnerabilidades de cross-site scripting (XSS) são bastante sérias no WordPress porque podem ser usadas, por exemplo, para injetar código PHP por meio do editor de modelos. Felizmente, eles exigem interação com um administrador.
O segundo problema mais comum são as vulnerabilidades de injeção de SQL. As injeções de SQL são mais graves do que as vulnerabilidades de script entre sites porque, na pior das hipóteses, podem ser usadas para extrair informações confidenciais do banco de dados – por exemplo, senhas – sem qualquer interação do usuário. Como resultado, eles podem ser usados para ataques maliciosos totalmente automatizados.
Quão boa ou ruim você diria que é a postura geral de segurança dos 1.000 plugins mais populares/baixados?
Isso é difícil de responder porque eu não analisei os 1.000 plugins mais populares em detalhes. Essas operações levariam muitos meses para serem concluídas e, quando estivermos prontos, precisaremos começar de novo porque alguns plugins são atualizados com muita frequência.
Por isso, é importante usar um serviço de segurança automatizado, como o Code Risk. Embora a partir da pontuação do CodeRisk, que é gerada a partir das varreduras de código-fonte automatizadas e não verificadas que fazemos no repositório, posso dizer que o código da maioria não é ruim, embora também existam plugins com pontuação ruim. A maioria desses plugins são muito grandes e têm muitas funcionalidades. Isso aumenta automaticamente as chances de ter um bug em algum lugar. De nossos testes manuais também podemos dizer que os grandes plugins muitas vezes têm vulnerabilidades lógicas.
Você pode nos contar um pouco sobre o que você está oferecendo aos desenvolvedores de plugins do WordPress?
Nosso projeto mais recente, CodeRisk, ajuda desenvolvedores e usuários a avaliar o risco de segurança do código de seus plugins gratuitamente. Por enquanto, isso é limitado aos plugins do WordPress que estão hospedados no repositório oficial do WordPress.
Estamos buscando automaticamente novos plugins do repositório WordPress e digitalizando-os com nosso RIPS de scanner de segurança PHP. Os resultados detalhados do RIPS são combinados em um valor de risco fácil de entender. O valor leva em consideração a gravidade da exploração bem-sucedida, a quantidade de problemas encontrados em relação ao tamanho do código e a probabilidade de que um problema possa ser abusado por terceiros.
Os desenvolvedores de plugins podem solicitar os resultados detalhados completos para seus próprios plugins por meio de um sistema automatizado. Eles podem usar as informações para corrigir possíveis vulnerabilidades e fortalecer seu código, tornando o ecossistema WordPress mais seguro. A ideia por trás do CodeRisk é capacitar os desenvolvedores de plugins a encontrar problemas em seu código por conta própria, mesmo que não sejam experientes em segurança. Embora façamos muitas pesquisas sobre a segurança do WordPress e relatemos muitas vulnerabilidades aos desenvolvedores, existem muitos plugins para analisá-los manualmente.
Muitos desenvolvedores de plugins estão assinando e usando seu serviço gratuito de análise de código-fonte? Como é a resposta da comunidade WordPress?
Atualmente, existem algumas dezenas de desenvolvedores de plugins que usam o CodeRisk para reduzir o risco de vulnerabilidades de segurança em seus plugins. Recebemos muitos bons comentários até agora e o CodeRisk já ajudou a resolver centenas de problemas.
Os scanners automatizados tendem a relatar falsos positivos e casos extremos que podem não ser exploráveis. Considerando que muitos desenvolvedores não são experientes em segurança, o que você está fazendo para ajudá-los e evitar alarmes falsos?
Nossos usuários devem estar cientes de que destacamos o código que representa um risco de segurança. Entre as vulnerabilidades de segurança não intencionais, isso também inclui outras descobertas, por exemplo, proteções fracas que podem se tornar uma ameaça mais tarde.
Você não precisa saber se e como um problema pode ser explorado para garantir que ele não se torne uma ameaça à segurança no futuro. Por exemplo, se você imprimir o valor de retorno de uma função, certifique-se de codificá-lo corretamente para evitar vulnerabilidades de script entre sites. Mesmo que o valor de retorno ainda não contenha entrada do usuário, esse pode não ser o caso no futuro.
Para onde você vê esse projeto WordPress gratuito? Você tem planos para isso? Talvez oferecer um serviço premium para desenvolvedores de mão, ajudá-los a entender os resultados e tirar o melhor proveito deles?
A próxima versão do CodeRisk adicionará suporte para temas do WordPress, pois eles são parte integrante da maioria dos blogs e, muitas vezes, também contêm vulnerabilidades. Em algum momento, gostaríamos de estender o CodeRisk a outros sistemas de gerenciamento de conteúdo. Atualmente, não há planos para um serviço premium, mas se houver demanda suficiente, isso pode mudar.
Você pode dar aos desenvolvedores do WordPress duas ou três práticas recomendadas de desenvolvimento seguro a serem seguidas para que eles possam escrever um código mais seguro?
Se você quiser escrever um código mais seguro, nunca confie cegamente no código existente. Sempre assuma que as funções podem retornar a entrada do usuário e tratá-las como tal. Para obter informações gerais sobre como escrever código PHP seguro, consulte o Guia de 2018 para construir software PHP seguro.
Visite o site da CodeRisk para obter mais informações sobre o serviço. E se você é um desenvolvedor de plugins do WordPress e seu plugin está no repositório de plugins do WordPress, inscreva-se em uma conta gratuita para ver quais vulnerabilidades seu plugin pode ter.