Os plugins do WordPress são seguros de usar?

Ao longo dos anos, pesquisas identificaram que mais de 20% dos 50 plugins WordPress mais populares são vulneráveis ​​a ataques comuns da Web. Além disso, uma pesquisa direcionada em plugins de e-commerce descobriu que 7 dos 10 plugins de e-commerce mais populares contêm vulnerabilidades. Infelizmente, os hackers normalmente exploram esses aplicativos vulneráveis ​​para acessar informações confidenciais, como registros de saúde e detalhes financeiros. Em outros casos, as vulnerabilidades permitem aos hackers desfigurar sites ou redirecioná-los para outros sites controlados pelo invasor.

Em casos mais recentes, vimos plugins maliciosos do WordPress sendo utilizados não apenas para manter o acesso em servidores comprometidos, mas também para minerar criptomoedas. Então, isso coloca uma questão de quão seguros são os plugins do WordPress.

Neste blog, vamos nos concentrar profundamente nos plug-ins do WordPress como fontes potenciais de violações de segurança.

Desenvolvimento Web baseado em plugins.

De um modo geral, o WordPress é o sistema de gerenciamento de conteúdo (CMS) mais popular do mundo, pois alimenta mais de 30% da Web.

Dito isso, a força central do WordPress está em sua capacidade de permitir a personalização de sites por meio de sua extensa oferta de dezenas de milhares de plugins e temas. Esses plugins variam em tipo e funcionalidade - desde adicionar um formulário de contato ao site até otimizar um blog para SEO ou até mesmo publicar novas postagens no Facebook automaticamente.

Desenvolvimento de terceiros.

A ideia principal por trás do desenvolvimento baseado em plug-ins é oferecer recursos adicionais para estender os recursos principais de um sistema. Essencialmente, o núcleo do aplicativo é normalmente mantido por um conjunto de desenvolvedores de longo prazo, enquanto terceiros criam vários plugins em torno do núcleo do aplicativo.

Esse processo é benéfico tanto para o provedor do aplicativo quanto para o provedor do plug-in, pois o provedor do aplicativo pode se concentrar mais na funcionalidade principal, enquanto o provedor do plug-in não precisa se preocupar com a infraestrutura do plug-in, que é fornecida pela funcionalidade principal do aplicativo. Geralmente, o WordPress também é suportado por uma comunidade global de milhares de desenvolvedores e entusiastas de software comercial e de código aberto.

Sem Diretrizes de Segurança

No geral, embora existam alguns conjuntos de padrões e recomendações de codificação, tecnicamente não há diretrizes de segurança nem requisitos padrão aos quais um desenvolvedor de plug-in precisa aderir estritamente. Isso significa que uma vulnerabilidade em um plug-in pode se propagar em milhões de sites.

E como o WordPress é amplamente usado, é, consequentemente, um alvo popular para ataques. Então, em essência, um hacker explorando a vulnerabilidade de um plugin pode infectar milhares de sites. Um cenário que já foi testemunhado por muitos blogueiros.

Infelizmente, vulnerabilidades relacionadas a plugins também tendem a ser recorrentes, exploráveis ​​e difíceis de detectar. Portanto, é necessário entender melhor essas vulnerabilidades para mitigar quaisquer ameaças de segurança relevantes. Vamos cavar mais fundo, sim?

O WordPress é realmente seguro?

Antes de mais nada, vamos responder a esta pergunta. Na maioria das vezes, o WordPress como um ecossistema bruto é muito seguro, desde que as melhores práticas de segurança do WordPress sejam seguidas. Em média, cerca de 30.000 novos sites são invadidos todos os dias na web. Esses hackers tendem a direcionar sites WordPress por causa de vulnerabilidades de plugins, senhas fracas e software obsoleto. Portanto, obter a melhor segurança requer um nível de intencionalidade, o que significa seguir algumas práticas recomendadas básicas de segurança do WordPress para reduzir sua vulnerabilidade a ataques.

Leia mais: 11 maneiras eficazes de expandir seu site WordPress para alto tráfego

