Práticas recomendadas de segurança para desenvolvedores de plugins e temas do WordPress

Publicados: 2020-12-09

Como desenvolvedor do WordPress, há muitas decisões que você precisa tomar sobre o que trabalhar. Seu principal interesse e prioridade é criar um tema ou plugin incrível, e as medidas de segurança geralmente ficam em segundo plano quando você se senta no banco do motorista para trabalhar no código. Quando foi a última vez que você se sentou e revisou seu próprio código para problemas de segurança? Não, eu não pensei assim

Essas dicas são baseadas na minha experiência tanto no desenvolvimento de plugins na CleverPlugins quanto em ajudar inúmeros clientes a colocar seus sites online novamente após serem invadidos. Desenvolver um plugin de segurança como o WP Security Ninja não me deixou menos paranóico com o código de outras pessoas.

O motivo mais comum para sites invadidos ainda é o péssimo gerenciamento de senhas, mas isso não deve ser uma desculpa para usar algumas das maneiras simples de proteger seu código.

Quando você desenvolve um plugin ou tema, você deseja que ele se torne popular e o instale no maior número possível de sites. Quanto maior o seu sucesso, maior a chance de as pessoas tentarem abusar do seu trabalho para hackear os sites de seus usuários.

Devido à popularidade do WordPress, tornou-se um dos alvos mais comuns para hackers. Se uma vulnerabilidade for detectada em um plugin ou tema, isso pode significar que milhares, senão centenas de milhares de sites estão abertos para abuso.

Infelizmente, acontece regularmente que uma vulnerabilidade aparece em um produto conhecido, por isso vale a pena tomar algumas medidas básicas de segurança para proteger seu código para seus usuários.

E a equipe de revisão do WordPress.org?

Você pode pensar que a equipe que revisa plugins e temas antes de publicar no repositório oficial verifica todos os tipos de problemas de segurança, mas a equipe é pequena e consiste apenas de algumas pessoas. A fila de plugins e temas para verificar está crescendo continuamente, então o tempo que eles têm para revisar cada um é limitado.

No entanto, se eles encontrarem algo, eles podem fechar automaticamente seu plug-in até que você o corrija ou enviar um e-mail avisando que você deve corrigir uma vulnerabilidade antes de um determinado período de tempo.

O ponto é que, uma vez que seu plugin ou tema esteja listado no repositório, você pode enviar atualizações por meio do repositório sem triagem adicional, para que uma vulnerabilidade possa entrar facilmente a qualquer momento e passar despercebida por quase qualquer período de tempo.

Basicamente, o reforço das medidas de segurança do seu plugin depende de você, então vamos ver algumas maneiras de proteger seu produto WordPress e evitar muitas dores de cabeça e potencialmente um impacto negativo em sua marca.

Aqui está o que você pode fazer para desenvolver com segurança seu plugin ou tema do WordPress.

1. Pense na segurança de todas as perspectivas!

Você nunca sabe quem pode estar usando seu plugin ou tema e qual o nível de compreensão que eles têm sobre segurança, se houver.

Você nunca sabe quem pode estar usando seu plugin ou tema e qual o nível de compreensão que eles têm sobre segurança, se é que existem.Tweet

Administradores, editores ou usuários regulares em qualquer site de cliente podem não usar senhas seguras e suas contas podem ser invadidas. Se o seu produto não estiver protegido, essas contas podem ser abusadas para obter acesso adicional e instalar código malicioso no site do seu cliente.

Você não deve esperar que os administradores do servidor que configuraram o servidor no qual o site é executado saibam o suficiente sobre como proteger seu site de outros sites no mesmo servidor. Se o site for hospedado por um grande provedor, você pode esperar que o site seja devidamente “separado”, mas você não sabe onde seu produto será instalado.

Isso soa paranóico? Pode ser. Mas, se e quando seu plugin ou tema se tornar super popular, você ficará feliz por ter adotado uma abordagem paranóica em relação à segurança.

Se e quando seu plugin ou tema se tornar super popular, você ficará feliz por ter adotado uma abordagem paranóica em relação à segurança.Tweet

