Quais são as falhas comuns de segurança que eu preciso procurar? [fechadas]

Aqui está uma lista de verificação modificada, com base na minha lista de verificação de segurança de dados / configurações atual (em andamento) usada para revisar Temas (os princípios não devem ser diferentes para Plugins do que para Temas):

1. Os plug-ins devem prefixar todas as opções, funções personalizadas, variáveis personalizadas e constantes personalizadas com o plugin-slug.

2. Os plug-ins devem implementar deliberadamente as páginas Opções de plug-in e Configurações de plug-in, em vez de usar scripts de copiar e colar de tutoriais de sites, como os abaixo, que estão desatualizados e não incluem segurança de dados adequada:

   • enlace
   • enlace

3. Os plug-ins devem usar a função add_options_page() para adicionar a Página de configurações de plug-ins ao menu Settings , em vez de usar add_menu_page() para adicionar um menu de nível superior.

4. Os plug-ins devem usar um recurso apropriado (por exemplo, manage_options ) para a capacidade de adicionar a página de configurações.

5. Os plug-ins devem salvar opções em uma única matriz, em vez de criar várias opções para a página de configurações. O uso da API de configurações (veja abaixo) lidaria com isso.

6. Os plug-ins devem usar a API de configurações (veja abaixo) para obter e salvar dados de entrada do formulário, em vez de confiar nos dados $_POST e $_REQUEST diretamente.

7. Para caixas de seleção e opções de seleção, os plug-ins devem usar as funções checked() e selected() para a saída de checked="checked" e selected="selected" , respectivamente.

8. Os plug-ins devem validar e limpar todos os dados não confiáveis antes de inserir dados no banco de dados e devem escapar de todos os dados não confiáveis antes de serem enviados nos campos de formulário Configurações e antes de serem enviados nos arquivos de modelo Tema:

   • enlace

9. Os plug-ins devem usar esc_attr() para entradas de texto e esc_html() (ou esc_textarea() no WP 3.1) para textareas.

10. Os plug-ins devem fornecer explicitamente a verificação do nonce das configurações da página, se não usar a API de configurações:

    • enlace

11. Também é altamente recomendável que os plug-ins usem a API de configurações, que é mais fácil de usar, mais segura e cuida do trabalho pesado das páginas de configurações:

    • enlace

Para um bom tutorial sobre o uso da API de configurações, consulte:

• enlace

• enlace

Se você quiser conferir um tema com uma página de configurações de tema segura e codificada, confira este tema: enlace

Existem dois aspectos para isso:

1. Princípios básicos.

   • O que estiver escrito no banco de dados deve ser verificado para injeções de SQL.
   • O que for impresso na tela deve ser verificado se ele não imprime JavaScript prejudicial.
   • Sempre que alguém faz alguma coisa, deve verificar se era sua intenção fazê-lo e se tem capacidade adequada.
   • Há muitas outras coisas que você ou eu nunca pensaremos em verificar.

2. Específicos.

   • O WordPress moderno leva a segurança a sério e tem como objetivo facilitar o trabalho dos desenvolvedores.
   • Portanto, para a maioria das coisas que você deseja fazer, é mais provável que seja feito com APIs do WP.
   • Então, o que você está fazendo, o primeiro passo seria aperfeiçoar e estudar a API apropriada.
   • Quanto mais longe você estiver da funcionalidade comum e simples, as coisas mais complexas que você precisará estudar e implementar.

1. Adicione defined('ABSPATH') or die('Access denied'); em todos os scripts de plug-in usados pelo wordpress diretamente
2. Adicione o arquivo index.php vazio em todos os diretórios
3. Adicione o .htaccess no diretório do plug-in com as instruções necessárias para impedir o acesso direto a determinados arquivos do plug-in.