De onde vêm essas vulnerabilidades?

Um relatório recente do wpscan.org revelou que o WordPress tem quase 4.000 vulnerabilidades de segurança conhecidas. A grande maioria dessas vulnerabilidades foi causada por plugins. E embora algumas dessas vulnerabilidades relacionadas a plugins possam ter consequências graves, muitas permanecem despercebidas por anos antes de serem corrigidas. Na maioria dos casos, eles geralmente podem ser corrigidos com pequenas alterações localizadas em seu código-fonte.

No entanto, antes de nos adiantarmos, vamos dar um passo para trás.

O que são plug-ins?

Basicamente, plugins são extensões de software que complementam aplicativos com novas funcionalidades e comportamentos personalizados. Em particular, o WordPress oferece milhares de plugins (mais de 52.000), que foram usados ​​para construir milhares de aplicativos web personalizados.

Como os aplicativos da Web baseados em plug-ins se tornaram mais populares, mais desenvolvedores voltaram sua atenção para explorar seu potencial de reimaginar aplicativos da Web compondo, configurando e estendendo diferentes plug-ins com funcionalidade de ponta.

Implicações do desenvolvimento de plugins

Dito isto, a capacidade de explorar plugins para estender sistemas web com funcionalidades adicionais e personalizadas tem implicações positivas e negativas para os desenvolvedores. Em primeiro lugar, em uma nota positiva, normalmente há várias opções de personalização para escolher, dando aos desenvolvedores a capacidade de criar aplicativos da Web de maneira rápida e fácil, adaptados às necessidades dos usuários. Assim, facilitando a prototipagem e o desenvolvimento rápidos.

No entanto, pelo lado negativo, um aplicativo da web pode acabar sendo uma composição complexa de vários plugins de diferentes fontes. O que, em última análise, apresenta preocupações relacionadas à segurança dos plugins. Por exemplo, TimThumb, um plug-in que foi empregado por milhões de aplicativos baseados em WordPress foi supostamente aberto a uma exploração em que os invasores poderiam executar deliberadamente código remoto.

De fato, cerca de 15% das vulnerabilidades em sistemas web podem ser consideradas críticas de acordo com o National Vulnerability Database (NVD) dos Estados Unidos, com quase 35% delas sendo vulnerabilidades facilmente exploráveis.

Quais são as consequências de plugins comprometidos?

Além de usuários perderem informações financeiras ou até mesmo terem seus registros de saúde comprometidos, quanto mais grave uma vulnerabilidade, maior o impacto financeiro nas empresas de software. Além disso, isso é agravado ainda mais se os desenvolvedores não liberarem um caminho viável no momento da divulgação. Assim, os fornecedores de plugins normalmente se esforçam para criar aplicativos mais seguros

Vamos agora investigar algumas vulnerabilidades de segurança normalmente encontradas em plugins para obter uma compreensão mais ampla de suas consequências e implicações.

Vulnerabilidades de segurança

Conforme coletamos, as vulnerabilidades abrem oportunidades para o potencial uso indevido de sistemas de software. Em última análise, como o WordPress permite que milhões de desenvolvedores em todo o mundo criem seus próprios plugins, não é realista esperar que um nível de comprometimento ocorra nos plugins.

Consequentemente, a segurança pode ser violada por interações imprevistas de plugins com o sistema principal, levando a vulnerabilidades que podem ser potencialmente exploradas por invasores. Isso implica que a segurança dos sistemas da Web depende de manter sob controle as vulnerabilidades do sistema principal e do plug-in.

Complexidade do WordPress

Por causa da complexidade do WordPress, às vezes ele tende a ser atormentado por vulnerabilidades. Por exemplo, o WordPress fornece uma infraestrutura intuitiva para a qual os plugins podem contribuir com novos recursos modificando o estado global compartilhado ou executando uma função em um ponto específico na execução do núcleo do sistema. Consequentemente, uma vulnerabilidade de plug-in pode surgir quando o plug-in envia dados de entrada maliciosos para componentes principais sem a devida higienização ou validação de entrada.

