Discussion :

[Coriolan]

WordPress : le nombre de vulnérabilités a triplé en 2018
une étude pointe du doigt les plugins comme la principale source des failles du CMS

En 2016, WordPress a été le CMS le plus ciblé par les cyberattaques, selon une étude menée par la société de sécurité Sucuri. Deux ans plus tard, le CMS a vu le nombre de vulnérabilités qui lui sont liés tripler.

Dans l’étude précédente, plusieurs facteurs ont été remis en cause pour leur implication dans la mise à mal de la sécurité, notamment le déploiement, la configuration et la maintenance entreprise par les webmasters ou l’hébergeur. Mais une nouvelle étude pointe du doigt les plugins comme principale source de vulnérabilités de WordPress.

A vrai dire, un CMS maintenu constamment à jour ne constitue pas un problème. C’est quand l’installation est hautement personnalisée qu’il devient difficile de maintenir la sécurité, et en même temps, le risque d’être piraté augmente de façon proportionnelle.

Pour WordPress, le risque est encore plus élevé puisque le CMS propulse près de 30 % des sites de la toile, un pourcentage de taille qui fait qu’il existe un large nombre de victimes potentielles, un facteur important qui attire les hackers de tous poils.

En 2018, Imperva a enregistré 542 vulnérabilités associées à WordPress, trois fois plus que le nombre de 2017. Joomla et Drupal combinés ont été affectés par moins de 150 bogues. Un nombre moins élevé de bogues ne reflète pas vraiment le niveau de sécurité d’une plateforme, ça ne veut en aucun cas dire qu’elle est plus sécurisée ou non, la preuve en est les failles importantes qui ont permis aux attaquants de faire des attaques ravageantes contre les sites Drupal, on parle là de Drupalgeddon, Drupalgeddon 2 ou encore Kitty.

Le nombre de vulnérabilités par CMS

Comme à chaque fois pour Wordpress, les plugins sont remis en cause. Parmi les vulnérabilités recensées par Imperva, 2 % seulement sont liées au code de WordPress. Le reste se trouve au niveau des dizaines de milliers de plugins listés sur le site officiel du CMS.

Le top 10 des plugins vulnérables de WordPress

La nature open source de Wordpress et la volonté de différencier son site du lot, poussent les utilisateurs du CMS à recourir à des plugins en nombre. Or il n’existe pas de contrôles stricts de ces plugins, et des fois ils ne sont pas mis à jour pendant plusieurs mois, voire des années. Par conséquent, ils rendent la tâche facile aux hackers pour compromettre la sécurité des sites web.

Types d'attaques les plus en vogue contre WordPress (par année)

L’étude d’Imperva a relevé aussi une augmentation du nombre de vulnérabilités affectant les applications web. Selon les données présentées, 58 % des web apps sont concernées, et dans 38 % des cas, il n’existe pas de solution ou de correctif. Ce constat va de pair avec une autre étude de Kaspersky qui a trouvé que 73 % des brèches de sécurité dans les réseaux d'entreprises sont dues aux applications web. Parmi les attaques les plus utilisées en 2018, il y a les attaques par injection permettant l’exécution de code à distance, les injections SQL et Cross-site Scripting (XSS).

Source : report from Imperva

Et vous ?

Qu’en pensez-vous ?
Utilisez-vous WordPress pour monter vos sites web ? Comment gérez-vous la sécurité de vos sites web ?

Voir aussi

Kitty : un malware qui cible les sites web Drupal pour le minage de cryptomonnaie en exploitant une vulnérabilité du système de gestion de contenu
73 % des brèches de sécurité dans les réseaux d'entreprises sont dues aux applications web selon Kaspersky Lab

[petitours]

Wordpress 5 est en soit un énorme bug de toute manière.
Ils avaient une solution certes techniquement très moche mais ultra réussie d'un point de vue utilisateur et écosystème. Avec le système d'édition d'article le plus génial qui soit, le truc où madame Michu arrive à rédiger un article en 4 clics encore plus facilement que sous word, avec gestion des révisions des articles et tout et tout. Faire autre chose que du contenu type article, blog relevait de la bidouille mais pour éditer des articles ou pages c’était quasi parfait. Facile à faire, facile à maintenir (se faisait quasi tout seul), top.