2. Prevenir ataques XSS – Cross-Site Scripting

Este está se tornando cada vez mais importante, pois o WordPress está se tornando um projeto mais voltado para o frontend com Gutenberg e ReactJS.

Um dos erros mais comuns dos desenvolvedores do WordPress é esquecer de validar e higienizar seu código – deixando-o aberto a ataques XSS. Existem algumas variações de XSS, mas, em geral, um ataque XSS ocorre quando um hacker tem permissão para injetar código no servidor e executá-lo no navegador de um visitante.

Imagine que você tenha um campo de entrada. Para simplificar, digamos que seja um campo de comentários onde usuários ou visitantes podem enviar um comentário a uma postagem.

Um hacker tentará enviar um comentário com "<script>alert('XSS');</script>" .

Agora, este é apenas um exemplo básico que aparece um alerta na tela do usuário e nada mais. Um hacker real usará o campo de comentários para injetar código que carrega código de seu site que pode roubar informações do navegador do visitante e muito mais.

Podemos evitar que isso aconteça validando, higienizando e escapando.

Validar é verificar os dados enviados antes de fazer qualquer coisa, como armazená-los no banco de dados. Sempre que os dados são enviados, você pode verificá-los e certificar-se de que são aceitáveis. Se for um campo de quantidade, você espera um número. Se não for um número, você poderá retornar uma mensagem de erro ao usuário.

Sanitizar os dados é processar as informações enviadas e garantir que elas não contenham nada que não desejamos armazenar, como remover caracteres indesejados. O WordPress tem várias funções incorporadas para ajudar com isso. Mais sobre higienização daqui a pouco.

Escapar é impedir que qualquer código malicioso seja executado em seu navegador. Digamos que você já tenha um código malicioso injetado em seu site, ou outro plugin ou tema está permitindo que hackers insiram código nos dados que você está usando – escapar os dados para a tela antes de mostrá-los evitará que seja um problema.

Vejamos o mesmo exemplo simples que usamos antes de "<script>alert('XSS');</script>"

Se não fizermos nada com esse código, o navegador pensará que é código HTML. O detalhe importante aqui são os caracteres < > que são usados ​​para definir tags HTML. Ao escapar destes, transformamos < em &lt; e > em &gt; O navegador agora entende que este não é um código HTML real e deve mostrar apenas um sinal de menor e maior que.

Ao validar, higienizar e escapar de todos os dados que entram e saem de seu aplicativo, você protege seus usuários de um dos métodos de ataque mais comuns.

3. Tenha cuidado com as injeções de SQL

Como o nome indica, um invasor pode usar injeções de SQL para fazer seu site processar uma consulta SQL ajustada e usá-la para obter acesso ao seu banco de dados.

Dependendo dos dados que você armazena em seu site, ter os dados do seu site vazados de um ataque de injeção de SQL pode passar de embaraçoso a devastar completamente sua reputação e seus negócios.

A injeção de SQL é uma maneira antiga de atacar um site, mas ainda é muito eficaz e há muitas pessoas procurando maneiras de usar essa forma de ataque. Em outubro de 2020, o popular plugin WordPress Loginizer anunciou que tinha uma vulnerabilidade de injeção de SQL que deixou mais de um milhão de sites em risco.

Em 2019, hackers desconhecidos roubaram milhões de dados fiscais de búlgaros por meio de um ataque de injeção de SQL e, em 2016, um grupo de hackers russos extraiu informações de eleitores de cerca de 500.000 pessoas em Ohio. Esses tipos de ataques ainda são muito eficazes e você pode encontrar muitas informações sobre eles.

História em quadrinhos sobre desinfecção de entradas de dados

Fonte: https://xkcd.com/327/

O local mais comum em que uma injeção de SQL acontece é em um campo de formulário que aceita entrada do usuário – por exemplo, um nome. O ataque acontece inserindo partes do código SQL nos campos de entrada, criando uma consulta personalizada dando um resultado diferente do que você esperaria.

Digamos que você tenha um formulário que permite que as pessoas pesquisem um nome específico.

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' AND meta_key = 'celebrity_name';