Exemplos de vulnerabilidades de plug-in

Em última análise, as vulnerabilidades de plug-in mais comuns são scripts entre sites, injeção de SQL e falsificação de solicitações entre sites. No geral, o tipo de vulnerabilidade mais perigoso que pode ser facilmente explorado por invasores é o SQL Injection. No entanto, existem outras vulnerabilidades, fontes de violação e comprometimentos, a saber:

• Erros de processamento de dados
• Validação de entrada imprópria
• Exposição de informações
• Travessia do caminho
• Recursos de segurança
• Controles de acesso
• Controle de acesso impróprio
• Autorização imprópria
• Autenticação imprópria
• Falsificação de solicitação entre sites
• Upload irrestrito de arquivo
• Arquivos Acessíveis a Partes Externas
• Link Seguinte
• Abrir redirecionamento
• Injeção de Comando
• Injeção de comando do SO
• Script entre sites
• Injeção SQL
• Injeção de código

Para mais contexto, vamos explorar os ataques e vulnerabilidades mais comuns.

• · Injeção de SQL: as injeções de SQL normalmente acontecem quando um invasor obtém acesso ao banco de dados WordPress de um usuário e a todos os dados de seu site. As injeções de SQL também podem ser usadas para inserir novos dados em um banco de dados, incluindo links para sites maliciosos ou de spam.

As injeções de SQL permitem a execução de comandos no servidor back-end, como a extração de informações confidenciais. Em um ambiente hospedado, um ataque de injeção de SQL pode ser usado como um trampolim para ataques contra sites não vulneráveis.

• · Cross-Site Scripting: Este ataque permite a execução de um script no cliente para burlar os controles de acesso. Normalmente, segmenta todos os visitantes de um site. Em um ambiente hospedado, esse ataque pode ser usado para roubar os cookies de sessão do administrador do site, permitindo que o invasor se passe por administrador.

• · Falsificação de solicitação entre sites: essa vulnerabilidade permite que o hacker execute uma transação em nível de aplicativo em nome da vítima. Em um ambiente hospedado, um invasor pode fazer logon no site em nome do administrador e realizar atividades maliciosas, como redirecionar usuários ou realizar transações administrativas.

Comum em plugins do WordPress, as vulnerabilidades de script entre sites funcionam dessa maneira – um invasor encontra uma maneira de fazer com que a vítima carregue páginas da Web com scripts JavaScript inseguros.

Onde a maioria das vulnerabilidades aparecem?

Um estudo técnico descobriu que a maioria das vulnerabilidades (cerca de 92%) aparecem no código do plugin. Além disso, de acordo com os resultados, vulnerabilidades como Cross-site Scripting e Cross-site Request Forgery foram mais comuns no código do plugin, enquanto outras vulnerabilidades foram mais prevalentes no código principal. Da mesma forma, o estudo revelou que a qualidade dos plugins variava e que não havia correlação entre as classificações dos plugins e o número de vulnerabilidades encontradas neles.

O processo de escrita de código PHP

O processo de escrita de código pode ser a gênese de qualquer vulnerabilidade ou comprometimento. De um modo geral, o PHP é bem conhecido por suportar a execução de código arbitrário no lado do servidor sem invocar diretamente o sistema operacional do host. Dito isso, sempre que os desenvolvedores são negligentes durante o processo de escrita de código, isso aumenta a possibilidade da introdução de vulnerabilidades de Cross-site Scripting no código do plugin.

Por outro lado, em relação ao SQL Injection é uma vulnerabilidade comum porque pode ser facilmente detectada e explorada. Ironicamente, mesmo um site com uma pequena base de usuários provavelmente estará sujeito a uma tentativa de ataque de SQL Injection.

Parte da exposição a vulnerabilidades decorre de desenvolvedores que usam recursos inseguros. Da mesma forma, a validação de entrada adequada ainda é um grande desafio para os desenvolvedores de plugins porque muitos dos plugins desenvolvidos recentemente foram criados por desenvolvedores não tão qualificados

