Problèmes de sécurité avec les extensions d'autorisation

This page is a translated version of the page Security issues with authorization extensions and the translation is 100% complete.

MediaWiki n'est pas conçu pour être un système de gestion de contenu (CMS - Content management system), ni pour protéger les données sensibles. Au contraire, il a été conçu pour être le plus ouvert possible. Ainsi, il ne prend pas en charge de manière inhérente une protection complète et étanche du contenu privé. Mais avec l'augmentation massive de l'utilisation de MediaWiki dans des réseaux internes des entreprises et avec les nombreuses fonctionnalités de type CMS qui émergent, une demande de meilleure sécurité se crée aussi.

Pour aider les auteurs d'extensions de sécurité, cette liste de défauts de sécurité trouvés est maintenue, pour qu'ils puissent tester à quel point leurs extensions les résolvent. Il y a plusieurs extensions qui revendiquent qu'elles fournissent un accès lecture/écriture sélectif aux pages dans Catégorie:Page des droits utilisateur d'extensions spécifiques , et actuellement la plupart d'entre elles ont plusieurs des problèmes listés.

Tester les extensions de sécurité

Si vous allez implémenter un accès en lecture ou écriture, vérifiez si votre extension comporte les défauts énumérés dans le tableau ci-dessous en vous connectant en tant qu'utilisateur sans les permissions lecture/écriture. Commencer une nouvelle session de navigateur web en mode incognito permet de naviguer sur le site comme un utilisateur sans privilèges pendant les tests et la configuration du logiciel.

Tableau des limites communes des extensions de sécurité

Fonction/Test Vérifier Commentaire
Inclusion/Transclusion
  • Peut-on accéder aux pages restreintes via {{:restricted article}} ? et que se passe-t-il si on utilise des niveaux multiples (transclusions de transclusions) ?
  • Peut-on accéder aux pages restreintes via une transclusion vers une redirection ?
  • Pouvez-vous contourner la restriction d'une transclusion en utilisant la transclusion dans le mode aperçu des modifications ou via Special:ExpandTemplates ?
  • Pouvez-vous contourner une restriction de transclusion en utilisant l'API (par exemple avec la méthode action=parse)
  • Pouvez-vous utiliser des messages d'erreur qui prennent des paramètres contrôlés par l'utilisateur et les analyser en tant que wikicode, pour contourner les restrictions
  • Peut-on accéder via le {{msgnw::nom de page}}
Ceci est partiellement corrigé avec le paramètre $wgNonincludableNamespaces introduit en MW 1.10 (rev:19934). Vous pouvez aussi utiliser manual:Hooks/BeforeParserFetchTemplateAndtitle , ParserOptions::setTemplateCallback(), ParserOptions::setCurrentRevisionCallback() mais faites attention avec le cache.
Préchargement
  • Pouvez-vous contourner la restriction en utilisant les paramètres d'URI editintro= ou preload= en mode édition ?
Doit être sécurisé si l'extension utilise l'accroche UserCan , au moins depuis la version 1.12 (et peut-être même avant).
Export XML (Special:Export)
  • Est-il possible d'exporter le contenu d'une page restreinte ?
Pour les extensions qui utilisent l'accroche userCan, cela a été corrigé dans MW 1.10 (rev:19935).
Flux Atom / RSS
  • L'article a-t-il été livré ? Avec un diff ou le contenu complet ?
    Il y a deux flux, l'un dans les pages spéciales des Changements récents et l'autre dans l'historique de la page. Des flux supplémentaires peuvent être fournis par les extensions.
Pour les extensions qui utilisent l'accroche userCan, cela a été corrigé dans MW 1.12 (rev:25944). userCan n'est pas honoré dans MW 1.14 et définitivement plus tôt (SpecialRecentChanges*.php a été déplacé) ! Les pages RecentChanges listent les commentaires des modifications.
Listings et recherche
  • Les pages non lisibles sont-elles listées sur la page Special:Search ? Des extraits sont-ils présentés ? (voir aussi phab:T10825)
  • Est-ce que les pages non lisibles sont listées sur Special:Recentchanges ou sur Special:Allpages ?
  • les pages non lisibles sont-elles listées sur d'autres pages spéciales, telles que Lonelypages, etc. ?
Pour les extensions qui utilisent l'accroche userCan, ceci a été partiellement corrigé dans MW 1.10 (rev:21821) : La page cherchée n'affiche plus d'extraits pour les pages non lisibles - mais elle liste encore le titre des articles non accessibles à l'utilisateur.
Liens de diff et des versions
  • Est-ce qu'un lien direct vers une page diff peut être utilisé pour afficher le texte d'une page restreinte ? Qu'en est-il d'un diff entre une révision d'une page non restreinte et une révision de page restreinte, en manipulant les identifiants de révision ?
  • Pouvez-vous utiliser un lien permanent (lien de révision) vers une ancienne version pour lire une page que vous ne devriez pas lire ? Qu'en est-il d'un lien qui a un ID de révision appartenant à un autre titre que celui que l'on référence, en manipulant l'URL ?
Pour les extensions qui utilisent l'accroche userCan, cela devrait être OK avec les versions récentes de MediaWiki.
API
  • Le paramètre revids pour action=query peut-il être utilisé pour obtenir des versions devant être cachées ?
  • action=compare peut-il filtrer le contenu des pages.
