Discussion :

[Stéphane le calme]

WordPress voudrait forcer la MàJ automatique des sites tournant sur des versions antérieures du CMS,
afin de renforcer la sécurité d'Internet dans son ensemble

Les développeurs derrière le système de gestion de contenu open source WordPress travaillent sur un plan visant à forcer la mise à jour automatique des versions antérieures du CMS vers des versions plus récentes. L'objectif de ce plan est d'améliorer la sécurité de l'écosystème WordPress et de l'ensemble de l'internet, les installations WordPress représentant plus de 34% des sites Web.

Les versions officiellement prises en charge n'incluent que les six dernières versions majeures de WordPress, qui sont actuellement toutes les versions comprises entre v4.7 et v5.2. Le plan consiste à mettre à jour automatiquement les anciens sites WordPress, à partir de la version 3.7, vers la version actuellement prise en charge minimale, à savoir la version v4.7.

Le processus de mise à jour automatique des versions non sécurisées ressemblerait à ceci:

1. Une publication d'un article sur wordpress.org/news pour informer le plus tôt possible des mises à jour à venir. Une date spécifique pour les mises à jour ne sera pas connue à ce stade, mais ce sera au moins 6 semaines dans le futur.
2. les version 3.7.30 à 4.6.15, qui:
   
   1. Autorisent les administrateurs à désactiver les mises à jour automatiques majeures en cliquant sur un simple bouton.
   2. Envoient un e-mail à tous les administrateurs / éditeurs de site pour leur demander de passer à la version la plus récente et les informer que leur site sera automatiquement mis à jour à la version 3.8 dans un avenir proche s'ils ne se désabonnent pas. Il renverra à une documentation plus détaillée, et inclura un lien sur lequel ils peuvent cliquer pour se désinscrire. Ils seront avertis des conséquences de la désinscription sur la sécurité. Les éditeurs ne pourront pas installer directement la mise à jour, mais ils pourront contacter les administrateurs qui le peuvent.
   3. Ajoutent une notification d’administrateur dans wp-admin, contenant des informations similaires à celles de l’e-mail. L'avis sera visible par tous les utilisateurs du site.
3. Tester les mises à jour automatiques de 3.7 à 3.8 sur les sites de test et apporter les améliorations nécessaires au système de mise à jour automatique.
   
   1. Une modification nécessaire consisterait à envoyer un e-mail au propriétaire du site si la mise à jour automatique échoue et si elle est restaurée à la version 3.7. L'e-mail doit être un avertissement fort, leur indiquant que leur site ne peut pas être mis à niveau vers une version sécurisée et qu'ils doivent procéder à une mise à jour manuelle et immédiate immédiatement. S'ils ne mettent pas à jour, il est presque garanti que leur site sera piraté à terme.
   2. De même, si la mise à jour automatique échoue et que l'utilisateur est bloqué sur une version non sécurisée, un avis d'administrateur doit être affiché dans wp-admin avec un avertissement similaire au courrier électronique ci-dessus. Ceci remplacerait la bannière de pré-version de 3.7.30 décrite ci-dessus.
4. Mettre à jour le manuel de base avec des détails sur le nouveau processus, afin que tout le monde sache déployer les mises à jour automatiques majeures.
5. Publiez un document sur WordPress.org énonçant explicitement une politique de support afin d'éviter toute confusion.
   
   1. Seule la dernière version majeure est officiellement prise en charge et garantie de recevoir les mises à jour de sécurité.
   2. Il n'y a pas de version LTS, et toutes les versions antérieures à la version actuelle sont EOL.
   3. Nous nous efforçons d’apporter des correctifs de sécurité aux 5 dernières versions majeures, mais aucune garantie n’est donnée, car cela n’est parfois pas réalisable.
   4. Il est fortement recommandé à tous de toujours utiliser la dernière version majeure.
6. T-30 jours : Version 3.7.31, qui:
   
   1. Envoie à tous les administrateurs du site et aux éditeurs un deuxième courrier électronique, semblable au premier, leur indiquant que leur site sera automatiquement mis à jour à la version 3.8 dans 30 à 45 jours, avec les instructions de retrait, etc.
   2. Mettre à jour la notification 3.7.30 wp-admin pour inclure la plage de dates de la mise à jour imminente.
   3. Inclure toutes les améliorations nécessaires au système de mise à jour automatique, comme décrit à l'étape 3.
