Création d’un groupe d’utilisateurs distinct pour la modification des CSS et JS globaux

Tracked in Phabricator:
Task T190015

Problématique

Les administrateurs ont un pouvoir extrêmement dangereux : en modifiant des pages telles que Common.js, ils peuvent instantanément exécuter du code sur des machines de millions de lecteurs et de milliers de contributeurs. (Il en est de même pour les autres groupes d’utilisateurs avec des privilèges comparables, tels que les modificateurs d’interface.) Bien que ce soit largement connu, seule une poignée de gens comprennent à quel point cela peut être utilisé à mauvais escient :

• En soumettant du code malveillant aux lecteurs ou contributeurs, un utilisateur malveillant peut faire à peu près n’importe quoi : hameçonner des mots de passe ou numéros de carte de crédit, détourner des dons, dés-anonymiser des contributeurs, faire des modifications au nom d’autres contributeurs, pousser des personnes à installer un maliciel, envoyer des pourriels, orchestrer des attaques DDoS contre des sites tiers…
• À la différence d’autres pouvoirs dangereux (par exemple les vérificateurs) qui ne peuvent pas être monétisés, il s’agit d’une cible lucrative pour un assaillant. Récemment nous avons vu quelqu’un abuser de ses privilèges pour exécuter des mineurs de cryptomonnaies sur les machines des visiteurs. Des choses bien pires encore peuvent attirer des assaillants à la recherche de revenus faciles.
• Les dégâts ne sont pas limités à un unique wiki : parce que les wikis Wikimedia utilisent tous le même système global d’authentification, une faille sur un wiki peut être utilisée pour s’approprier des comptes d’administrateurs d’autres wikis et étendre encore l’attaque.

Par conséquent, les administrateurs escrocs et les pirates volant des comptes d’administrateurs présentent une sérieuse menace et nous devons faire notre possible pour la réduire. C’est un petit miracle qu’aucun incident majeur ne soit arrivé jusqu’à présent, même si des comptes d’administrateurs sont volés régulièrement. Nous devons réduire notre dépendance aux miracles.

En même temps, le fait que les communautés Wikimedia puissent modeler leur environnement de travail est extrêmement précieux et devrait être préservé. Les gadgets pour l’interface des contributeurs permettent un gain immense en productivité ; les modifications dans l’interface des lecteurs permettent d’adapter les centaines de wikis Wikimedia aux nombreux et divers problèmes et cas d’utilisation auxquels ne pourraient pas répondre un développement centralisé ; pouvoir résoudre les problèmes localement au lieu de devoir solliciter une aide extérieur est une importante source d’autonomisation et de motivation pour la communauté d’un wiki. Le contrôle de l’environnement CSS et JS local devrait être laissé aux communautés locales.

Solution

La plupart des administrateurs ne veulent pas ou n'ont pas besoin de modifier le CSS et le JavaScript, puisqu'ils doivent maîtriser ces langages, ce qui n'est pas le cas de la majorité des administrateurs. Les gens qui modifient déjà le CSS et le JavaScript pour l'ensemble d'un site (ou qui souhaitent le faire) ne devraient pas être entravés, mais les administrateurs indifférents ne devraient pas avoir ce droit. Un assaillant ne tirerait donc aucun avantage du vol de leur compte. Également, les communautés qui souhaitent vérifier les éditeurs de JavaScript ou de CSS de façon plus serrée que les administrateurs (ce qui est une sage mesure) doivent être soutenues par le logiciel du wiki.

Pour faciliter cette mesure, le groupe utilisateur administrateurs d'interface sera créé. Seulement les utilisateurs de ce groupe pourront modifier les pages JavaScript/CSS qui modifient tout le site. De façon automatique, les bureaucrates et les stewards pourront accorder ce droit, de la même façon que pour les administrateurs. La façon de nommer des administrateurs techniques est laissée à la discrétion de la communauté locale (ou la communauté Wikimedia globale si la communauté crée une politique globale de la façon usuelle).

Plusieurs bénéfices en seront tirés :

