Les modules concernés incluent RESTWS qui est utilisé pour créer des APIs Rest et serait installé sur un peu moins de 6000 sites. Le code d’intrusion par exécution à distance a été détecté par Devin Zuczek (@djdevin) et a été classifié très critique.

Le module Coder utilisé par au moins 4951 sites pour des analyses de codes est aussi touché par cette brèche d’intrusion par exécution à distance qui a été découverte par un chercheur de la NCC, Nick Bloor (@nickstadb) et est lui aussi classé très critique, car il n’a même pas besoin que le module soit actif pour être exploité.

Le module Webform Multiple File Upload (permet le téléchargement de fichiers multiples) qui est utilisé pour collecter des fichiers utilisateurs par un peu plus de 3000 sites est lui aussi concerné. La brèche critique a été découverte par l’Australien Ben Dougherty(@_benjy1) qui travaille au sein de Drupal sur les questions de sécurité.

Pour exploiter cette dernière brèche, un attaquant doit être en mesure de soumettre un formulaire web qui aura auparavant été modifié et selon la configuration du site peut induire une préauthentification. Ces facteurs fluctuants ont pour effet de limiter l’impact sécuritaire de celui-ci et cela explique pourquoi son classement est critique et non très critique.

Vous vous sentez peut-être en sécurité et loin d’avoir des soucis de vulnérabilité sur vos propres systèmes et portails, mais il y a ce moment même, des milliers d’ordinateurs (la plupart basés en Asie et en Europe de l’Est) qui récoltent des ``pétaoctets`` de données pour être épluché pour un usage futur, des attaques indirectes ou même pour améliorer les outils et capacités à pénétrer les systèmes. La fuite de documents de la firme d’avocats Mossack Fonseca, la fameuse Panama Papers qui a dévoilé au grand jour les pratiques douteuses de riches et influents clients pour éviter de payer leurs taxes aurait été initialement le résultat de vulnérabilités non adressées sur des systèmes de gestion de contenu populaires: Drupal et WordPress.

Drupal affiche de plus de 30,000 développeurs qui ont contribué à plus de 33,000 modules.
Quel nombre impressionnant n’est ce pas ?

L’utilisation de modules ou plugins de tierce partie ne peut pas être considérée comme une question mineure lorsque vous évaluer la meilleure solution pour mettre en place votre application web ou votre progiciel. Après un certain temps passé à choisir vos modules (parmi 33,000! ), si la première étape de l’installation de module se résume en général "Est-ce que tout fonctionne adéquatement" la deuxième étape avant production est "Est-ce qu’ils marchent tous ensemble". Vous pouvez penser une fois que tout marche, et qu’après quelques compromis tout ira pour le mieux. Ça, c’est loin d’être gagné! L’utilisation de modules externes est une décision très importante avec des conséquences qui seront de plus en plus ressenties avec le temps.

Inévitablement le noyau de votre progiciel va évoluer et il y aura des mises à jour. Les comportements utilisateurs vont évoluer et changer de même les interactions et les systèmes de consultation. Vous (ou votre business) allez alors être dépendant d’un développeur (95% des modules sont créés et maintenus par une seule personne) pour mettre à jour et adapter le module pour qu’il fonctionne malgré les changements. Vous allez être dépendant du temps qu’il aura a y consacrer pour un module écrit il y a quelques années, s’il désire toujours s’en occuper.

Quelques liens a ce sujet:
http://pluginproblems.com/
https://www.nosegraze.com/hate-relying-third-party-plugins/
https://blog.sucuri.net/2016/03/when-wordpress-plugin-goes-bad.html
https://www.itsupportguides.com/wordpress/beware-wordpress-developers-that-rely-on-third-party-plugins/

J’aime les interactions, mais je me sens plus à l'aise sans utiliser des plugins de tierce partie ou des modules externes si ce n’est pas nécessaire. C’est aussi une des raisons (avec un vrai système multi-langage incluant les langages droite a gauche) qui m’ont amené à utiliser et travailler sur Tiki Wiki. Me basant sur ce solide et libre logiciel de gestion de contenu et Web-App builder j’ai dirigé des centaines de projets, contribué moi-même au code et suis maintenant un spécialiste Tiki Wiki, de la gestion des mises en production et même administrateur de ce projet.

Ce n’est pas dans mes habitudes de dire "faites comme je le dis". Aussi j’espère juste avoir mis en lumière un aspect souvent mal géré et surtout vous avoir donné matière à mieux comprendre les risques à utiliser des plugins de tierce partie. Étudier cet aspect, considérez d’autres opinions et faites-vous votre propre idée. Choisissez votre progiciel selon vos meilleurs intérêts et en toute connaissance de cause.