As vulnerabilidades causadas pelos plugins do WordPress são críticas?

Todas as coisas consideradas; uma vulnerabilidade pode influenciar negativamente o sistema web de várias maneiras. Por exemplo, a exploração bem-sucedida de uma vulnerabilidade pode levar a uma perda completa de confidencialidade, embora sem perda de disponibilidade.

Como foi observado, SQL Injection parece ser o tipo de vulnerabilidade mais perigoso, embora afete apenas parcialmente a integridade, disponibilidade e confidencialidade do sistema. No entanto, essa vulnerabilidade tem o potencial de permitir aos invasores acesso irrestrito a arquivos ou informações.

Portanto, inadvertidamente, a maioria das vulnerabilidades tem potencial para levar a violações de dados, enquanto algumas vulnerabilidades não necessariamente expõem o aplicativo da Web a sérios riscos de segurança. De qualquer forma, é importante evitar arriscar com essas probabilidades.

Por quanto tempo uma vulnerabilidade pode sobreviver no código de um plugin do WordPress?

Normalmente, vulnerabilidades no código tendem a transitar por estados distintos, variando desde a introdução, passando pela divulgação, até o lançamento de um patch corrigindo a ameaça à segurança.

Normalmente, uma vulnerabilidade é divulgada quando o descobridor revela os detalhes da ameaça à segurança para um público mais amplo. Eventualmente, a vulnerabilidade é corrigida quando o desenvolvedor lança um patch que corrige a ameaça de segurança subjacente. No entanto, às vezes, uma vulnerabilidade permanece despercebida em um aplicativo da Web por anos antes de ser identificada e corrigida.

Possíveis Mitigações e Métodos de Detecção

É melhor prevenir do que remediar, como muitos dizem. Portanto, se os desenvolvedores de plugins puderem entender, detectar e eliminar completamente o Cross-site Scripting, SQL Injection e Cross-site Request Forgery, é possível que tenhamos plugins com 75% menos vulnerabilidades.

No entanto, vale a pena notar que essas três vulnerabilidades não são as únicas vulnerabilidades que podem ser exploradas por invasores. Mas sim, são as vulnerabilidades mais comuns.

Portanto, embora essas estratégias de mitigação propostas não garantam que um determinado plug-in seja totalmente seguro, elas, no entanto, definem bons princípios para prevenção de vulnerabilidades. Por exemplo:

1. Entenda como os dados são usados ​​e a codificação esperada pelas partes principais do WordPress. Nesse caso, os desenvolvedores devem sempre assumir todas as entradas como maliciosas e rejeitar qualquer entrada que não esteja estritamente em conformidade com o padrão de codificação exigido ou transformá-la em uma entrada válida.
2. Para proteger os bancos de dados da injeção de SQL, os desenvolvedores devem usar instruções SQL parametrizadas, separando o código da manipulação de dados. Além disso, sempre verifique os cabeçalhos para verificar se a solicitação é da mesma origem. Além disso, também pode ser útil evitar a exposição de dados a invasores não autenticados.
3. Uma boa prática é evitar o método GET para qualquer solicitação que acione uma mudança de estado.

Detecção de Vulnerabilidade

Infelizmente, não existe um método consistente para detectar os pontos fracos de código mais comuns com 100% de precisão e cobertura. Infelizmente, mesmo as técnicas modernas que usam análise de fluxo de dados para detectar Cross-site Scripting, às vezes dão falsos positivos.

Por outro lado, métodos de análise manual, como revisões de código, tendem a ser mais eficazes do que métodos totalmente automatizados, especialmente para vulnerabilidades relacionadas ao design. Por exemplo, a falsificação de solicitação entre sites é especialmente difícil de detectar de forma confiável usando métodos automatizados porque cada aplicativo tem sua própria política de segurança e maneira de indicar quais solicitações exigem forte confiança de que o usuário pretende fazer a solicitação.