7. Déploiement des mises à jour automatiques par phases:
   
   1. Le processus général consisterait à déployer sur un sous-ensemble de sites 3.7, puis d'attendre une semaine pour voir si des problèmes sont signalés. Si quelque chose d'inattendu se produit, le processus peut être interrompu afin de résoudre ces problèmes, puis redémarré.
   2. T-0 jours: déploiement sur 2% des 3,7 sites.
   3. T + 7 jours: Déploiement à 18% supplémentaires.
   4. T + 14 jours: déploiement sur les 80% restants.
8. Si tout se passe bien, le processus peut être répété pour mettre à jour les sites 3.8 vers 3.9, et ainsi de suite jusqu'à ce que tous les sites exécutent 4.7. Certaines des étapes peuvent être automatisées pour faciliter le processus à l'avenir.

Nous pouvons résumer les étapes de mises à jour automatique comme suit:

• 2% de tous les sites WP 3.7 seront mis à jour automatiquement vers WP 3.8
• Après une semaine, 18% supplémentaires seront mis à jour automatiquement vers WP 3.8
• Après deux semaines, 80% des sites WP 3.7 seront mis à jour automatiquement vers WP 3.8.
• Les mêmes étapes que ci-dessus sont répétées cette fois-ci en migrant les sites de WP 3.8 à 3.9; WP3.9 à WP 4.0; etc.

L’équipe WordPress a déclaré qu’elle envisageait de surveiller ce processus de mise à jour automatique forcée à plusieurs niveaux pour détecter les erreurs et les ruptures de site. Si quelque chose ne va pas, la mise à jour automatique peut être complètement arrêtée.

Si seuls quelques sites individuels tombent en panne, ceux-ci seront rétablis dans leurs versions précédentes et le propriétaire en sera averti par courrier électronique.

« L'e-mail doit être un avertissement fort, leur indiquant que leur site ne peut pas être mis à niveau vers une version sécurisée et qu'ils doivent le mettre à jour manuellement immédiatement. S'ils ne le font pas, il est presque garanti que leur site sera piraté finalement », a déclaré Ian Dunn, un membre de l’équipe de développement WordPress.

Un premier plan de mise à jour automatique aurait fait des ravages sur Internet

Cela semble être une solution judicieuse, mais une proposition antérieure demandait à l'équipe WordPress de mettre à jour de force tous les anciens sites WordPress vers la version 4.7 à la fois.

Cette idée a été rapidement mise au rebut après une avalanche de réactions négatives de la part des propriétaires de sites WordPress qui ont averti que des millions de sites seraient tombés en panne avec des erreurs WSOD (écran blanc de la mort) causées par des incompatibilités entre les thèmes, les plugins et la nouvelle version de base de WordPress.

La mise à jour automatique forcée à plusieurs niveaux est le résultat du retour d'information et prend en compte les risques de casse de site.

En outre, l'équipe WordPress prévoit d'autoriser les propriétaires de sites à se désinscrire de ce processus de mise à jour forcée. L’équipe WordPress envisage d’envoyer des courriers électroniques aux administrateurs de sites Web et d’afficher un avertissement sévère dans les tableaux de bord des sites Web avant de lancer le processus de mise à jour automatique. Ces avertissements comprendront également des instructions de désinscription et seront affichés / envoyés au moins six semaines avant la mise à jour automatique d'un site.

« Ils seront avertis des conséquences du désengagement sur la sécurité », a déclaré Dunn dans un billet de blog. Pour le moment, les détails du processus de mise à jour automatique n'ont pas encore été finalisés.

Plus de 3% d'Internet utilise des sites WordPress obsolètes

Les versions antérieures à la version 3.7 ne seront pas mises à jour automatiquement car la version 3.7 est la version dans laquelle le mécanisme de mise à jour automatique a été inclus dans le CMS. Ces anciennes versions ne prennent en charge que les mises à jour manuelles et ne peuvent pas être mises à jour automatiquement. Les versions antérieures à la version 3.7 représentent moins de 1% de toutes les installations WordPress, donc ce ne sera pas un gros problème.