Este exemplo simples pegaria todas as linhas da meta tabela post com todas as linhas que têm o nome Henry e uma chave específica, celebrity_name – dessa forma, não retornamos o banco de dados inteiro e apenas as linhas específicas de que precisamos.

Um invasor tentaria analisar um valor diferente – por exemplo 'Henry' OR 1=1--

A consulta agora retornará todas as linhas com nosso valor específico ou qualquer outra coisa – já que OR 1=1 no SQL é sempre verdadeiro.

Mas fica pior. Nossa consulta SQL só pediu resultados em que a meta_key corresponda ao valor específico que estamos procurando, portanto, não retornaríamos tudo. Isso deve limitar o impacto do ataque de injeção de SQL, certo?

Bem, não é assim. No SQL, o traço duplo é um indicador de comentário, então tudo o que vem depois disso é comentado.

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1--' AND meta_key = 'celebrity_name';

Isso significa que a consulta se parece com isso:

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1

A consulta agora retorna essencialmente tudo naquela tabela de banco de dados.

Este foi apenas um exemplo simples. Existem muitas maneiras mais complicadas de acessar a maioria, se não todas, as informações em um banco de dados. Um invasor poderia tentar ataques cegos de injeção de SQL, o que significa executar código em seu banco de dados – adicionando um novo administrador, removendo todos os seus dados e assim por diante.

A maioria dos ataques seria na forma de strings de consulta aleatórias contendo partes do SQL enviadas aos formulários do seu site. Os scripts automatizados detectariam quaisquer alterações na saída do seu site e, em seguida, detectariam o potencial de ataque.

Uma maneira simples e eficaz é enviar um apóstrofo ' como entrada e ver se isso muda alguma coisa, ocorre um erro ou mais resultados são retornados.

WordPress para o resgate

Em vez de interagir diretamente com o banco de dados, qualquer desenvolvedor deve usar a classe de abstração de banco de dados embutida no WordPress, $wpdb .

A classe $wpdb no WordPress tem toda a funcionalidade CRUD que você precisa para interagir com o banco de dados com segurança, e você pode até usar a classe para interagir com suas próprias tabelas de banco de dados se seu plugin ou tema precisar.

Você pode resolver o problema antecipando que tipo de dados deve ser razoavelmente inserido em cada formulário de entrada. Em nosso exemplo anterior, procuramos por um nome. Poderíamos higienizar a entrada para garantir que só aceitamos cartas. Se você tiver uma caixa de seleção ou um grupo de rádio que contenha apenas algumas opções, poderá verificar os dados para garantir que seja apenas uma das opções permitidas.

A coisa mais importante que você pode fazer para resolver o problema é preparar seus dados com a $wpdb->prepare() .

Essa função recebe uma string de consulta preparada e uma matriz dos argumentos que você deseja adicionar à consulta SQL.

$meta_key = 'celebrity_name';
$meta_val = 'Henry'
$allhenrys = $wpdb->get_results(
  $wpdb->prepare(
    "SELECT * FROM $wpdb-&gt;postmeta WHERE meta_key = %s AND meta_value = %s",
    $meta_key,
    $meta_val
  )
);

Todo o trabalho ocorre dentro da função prepare() . O primeiro parâmetro, a consulta preparada – contém o espaço reservado %s em vez dos valores reais. Isso é substituído pelas outras variáveis ​​analisadas, $meta_key e $meta_val .

Observação – É importante não ter um apóstrofo em sua consulta em torno dos espaços reservados, pois a função os adicionará para você.

Este é um exemplo simplificado, mas o mesmo processo pode ser usado para qualquer consulta de banco de dados e você pode usar %s para strings, %d para inteiros e %f para floats.

Há também funções para situações específicas, como adicionar uma nova linha ao banco de dados. Para isso, você pode usar $wpdb->insert() .

$wpdb->insert(
  "{$wpdb->prefix}my_custom_table",
  array(
    'name'   => 'Henry',
    'userid' => 123,
    'score'  => 10,
  ),
  array(
    '%s',
    '%d',
    '%d',
  )
);