No entanto, por outro lado, a análise manual pode ser útil para encontrar SQL Injection, embora possa não atingir a cobertura de código desejada dentro de restrições de tempo limitadas. Isso pode se tornar difícil para pontos fracos que devem ser considerados para todas as entradas, pois a superfície de ataque pode ser muito grande.

Consequentemente, algumas organizações enfatizam a importância de uma abordagem equilibrada que inclua revisões manuais e análises automatizadas que englobem todas as fases do processo de desenvolvimento do sistema web.

Melhores práticas para proteger seu aplicativo WordPress

• Baixe plugins apenas de fontes confiáveis, como WordPress.org: Como qualquer pessoa pode desenvolver um plugin WordPress, os hackers exploram notoriamente essa vulnerabilidade para ocultar seus próprios plugins maliciosos. Um mercado respeitável pode não garantir totalmente o acesso a plugins inofensivos, mas é recomendado como uma prática de mitigação.
• Certifique-se sempre de que todos os seus plugins estão atualizados: os usuários do WordPress normalmente recebem e-mails de notificação que geralmente ignoram. Certifique-se de configurar seus plugins para atualizar automaticamente, ou pelo menos atualizá-los manualmente.
• Verifique a postura de segurança do plug-in verificando problemas de segurança: A maioria dos plug-ins é de código aberto, o que significa que seu código-fonte está disponível. Portanto, certifique-se de usar uma ferramenta estática de análise de código-fonte que fornecerá a “conta de saúde” do plug-in. Alguns scanners avançados podem até apontar para você as recomendações de correção ideais e mais rápidas.
• Remova todos os plugins não utilizados: Infelizmente, o código de plugins antigos e não utilizados normalmente permanece no servidor – mesmo quando os plugins estão inativos. Portanto, certifique-se de sempre remover plugins não utilizados como parte da manutenção do seu site WordPress

Recomendações para desenvolvedores de plug-ins

• Sempre incorpore a segurança durante o desenvolvimento do plug-in: as vulnerabilidades incorrem em um custo mais alto para serem corrigidas posteriormente, portanto, sempre integre a segurança no desenvolvimento do plug-in como parte de seu processo seguro de Ciclo de Vida de Desenvolvimento de Software (SDLC).
• Execute o plug-in por meio de um scanner de código para garantir que ele atenda aos padrões de segurança mais recentes. Certifique-se de realizar um teste abrangente de análise de código-fonte durante o desenvolvimento e antes do lançamento.

Desenvolvendo Plugins Seguros

Como foi observado, os desenvolvedores de plugins precisam se esforçar para escrever um código seguro. Infelizmente, muitos desenvolvedores ainda não sabem como, pois não são tão habilidosos. Particularmente, dada a natureza das vulnerabilidades mais comuns citadas acima, fica claro que muitos desenvolvedores não entendem os ataques comuns, as funções de segurança fornecidas pela linguagem e plataforma que usam e como usar as práticas aplicáveis ​​para mitigar os problemas de segurança.

Portanto, nossa recomendação no Creole Studios é que talvez novas metodologias devam ser desenvolvidas sob medida para desenvolvedores de plugins. Tais metodologias devem promover a segurança nas fases de requisitos e design, pois os desenvolvedores são as entidades mais importantes na segurança de software.

Pensamentos finais

Para resumir o tópico, os plugins do WordPress podem ser comprometidos, com as vulnerabilidades mais comuns sendo Cross-site Scripting, SQL Injection e Cross-site Request Forgery.

Infelizmente, a pesquisa parece sugerir que a frequência com que essas vulnerabilidades ocorrem não parece estar diminuindo com o tempo. É seguro supor que a principal razão para isso é que a maioria dos desenvolvedores de plugins do WordPress permanecem um pouco pouco qualificados em relação à programação segura.

Dito isto, a primeira linha de defesa deve ser a equipe de desenvolvimento! E acreditamos que, uma vez que as melhores práticas de segurança sejam implementadas, os usuários podem dormir melhor à noite, sabendo que estão protegidos contra criminosos cibernéticos.

Para obter mais informações sobre nossas práticas de segurança do WordPress, entre em contato para uma consulta.