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, 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
Envisagez le déplacement du mot de passe de la base de données ou d'autres données potentiellement sensibles, de  vers un autre fichier situé ailleurs qu'à la racine des documents web, et d'inclure ce fichier de   (en utilisant  ). 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èe équivalente, en modifiant  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  ), 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.

Initialiser DocumentRoot à /dev/null
Une option plus sécurisée pour le serveur web Apache est de faire pointer le  vers un répertoire vide ou non existant, puis d'utiliser les directives   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  explicitement vers un répertoire spécifique, puis qui nécessitent un ou plusieurs fichers source. Par exemple :

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 :

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) 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  et   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.
 * Divers exécutables et extensions de script sont explicitement mises en liste noire même si vous autorisez les utilisateurs à modifier la liste blanche.
 * Plusieurs extensions connues de fichiers image ont leut type vérifié en utilisant la fonction PHP.
 * 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, ).

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

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. 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 pour configurer un domaine différent pour desservir les fichiers média.

Programmes externes

 * 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,  peut être exécuté sur les fichiers téléversés.
 * Si activé, l'extension Math appellera l'exécutable, qui appellera  ,  , et   (qui appelle  ).

Voir aussi

 * Général
 * Paramètres de configuration : Accès
 * meta:Category:MediaWiki authentication
 * Planification / collecte des besoins
 * Autorisation de l'utilisateur
 * Authentication/AuthPlugin - définit l'architecture des greffons pour déterminer l'identité de l'utilisateur
 * - paramètre de configuration utilisé par l'architecture des greffons
 * - extensions d'autorisation disponibles
 * - 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
 * FAQ/Utilisateur initial non créé par l'installeur
 * FAQ/Anti-spam
 * - 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
 * 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
 * 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