Problèmes de sécurité avec les extensions d'autorisation
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 |
|
Ceci est partiellement corrigé avec le paramètre $wgNonincludableNamespaces introduit en MW 1.10 (rev:19934). Vous pouvez aussi utiliser manual:Hooks/BeforeParserFetchTemplateAndtitle , manual:Hooks/ParserFetchTemplate , ParserOptions::setTemplateCallback(), ParserOptions::setCurrentRevisionCallback() mais faites attention avec le cache. |
Préchargement |
|
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) |
|
Pour les extensions qui utilisent l'accroche userCan , cela a été corrigé dans MW 1.10 (rev:19935).
|
Flux Atom / RSS |
|
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 |
|
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 |
|
Pour les extensions qui utilisent l'accroche userCan , cela devrait être OK avec les versions récentes de MediaWiki.
|
API |
|
Dans les MediaWiki modernes, une accroche userCan doit obtenir le cas prop=revisions , mais peut-être pas les autres
|
Liens d'action |
|
Pour les extensions qui utilisent l'accroche userCan , cela doit être OK avec les versions récentes de MediaWiki.
|
Droits associés |
|
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 |
|
|
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 |
|
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 |
|
|
Section des modifications |
|
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 |
|
Nécessite un accroche WatchArticle qui va appeler userCan .
|
Autres extensions |
|
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 |
|
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.