Manuel:Droits d'accès aux images

From mediawiki.org
This page is a translated version of the page Manual:Image authorization and the translation is 68% complete.
Outdated translations are marked like this.

Cet article concerne les administrateurs système qui souhaitent restreindre l'accès aux images et aux fichiers en se basant sur les utilisateurs et (ou) les droits des groupes d'utilisateurs.

Les fichiers téléversés sont généralement distribués directement par le serveur web, et non pas par MediaWiki. Alors qu'il existe un niveau minimal de sécurité masqué par l'encodage des chemins (comme /c/c4/...), le chemin peut être calculé facilement à partir du nom de fichier ce qui ne fournit pas de réelle protection.

Ce n'est pas une configuration recommandée. MediaWiki n'est pas conçu pour être un système de gestion de contenu (CMS - Content management system), ni pour protéger les données sensibles. Au contraire, il a été conçu pour être le plus ouvert possible. Ainsi, il ne prend pas en charge de manière inhérente une protection complète et étanche du contenu privé. Tout administrateur souhaitant utiliser cette fonctionnalité doit relire attentivement les Problèmes de sécurité avec les extensions d'autorisation.

Présentation

Par défaut, toutes les images et les fichiers téléversés sont accessibles directement par le serveur web. Si vous souhaitez donner l'accès uniquement aux utilisateurs autorisés de l'environnement MediaWiki, il faut réunir deux conditions :

  1. Le répertoire actuel doit être protégé contre l'accès direct et,
  2. MediaWiki Authorization doit être appelé en exécutant un script lorsqu'une URL contenant ce répertoire est demandée pour accèder à une image ou un fichier.

L'implémentation fondamentale nécessite :

  1. Le répertoire des images ($wgUploadDirectory ) doit être déplacé en dehors de la racine du web dans le système de fichiers, ou bien protégé
  2. Le chemin de téléversement ($wgUploadPath ) doit pointer vers img_auth.php .

Dans les deux cas, les mécanismes dépendent de la plateforme utilisée pour le serveur web. Cet article fournit des instructions détaillées pour les plateformes suivantes :

  1. Apache (la plupart des versions)
  2. Microsoft Internet Information Server (IIS), version 6.0 et supérieure

Dans toutes les instructions, on suppose que MediaWiki est installé dans /path/to.

Par exemple dans :

http://wiki.example.org/MyWiki

/path/to vaut /MyWiki

Comment fonctionne img_auth.php ?

L'autorisation pour les images fonctionne en dirigeant les requêtes pour les médias téléversés par le script img_auth.php, au lieu d'autoriser le serveur web à envoyer le fichier directement au navigateur. Ceci se fait en initialisant $wgUploadPath avec la valeur de l'emplacement ($wgUploadPath = "$wgScriptPath/img_auth.php";) du script img_auth.php plutôt que celui du répertoire de téléversement. Ainsi MediaWiki génère l'URL des fichiers avec un format similaire à http://wiki.example.org/w/img_auth.php/01/01/Example.png. Lorsque le serveur web reçoit une requête pour une telle URL, il sait qu'il doit appeler le script img_auth.php et lui passer le reste de l'URL en tant que PATH_INFO. Le script va ensuite vérifier si l'utilisateur a le droit d'accéder au fichier donné dans PATH_INFO en suivant le mécanisme classique utilisé pour gérer l'accès aux pages du wiki. Si img_auth.php détermine que l'utilisateur peut accéder au fichier demandé, il lit le contenu de ce dernier et le lui envoie comme s'il provenait du serveur web directement à partir du disque. Par contre si l'utilisateur n'a pas accès au fichier, img_auth.php renvoie l'erreur 403 classique « Access Denied » .

Configurer le téléversement des fichiers

Avant d'adopter cette configuration, il est très important que vous compreniez comment configurer le téléversement des fichiers. Veuillez prendre quelques instants pour relire et comprendre cet article - cela vous épargnera beaucoup de temps.

Prise en charge du PATH_INFO PHP

Ceci nécessite que votre configuration PHP prenne en charge PATH_INFO (beaucoup de configurations CGI ne le font pas) et que vous êtes dans le mode $wgWhitelistRead ou sinon, il n'y aura pas de point ... à moins que vous ne souhaitiez sécuriser davantage l'installlation MediaWiki; voir ci-dessous. See below.

Un autre scénario dirigé par la sécurité (uniquement pour Apache/Unix)

