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.
 * If you require  for another web application, consider enabling it selectively, only for the virtual host or subdirectory that requires it.
 * MediaWiki should be safe even if this is on; turning this off is a precaution against the possibility of unknown vulnerabilities.
 * Désactivez  sauf si vous en avez particulièrement besoin.
 * Remote PHP code execution vulnerabilities may depend on being able to inject a URL into a  or  . If you don't require the use of remote file loading, turning this off can prevent attacks of this kind on vulnerable code.
 * MediaWiki may require this setting to be on for the Lucene search extension, the OAI harvester extension, the TitleBlacklist extension, and certain uses of Special:Import in 1.5. It should not however be required in a typical installation.
 * MediaWiki should be safe even if this is on; turning this off is a precaution against the possibility of unknown vulnerability.
 * 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

Alternatively, you could add this apache directive to turn off register_globals on a per-directory basis:

php_flag register_globals off

Then restart Apache to reload the changes by  or   (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
In general, you should keep access to your MySQL or MariaDB database to a minimum. If it will only be used from the single machine it's running on, consider disabling networking support, or enabling local networking access only (via the loopback device, see below), so the server can only communicate with local clients over Unix domain sockets.

If it will be used over a network with a limited number of client machines, consider setting the IP firewall rules to accept access to TCP port 3306 (MySQL/MariaDB's port) only from those machines or only from your local subnet, and reject all accesses from the larger internet. This can help prevent accidentally opening access to your server due to some unknown flaw in the database server, a mistakenly set overly broad GRANT, or a leaked password.

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

If LocalSettings.php has leaked
If LocalSettings.php has leaked to the public, reprotect it and:


 * 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
 * Monitoring user activity
 * Assignment of access rights by IP, user identity
 * Access control
 * - describes configuration of the default MediaWiki rights architecture
 * - divers trucs et conseils
 * - restrictions sur l'accès aux images en fonction de l'adresse IP ou de l'utilisateur
 * - extensions that assist in user rights management
 * Paramètres de configuration :, ,
 * Security-enhanced MediaWiki versions/sample installations
 * 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 for designing access rights-aware special pages.
 * 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 for designing access rights-aware special pages.
 * 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