web-dev-qa-db-fra.com

Quelles sont les failles de sécurité communes que je dois rechercher?

En tant que wannabe WP développeur de plug-in, quels sont les principaux défauts/failles de sécurité que je devrais rechercher?

Je suis sur le point de créer un nouveau plugin avec un panneau de configuration (c.-à-d. Champs de saisie et autres). De quoi devrais-je m'inquiéter?

Par exemple, la désinfection des données représente-t-elle un gros problème puisqu'elle se trouve dans/wp-admin/area? Un utilisateur malveillant peut-il directement accéder à ma page de plug-in et envoyer POST demandes ou quelque chose du genre?

Je vous remercie!

pluginsplugin-developmentsecuritysql
15
MrBatman

Voici une liste de contrôle modifiée, basée sur ma liste de contrôle de sécurité des paramètres/données en cours utilisée pour la révision des thèmes (les principes ne doivent pas être différents pour les plugins par rapport à ceux utilisés pour les thèmes):

  1. Les plugins doivent préfixer plugin-slug dans toutes les options, fonctions personnalisées, variables personnalisées et constantes personnalisées.

  2. Les plugins doivent implémenter délibérément les pages Options de plug-in et Paramètres de plug-in, plutôt que de s'appuyer sur des scripts copier-coller de didacticiels de sites Web, tels que ceux ci-dessous, qui sont obsolètes et n'incluent pas une sécurité des données appropriée:

  3. Les plug-in doivent utiliser la fonction add_options_page() pour ajouter la page des paramètres du plug-in au menu Settings, plutôt que d'utiliser add_menu_page() pour ajouter un menu de niveau supérieur.

  4. Les plugins doivent utiliser une capacité appropriée (par exemple, manage_options) pour pouvoir ajouter la page des paramètres.

  5. Les plugins doivent enregistrer les options dans un seul tableau, plutôt que de créer plusieurs options pour la page de paramètres. L'utilisation de l'API de configuration (voir ci-dessous) permettrait de gérer cela.

  6. Les plugins doivent utiliser l'API Settings (voir ci-dessous) pour obtenir et enregistrer des données de saisie de formulaire plutôt que de s'appuyer directement sur les données $_POST et $_REQUEST.

  7. Pour les cases à cocher et les options de sélection, les plug-ins doivent utiliser les fonctions checked() et selected() pour générer checked="checked" et selected="selected", respectivement.

  8. Les plugins doivent valider et assainir toutes les données non fiables avant de les entrer dans la base de données. Ils doivent également échapper à toutes les données non fiables avant d'être affichés dans les champs du formulaire Paramètres et avant d'être affichés dans les fichiers de modèle de thème:

  9. Les plugins doivent utiliser esc_attr() pour les entrées de texte et esc_html() (ou esc_textarea() dans WP 3.1) pour textareas.

  10. Les plugins doivent explicitement fournir la vérification de la nonce de la page de configuration, si vous n'utilisez pas l'API de configuration:

  11. Il est également fortement recommandé aux plug-ins d'utiliser l'API Settings, qui est plus facile à utiliser, plus sécurisée et prend en charge une grande partie du travail acharné des pages de paramètres:

Pour un bon tutoriel sur l’utilisation de l’API de paramètres, voir:

Si vous souhaitez consulter un thème avec une page de paramètres de thème sécurisée et solidement codée, consultez ce thème:
http://wordpress.org/extend/themes/coraline

16
Chip Bennett

Il y a deux aspects à cela:

  1. Principes de base.

    • Tout ce qui est écrit dans la base de données doit être vérifié pour les injections SQL.
    • Tout ce qui est imprimé à l'écran doit être vérifié pour ne pas imprimer de code JavaScript nuisible.
    • Chaque fois que quelqu'un fait quelque chose, il convient de vérifier que son intention était de le faire et qu'il dispose des capacités appropriées.
    • Il y a beaucoup d'autres choses que vous ou moi ne penserons jamais à vérifier.

  2. Détails.

    • WordPress moderne prend la sécurité au sérieux et vise à faciliter la tâche des développeurs.
    • Donc, pour la plupart des choses que vous voulez faire, il existe probablement un moyen de le faire avec les API WP.
    • Donc, quoi que vous fassiez, votre première étape serait de bien et étudier l'API appropriée.
    • Plus vous vous écartez des fonctionnalités simples et communes, plus vous aurez à étudier et à mettre en œuvre des tâches complexes.
11
Rarst
  1. Ajoutez defined('ABSPATH') or die('Access denied'); au script de chaque plugin utilisé directement par wordpress
  2. Ajouter un fichier index.php vide à chaque répertoire
  3. Ajoutez .htaccess dans le répertoire du plugin avec les instructions nécessaires pour empêcher un accès direct à certains fichiers du plugin.
1
egor