Les sites WordPress exécutant des versions de v3.7 à v4.7 représentent 11,7% de tous les sites WordPress, ce qui correspond à peu près à la dizaine de millions de sites. Cela représente environ 3% de tous les sites Internet, utilisant actuellement des versions extrêmement anciennes de WordPress. WordPress 3.7 est sorti le 23 octobre 2013, tandis que l'actuelle version "sûre" minimale, v4.7, a été publiée en décembre 2016.

L’équipe de sécurité WordPress a fait allusion à ce plan l’année dernière. Lors de la conférence sur la sécurité organisée par DerbyCon 2018, le responsable de l'équipe de sécurité de WordPress, Aaron Campbell, a déclaré que son équipe travaillait à « effacer l'existence des anciennes versions d'Internet ». C'est ce que cela signifiait.

La volonté de l'équipe de développement de WordPress de mettre à jour de force toutes les anciennes versions de CMS vers la nouvelle version s'explique par le manque de ressources humaines. Au cours des six dernières années, les développeurs WordPress ont porté chacun de ces correctifs de sécurité pour toutes les versions remontant à WordPress 3.7.

Bien que cela ait été faisable au début, à mesure que le CMS WordPress avançait, cela prenait de plus en plus de temps, car les développeurs WordPress devaient convertir le code PHP plus récent en un code compatible avec l'ancien code WordPress.

« C'était vraiment embêtant pour nous en tant qu'équipe de sécurité », a déclaré Campbell à propos de ce processus, l'an dernier à DerbyCon. « Mais c'est absolument la meilleure chose pour nos utilisateurs. Et parce que c'est là que nous établissons la mesure du succès, c'est ce que nous faisons. »

En faisant migrer tous les utilisateurs vers WordPress 4.7 (puis 4.8, 4.9, etc.), les développeurs leur facilitent également la vie, mais renforcent également la sécurité d'Internet dans son ensemble.

Actuellement, WordPress est le système de gestion de contenu le plus ciblé par des cybercriminels, principalement en raison de son adoption massive et de sa grande surface d'attaque. Réduire la surface d’attaque est le moyen le plus simple de lutter contre les réseaux de zombies de logiciels malveillants qui s’emparent des sites WordPress et les utilisent pour héberger des logiciels malveillants, faire du spam par SEO ou lancer des attaques par DDoS.

Source : WordPress

Et vous ?

Utilisez-vous WordPress ?
Si non, pourquoi ? Si oui, sur quel type de site ?
Sur quelle version êtes-vous ?
Si vous êtes sur une ancienne version pourquoi n'avez-vous pas fait la mise à jour ?
Que pensez-vous de cette décision de forcer les mises à jour des anciennes versions tout en permettant aux propriétaires de sites de se soustraire au processus ?
Votre site a-t-il déjà été victime d'une des nombreuses attaques qui ont ciblé le CMS ?

Voir aussi :

Un quart des principaux CMS, dont WordPress, utilisent la fonction obsolète MD5 comme schéma de hachage de mot de passe par défaut
WordPress 5.2 « Jaco » débarque avec la possibilité de voir l'état de santé de votre site, et la protection contre les erreurs fatales PHP
Un tiers des 10 millions de sites Web les plus populaires du Web utilisent désormais WordPress, d'après les statistiques publiées par la W3Techs
Parmi les sites CMS piratés en 2018, 90 % sont des sites WordPress et 97 % des sites PrestaShop piratés sont obsolètes, selon un rapport
Un ex-employé pirate le plugin WordPress WPML pour spammer les utilisateurs, se servant d'une backdoor qu'il avait laissée sur le site pour son usage

[Anselme45]

WordPress voudrait forcer la MàJ automatique des sites tournant sur des versions antérieures du CMS

Que voilà une excellente... mauvaise idée!

Sur le papier, l'idée est géniale... Dans la réalité, bonjour les sites bloqués et inutilisables suite à une MàJ raté!

Quand on constate avec les OS de Microsoft qu'un update sur deux plante malgré les ressources dont dispose Microsoft pour s'assurer que tout fonctionne correctement, je vois mal comment une MàJ automatique de WordPress pourra s'effectuer dans tous les cas sans problème...

[transgohan]

Si tous les plugins étaient fournis et maintenus par Wordpress cela ne poserai aucun souci de forcer des mises à jour automatique.
Mais ce n'est pas le cas et donc je prédis une hécatombe.