O uso da função prepare pode ajudar a evitar a maioria das tentativas de injeção de SQL em seu produto.

Por favor, lembre-se de verificar a documentação do $wpdb. Algumas funções escaparão da entrada para você; outros esperam que você mesmo escape da entrada antes de analisar os dados para a função.

4. Use nonces para proteger suas solicitações

Usar o sistema nonce no WordPress pode ajudá-lo a evitar muitos ataques. Um nonce em termos de segurança é um número usado apenas uma vez. A ideia é adicionar esse número exclusivo a todas as solicitações que você fizer do seu código para a instalação do WordPress como forma de verificar se essa solicitação é legítima.

É um pouco como ter uma senha secreta que você precisa dar ao segurança para entrar em um clube

No entanto, os nonces no WordPress são um pouco diferentes – eles não são um número nem o nonce é usado apenas uma vez.

Tecnicamente, os nonces no WordPress podem conter letras minúsculas e números e, em vez de serem usados ​​apenas uma vez , são regenerados após um período de tempo.

A maneira como você usa um nonce é que o código PHP que registra seus arquivos JavaScript gera uma pequena combinação única de números e letras e analisa isso para que seu código JS possa lê-lo.

Toda vez que o código JavaScript envia uma solicitação ao seu site, ele envia essa parte do código e, se o código não corresponder, seu código deve ignorar a solicitação completamente.

É sempre um pouco mais fácil com um exemplo, então vamos ver uma maneira simples de carregar um arquivo .js em seu plugin seguindo estes passos:

Usando nonces em um plugin do WordPress

add_action('wp_enqueue_scripts', 'load_my_plugin_script');

function load_my_plugin_script() {
  // Register the script with all details and ensures it is loaded after jQuery
  wp_register_script('secure-plugin', plugin_dir_url( __FILE__ ). 'js/secure-plugin.js', array( 'jquery' ) );

  // Here happens the magic, we add some details to an object that we can later reference and read from in our JS code.
  wp_localize_script(
    'secure-plugin',
    'plugin_ajax_object',
    array(
      'nonce' => wp_create_nonce('secure-plugin-nonce')
    )
  );

  // Once that is done, we can now enqueue the script
  wp_enqueue_script('secure-plugin');
}

Nesta função, dizemos ao WordPress para carregar um arquivo JavaScript. Primeiro, registramos o arquivo que queremos carregar com wp_register_script() .

Em seguida, usamos wp_localize_script() para analisar uma matriz de dados, em particular “nonce” que contém o nonce exclusivo que queremos usar em nosso código JS. Lembre-se, você também pode enviar todos os tipos de outras informações nesse array, mas estamos simplificando neste exemplo.

Ao enviar uma solicitação do seu arquivo JavaScript, você precisa incluir esse nonce exclusivo. Fazer isso é fácil:

Usando nonce do plugin WordPress em um arquivo JavaScript

jQuery(document).ready(function($) {
  $.ajax({
    url: ajaxurl, // WP variable, contains URL pointing to admin-ajax.php
    type: 'POST',
    data: {
      'action':      'get_custom_data',
      '_ajax_nonce': plugin_ajax_object.nonce,
      'user_data':   'Some input from a user'
    },
    success: function( response ) {
      // Here we do what happens if all is good - update the interface with a success message!?
    },
    error: function( response ) {
      // Whooops, something went wrong!
      // console.log(response);
    }
  });
});

Como usamos wp_localize_script() , podemos usar a variável plugin_ajax_object em JavaScript. Enviamos o nonce como uma variável, _ajax_nonce .

Verifique e verifique um nonce em um plugin do WordPress a partir do código JavaScript

add_action('wp_ajax_get_custom_data', 'get_custom_data');

function get_custom_data() {
  // Ready for the magic to protect your code?
  check_ajax_referer('secure-plugin-nonce');

  /**
   * That's it - the check_ajax_referer function verifies the nonce is correct or it dies and stops code execution if it fails.
   *
   * If you want to customize the error handling and perhaps return an error to your JS code, you could change the code to something like:
   * if ( ! check_ajax_referer( 'secure-plugin-nonce', false, false ) ) {    
   *   wp_send_json_error( 'Invalid nonce' );
   * }
   */

  $sanitized_user_data = sanitize_text_field( $_POST['user_data'] );

  // ... continue with the rest of your plugin's function code ...
}

