web-dev-qa-db-fra.com

Sécurité dans le développement du plugin WordPress

Mon plugin est Mailer.app pour WordPress. Je suis achevé à 85% et je me concentre sur la sécurité avant la publication. Avant les questions, je devrais décrire l’architecture des plugins:

  • Le plug-in est capable de prendre username& passwordet relatif imapname __/smtpdétails du serveur.
  • Les détails sont validés et garantis que les correctifs imap/smtp sont entrés (connexion valide établie)
  • Les détails du serveur + le courrier électronique sont chiffrés à l'aide de EKEYenregistré dans le class.client.php sous le nom CONSTname__

  • passwordest crypté (ne peut pas être haché comme texte brut pour imap/smtp) et est stocké dans un cookie en utilisant un CKEYenregistré dans le class.client.php.

  • Les données sont déchiffrées à l'aide du cookie et des données de l'utilisateur.

Passons maintenant aux questions de sécurité de WordPress. Je travaille avec wp depuis environ 3 ans et je ne comprends pas comment trouver des informations à leur sujet:

  • Est-ce que d'autres plugins peuvent accéder à mon code de plugin? par exemple. require("../plugins/mail/class.client.php') et appelez new Client()? Si oui, comment puis-je l'éviter et pourquoi est-ce autorisé?
  • Est-ce qu'un autre plugin peut lire le contenu du fichier pendant que je stocke la clé de cryptage dans la classe Clientname__? Si c'est le cas, pouvez-vous recommander un emplacement pour le stocker afin que seule la classe Client() de ce plugin puisse y accéder?
  • J'utilise current_user_can() et noncesmais est-ce suffisant pour ajouter une sécurité suffisante à AJAX? les nonces peuvent-ils être expirés? et où puis-je en savoir plus sur la sécurité, les applications ajax et Web?.
  • multisitepeut-il créer des problèmes d’ajouts à partir de mon scénario ?.

Regardons un exemple de mon code:

class.client.php

final class Client {
    const SALT = "bsas8D889b8989sHBsd"; // hash salt
    const EKEY = "23123asdas9dsbbad96"; // db encryption key
    const CKEY = "b797a78skj15hjhHJDa"; // cookie encryption key
    private static function GetUserData(){
        return $this->decrypt_data()
    }
    public static function StoreUserData($data){
        return $this->validate_and_store();
    }
    public static function GetEmails(){
        return $this->show_emails($this->GetUserData());
    }
}

class.admin.php

final class Admin {
    public function __construct(){
        add_menu_page('mlr', 'mlr', 'manage_options', 'mlr', array($this,'admin_page'));      
    }
    public function admin_page(){
        $user = new Client();
        echo $user->GetEmails();
    }
}

Quel est mon but ultime? Les autres plugins, qu'ils soient infectés (porte dérobée, etc.) ou non, ne peuvent pas accéder au usernamename __/passwordname __/mailde mon courrier électronique, voilà l'essentiel de la question. Les données utilisateur chiffrées et stockées dans la base de données ne peuvent être déchiffrées qu'à l'aide de Cookie et de $key; $key étant l'élément le plus vulnérable.

Désolé pour le très long post, mais je dois obtenir ces questions de la poitrine et, espérons-le, un aperçu et de l'aide.

Merci

multisitewp-admincookiesplugins-urlencryption
5
Kivylius

Quel est mon but ultime? Les autres plugins, qu'ils soient infectés (porte dérobée, etc.) ou non, ne peuvent pas accéder au usernamename __/passwordname __/mailde mon courrier électronique, voilà l'essentiel de la question.

La seule façon d’en être sûr est de ne pas les stocker d’une manière qui puisse être déchiffrée automatiquement dans la base de données/le système de fichiers - c’est-à-dire ne pas les stocker en texte brut ou de manière à être automatiquement déchiffrables.

Je vous recommande de concaténer/hacher vos propres sels et clés de sécurité avec ceux configurés pour WordPress lui-même - vous ne devriez jamais distribuer un plug-in qui utilise des sels codés en dur, car tout utilisateur du plug-in se voit remettre les clés de ce qui a été haché pour chaque installation. En ajoutant dans les propres sels de l'installation WordPress, si vous découvrez que votre plug-in est vulnérable, vous pouvez mettre à jour les sels et invalider les magasins d'informations d'identification de toutes les installations lorsque la mise à jour du plug-in est poussée. Si une installation individuelle devient compromise, un utilisateur peut modifier ses sels WordPress et également invalider ses informations d'identification sans modifier le plug-in.

Est-ce que d'autres plugins peuvent accéder à mon code de plugin? par exemple. require("../plugins/mail/class.client.php') et appelez new Client()?

Oui.

Si oui, [...] pourquoi est-ce autorisé?

Ce n'est pas "autorisé", mais plutôt une conséquence d'environnements de script interprétés. "Étendre WordPress" avec des thèmes et des plugins est juste cela - il modifie l'exécution de WordPress en utilisant une source brute pour atteindre le résultat souhaité. Je ne connais aucun langage interprété offrant des mécanismes fiables pour "verrouiller" des parties du script source à partir d'autres parties de la même base de code. Systèmes d'exploitation, bien sûr.

Cette responsabilité incombe plutôt à l'environnement d'exécution et à quiconque le contrôle.

Comment puis-je l'empêcher?

Il est peut-être possible d’utiliser une boîte à sable sérieusement complexe et d’exécuter différentes parties de WordPress dans différents threads - mais ce n’est pas du tout la conception de WordPress qui nécessiterait une reconfiguration lourde de l’environnement. Même dans ce cas, il serait toujours susceptible de subir diverses attaques. Malgré le JavaScript en mode bac à sable de Google Chrome, il resterait un code malveillant capable d’annuler les mesures.