et maintenant c'est Gutenberg... "truc" ultra spécifique en ergonomie donc totalement impossible à prendre en main par madame Michu sans une longue formation (à la notion de bloc déjà...), qui casse la plupart des extensions existantes (et casse avec les sites en production) et ne sait pas faire le 1/500 de ce que savent faire les pages builder qui existent déjà gratuitement sous WP (elementor, siteOrigin PageBuilder...)

Il ont réussi à faire émerger un fork de wordpress tellement cette version 5 est grotesque https://www.classicpress.net/

a en lire ce post ils auraient mieux fait de gérer les failles plutôt que de mettre ce Gutenberg (qui doit se retourner dans sa tombe !)

[zozizozu]

...cette version 5 est grotesque...

Je te trouve un peux rude, ce nouvel éditeur n'est pas mal du tout ...
De plus, l'article explique bien que

une nouvelle étude pointe du doigt les plugins comme principale source de vulnérabilités ...

, ce que je confirme personnellement : aucun plugins + MAJ automatique + fail2ban, et depuis 4 ou 5 ans, aucun de mes sites sous WP n'a été compromis ( contrairement à d'autre ... )

[badaze]

Je ne connais pas Wordpress (dans la mesure où je ne l’utilise pas). Il n’y a pas de système de certification des plugins ?

[zozizozu]

Il n’y a pas de système de certification des plugins ?

Si, mais, de fait, les utilisateurs font ce qu'ils veulent, installent n'importe quoi, excepté bien sur la mise à jour du système ...

[petitours]

Mise à jour du système qui se fait automatiquement pour les mises à jours mineures (typiquement celles de sécurité) et très simplement (quand ils ne massacrent pas tout avec un Gutenberg) pour les versions majeurs.
De ce fait, même si les plugins sont pleins de soucis, je ne serais pas étonné que les sites wordpress soient globalement bien plus à jour et donc bien moins vulnérables que dans d'autres CMS.

Si le CMS a 0 failles mais que les utilisateurs tournent avec la version qui date de 5 ans...

[badaze]

Qu’en est-il avec les changements de versions de php ?

Est-ce que ce n’est pas un frein au passage à des versions de Wordpress plus récentes pour qui ne sait/ne peut mettre à jour php ?

[cedric_g]

La problématique de mise à jour des sites est souvent liée au temps/coût de mise à jour vs rentabilité du site. Sur un site complexe basé sur un template premium et une foultitude de dév. spécifiques comme ça m'est déjà arrivé, franchement c'est la croix et la bannière de faire un upgrade sans y passer un certain temps, pour ne pas dire un temps certain.

L'un de mes principaux sites n'est par exemple toujours pas responsive à cause de cela (j'ai trouvé un pis aller mais il faudra qu'un jour je refasse intégralement ce dernier...)


Me concernant, j'utilise un plugin premium (HideMyWP) qui, bien paramétré, permet de supprimer littéralement tous les éléments permettant d'identifier que le site est un Wordpress via analyse du code. Couplé à iTheme Security et à une gestion convenable du reste, je n'ai JAMAIS eu depuis 2007 que j'utilise Wordpress, un soucis de hacking sur l'un de mes sites, sauf un... qui a justifié l'utilisation de HideMyWP il y a quelques années.

[petitours]

Perso j'ai 5 sites wordpress qui tournent sur des hébergements mutualisés et je n'ai jamais eu de soucis particulier.
Mais ne pas avoir de soucis ne veut pas dire que l'on en aura jamais ou que c'est parce que le site à su résister à une attaque.

J'ai un copain qui a trouvé une sauvegarde un peu longue un jour, il avait des 100n de Mo d'images d'enfants tout nus sur son hébergement... c’était du joomla de mémoire et joomla y était en plus surement pour rien.

Pour moi le site vitre on s'en moque ; après pour qui stocke des données sensibles c'est pas la même histoire/ Perso je n'utiliserai pas Wordpress pour stocker quoi que ce soit qui a de la valeur.

[zozizozu]

Qu’en est-il avec les changements de versions de php ?

Est-ce que ce n’est pas un frein au passage à des versions de Wordpress plus récentes pour qui ne sait/ne peut mettre à jour php ?

C'est clairement cela, personnellement, j'ai du compiler php7 sur mon serveur car c'était plus simple que de mettre à jour Debian pour avoir une version php récente ...