Même si vous ne voulez pas restreindre l'accès à vos images, vous pouvez utiliser la mécanique de img_auth.php : pour éviter les répertoires accessibles publiquement, sur lesquels le serveur web a des droits d'écriture. Bien qu'avoir un répertoire sur le serveur web accessible en écriture n'est pas dangereux en soi, ceci est la première moitié pour une attaque réussie de votre serveur web. La seconde moitié ensuite pourrait être un script exploitable (PHP) de MediaWiki lui-même ou, plus vraisemblablement, un autre script. Si l'attaquant peut exploiter le script corrompu pour téléverser ou pour générer un autre script qui va l'aider lors d'attaques ultérieures, de spamming, ou autres ... l'attaquant doit encore trouver un endroit pour y enregistrer ce script, qui soit accessible en écriture par le serveur web ... , disponible et bien connu dans le répertoire 'images' des installations standard de MediaWiki.

Une toute première mesure de sécurité pour cela, est de mettre un fichier .htaccess dans le répertoire 'images' avec le contenu suivant :

# ne pas exécuter PHP dans la zone de téléversement
php_admin_flag engine off

Par contre .htaccess ne doit pas être modifiable par le serveur web ! C'est dommage que MediaWiki ne soit pas livré avec cette restriction par défaut (au moins pas dans la version 1.6.10).

Il serait encore meilleur de déplacer le répertoire 'images' accessible en lecture, en dehors de la racine des documents, en le renommant sous un nom que l'on ne puisse pas deviner (par exemple le code de hachage MD5 de <ceQueVousVoulez>) et de distribuer les images via 'img_auth.php', de sorte que le répertoire réel ne soit jamais divulgué nulle part.