A mágica acontece com a função check_ajax_referer() que verifica o nonce e simplesmente falha e interrompe qualquer execução de código se o nonce não corresponder ao esperado.

Você pode personalizar ainda mais o código para retornar informações específicas ao usuário sobre o que aconteceu.

Usar nonces em seu código é uma maneira rápida, fácil e eficaz de evitar muitos tipos de tentativas de hackers. Isso não significa que você pode pular todas as outras medidas de segurança, mas ajuda a reduzir os piores problemas.

Lembra do que eu disse sobre nunca confiar em ninguém? Isso nos leva a outra maneira de proteger seu código – sanitizando.

Inscreva-se e pegue uma cópia gratuita do nosso livro

11 técnicas comprovadas para aumentar sua taxa de sucesso em disputas de cartão de crédito em 740%

Compartilhe com um amigo

Digite o endereço de e-mail do seu amigo. Só enviaremos este livro por e-mail, honra do escoteiro.

Obrigado por compartilhar

Impressionante - uma cópia de '11 técnicas comprovadas para aumentar sua taxa de sucesso em disputas de cartão de crédito em 740%' acabou de ser enviada para . Quer nos ajudar a divulgar ainda mais? Vá em frente, compartilhe o livro com seus amigos e colegas.

Grato pela assinatura!

- acabamos de enviar sua cópia de '11 técnicas comprovadas para aumentar sua taxa de sucesso em disputas de cartão de crédito em 740%' para .

Tem um erro de digitação no seu e-mail? clique aqui para editar o endereço de e-mail e enviar novamente.

Capa de livro
Capa de livro

5. Higienize a entrada do usuário

No exemplo anterior, incluímos um dado adicional enviado de JS para PHP. Toda vez que você insere dados em seu código, você deve esperar que ele seja inseguro.

'user_data':'Some input from a user'

Neste exemplo, é uma string simples, mas como estamos enviando dados de volta ao PHP, precisamos garantir que a entrada não contenha nenhum código que possa ser explorado em nosso ambiente PHP ou armazenado no banco de dados, permitindo mais abusos.

Entra a higienização. O WordPress tem uma variedade de funções que pega qualquer entrada que você der e limpa os dados antes de devolvê-los a você.

Neste exemplo, usamos a função sanitize_text_field() , mas o WordPress vem com muitas funções de limpeza adequadas para diferentes tipos de dados.

Existem muitas outras funções e métodos excelentes integrados ao WordPress que você pode usar para manter seu código seguro e evitar abusos.

Você nunca deve usar nenhum dado enviado ao seu código sem limpá-lo primeiro. Confira este artigo sobre erros comuns de desenvolvedores do WordPress com mais detalhes sobre higienização e outras ótimas dicas práticas.

E isso me leva à próxima dica, que a maioria dos desenvolvedores do WordPress experimentou:

6. Lembre-se de que is_admin() não é o que você pensa

Quando você começar a pensar em proteger seu código do mal, provavelmente encontrará a função is_admin() , e pelo nome, parece ser tudo o que você precisa, e tudo o que você precisa fazer é envolver seu código com isso, e tudo ficará bem.

Não, infelizmente não. A função is_admin() detecta apenas se o código está sendo executado no lado administrativo do site. Não faz nada para detectar se seu código está sendo executado por um usuário ou administrador comum.

Você nunca notará isso se apenas inserir o código em seu plug-in, porque provavelmente está executando o código na interface de administração, e isso significa que o código será avaliado apenas como true , e você parará de pensar nele e passará para algo outro.

A maneira correta de verificar se um usuário é um administrador é verificar a capacidade do usuário:

  if ( current_user_can( 'activate_plugins' ) ) { 
    // Do your code here
  }

Existem diferentes recursos para diferentes funções de usuário, para que você tenha um controle muito mais granular. Na maioria dos casos, 'activate_plugins' é o que você precisa apenas para administradores.