• Le nombre de comptes qui pourrait abuser des ressources du site sera drastiquement réduit. Moins de comptes qui peuvent servir de vecteurs d'attaques amène moins d'occasions qu'un compte puisse être vulnérable lorsque la base de données des mots de passe d'un site Web tiers est compromise. (Également, les administrateurs réguliers ont un souci moindre d'être la cible d'un vol d'identité.) Un nombre moindre de comptes est plus facile à surveiller pour détecter des identifications suspectes.
• Au-delà du simple nombre de comptes, cela éliminera les comptes les plus vulnérables comme vecteurs d'attaques. Les utilisateurs qui peuvent rédiger du code JavaScript et du CSS montrent en général de plus grandes compétences en TIC, et donc applique des techniques de sécurité supérieures pour les mots de passe et les systèmes.
• À l'avenir, nous pourrions relever les exigences de sécurité pour les éditeurs de CSS/JS (comme exiger une authentification à deux facteurs) sans gêner tous les autres administrateurs dont la compromission du compte poserait un danger moindre.

Pour l'aspect technique : un nouvel ensemble de permissions (editsitecss et editsitejs) sera introduit pour MediaWiki. Pour modifier une page .css ou .js dans l'espace de noms MediaWiki, à la fois l'ancienne permission editinterface et la permission editsiteXXX pertinente seront nécessaires. Les administrateurs et les autres groupes utilisateurs qui jouissent déjà de la permission editinterface recevront les nouveaux droits pendant la courte période de migration (de façon à ce que la transition se déroule sans heurt). Les droits seront plus tard retirés ; ensuite, le logiciel interdira tout autre groupe que les administrateurs techniques.

Comment aider

• À la fin de cette consultation, une période de migration de probablement deux semaines sera mise en œuvre, période pendant laquelle le groupe des administrateurs techniques sera activé, tout en autorisant n'importe quel administrateur à modifier le code CSS/JS. Prière d'informer votre communauté pour que des utilisateurs puissent joindre ce groupe et qu'elle décide d'un processus pour décider qui sera ajouté. (L'autorisation d'ajout à ce groupe est à la discrétion de chaque communauté locale ; ça peut être aussi simple qu'ajouter tous les administrateurs qui le demandent.)
• Également, prière de vous assurer que votre wiki contient des documents et un processus d'élection pour le nouveau groupe une fois la période de migration terminée. Encore une fois, ça peut être aussi simple que demander à tout nouvel administrateur nouvellement élu s'il souhaite être administrateur technique et s'il est familier avec JavaScript et les pratiques de sécurité de base. Dans tous les cas, nous recommandons d'être aussi exigeant que pour les administrateurs (en termes de confiance et du comportement), et même d'être plus exigeant (consulter la page du groupe des utilisateurs (en anglais) pour des conseils supplémentaires).
• Dites-nous sur le flux d'édition du CSS/JS qui exige des permissions supplémentaires (ça aidera à déterminer quels droits les administrateurs techniques devraient avoir par défaut). Par exemple, est-ce que les administrateurs techniques ont besoin de supprimer des pages ou de modifier un modèle ?
• Suggérez un meilleur nom pour le groupe ! « Administrateurs techniques » n'est pas chic. Les aspects à tenir compte : les membres du groupe sont distincts des développeurs qui maintiennent le code hors wiki (développement de MediaWiki, maintient des outils de Toolforge, etc.) ; ils sont distincts des gens qui travaillent avec Lua (espace de noms Module) ; le groupe d'utilisateurs qui peuvent modifier l'interface existe toujours (les messages MediaWiki) ; dans l'idéal, le nom du groupe devrait indiquer que ce rôle exige au moins autant de confiance que pour les administrateurs.
• Si vous voyez des soucis que ce document omet, ou si vous voyez des modifications qui rendraient les changements plus utiles ou moins lourds, prière de nous le dire !

Prière d'écrire sur la page de feedback. Vous pouvez nous le dire dans n'importe quelle langue.

FAQ

Qui est à l'origine de ce document ?

Cette page et les changements correspondants dans le code source ont été écrits par l'utilisateur Tgr (de façon volontaire). Cette page est basée sur la discussion du ticket T190015 et de la liste de diffusion wikitech-l, il semble y avoir consensus de la communauté de développeurs de MediaWiki sur ce sujet.

Est-ce un appel à commentaires (RfC) ?

Pas dans le sens où ce changement sera basé ou non sur le consensus communautaire. Ceci n'est pas un vote. Les décisions sur la sécurité du logiciel sont gouvernées par le consensus de la communauté des développeurs de MediaWiki qui est prioritaire par rapport au consensus des éditeurs. La décision finale sera prise lors de la revue de code, comme d'habitude. Cela étant dit, les commentaires sont les bienvenus ! Les discussions pourraient aboutir à faire les choses différemment que suggérées ici, ou bien, elles pourraient décider de détails importants sur les autres permissions que devrait obtenir ce nouveau groupe d'utilisateurs. Elles pourraient aussi aider les communautés à aborder ce changement logiciel dans ses politiques et procédures.

Est-ce une réponse impulsive aux incidents récents ?

Non. Même si les récents incidents ont souligné l'importance de ce changement. L'idée a été débattue pendant plusieurs années et le patch spécifique qui motive cette consultation a été écrit en mars.

Même si ça arrive, les administrateurs auront des façons de déployer du JavaScript pour tout le site.

C'est un (difficile) problème technique qui sera traité dans le futur. Toutefois, limiter la possibilité des administrateurs de modifier le JS à quelques hacks obscurs et peu connus réduit de façon notable réduit la superficie d'attaque, et rend plus facile le suivi des vulnérabilités.

Pourquoi l'édition du CSS est-il traité de la même manière que l'édition du JavaScript ?

Même si le CSS est moins sensible que le JS, c'est encore dangereux :

• Les propriétés d'images du CSS peuvent servir à retirer l'anonymat des utilisateurs.
• Dans quelques vieux navigateurs, du code JavaScript peut être intégré dans le CSS.
• Le CSS peut être utilisé pour voler les tokens d'édition (et donc éditer au nom de quelqu'un d'autre en utilisant ses privilèges) ; toutefois c'est présentement limité parce que les navigateurs ne le supportent pas.
• Du détournement de clic basé sur du CSS peut être utilisé pour monter des attaques d'hameçonnage.

Les statistiques montrent que tous les administrateurs qui modifient le code CSS modifient aussi du code JS. Il n'y a donc aucune raison de traiter les deux problèmes de façon séparée.

À l'avenir, la capacité d'utiliser un sous-ensemble de commandes CCS « propres » pourrait être introduit ; suivre le projet TemplateStyles pour connaître l'état des lieux.

Est-ce que les pages TemplateStyles .css sont touchées ?

Non, seulement les pages CSS de l'espace de noms MediaWiki. Le code CSS TemplateStyles n'est pas rendu « propre » de façon automatique dans le but de prévenir tout usage dangereux.

Pourquoi ne pas prévenir de façon automatique les utilisateurs pouvant modifier du JavaScript qu'ils font quelque chose de dangereux ?

Même si des améliorations sont faites dans ce domaine (comme le CSP et quelques étapes de révision de code), elles ne préviendront jamais de façon complète des attaques - il est impossible de rendre « propre » un langage de programmation. En outre, ils sont beaucoup plus complexes et requièrent beaucoup plus d'efforts. À court terme, réduire le nombre de comptes pouvant modifier du JavaScript est de loin la stratégie d'atténuation la plus réalisable ; à long terme, cela devrait quand même se faire aux côtés d'autres méthodes stratégiques.

Qu'en est-il des permissions editusercss/edituserjs ?

Ces (très peu connues et très peu utilisées) permissions permettent de modifier le CSS/JS des autres utilisateurs. Puisqu'elles facilitent le vol d'identité d'un compte utilisateur, les mêmes considérations s'appliquent et ces permissions seront également restreintes de la même façon. (À long terme, voir T197087.)

Et pour la nouvelle permission editsitejson ?

Elles servent à modifier les pages .json dans l'espace de noms MediaWiki (ce que logiciel fait depuis peu, pour les pages de configuration de gadgets et de bots). JSON représente des donnés, pas du code, c'est donc moins dangereux et les administrateurs pourront encore le modifier ; les gadgets devraient être écrits de façon à ce qu'un assaillant qui contrôle des pages .json ne puisse compromettre les gadgets et les bots.