MediaWiki

Manuel:Sécurité

This page is a translated version of the page Manual:Security and the translation is 94% complete.
Outdated translations are marked like this.
Languages:
Si vous pensez avoir trouvé un problème de sécurité dans MediaWiki ou sur l'un des sites web Wikimedia, allez sur la page Sécurité pour avoir les informations de contact afin que nous puissions préparer une version avec la correction.
Brian Wolff présente la manière de sécuriser une installation MediaWiki au EMWCon 2018.

Soyez à jour dans vos produits

La chose la plus importante à faire au niveau sécurité est de toujours garder votre logiciel à jour. A la fois MediaWiki et le logiciel duquel il dépend vont recevoir de temps en temps de nouvelles versions qui corrigent les nouvelles failles de sécurité découvertes dernièrement peuvant vous concerner.

Les développeurs MediaWiki recommandent fortement à chaque personne qui exécute MediaWiki de souscrire à la liste de diffusion mediawiki-announce. C'est une liste à faible trafic qui diffuse uniquement les annonces de nouvelles versions.

Conformément au cycle de vie des versions de MediaWiki, chaque version recevra des mises à jour de sécurité pendant un an. Les anciennes versions peuvent contenir des failles de sécurité connues mais non corrigées.

Noubliez pas de suivre également les mises à jour de Apache, PHP, MySQL/MariaDB, et des autres logiciels qui s'exécutent sur vos serveurs – à la fois pour le système d'exploitation ainsi que pour les autres applications web.

Faites attention aux extensions que vous utilisez

Il existe une grande variété d'extensions disponibles pour MediaWiki. Malheureusement, ces extensions sont également d'une grande variété de niveaux de qualité. L'utilisation d'une extension de faible qualité avec MediaWiki est l'une des causes les plus courantes de problèmes de sécurité pour MediaWiki.

