Manual:Security/fr


 * 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 pour avoit les informations de contact afin que nous puissions préparer une version avec la correction.



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.

Plusieurs installations personnelles de MediaWiki 1.3.x ont été affectées à l'automne 2004 par un ver attaquant une faille dans phpBB; une fois qu'il a pénétré les sites phpBB non corrigés d'autres clients, il a ajouté un message vous êtes piraté à d'autres fichiers .php inscriptibles sur le système, y compris les modèles compilés utilisés par MediaWiki 1.3.

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 effectuées 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 avec 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 de vous assurer que l'utilisateur sous lequel vous exécutez php (souvent www-data si vous utilisez debian) et l'utilisateur avec lequel vous exécutez mysql n'ont pas accès en écriture à aucun répertoire web accessible avec php activé.

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  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 ). Ensuite, vous exécutez  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  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.

TLS
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. 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 ou autre initialisation :


 * Désactivez.
 * De nombreuses attaques de sécurité PHP sont basées sur l'injection de valeurs de variables globales, donc s'assurer qu'il est désactivé peut éviter de nombreuses vulnérabilités potentielles.
 * Si vous avez besoin de  pour une autre application web, envisagez de l'activer de manière sélective, uniquement pour l'hôte virtuel ou le sous-répertoire qui en a besoin.
 * MediaWiki devrait être sûr même s'il est activé; cette désactivation est une précaution contre les possibilités de vulnérabilités inconnues.
 * Désactivez  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  ou un  . Si vous n'avez pas besoin d'utiliser le chargement de fichiers à distance, le désactiver peut empêcher des 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.
 * 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 :

register_globals = On

Remplacez le par :

register_globals = Off

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

php_flag register_globals off

Redémarrez ensuite Apache pour recharger les modifications par  ou   (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é.

If you create a new MySQL/MariaDB user for MediaWiki through MediaWiki's installer, somewhat liberal access is granted to it to ensure that it will work from a second server as well as a local one. You might consider manually narrowing this or establishing the user account yourself with custom permissions from just the places you need. The database user only needs to have SELECT, INSERT, UPDATE and DELETE permissions for the database.

In particular, the FILE privilege is a common cause of security issues. You should ensure that the MySQL/MariaDB user does not have this privilege or any of the "server administration" privileges.

Note that the  table in MediaWiki's database contains hashed user passwords and may contain user e-mail addresses, and should generally be considered private data.

Scripts de maintenance
Pour les maintenance scripts|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.
 * Setting  in your my.ini (under section  ) will cause MySQL/MariaDB to only listen on the loopback interface. This is the default in the EasyPHP install for Windows. (If you are using MySQL/MariaDB on a Unix machine, the setting may be   instead in the my.cnf file.)
 * 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) Change  if that leaked too
 * 2) Modifiez quelques lettres dans
 * 3) Reset the user_token column in your user table so that it can't be used to impersonate your users

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


 * 1) Modifiez
 * 2) Replace  with a different random string of letters and numbers
 * 3) Make a different  (optional)
 * 4) Reset the user_token column in your user table so that it can't be used to impersonate any users

Mots de passe de la base de données
See for some precautions you may wish to take to reduce the risk of MySQL/MariaDB passwords being presented to the web.

Affichage alternatif de fichier
MediaWiki is designed to run in-place after being extracted from the distribution archive. This approach is convenient, but can result in reduced security or unnecessarily duplicated files.

You avoid duplicates in a mass installation or to keep sensitive files out of the web root for safety by manually relocating or consolidating various files.

Moving the main includes and skin files may require carefully picking and choosing and altering the  set in your. Experiment with this as desired.

If working to improve security, keep in mind that  uses the current directory as a base. This means that only setting your  may not help to improve the security of your installation.

Déplacer les informations sensibles
Consider moving the database password or other potentially sensitive data from  to another file located outside of the web document root, and including that file from   (through  ). This can help to ensure that your database password will not be compromised if a web server configuration error disables PHP execution and reveals the file's source text.

Similarly, editing  with some text editors will leave a backup file in the same directory with an altered file extension, causing the copy to be served as plain text if someone requests, for example,. If you use such an editor, be sure to disable backup generation or move sensitive data outside the web root.

A MediaWiki debug logfile as it is used for debugging also contains sensitive data. Make sure to always disallow access for non authorized persons and the public as explained, delete remains of such logfiles when they are not needed, and comment or clear the logfile lines in your.

Initialiser DocumentRoot à /dev/null
A more secure option for the Apache Web Server is to set the  to an empty or non-existent directory, and then use   directives in the Apache configuration to expose only the scripts and directories that need to be web-accessible.