Se você deseja uma maneira de permitir que administradores e editores façam algo, você deve testar o 'edit_pages' .

7. Adicione rel=”noopener” ou rel=”noreferrer” aos seus links

Vincular a recursos externos é bastante normal, e o método antigo de adicionar target="_blank" a esses links faz sentido porque você não deseja que seus usuários saiam de sua página de plugin/tema.

No entanto, isso abre você para o que é chamado de Tabnabbing. Este é um problema de segurança em que o código JavaScript malicioso pode roubar informações de seus usuários abusando do recurso window.opener do JavaScript.

Prevenir isso pode ser tão simples quanto adicionar rel="noopener" aos seus links. A página para a qual você vincula hoje pode ser boa, mas isso pode mudar no futuro.

rel=noopener significa que a página para a qual você está vinculado não pode acessar informações ou obter qualquer controle de sua página.

rel=noreferrer faz o mesmo e também instrui o navegador a não passar nenhuma informação de referência por meio do cabeçalho Referrer. Adicionar rel="noreferrer" significa que a página para a qual você está vinculado não sabe de onde o visitante se origina.

Nota: Essas duas propriedades não devem ser confundidas com rel=nofollow , que está relacionada ao SEO.

8. Use HTTPS e tokens seguros com APIs de terceiros

Como desenvolvedor, muitas vezes você terá que integrar APIs, e é vital fazer isso com segurança para proteger os dados que você está enviando para frente e para trás.

Felizmente, já existem padrões estabelecidos sobre como fazer isso com segurança; um deles é HTTPS. O uso de HTTPS introduz uma camada de segurança onde todos os dados transmitidos são criptografados.

No entanto, para garantir que seus dados estejam protegidos contra olhos espiões, usar HTTPS não é suficiente.

Como este artigo da Ars Technica explica, “HTTPS não significa que seus dados estão seguros, apenas significa que sua conexão está segura”.

Tokens seguros – JWT

Um padrão seguro para lidar com a comunicação e as integrações de API é o uso de JSON Web Tokens, JWT.

Um token seguro é criado fazendo uma solicitação a um servidor que valida os detalhes de login de um usuário e gera um token, um pequeno pedaço de string que contém dados, como nome de usuário, ID e assim por diante.

Ao enviar solicitações subsequentes ao servidor, você inclui esse token na solicitação. Este token prova que você está autenticado e tem acesso. Se o token for válido e não tiver expirado, o servidor usará os detalhes do usuário contidos no token e extrairá os dados solicitados.

O servidor pode processar solicitações rapidamente dessa maneira, em comparação com o uso de uma chave de API, que exigiria pesquisar o usuário por meio dessa chave antes de decidir processar os dados. Usando um token, você pode incluir dados dentro do token sobre o usuário e salvar várias consultas de banco de dados.

Com a forma como um token seguro é gerado e usado posteriormente, não é possível criar tokens falsos ou manipular o conteúdo de um token. Só é possível criar um token válido conhecendo uma chave secreta, que a empresa por trás da plataforma manterá bem escondida.

Uma observação muito importante a ser lembrada é que os dados dentro de um token não são criptografados. É impossível adulterar o conteúdo do token sem invalidá-lo, mas os dados dentro de um token podem ser lidos facilmente por qualquer pessoa, portanto, não é um bom lugar para armazenar dados confidenciais.

Um bom recurso se você quiser se aprofundar mais nos tokens e como eles funcionam é a Introdução aos JSON Web Tokens.

9. Não use bibliotecas externas de CDNs

Embora possa ser tentador incluir quaisquer bibliotecas que você possa precisar via cdnjs.com ou outras CDNs globais gratuitas, existem algumas quedas.

Em primeiro lugar, você não tem controle sobre as bibliotecas e qualquer código malicioso que se infiltre nos arquivos que você inclui.

Embora as CDNs sejam geralmente estáveis ​​e rápidas por definição, elas também estão sujeitas a mais ataques. Se o seu código depende de uma biblioteca JS em um CDN sob ataque, seu plugin e tema serão carregados muito lentamente ou não serão carregados.