Dans les MediaWiki modernes, une accroche userCan doit obtenir le cas prop=revisions, mais peut-être pas les autres
Liens d'action
  • Pouvez-vous utiliser action=raw ou les options action=render pour lire une page que vous ne devriez pas lire ?
  • Vous pouvez accéder à une version imprimable d'une page que vous ne devriez pas lire ?
  • Un lien direct vers la page de modification peut-il être utilisé pour afficher le contenu de page d'une page restreinte ?
Pour les extensions qui utilisent l'accroche userCan, cela doit être OK avec les versions récentes de MediaWiki.
Droits associés
  • L'extension empêche-t-elle l'utilisateur de créer une nouvelle page à laquelle il n'aura pas d'accès en lecture ?
  • Pouvez-vous déplacer ou renommer une page sur laquelle vous avez un accès en lecture mais pas d'accès en écriture ?
  • Pouvez-vous lire la page de discussion d'une page à laquelle vous n'avez pas accès ? Pouvez-vous écrire sur une page de discussion d'une page dont vous n'avez pas d'accès en écriture, à moins que cela ne vous ait été spécialement attribué ?
Si vous utilisez userCan, cela doit être OK, mais vous devrez peut-être écrire une accroche ArticleInsertComplete pour les créations et une accroche TitleMoveComplete pour les déplacements qui appellent userCan pour les droits de « CTRL-ENTER ».
Porte arrière des auteurs
  • Certaines extensions permettent toujours à l'auteur original d'une page d'y accéder, en ignorant les restrictions d'accès plus récentes.
Mise en cache
  • Cache de l'analyseur syntaxique (activé par défaut) met en cache les articles entre utilisateurs.
  • $wgEnableSidebarCache (non activé par défaut) effectue une fonction similaire pour la barre latérale. Si l'extension pouvait envoyer différentes pages à différents utilisateurs, elle pourrait être incompatible avec la mise en cache.
Limiter la mise en cache des articles aux utilisateurs anonymes pourrait améliorer les performances pour les sites ayant principalement des utilisateurs anonymes (comme Wikipedia), sans compromettre la sécurité.
Fichiers et images
  • Pouvez-vous télécharger un fichier directement sans avoir accès en lecture à son article associé ?
  • Pouvez-vous télécharger la vignette d'un fichier d'image directement indépendamment de l'accès en lecture à son article associé ?
  • Pouvez-vous téléverser ou supprimer une image indépendamment de l'accès en écriture à son article associé ?
Etant donné que les fichiers téléversés sont normalement fournis directement par le serveur web, et non pas via MediaWiki, il n'est pas possible facilement pour les extensions d'en empêcher l'accès. Voir Manual:Image Authorisation pour les instructions concernant le paramètrage des restrictions d'accès pour les images. (img_auth.php utilise userCan depuis r52751).
−Redirections
  • Si un utilisateur a le droit de voir une redirection mais pas la page sur laquelle elle pointe, sera-t-il toujours redirigé ?
  • Si un utilisateur a les droits pour voir une page mais pas une redirection qui pointe vers cette page, peut-il accéder à la page via la redirection ?
Section des modifications
  • Un utilisateur peut-il utiliser la fonction d' édition de section pour une page, même s'il ne peut pas modifier la page complète (soit par l'interface, ou en modifiant l'URL) ?
  • Un utilisateur peut-il utiliser la fonction édition de section pour les pages auxquelles il a obtenu l'accès ?
Si la sécurité repose sur des balises intégrées au code de la page, ces balises ne seront pas nécessairement présentes dans le texte que vous éditez, même si elles sont présentes ailleurs sur la page.
Suivre des pages
  • Un utilisateur peut-il voir une page dont il n'a pas l'accès en lecture ?
  • L'utilisateur peut-il détourner une page qu'il n'est pas autorisé à lire ?
  • L'utilisateur reçoit-il encore des notifications même s'il était bloqué ?
Nécessite un accroche WatchArticle qui va appeler userCan.
Autres extensions
  • Un utilisateur peut-il utiliser d'autres extensions pour afficher une partie d'une page ? Pensez à DynamicPageList ou Semantic MediaWiki , qui fournissent des moyens pour interroger la base de données pour certaines pages ou certaines propriétés.
  • Une extension affiche-t-elle le titre des pages confidentielles, comme un gadget de page récemment modifiée ?
  • Pouvez-vous récupérer le contenu d'une page via mw.title.new( "Page name" )::getContent() de Scribunto

Scribunto respectera les procédures de rappel de la version ParserOptions::setCurrentRevisionCallback, mais d'autres extensions ne le feront peut-être pas

Pollution du cache

Existe-t-il une situation où une page privée pourrait être mise en cache par MediaWiki, avec les droits vérifiés au moment du cache ? Puis plus tard, un autre utilisateur obtient la valeur en cache sans que la vérification des autorisations ne soit exécutée.

API:API REST
  • Est-ce que l'API REST affiche les pages confidentielles ?
Activé lorsque VisualEditor ou d'autres extensions sont activées.

Il y a probablement d'autres "trous" dans le système de protection de lecture. Donc, interdire l'accès en lecture devrait plutôt être vu comme une mesure dissuasive de "rien à voir ici, passez votre chemin" qu'une garantie absolue de secret.