Scripts du chargeur
A PHP-only solution that will work with any web server is to write a series of scripts that explicitly  to a specific directory and then require one or more source files. For example:

Sécurité de l'utilisateur
Anyone able to edit the user-interface system messages in the MediaWiki: namespace can introduce arbitrary HTML and JavaScript code into page output. This includes wiki users who have the editinterface permission, as well as anyone with direct write access to the text table in the database.

HTML is disabled on many system messages, particularly those displayed at the login screen, so the risk of password-snarfing JavaScript should be minimal. Malicious code could still attempt to exploit browser vulnerabilities (install spyware, etc), though, so, you should make sure that only trusted people can modify system messages.

Sécurité de téléchargement

 * Voir aussi :

La principale préoccupation est la suivante : Comment empêcher les utilisateurs de télécharger 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 dans le monde entier, ou bien appartenir au compte d'utilisateur limité du serveur Web. Sur un système multi-utilisateurs, il est possible à d'autres utilisateurs locaux de glisser des fichiers malveillants dans votre répertoire de téléversement (voir les notes multiutilisateur ci-dessus) If at all possible, make the directory writable only by the web server's account, don't make the directory world-writable.
 * 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.
 * Generated thumbnails and uploaded files held for overwrite confirmation may be kept in images/thumb and images/tmp without visible notice in the MediaWiki web interface. Keep an eye on their sizes as well.

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


 * Par défaut, les extensions de fichier .png, .gif, .jpg, .jpeg et webp sont en liste blanche.
 * Various executable and script extensions are explicitly blacklisted even if you allow users to override the whitelist.
 * Several known image file extensions have their types verified using PHP's function.
 * Les fichiers téléchargé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.

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, ).

For instance, an Apache .conf file fragment to do this if your MediaWiki instance is in /Library/MediaWiki/web might look something like:

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 :

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

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. For full security it is best to have uploads served from an entirely separate domain, not a subdomain, but even a subdomain will provide additional security. 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. See for configuring a different domain to serve media files.

Programmes externes

 * peut être exécuté pour résoudre les conflits de fusion des modifications.
 * If ImageMagick support for thumbnails or SVG images is enabled,  may be run on uploaded files.
 * If enabled, Math extension will call  executable, which calls ,  , and   (which calls  ).

Voir aussi

 * Général
 * meta:Category:MediaWiki authentication
 * Planning/Requirements gathering
 * Autorisation de l'utilisateur
 * Authentication
 * AuthPlugin - describes plug-in architecture for determining user identity
 * - configuration variable used by plug-in architecture
 * - authorization extensions available
 * - reseting a MediaWiki user's password
 * Surveillance de l'activité utilisateur
 * Attribution des droits d'accès par adresse IP, identité d'utilisateur
 * Access control
 * - décrit la configuration de l'architecture des droits MediaWiki par défaut
 * - divers trucs et conseils
 * - restrictions sur l'accès aux images en fonction de l'adresse IP ou de l'utilisateur
 * - extensions qui aident à la gestion des droits utilisateurs
 * Paramètres de configuration :, ,
 * Versions de MediaWiki à sécurité renforcée/Exemples d'installation
 * Alertes de sécurité
 * - comment rapporter les problèmes, recevoir les notifications
 * Template:XSS alert
 * ModSecurity
 * Détails techniques
 * database schema: User groups table, User table, Revision table, Recentchanges table
 * hooks: UserLoginForm, UserLoginComplete, UserLogout, UserLogoutComplete, UserEffectiveGroups, UserGetImplicitGroups, UserGetRights
 * code:
 * - instructions pour la conception de pages spéciales sensibles aux droits d'accès.
 * Open Web Application Security Project (OWASP)
 * Web Application Security - Modsecurity Rules (WAS)
 *  - pour les développeurs
 * - comment rapporter les problèmes, recevoir les notifications
 * Template:XSS alert
 * ModSecurity
 * Détails techniques
 * database schema: User groups table, User table, Revision table, Recentchanges table
 * hooks: UserLoginForm, UserLoginComplete, UserLogout, UserLogoutComplete, UserEffectiveGroups, UserGetImplicitGroups, UserGetRights
 * code:
 * - instructions pour la conception de pages spéciales sensibles aux droits d'accès.
 * Open Web Application Security Project (OWASP)
 * Web Application Security - Modsecurity Rules (WAS)
 *  - pour les développeurs
 * Web Application Security - Modsecurity Rules (WAS)
 *  - pour les développeurs