Avant de décider d'utiliser une extension, vous devez effectuer des recherches de base sur l'extension. Les extensions écrites par des membres éminents de la communauté de développement MediaWiki sont généralement assez sûres. De même, toute extension utilisée sur un wiki géré par la Fondation Wikimedia a probablement été examinée attentivement et est probablement sûre (il n'y a bien sûr aucune garantie). Cependant, si vous trouvez dans les alentours une extension de Github qui n'a pas été touchée depuis de nombreuses années et qui a été développée par quelqu'un de peu d'expérience dans le développement web, le risque est potentiellement assez élevé.

À la fin de la journée, vous devez évaluer le risque de sécurité lié à l'installation d'une extension de la même manière que vous évalueriez le risque de sécurité lié à l'installation de tout autre bout de logiciel.

Les extensions doivent également être tenues à jour comme tout autre logiciel. Les extensions fournies avec MediaWiki ont des annonces de sécurité faites sur la liste de diffusion mediawiki-annonce, mais pas les autres. Certaines extensions, mais certainement pas toutes, annoncent des problèmes de sécurité sur la liste de diffusion mediawiki-l.

Droits d'accès aux fichiers

L'une des choses importantes que vous pouvez faire pour sécuriser votre installation MediaWiki est : Vous assurer que l'utilisateur exécutant PHP n'a pas accès en écriture sur aucun fichier ni répertoire accessible à partir du web, sur lequel PHP peut opérer.

Dans les systèmes basés sur Debian cela signifie que l'utilisateur www-data ne doit pas être propriétaire drs fichiers PHP.

Sur les systèmes de type Unix, vous pouvez faire cela en vous assurant que le répertoire/les fichiers Mediawiki appartiennent à une personne différente de l'utilisateur du serveur web (www-data) ou que l'utilisateur du serveur mysql. Selon la manière dont vous avez installé MediaWiki, cela peut déjà être le cas, mais sinon, vous pouvez le faire en faisant chown -R <nomUtilisateurIci> /path/to/MediaWiki/ où le nom d'utilisateur est un utilisateur différent de celui du serveur web ou de l'utilisateur mysql (vous utiliserez généralement votre propre nom d'utilisateur à condition que mysql et php ne s'exécutent pas sous votre nom d’utilisateur). Après avoir fait cette étape, vous devrez peut-être changer le propriétaire du répertoire d'images en utilisateur php, car les fichiers téléversés doivent s'y copier, donc MediaWiki doit pouvoir écrire à cet endroit (par exemple chown -R www-data /path/to/MediaWiki/images). Ensuite, vous exécutez chmod -R go-w /path/to/MediaWiki pour supprimer l'accès en écriture à tous les autres utilisateurs sauf aux propriétaires des fichiers. Après avoir effectué cette étape, vous devrez peut-être réactiver l'accès en écriture sur le répertoire images.

Les répertoires auxquels MediaWiki doit avoir accès en écriture (tels que $wgCacheDirectory si cette fonctionnalité est activée) doivent être situés hors de la racine web. L'exception étant le répertoire des images qui doit être sous la racine web. Néanmoins il est important de désactiver php sur le répertoire des images. Les détails sur la façon de procéder varient selon le serveur web, mais sur Apache, cela peut parfois être réalisé en utilisant php_flag engine off dans un fichier .htaccess. Si vous effectuez cette opération via un fichier de configuration dans le répertoire images lui-même, vous devez vous assurer que le fichier de configuration n'est pas accessible en écriture par le serveur web. Pour plus de détails, voir la section ci-dessous sur la sécurité du téléversement.

Votre fichier LocalSettings.php doit être lisible par l'utilisateur php, néanmoins il ne doit pas être lisible par tout le monde, pour empêcher d'autres processus de découvrir le mot de passe de votre base de données et d'autres informations sensibles. Comme tous les fichiers MediaWiki, l'utilisateur php ne doit pas pouvoir écrire dans LocalSettings.php.


Sécurité du niveau transport (TLS, HTTPS)

Pour vous protéger contre les attaques de style firesheep et des fuites générales de confidentialité, il est recommandé d'héberger votre site en utilisant TLS (HTTPS). Un guide pour configurer TLS est hors de la portée de ce document, mais il convient de noter que c'est beaucoup moins cher maintenant que letsencrypt.org fournit des certificats gratuits.

Si vous configurez TLS, il est important de tester votre site avec ssllabs.com/ssltest/ pour vous assurer qu'il est correctement configuré, car il est facile de mal configurer TLS accidentellement.

Si vous activez TLS, vous pouvez également configurer votre serveur Web pour envoyer l'en-tête strict-transport-security. Cela améliorera considérablement la sécurité de votre site web contre les écoutes, mais avec l'inconvénient que vous ne pouvez pas décider d'arrêter l'utilisation de TLS pendant une période de temps définie.

Recommendations PHP générales

Veuillez vous référer à l'OWASP PHP Security Cheat Sheet

Ces conseils s'appliquent à pratiquement tous les environnements PHP et ne sont pas nécessairement spécifiques à MediaWiki.

Recommandations de configuration PHP pour php.ini ou autre initialisation :

  • Désactivez allow_url_fopen sauf si vous en avez particulièrement besoin.
    • Les vulnérabilités d'exécution de code PHP à distance peuvent dépendre de la possibilité d'injecter une URL dans un include() ou un require(). Si vous n'avez pas besoin d'utiliser le chargement de fichiers à distance, le désactiver peut empêcher les attaques de ce type sur du code vulnérable.
    • MediaWiki peut exiger que ce paramètre soit activé pour l'extension de recherche Lucene, l'extension moissonneuse OAI, l'extension TitleBlacklist et certaines utilisations de Special:Import en 1.5. Il ne doit cependant pas être obligatoire dans une installation typique.
    • MediaWiki devrait être sûr même s'il est activé; cette désactivation est une précaution contre la possibilité d'une vulnérabilité inconnue.
  • Désactivez session.use_trans_sid .
    • S'il est activé, les ID de session peuvent être ajoutés aux URL qualquefois si les cookies ne font pas leur travail. Cela peut divulguer des données de session de connexion à des sites tiers via des données de référence ou un copier-coller de liens.
    • Vous devez toujours désactiver ceci dans le cas où il serait positionné.

Par exemple si vous voyez cette ligne dans php.ini : 

allow_url_fopen = On

Remplacez la par : 

allow_url_fopen = Off

Alternativement, vous pouvez ajouter cette directive Apache pour désactiver allow_url_fopen par répertoire : 

php_flag allow_url_fopen off

Redémarrez ensuite Apache pour recharger les modifications par apachectl reload ou rcapache2 reload (SuSE).

Sur un système multi-utilisateur avec PHP installé en tant que module Apache, tous les scripts des utilisateurs s'exécuteront sous le même compte utilisateur à privilèges réduits. Cela peut donner à d'autres utilisateurs un accès pour lire vos fichiers de configuration (y compris les mots de passe de base de données), lire et modifier vos données de session de connexion ou écrire des fichiers dans votre répertoire de téléversement (si activé).

Pour la sécurité multi-utilisateurs, envisagez d'utiliser une configuration CGI/FastCGI dans laquelle les scripts de chaque utilisateur s'exécutent sous leur propre compte.

Recommendations générales pour MySQL et MariaDB

En général, vous devez limiter le plus possible l'accès à votre base de données MySQL ou MariaDB. S'il ne sera utilisé que sur la seule machine sur laquelle il s'exécute, envisagez de désactiver la prise en charge réseau ou d'activer uniquement l'accès réseau local (via le périphérique de bouclage, voir ci-dessous), afin que le serveur ne puisse communiquer avec les clients locaux que via les sockets de domaine Unix.

S'il sera utilisé sur un réseau avec un nombre limité de machines clientes, envisagez de définir les règles du pare-feu IP pour accepter l'accès au port TCP 3306 (port MySQL/MariaDB) uniquement à partir de ces machines ou uniquement à partir de votre sous-réseau local, et rejetez tous les accès plus larges venant d'Internet. Cela peut empêcher l'ouverture accidentelle de l'accès à votre serveur en raison d'une faille inconnue dans le serveur de base de données, d'un GRANT trop large par erreur ou d'un mot de passe divulgué.

Si vous créez un nouvel utilisateur MySQL/MariaDB pour MediaWiki via le programme d'installation de MediaWiki, un accès quelque peu libéral lui est accordé pour garantir qu'il fonctionnera à partir d'un deuxième serveur ainsi que d'un serveur local. Vous pouvez envisager de réduire manuellement cela ou d'établir vous-même le compte utilisateur avec des autorisations personnalisées à partir des endroits dont vous avez besoin. L'utilisateur de la base de données n'a besoin que des droits du SELECT, INSERT, UPDATE et DELETE pour la base de données.

En particulier le privilège FILE privilege est une cause commune des problèmes de sécurité. Vous devez vous assurez que l'utilisateur MySQL/MariaDB ne possède pas ce privilège ni aucun des autres privilèges concernant l' « administration du serveur ».

Remarquez que la table user dans la base de données MediaWiki contient les mots de passe hachés des utilisateurs ainsi que leur adresse courriel, et doivent en général être considérés comme des données privées.

Scripts de maintenance

Pour les scripts de maintenance, vous pourriez vouloir créer un utilisateur qui soit administrateur de la base de données avec davantage de droits. Pour cela, initialisez les variables suivantes avec les données de connexion de ce compte :

Voir Scripts de maintenance scripts/Configuration pour les détails concernant les droits requis pour MySQL et MariaDB.

Mise à jour de MediaWiki

Durant la mise à jour, des droits supplémentaires MySQL/MariaDB peuvent être nécessaires.

Informations supplémentaires sur MySQL et MariaDB

  • mysql command-line options --skip-networking.
  • En initialisant bind-address=127.0.0.1 dans votre my.ini (sous la section [mysqld]) vous imposerez à MySQL/MariaDB de n'écouter que sur l'interface de rebouclage. C'est le fonctionnement par défaut dans l'installation EasyPHP pour Windows (si vous utilisez MySQL/MariaDB sur une machine Unix, le paramètre peut être skip-networking à la place, dans le fichier my.cnf).
  • syntaxe de GRANT et REVOKE

Fuites de la base de données MySQL ou MariaDB

S'il y a eu des fuites vers le public, dans LocalSettings.php:

  1. Modifier $wgDBpassword s'il a été également divulgué
  2. Modifiez quelques lettres dans $wgSecretKey
  3. Effacez le contenu de la colonne user_token de votre table user pour qu'elle ne soit pas utilisées pour rendre vos utilisateurs impersonnels


Si LocalSettings.php a été divulgué

Si LocalSettings.php a été divulgué au public, reprotégez le et :

  1. Modifiez $wgDBpassword
  2. Remplacez $wgSecretKey par une chaîne aléatoire différente de lettres et de chiffres
  3. Faites un $wgSpamRegex différent (facultatif)
  4. Effacez le contenu de la colonne user_token de votre table user de sorte qu'elle puisse être utilisée pour rendre impersonnels tous les utilisateurs

Mots de passe de la base de données

Voir Manuel:Sécuriser les mots de passe de la base de données pour quelques précautions que vous voudriez prendre pour réduire le risque que les mots de passe de MySQL/MariaDB soient diffusés sur le web.

Affichage alternatif de fichier

MediaWiki est conçu pour fonctionner sur place après avoir été extrait de l'archive de distribution. Cette approche est pratique, mais peut entraîner une sécurité réduite ou des fichiers dupliqués inutilement.

Vous évitez les doublons dans une installation de masse ou pour conserver les fichiers sensibles hors de la racine web pour des raisons de sécurité en déplaçant ou en consolidant manuellement divers fichiers.

Le déplacement des fichiers principaux et des fichiers d'habillage peut nécessiter une sélection, un choix et une modification soigneuse du jeu de include_path initialisé dans votre LocalSettings.php. Expérimentez avec cela comme vous le souhaitez.

Si vous travaillez pour améliorer la sécurité, gardez à l'esprit que WebStart.php utilise le répertoire courant comme base. Cela signifie que la seule définition de votre include_path peut ne pas contribuer à améliorer la sécurité de votre installation.

Déplacer les informations sensibles

Envisagez le déplacement du mot de passe de la base de données ou d'autres données potentiellement sensibles, de LocalSettings.php vers un autre fichier situé ailleurs qu'à la racine des documents web, et d'inclure ce fichier de LocalSettings.php (en utilisant include()). Ceci peut aider à vous assurer que le mot de passe votre base de données ne sera pas compromis si une erreur de configuration du serveur web bloque l'exécution de PHP et révèle le texte source du fichier.

De manière équivalente, en modifiant LocalSettings.php avec un éditeur de texte quelconque vous laisserez un fichier de sauvegarde dans le même répertoire avec une extension de fichier différente (par exemple LocalSettings.php~), ce qui vous permettra de réutiliser cette copie comme texte brut si quelqu'un la demande. Si vous utilisez un tel éditeur, assurez-vous de désactiver la génération de sauvegarde ou déplacez les données sensibles ailleurs qu'à la racine web.

Un fichier journal de débogue MediaWiki, tel qu'il est utilisé pour le débogue contient également des données sensibles. Assurez-vous de toujours interdire l'accès aux personnes non-autorisées et au public tel ce ça a été expliqué, supprimez les fichiers journal s'ils ne sont plus nécessaires, et commentez ou effacez les lignes des fichiers journal dans votre LocalSettings.php. 

/**
 * The debug log file should never be publicly accessible if it is used, as it may contain private data.
 * But it must be in a directory writable by the PHP script running within your Web server. 
 */
# $wgDebugLogFile  = "c:/Logs/mediawiki/debug.log"; // Windows
$wgDebugLogFile  = "/var/log/mediawiki/{$wgSitename}-debug.log"; // Linux

Initialiser DocumentRoot à /dev/null

Une option plus sécurisée pour le serveur web Apache est de faire pointer le DocumentRoot vers un répertoire vide ou non existant, puis d'utiliser les directives Alias dans la configuration Apache pour n'exposer que les scripts et les répertoires qui n'ont pas besoin d'être accédés à partir du web.

Scripts du chargeur

Une solution uniquement PHP qui fonctionnera avec tous les serveurs web est d'écrire une série de scripts qui chdir() explicitement vers un répertoire spécifique, puis qui nécessitent un ou plusieurs fichers source. Par exemple : 

<?php
chdir('/path/to/wiki');
require('./index.php');

Sécurité de l'utilisateur

Toute personne capable d'éditer l'interface utilisateur des messages système dans l'espace de noms MediaWiki: peut introduire du code HTML arbitraire et du JavaScript dans la sortie de la page. Ceci comprend les utilisateurs wiki qui ont les droits editinterface, ainsi que toute personne qui accède directement en écriture à la table text de la base de données.

Le HTML est désactivé sur beaucoup de messages système, particulièrement ceux affichés sur l'écran de connexion, donc le risque de blocage du mot de passe par Javascript doit donc être minime. Le code malicieux pourrait encore essayer d'exploiter les failles du navigateur (installation de spyware, etc), bien que vous devriez vous assurer que seulement les utilisateurs de bonne foi puissent modifier les messages système.

Sécurité des téléversements

Voir aussi : Configuration du téléversement de fichiers

La principale préoccupation est la suivante : Comment empêcher les utilisateurs de téléverser des fichiers malveillants ?

Le téléversement de fichiers est une fonctionnalité optionnelle de MediaWiki et désactivée par défaut. Si vous l'activez, vous devez également fournir un répertoire à la racine web accessible en écriture par l'utilisateur du serveur web.

À cela plusieurs implications pour la sécurité :

  • Le répertoire peut avoir besoin d'être accessible en écriture par tous, ou bien appartenir au compte utilisateur limité au serveur web. Sur un système multi-utilisateurs, il est possible à d'autres utilisateurs locaux d'enregistrer des fichiers malveillants dans votre répertoire de téléversement (voir les notes multi utilisateur ci-dessus) Si possible, rendez le répertoire accessible en écriture uniquement par le compte du serveur web, ne rendez pas le répertoire accessible en écriture pour tout le monde.
  • Alors que la configuration de PHP définit une limite de taille de fichier pour les téléversements individuels, MediaWiki ne fixe aucune limite sur la taille totale du téléversement. Un visiteur malveillant (ou trop zélé) pourrait remplir la partition du disque en téléversant beaucoup de fichiers.
  • Les vignettes générées et les fichiers téléversés conservés pour confirmer l'écrasement peuvent être conservés dans images/thumb et images/tmp sans note visible dans l'interface web de MediaWiki. Gardez également un œil sur leurs tailles.

La configuration par défaut tente de limiter les types de fichiers qui peuvent être téléversés pour des raisons de sécurité :

  • Par défaut, les extensions de fichier .png, .gif, .jpg, .jpeg et webp sont en liste blanche ($wgFileExtensions ).
  • Divers exécutables et extensions de script sont explicitement mis en liste noire ($wgProhibitedFileExtensions ) même si vous autorisez les utilisateurs à modifier la liste blanche ($wgStrictFileExtensions ).
  • Plusieurs extensions connues de fichiers image ont leur type vérifié par la fonction PHP getimagesize().
  • Les fichiers téléversés sont vérifiés pour voir s'ils peuvent déclencher des bogues de détection de type de fichier dans Internet Explorer et Safari, ce qui peut les amener à s'afficher en tant que HTML. (Il a été proposé de supprimer ce contrôle, voir T309787).

Par précaution, vous devez explicitement désactiver l'exécution côté serveur des scripts PHP (et tous les autres types de scripts que vous pourriez avoir) dans le répertoire de téléversement (par défaut, images). Vous devez aussi indiquer aux navigateurs de ne pas parcourir les fichiers en initialisant l'entête X-Content-Type-Options: nosniff.

Pour faire cela, par exemple, un fragment de fichier Apache .conf quand votre instance MediaWiki est dans /Library/MediaWiki/web peut ressembler à : 

<Directory "/Library/MediaWiki/web/images">
   # Ignore .htaccess files
   AllowOverride None
   
   # Serve HTML as plaintext, don't execute SHTML
   AddType text/plain .html .htm .shtml .phtml
   
   # Don't run arbitrary PHP code.
   php_admin_flag engine off

   # Tell browsers to not sniff files
   Header set X-Content-Type-Options nosniff
   
   # If you've other scripting languages, disable them too.
</Directory>

Si vous n'avez pas accès aux fichiers de configuration Apache, mais que vous pouvez utiliser les fichiers .htaccess pour remplacer les paramètres de configuration sur des répertoires spécifiques, vous pouvez placer un fichier .htaccess dans le répertoire de téléversement qui ressemble à ceci : 

# Serve HTML as plaintext, don't execute SHTML
AddType text/plain .html .htm .shtml .phtml .php .php3 .php4 .php5 .php7

# Old way of registering php with AddHandler
RemoveHandler .php

# Recent way of registering php with SetHandler
<FilesMatch "\.ph(p[3457]?s?|tml)$">
   SetHandler None
</FilesMatch>

# If you've other scripting languages, disable them too.

Votre configuration exacte peut être différente. En particulier, l'utilisation des options open_basedir peut compliquer la gestion des téléversements.

Si vous utilisez une des solutions ci-dessus, vous pouvez vérifier qu'elle fonctionne réellement à l'aide de ce simple test.

  • Créez un fichier 'test.php' dans le répertoire de téléversement.
  • Insérez <?php phpinfo(); dans le fichier.
  • Accédez au chemin dans un navigateur. Si vous ne voyez que le texte du fichier, c'est bon - sinon quelque chose est faux quelque part.

Désactiver la solution PHP pour Nginx : http://serverfault.com/a/585559/162909

Pour une meilleure sécurité, vous devrez aussi prendre en compte l'utilisation d'un domaine séparé pour les fichiers téléversés. Pour une sécurité totale, il est préférable que les téléversements soient servis à partir d'un domaine entièrement séparé, et non d'un sous-domaine, mais même un sous-domaine fournira une sécurité supplémentaire. Ceci est particulièrement important si vous permettez le téléversement de fichiers SVG depuis que ce format de fichier est similaire à HTML. Par sécurité, MediaWiki contrôle les téléversements SVG mais il est préférable d'avoir plusieurs niveaux de défense. Voir $wgUploadPath pour configurer un domaine différent pour desservir les fichiers média.

Programmes externes

  • /usr/bin/diff3 peut être exécuté pour résoudre les conflits de fusion des modifications.
  • Si la prise en charge de ImageMagick pour les vignettes ou les images SVG est activée, convert peut être exécuté sur les fichiers téléversés.
  • This list is incomplete.

You can use Shellbox to provide a more locked-down running environment for external commands.

Voir aussi

Retrieved from "https://www.mediawiki.org/w/index.php?title=Manual:Security/fr&oldid=6872169"