Comme pour toute la sécurité de l'information, il faut supposer que si l'environnement est compromis, il en va de même pour tout ce qu'il contient, quelles que soient les mesures de sécurité en place. Même les virus binaires dans les environnements en mode bac à sable et ceux exécutés dans les systèmes d'exploitation virtuels peuvent sortir de leurs limites pour nuire au système hôte, s'ils sont conçus pour de tels scénarios.

Si les utilisateurs de votre plug-in ne parviennent pas à sécuriser correctement leurs installations WordPress ou à installer du code compromis, aucune partie du système de fichiers ou de la base de données ne peut être considérée comme "sûre" pour la sécurité des informations critiques. Comme si un virus se retrouvait sur votre ordinateur, aucun programme ou document ne peut être considéré comme fiable ni non exposé. Si vous stockez les mots de passe dans un fichier texte, vous devez supposer que tous les comptes pertinents sont compromis ou vulnérables. Ici comme partout dans le monde de la sécurité informatique, les utilisateurs ne doivent pas installer d’exécutables qu’ils ne comprennent pas ou ne comprennent pas - ceux qui n’ont pas une bonne base pour faire la différence entre des programmes fiables et bien implémentés devraient avoir une capacité limitée à acquérir et/ou installez de tels articles.

En bref, si vous ne contrôlez pas vous-même directement les installations WordPress sur lesquelles votre plugin est installé, vous ne pouvez pas empêcher votre plugin de se compromettre au-delà du respect des bonnes pratiques de sécurité dans votre implémentation.

Un autre plugin peut-il lire le contenu du fichier pendant que je stocke la clé de chiffrement dans la classe Client?

Oui. En fait, n'importe quel plugin pourrait analyser le fichier wp-config.php de l'installation WordPress et obtenir les informations de la base de données et les sels si son auteur le souhaite. Le problème, c’est qu’un plugin n’a même pas besoin de faire cela pour compromettre une installation car l’environnement PHP et WordPress donnent déjà aux plugins ce qui revient à laisser libre cours à la base de données et au système de fichiers pour atteindre leurs objectifs, dans la mesure où la base de données et Le système de fichiers lui-même le permet. Sans ces capacités, les plugins auraient une portée extrêmement limitée.

Si c'est le cas, pouvez-vous recommander un emplacement pour le stocker afin que seule la classe Client () de ce plugin puisse y accéder?

Les identifiants stockés et/ou transmis en clair ne sont jamais complètement "sûrs", point à la ligne.

Si votre application nécessite un tel stockage/transmission, les informations d'identification ne peuvent être aussi sûres que l'environnement dans lequel elles sont stockées. Vous pouvez ajouter des objets supplémentaires pour masquer les informations d'identification, mais il n'en reste pas moins que si votre code contient tout ce dont il a besoin pour déchiffrer les informations d'identification, il en va de même pour tout autre code de l'environnement. Cela revient essentiellement à stocker un fichier crypté contenant des mots de passe sur votre ordinateur, à côté d’un script Shell qui décrypte le fichier dès qu’il est exécuté. La meilleure façon de les protéger est de sécuriser l'environnement.

J'utilise current_user_can() et nonces mais est-ce suffisant pour ajouter une sécurité suffisante à AJAX?

Cela dépend des spécificités de votre application et de ce qui est transmis via AJAX. Généralement, ces mécanismeslorsqu'ils sont correctement implémentéssuffisent pour validate que les demandes AJAX proviennent d'une source cohérente. Cependant, ils ne sont en eux-mêmes qu'un élément de la sécurité AJAX. En règle générale:

  • Ne prenez aucune mesure tant que la demande n'est pas "suffisamment" vérifiée, y compris en utilisant current-user_can() , check_ajax_referer()
  • Échapper, valider et désinfecter toutes les choses qui comprennent des données dynamiques. Ces pratiques sont essentielles pour empêcher les injections SQL, l’exécution arbitraire PHP et la transmission de code JavaScript malveillant aux visiteurs. Cela inclut $_GET, $_POST et $_COOKIE ainsi que tout élément récupéré dans la base de données qui sera évalué comme PHP ou envoyé au navigateur. Découvrez quelles fonctions WordPress gèrent les tâches pour vous - mais en cas de doute, exécutez-les vous tu peux être sûr.
  • Si vous contrôlez l’environnement du serveur, sécurisez votre site avec un certificat SSL et utilisez le protocole HTTPS afin de limiter les risques d’attaques de type "man-in-the-middle" ( le projet Let's Encrypt est bien en passe de certificats de confiance gratuitement).
  • Assurez-vous que votre gestion des erreurs est implémentée de manière à ce que si votre script de serveur induise l'accès direct ou directement par un client, aucune donnée sensible n'est renvoyée au navigateur.

Les nonces peuvent-ils être expirés?

Oui - WordPress fournit le nonce_lifetime filter à cette fin. Par défaut, un nonce WordPress est valide pendant 12 à 24 heures.

Le multisite peut-il créer des problèmes d'ajouts à partir de mon scénario?

Cela dépend de la manière dont votre plugin est installé et de votre intention d'être utilisé dans un environnement multisite - les "problèmes" potentiels qui pourraient survenir pourraient en réalité être des résultats souhaitables en fonction de ce que vous recherchez.

Vous souhaiterez peut-être stocker les informations d'identification du courrier en tant que données propres à l'utilisateur ou au site, en fonction de ceux qui devraient avoir accès à quel courrier. Vous voudrez peut-être même implémenter des rôles personnalisés rôles et fonctionnalités pour fournir un accès plus détaillé aux boîtes aux lettres.

1
bosco