Est WP vulnérable lors de la mise en place de plugins ou de thèmes?
Une fois, j’ai eu un problème qui voulait dire que quelqu'un avait réussi à modifier les fichiers de mon site Web sans informations d'identification FTP ou SSH. Probablement il est entré par WP (probablement ce n'était pas un "il", mais un "ça", un bot), nous avons dit après enquête.
Quoi qu'il en soit, depuis lors, j'utilise le plugin WordPress File Monitor , qui m'envoie par courrier électronique lorsque les fichiers sont modifiés. Désormais, lorsque je mets à jour des plugins ou des thèmes, j’effectue une analyse avec le moniteur de fichiers, puis une mise à jour et une nouvelle analyse. Le moniteur envoie une alerte en raison de la mise à jour et je la supprime, car "c'est à cause de la mise à jour".
Maintenant, je me demande si si WP est particulièrement vulnérable lors de la mise à jour (par exemple, s'il est possible que la mise à jour ne provienne pas du WP serveurs mais par un pirate informatique), alors avec cela j'ouvre une fuite dans la sécurité de mon site.
Par contre, si les plugins/thèmes mis à jour fonctionnent (que je vérifie toujours), et que seuls les fichiers des plugins sont modifiés (que je vérifie aussi toujours), alors, à mon avis, pas si probable que quelqu'un a piraté mon site lors de la mise à jour.
Est-ce que je fais la bonne chose ici ou dois-je mieux vérifier après la mise à jour?
Ce que vous faites en ce moment est acceptable, mais il existe des moyens bien meilleurs pour le faire.
Le problème des attaques de type homme du milieu réside dans le fait que s’insérer entre Wordpress.org et un serveur dans un centre de données n’est pas une tâche facile. Ce scénario est donc très improbable.
Cependant
Si vous abandonnez le programme de mise à jour intégré et utilisez plutôt les référentiels git pour extraire vos données, vous pouvez alors garantir à 100% la sécurité de vos plugins et de vos thèmes, , même en cas d'attaque au milieu .
Ceci est dû aux promesses de fiabilité faites par git. Un référentiel git a un hachage SHA-1 qui représente son historique VCS, et toute tentative de "manipuler" ou de manipuler un référentiel git pour ajouter du code invalidera ce hachage, provoquant un blocage de git. Pour cette raison, tant que ce hachage est bon, vous pouvez extraire les modifications de code de n'importe où, aussi douteux soit-elles, grâce à la garantie cryptographique.
Voici Linus Torvalds qui parle de la confiance et de la fiabilité dans Git bien mieux que ce que je pourrais expliquer:
http://youtu.be/4XpnKHJAok8?t=56m10s
Une fois que vous avez migré vers une configuration contrôlée par la version, vous pouvez configurer votre dossier wp-content, etc. pour qu'il ne lise que pour les serveurs Apache/WWW/Nginx. Si un référentiel non-Git est corrompu ou compromis, il vous suffit de revérifier le référentiel en place et d'annuler les dommages.
Des outils de provisioning/déploiement tels que Composer seraient également utiles ici.
Notez que si Git empêcherait une attaque entre hommes en mettant en évidence les incohérences dans les données et en fournissant des preuves de falsification, il ne fera que garantir que vous disposez de la copie correcte de la source. Cela n'empêche pas le développeur d'origine de faire une dépression nerveuse et de placer une commande DROP ALL TABLES dans son plug-in. Pour cela, nous avons des tests dans des bacs à sable, des relectures/critiques de code et des forums d'assistance.
Votre mise à jour est aussi sécurisée qu'un point faible de votre chaîne de mises à jour. Étant donné que les mises à niveau sont effectuées via HTTPS depuis 3.7, une attaque MITM contre wordpress.org sera si difficile que vous ne devriez même pas vous soucier de la protéger, car toute personne disposant des ressources nécessaires vous en tirera d'une manière ou d'une autre.
Les points les plus problématiques sont les comptes de wordpress.org et votre compte sur votre serveur. Vous pouvez protéger votre serveur, mais vous ne pouvez pas vous protéger contre le piratage des comptes wordpress.org et l'insertion de code malveillant dans les plug-ins et les thèmes que vous utilisez.
Le seul moyen d’être totalement sûr de la mise à jour du site consiste à télécharger manuellement les fichiers sur le serveur après les avoir vérifiés.
Remarque secondaire: si les fichiers sur votre serveur ont été modifiés sans accès FTP ou SSH, votre serveur n'est pas suffisamment sécurisé et vous n'isolez probablement pas votre Apache en tant qu'utilisateur différent et ne définissez pas les autorisations appropriées sur vos répertoires.