Pour faire cela, suivez les étapes ci-après :

  1. connectez-vous au shell de votre serveur web en mode ligne de commande (des actions similaires sont souvent possibles avec votre client FTP, si ce n'est pas le cas demandez à votre fournisseur de vous aider)
  2. créez le répertoire images/upload en dehors de (en parallèle de) la racine de votre document (notez le /.. à la fin du chemin) et de sorte que l'on ne puisse pas le deviner :
    cd </chemin/absolu/vers/la/racine/de/vos/documents>/..
    mkdir <nom_de_répertoire_non_devinable>
    
  3. déclarez-le accessible en lecture et écriture par le serveur web :
    chgrp <groupe_de_votre_serveur_web> <nom_de_répertoire_non_devinable>
    chmod 770 <nom_de_répertoire_non_devinable>
    
  4. créez le fichier .htaccess comme indiqué ci-dessus en mode lecture seule (un peu parano non ? car le serveur web ne vient jamais ici mais seul PHP ignorant habituellement les fichiers .ht*; et au cas où ce répertoire devrait être rendu disponible au serveur web directement) :
    cd <nom_de_répertoire_non_devinable>
    echo 'php_admin_flag engine off' > .htaccess
    chmod 444 .htaccess
    
  5. mettez à jour votre fichier de configuration LocalSettings.php : $wgUploadPath = "$wgScriptPath /img_auth.php"; $wgUploadDirectory = '</chemin/absolu/vers/la/racine/de/vos/documents>/../<nom_de_répertoire_non_devinable>'; $wgEnableUploads = true; # Nous ne voulons pas restreindre l'accès mais simplement rendre l'installation de MediaWiki plus sécurisée $wgWhitelistRead = false;

qui devrait faire ce qu'on attend sans configuration supplémentaire.

Cela devrait convenir pour tous les serveurs web qui utilisent PHP avec un module Apache. Il n'y a pas d'autre modification des fichiers de configuration Apache à faire. Par conséquent vous ne verrez jamais le chemin vers vos images, car img_auth.php intercepte tous les accès en lecture. Mais toutes vos images sont disponibles, y compris les vignettes.

Si vous utilisez CGI ou IIS, votre fidélisation (milage) peut varier.

Instructions Apache

Apache étape 1. Protéger le répertoire images de l'accès Internet

Dans votre répertoire [/path/to]/images , créez un fichier .htaccess contenant une ligne :

Deny from All
Si vous n'avez pas déplacé votre répertoire, il n'y a pas lieu de modifier $wgUploadDirectory

<span id="Apache_Step_2._Execute_Script_img_auth.php_for_all_Accesses">

Apache étape 2. Executer le script img_auth.php pour tous les accès

Apache étape 2.1. modifier $wgUploadPath dans LocalSettings.php. Pas utile si l'étape 2.2 Apache a été faite

$wgUploadPath = "[/path/to]/img_auth.php";

[/path/to] est l'URL du chemin, et non pas le chemin du fichier dans le système, donc si img_auth.php se trouve dans /usr/share/mediawiki mais est accédé par http://example.org/mediawiki/img_auth.php, la ligne lue sera :

$wgUploadPath = "/mediawiki/img_auth.php";

Vérifiez d'avoir bien commencé par une barre oblique / si img_auth.php se trouve actuellement dans votre répertoire racine. Les images ne seront pas affichées si vous oubliez de le faire. Ainsi :

$wgUploadPath = "/img_auth.php";

Apache étape 2.2. créer des alias pour exécuter img_auth.php

Cette étape est uniquement nécessaire si vous souhaitez continuer à utiliser des URLs contenant les chemins directs vers vos images. MediaWiki ne doit jamais avoir besoin de cela si vous avez terminé avec succès les mises à jour précédentes de la configuration.

Mettez à jour le fichier httpd.conf en ajoutant les deux alias suivants :

Alias [/path/to]/images/ [/path/to]/img_auth.php/
Alias [/path/to]/images [/path/to]/img_auth.php

Le second [/path/to] de chaque ligne représent le chemin absolu dans l'arborescence des fichiers, et il peut être nécessaire d'ajouter la barre oblique de terminaison à img_auth.php (c'est à dire pour obtenir [/path/to]/img_auth.php/).

Apache étape 2.3. redémarrez votre serveur Apache

Instructions Apache sans PATH_INFO avec mod_rewrite

Apache étape 1. télécharger le script cgi de prise en charge d'autorisation d'image

Si PATH_INFO n'existe pas, téléchargez le script CGI de prise en charge des droits des images. Enregistrez le script sous le nom cgi_img_auth.php dans votre répertoire MediaWiki.

Apache étape 2. Protéger le répertoire Images de l'accès Internet

Dans votre répertoire [/path/to]/images, créez un fichier .htaccess contenant une seule ligne :

Deny from All
Si vous n'avez pas déplacé votre répertoire, il n'y a pas lieu de modifier $wgUploadDirectory

Apache étape 3. Executer le script cgi_img_auth.php pour tous les accès

Apache étape 3.1. mettre à jour $wgUploadPath dans LocalSettings.php

$wgUploadPath = "[/path/to]/cgi_img_auth.php";

Apache étape 3.2. modifier .htaccess

Mettez à jour le fichier .htaccess pour qu'il ressemble à

RewriteEngine on
RewriteRule ^/path/to/images(.*)$ /path/to/cgi_img_auth.php/$1 [R]
RewriteRule ^path/to/cgi_img_auth.php/(.*)$ path/to/cgi_img_auth.php?path=/$1

Notez par ailleurs que cette étape n'est pas nécessaire avec certaines installations.

Apache - assurez la compatibilité en utilisant des URLs à jour

Si votre site web modifie les URLs via .htaccess, alors il vous faudra une exception avant de faire la réécriture de l'adaptation :

RewriteCond %{REQUEST_URI} /img_auth\.php/
RewriteRule ^ - [L]

(cela signifie : dans le cas où img_auth est appelé, arrêter les règles)

Exemple de fichier .htaccess :

RewriteEngine On
# First condition&rule:
RewriteCond %{REQUEST_URI} /img_auth\.php/
RewriteRule ^ - [L]
# Rest of rules:
RewriteCond ...
RewriteRule ...

Apache - masquer la liste des répertoires

Si vous ne souhaitez pas que les utilisateurs puissent lister votre répertoire d'images, indiquez-le dans la configuration Apache :

        <Directory /var/www/wiki/images>
                Options -Indexes
        </Directory>

Instructions IIS

L'implémentation sous IIS est plus complexe car on n'y dispose pas des possibilités du 'pipe' de Apache ou d'Unix en général. Néanmoins, avec quelques manipulations on peut faire en sorte que IIS puisse exécuter le CGI et assurer la protection.

Avertissement Avertissement : L'approche img_auth ne fonctionne qu'avec le mode ISAPI PHP sur la plateforme WIMP (Windows, IIS, MySQL, PHP). Si vous avez suivi les instructions d'installation standard pour Windows, votre wiki utilise CGI (php-cgi.exe) et vous devrez passer à ISAPI. Les instructions pour faire cela se trouvent dans l'espace de discussion. Il y a un bogue dans la manière dont php-cgi traite l'analyse syntaxique de PATH_INFO, qui provoque l'erreur CGI suivante avec certains fichiers du chemin restreint : "CGI Error: The specified CGI application misbehaved by not returning a complete set of HTTP headers" . C'est un problème PHP ou IIS, et non pas MediaWiki.

IIS étape 1. Protéger le répertoire images de l'accès Internet anonyme

Avec IIS il est important que les utilisateurs ne puissent pas accéder aux images et aux fichiers en utilisant les URLs alternatives de leur chemin de sorte à empêcher de sauter les redirections virtuelles des répertoires. C'est pourquoi il faut créer un nouveau répertoire hors de la racine de MediaWiki.

IIS étape 1.1 créer un nouveau répertoire physique

Créez un nouveau répertoire physique. Ce répertoire ne doit pas se trouver à l'intérieur d'un autre répertoire web existant, ni d'un autre répertoire web virtuel :

Exemple :

c:\inetpub\wwwroot\MyWikiImg

IIS étape 1.2 vérifiez ou configurez la sécurité des répertoires

La sécurité du répertoire doit permettre la lecture, l'écriture, la modification pour le compte des invités internet (habituellement IUSR_[nom de serveur]). Ne vous inquiétez pas, on va corriger cela dans les étapes suivantes.

IIS étape 2. exécuter le script img_auth.php pour tous les accès au répertoire image

Sous IIS ceci est réalisé en créant un répertoire virtuel de même nom que le répertoire physique (s'il n'est pas à la racine du serveur web).

IIS étape 2.1 créer le répertoire virtuel de même nom que le répertoire physique

Créez un nouveau répertoire virtuel en utilisant Start→Administrative Tools→Internet Information Services (IIS) Manager dans le service web que vous utilisez pour MediaWiki.

Pour créer le répertoire virtuel, cliquez-droit sur le service web -> New Virtual Directory...

Dans l'assistant, créez un nouveau répertoire virtuel ayant le même nom que le répertoire physique et faites le pointer vers ce répertoire.

IIS étape 2.2 rediriger le nouveau répertoire virtuel vers img_auth.php

Encore dans IIS Manager, cliquez-droit sur le nouveau répertoire virtuel → Properties et sélectionnez l'onglet 'Virtual Directory' pour modifier l'intitulé concernant l'origine qui vient maintenant d'une redirection : 'The content for this resource should come from:' en 'A redirection to a URL'. Initialisez 'Redirect To:' avec l'URL vers img_auth de votre MediaWiki.

Exemple :

http://wiki.example.org/MyWiki/img_auth.php

N'oubliez pas de cliquer sur Apply pour exécuter.

IIS étape 3 copier l'ancien répertoire image dans le nouveau

Copiez le contenu de l'ancien répertoire d'images ($ip/image) ainsi que les sous-répertoires dans le nouveau répertoire que vous avez créé.

Le dossier 'image' ne se trouvera pas dans le nouveau répertoire.

Le nouveau répertoire ne devrait pas apparaître comme :

Mauvais :

MyWikiImg
  images
    0
    1
    . . .

Bon :

MyWikiImg
  0
  1
  . . .

IIS étape 4 rediriger le traitement des images MediaWiki

IIS étape 4.1 modifier $wgUploadPath dans LocalSettings.php

$wgUploadPath = "[NewVirtualDirPath]";

Exemple :

$wgUploadPath = "/MyWikiImg";

IIS étape 4.2 modifier $wgUploadDirectory dans LocalSettings.php

$wgUploadDirectory = "[NewVirtualDirImages]";

Exemple :

$wgUploadDirectory = "D:\Inetpub\wwwroot\MyWikiImg";

IIS étape 4.3 redémarrer votre service web IIS

IIS étape 4.4 PATH_INFO IIS problématique

Si votre installation ne fonctionne pas, c'est peut-être que img_auth.php nécessite que le serveur renvoie PATH_INFO pour savoir exactement à quel fichier vous souhaiter accéder (par exemple tout ce qui suit le répertoire virtuel dans l'URL).

Il existe plusieurs articles et conseils sur le fait que certaines versions de IIS peuvent interdire les variables serveur PATH_INFO et PATH_TRANSLATE 'pour des raisons de sécurité'. Ce problème n'est pas apparu chez nous avec le serveur à jour et les patchs actuels (IIS 6.0) mais il a été observé avec IIS 4.0 (et peut-être les versions antérieures), que vous pourrez investiguer si img_auth.php ne fonctionne pas.

L'article complet de la base de connaissance se trouve sur Using PATH_INFO and PATH_TRANSLATED from CGI Applications. Cet article vous indique la manière d'exécuter un programme écrit en MS Visual Basic (il est possible que vous deviez charger CScript).