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 la 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é.

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  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 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.
 * En initialisant  dans votre my.ini (sous la section  ) 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   à 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  s'il a été également divulgué
 * 2) Modifiez quelques lettres dans
 * 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
 * 2) Remplacez  par une chaîne aléatoire différente de lettres et de chiffres
 * 3) Faites un  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 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  initialisé dans votre. Expérimentez avec cela comme vous le souhaitez.

Si vous travaillez pour améliorer la sécurité, gardez à l'esprit que  utilise le répertoire courant comme base. Cela signifie que la seule définition de votre  peut ne pas contribuer à améliorer la sécurité de votre 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é des téléversements

 * Voir aussi :

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 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é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.
 * 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é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.

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
 * - réinitialisation du mot de passe utilisateur MediaWiki
 * 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