Isso aconteceu com um site de cliente em que a CDN pública que um plug-in estava usando no momento estava expirando para usuários em algumas regiões, tornando a interface inutilizável. No final, tive que alterar o plugin para usar uma cópia local do script JS como uma solução rápida.

O uso de uma fonte externa de terceiros também pode comprometer a privacidade. Será possível que o CDN registre todos os IPs de seus usuários – certifique-se de verificar a política GDPR e informar seus clientes.

Em geral, se você usar provedores de CDN de terceiros respeitáveis, não enfrentará nenhum problema, mas a abordagem mais simples e confiável é distribuir a biblioteca JS incluída em seu produto.

Você sabia? O WordPress vem com várias bibliotecas JS incluídas. Muitas das bibliotecas JS mais comuns que você pode querer usar vêm incluídas no WordPress. Essas bibliotecas cobrirão a maioria de suas necessidades básicas.

Dica do desenvolvedor: Carregue apenas os arquivos JS e CSS extras nas páginas específicas que você precisa. Como desenvolvedor e usuário, não gosto muito de plugins que retardam o administrador ao carregar arquivos JS e CSS desnecessários em todas as páginas. Ele não apenas diminui a velocidade de outras páginas de administração, mas também pode realmente atrapalhar o layout visual e tornar algumas páginas de administração quase inutilizáveis. Por favor

Existem também algumas ferramentas que podem ajudá-lo a proteger seu código, e uma ótima ferramenta que você pode usar gratuitamente é o Coderisk.

Está contratando
Desenvolvedor PHP Sênior
Construa o núcleo dos produtos, serviços e APIs da Freemius e veja seu impacto direto nos negócios de plugins e temas do WordPress.
Especialista em migração de e-commerce
Gerencie o processo de migração de licenças e integração de produtos para empresas de plugins e temas que estão começando a vender com o Freemius.
Profissional de marketing de conteúdo
Compartilhe nosso conhecimento por meio de conteúdo escrito, visual e de áudio acionável sobre as melhores maneiras de vender plugins e temas.

10. Use ferramentas e serviços para analisar seu código

Risco de código

Existem muitos serviços automatizados para ajudar a identificar problemas de código. Exakat, SonarSource e PHPStan, para citar alguns, e um dos meus favoritos – Coderisk.com – Uma maneira fácil de encontrar alguns dos erros de segurança mais óbvios em seu código.

Esta empresa verifica todos os plugins do WordPress do repositório público do WordPress.org. Seu software é capaz de escanear e identificar centenas de diferentes tipos de problemas de segurança com base em diferentes padrões de codificação.

De acordo com suas próprias estatísticas, eles escanearam mais de 4 bilhões de linhas de código público até agora, e há muitos problemas até mesmo com os principais plugins.

Para se inscrever no serviço gratuito deles é bastante simples - você pode criar uma conta gratuita e começar a reivindicar seus plugins. Reivindicar um plug-in é tão simples quanto pegar uma única linha de código que você coloca em seu readme.txt na próxima vez que implantar uma nova versão.

Isso permite que você acesse a última varredura do seu plugin e, dentro, eles têm informações e detalhes específicos sobre cada problema, com links diretos para o seu código.

Painel de segurança do Coderisk

Lembre-se de que este é um serviço gratuito, portanto, eles podem não atualizar a verificação do seu plug-in com tanta frequência, mas quando você receber uma notificação, vale a pena verificar seu código, pois você pode ter introduzido um erro desde a última vez que revisou seu código.

A interface é bastante fácil de navegar quando você pega o jeito, e o sistema é muito útil, fornecendo instruções muito fáceis de entender sobre o que está errado, o que ajuda a rastrear o erro.

Há também muitas maneiras de filtrar bugs, e você pode marcar cada problema como corrigido ou muitas outras opções para ajudá-lo a obter rapidamente uma visão geral de todos os problemas.