[Fagus]

Pareil, je souhaite bien du courage à tous ceux qui retrouveront leur site cassé !

Les CMS, c'est bien à plusieurs. Mais quand il n'y a qu'un webmestre, on a vu mieux niveau surface d'attaque. J'utilise pour ma part un CMS (SPIP) converti en html statique : surface d'attaque minimale = pas de soucis de mise à jour cassant les plugins.
Si c'était à refaire, aujourd'hui j'utiliserai Jekyll.

[Sodium]

Wordpress est un CMS extrêmement mal codé systèmatiquement utilisé avec une ribambelle de plugins très mal codés, utilisés par des gens qui codent encore plus mal que cela. Bon courage.

[Zefling]

Pareil, je souhaite bien du courage à tous ceux qui retrouveront leur site cassé !

Les CMS, c'est bien à plusieurs. Mais quand il n'y a qu'un webmestre, on a vu mieux niveau surface d'attaque. J'utilise pour ma part un CMS (SPIP) converti en html statique : surface d'attaque minimale = pas de soucis de mise à jour cassant les plugins.
Si c'était à refaire, aujourd'hui j'utiliserai Jekyll.

Entre un site casé et un serveur zombie, c'est quoi qu'est le mieux ?

Expérience vécue : mon frère s'est fait dégagé son site pour raison de sécurité, car il n'avait pas mis à jour son CSM (joomla à l'époque). Résultat, je lui ai tout passé sous Wordpress et je suis limite bien content de pas m'occuper des mise à jour ça se fait tout seul. Je peux regarder ça de loin sans que ça me prennent la tête.

Les CMS, c'est bien pour ceux qui n'ont aussi que très peu de connaissance informatique.
À titre perso, je préfère coder mon site, au moins quand il y a un problème je sais d'où ça vient, mais c'est beaucoup plus austère au niveau de l'interface d'admin.

[Madmac]

Entre un site casé et un serveur zombie, c'est quoi qu'est le mieux ?

Expérience vécue : mon frère s'est fait dégagé son site pour raison de sécurité, car il n'avait pas mis à jour son CSM (joomla à l'époque). Résultat, je lui ai tout passé sous Wordpress et je suis limite bien content de pas m'occuper des mise à jour ça se fait tout seul. Je peux regarder ça de loin sans que ça me prennent la tête.

Les CMS, c'est bien pour ceux qui n'ont aussi que très peu de connaissance informatique.
À titre perso, je préfère coder mon site, au moins quand il y a un problème je sais d'où ça vient, mais c'est beaucoup plus austère au niveau de l'interface d'admin.

C'est pour cela que Jekyll est un meilleur choix car Jekyll est une générateur de site statique. Jekyll est basée sur Rails.Et il sert uniquement à l'édition. par conséquence, tu n'as pas besoin d'installer Ruby ou Rails sur ton site. Donc c'est assez facile de faire un site qui est solide.

[chrtophe]

C'est pour cela que Jekyll est un meilleur choix car Jekyll est une générateur de site statique

Et tu fais comment si ton site est dynamique ?

[Madmac]

Et tu fais comment si ton site est dynamique ?

Parce que ton site est dynamique, tu ne pourrais pas avoir de page statique? Dans ce cas, tu fais d'une pierre, deux coups: Tu augmente ta sécurité et tu réduis la charge de ton serveur. Honnêtement, au train où vont les choses avec les solutions coté-client, un serveur pour un blog va devenir, de plus en plus, une curiosité.

[chrtophe]

Honnêtement, au train où vont les choses avec les solutions coté-client, un serveur pour un blog va devenir, de plus en plus, une curiosité.

Bine que WordPress soit à l'origine un moteur de blogs, et qu'il soit critiquable sur certains points, il équipe plus de 30% des sites mondiaux. Le nombre de site pouvant être cassé par un forçage de mises à jour automatiques pourrait être important.

[Sodium]

Bine que WordPress soit à l'origine un moteur de blogs, et qu'il soit critiquable sur certains points, il équipe plus de 30% des sites mondiaux.

C'est le seul point sur lequel il n'est pas critiquable, effectivement il a eu son succès...

Pour te le reste, je déconseille vivement à tout développeur sensible de jeter un oeil à son code source.