Quelles sont les failles de sécurité courantes que je dois rechercher? [fermé]

16

En tant que développeur de plugin WP en herbe, quels sont les principaux défauts / trous de sécurité que je dois rechercher?

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

Par exemple, le nettoyage des données est-il si important car il se trouve dans la zone / wp-admin /? Quelqu'un malveillant pourrait-il directement toucher ma page de plug-in et envoyer des demandes POST ou quelque chose comme ça?

Je vous remercie!

plugins plugin-development security sql MrBatman
la source

Réponses:

16

Voici une liste de contrôle modifiée, basée sur mes paramètres actuels (travail en cours) / liste de contrôle de sécurité des données utilisée pour examiner les thèmes (les principes ne devraient pas être différents pour les plugins que pour les thèmes):

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

  2. Les plug-ins 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 de copier-coller provenant de didacticiels de sites Web, tels que ceux ci-dessous, qui sont obsolètes et n'incluent pas la sécurité des données:

  3. Les plugins doivent utiliser la add_options_page()fonction pour ajouter la page des paramètres du plugin au Settingsmenu, 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 la capacité d'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 des paramètres. L'utilisation de l'API Settings (voir ci-dessous) gérerait cela.

  6. Les plugins doivent utiliser l'API Settings (voir ci-dessous) pour obtenir et enregistrer les données d'entrée de formulaire plutôt que de s'appuyer sur les données $_POSTet $_REQUESTdirectement.

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

  8. Les plugins doivent valider et désinfecter toutes les données non fiables avant d'entrer des données dans la base de données, et doivent échapper toutes les données non fiables avant d'être sorties dans les champs du formulaire Paramètres et avant d'être sorties dans les fichiers de modèle de thème:

  9. Les plugins doivent être utilisés esc_attr()pour les entrées de texte et esc_html()(ou esc_textarea()dans WP 3.1) pour les zones de texte.

  10. Les plugins doivent explicitement fournir une vérification de nonce de la page Paramètres, s'ils n'utilisent pas l'API Paramètres:

  11. Il est également fortement recommandé que les plugins utilisent l'API Paramètres, qui est plus facile à utiliser, plus sécurisé et prend en charge une grande partie du travail acharné des pages de paramètres:

Pour un bon didacticiel sur l'utilisation de l'API 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

Chip Bennett
la source
Et je dois ajouter: si quelqu'un voit quelque chose qui manque dans la liste, veuillez commenter , afin que je puisse l'ajouter à la liste de contrôle, pour aider à améliorer l'examen de la sécurité des thèmes!
Chip Bennett
Wow, grande liste, merci. Je me demande si cela vaut la peine de faire de cette question un wiki communautaire et de faire de chacun de ces points leur propre réponse pour mieux permettre la discussion et l'élaboration?
goldenapples
Je serais d'accord avec ça, mais je ne veux pas détourner la question de l'affiche originale (sauf si c'est comme ça que les choses se font sur StackExchange? Je suis encore nouveau ici ...).
Chip Bennett
Je ne sais pas non plus ... laissez-le à la discrétion des modérateurs, je suppose. Il semble que cela poserait une grande question sur le wiki, car ses pratiques si importantes et meilleures sont toujours en cours d'élaboration. @Rarst?
goldenapples
Je pourrais créer une nouvelle question, si besoin est?
Chip Bennett
11

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 qu'il avait l'intention 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 y a très probablement un moyen de le faire avec les API WP.
    • Donc, quoi que vous fassiez, votre première étape consiste à affiner et à étudier l'API appropriée.
    • Plus vous vous éloignez des fonctionnalités communes et simples, plus vous devrez étudier et mettre en œuvre des choses complexes.
Rarst
la source
1
  1. Ajoutez defined('ABSPATH') or die('Access denied');à chaque script de plugin utilisé directement par wordpress
  2. Ajouter un fichier index.php vide dans chaque répertoire
  3. Ajoutez .htaccess dans le répertoire du plugin avec les instructions nécessaires pour empêcher l'accès direct à certains fichiers du plugin.
egor
la source