Observação: se você nunca executar o Coderisk (ou qualquer outra ferramenta em sua categoria) em seu código, não se preocupe com o número de problemas suspeitos sobre os quais você será avisado. Essas ferramentas podem gerar uma boa quantidade de falsos positivos, pois apenas analisam o código sem entender a lógica do negócio. Use a saída da ferramenta como uma lista inicial sólida de itens a serem revisados.

PHP_CodeSniffer

Outra ótima ferramenta para verificar seu código é o PHP_CodeSniffer. O PHPCS consiste em dois scripts, PHPCS que verifica seu código e relata erros para você e o PHPCBF que pode corrigir automaticamente uma grande variedade de problemas que o PHPCS identifica.

Usar o PHPCS é muito fácil de usar a partir da linha de comando, uma vez que você o tenha instalado. Essa ferramenta não impedirá que problemas de segurança apareçam em seu código, mas você pode eliminar erros simples de codificação, o que torna muito mais difícil abusar de problemas maiores.

Também é possível integrar o PHPCS diretamente em seu editor, como Sublime Text e Visual Code. Dessa forma, você pode ver facilmente quaisquer erros e corrigi-los rapidamente em seu IDE.

Não importa se você trabalha em equipe ou como um único desenvolvedor, vale a pena usar um sistema automatizado, pois é uma maneira fácil de eliminar problemas básicos de segurança que você poderia perder.

Usar um sistema automatizado para escanear seu código em busca de problemas de segurança não é um método seguro para pegar todos os bugs, mas pode ajudá-lo a identificar os erros mais óbvios.

11. Não copie e cole código da web sem uma revisão adequada

Manter seu produto WP o mais seguro possível deve ser um processo contínuo, não apenas de vez em quando. Ao introduzir novos recursos ou remover código, você também pode apresentar novos problemas de segurança.

O Google nem sempre é seu amigo. Como desenvolvedor, você está acostumado a verificar a grande internet em busca de exemplos de código para inspirá-lo – ou apenas reescrever pedaços aqui e ali, se você for preguiçoso.

A maioria dos pedaços de código que você encontra na Internet raramente está pronta para uso em um ambiente de produção seguro e serve como exemplo de qualquer problema de codificação que você esteja tentando corrigir. Usar esses pedaços de código cegamente e sem revisão pode introduzir problemas muito rapidamente.

Há muito o que fazer como desenvolvedor do WordPress, e corrigir um problema de segurança urgente em seu plugin com milhares de instalações não deve ser uma delas.

Tenha em mente que sua reputação está em jogo

Se você não estiver prestando atenção à segurança do seu plugin ou tema, estará colocando seus usuários, seus negócios, seus negócios e sua reputação em jogo. Isso é muito tempo e dinheiro potencialmente desperdiçados!

As vulnerabilidades de segurança podem ter um grande impacto na confiança que os clientes depositam em sua marca ou produtos. O exemplo do Loginizer acima mostra que mesmo as vulnerabilidades de segurança mais embaraçosas podem acontecer com os próprios desenvolvedores de plugins de segurança! E os outros exemplos sobre fraude eleitoral e hacks governamentais nos dizem que qualquer um é vulnerável.

Se e quando você descobrir uma vulnerabilidade, aja rapidamente para resolvê-la e siga as práticas recomendadas para anunciar o problema publicamente (se necessário) junto com a liberação de uma correção.

Se você ficar à frente do jogo quando se trata de comunicação e dos problemas de “relações públicas” que podem surgir de uma vulnerabilidade, você pode evitar algumas dores de cabeça gigantes e aumentar sua reputação em vez de danificá-la.

Obrigado por Ler!

Pode ser assustador olhar para todas as coisas que você precisa fazer quando você não sabe o que procurar para começar, e pode ser difícil encontrar as informações certas. Se você não tem a menor ideia de por onde começar, deve considerar a revisão do seu produto por um especialista em segurança do WP (eu também faço revisões de segurança).

É tentador economizar dinheiro ou tempo para uma revisão de segurança, mas o custo de não proteger seu produto o máximo possível pode ser ainda maior a longo prazo.

Estas são apenas algumas das maneiras pelas quais você pode e deve proteger seu produto WordPress contra abusos. Se você tiver alguma dúvida, lembre-se - Não confie em ninguém