|
|
Binaires CGI
Faiblesses connues
Cas 1: Tous les fichiers sont publics
Cas 2: utilisation de la directive de compilation --enable-force-cgi-redirect
Cas 3: Utilisation du "doc_root" ou du "user_dir"
Cas 4: L'exécutable PHP à l'extérieur de l'arborescence du serveur
|
Utiliser le PHP comme un CGI exécutable vient
la majorité du temps du fait que l'on ne veut pas l'utiliser comme un module
du serveur web, (comme Apache), ou bien que l'on souhaite l'utiliser en
combinaison d'un CGI complémentaire, afin de
créer un environnement de script sécurisé (en utilisant
des techniques de chroot ou setuid). Une telle décision signifie
habituellement que vous installez votre exécutable dans le
répertoire cgi-bin de votre serveur web.
CERT CA-96.11 recommande effectivement de
placer l'interpréteur à l'intérieur du répertoire
cgi-bin. Même si le binaire PHP peut être utilisé comme
interpréteur indépendant, PHP a été
pensé afin de rendre impossible les attaques que ce type
d'installation induit.
-
Accès au système de fichier:
`http://ma.machine/cgi-bin/php?/etc/passwd'
Lorsque la requête est passée dans une url, après le point
d'interrogation (?), elle est envoyée à l'interpréteur
comme une ligne de commande par l'interface CGI. Habituellement,
l'interpréteur ouvre le fichier spécifié et
l'exécute.
Lorsqu'il est invoqué comme exécutable CGI, le PHP refuse
d'interpréter les arguments de la ligne de commande.
-
Accès d'un document web sur le serveur :
`http://my.host/cgi-bin/php/secret/doc.html'
Le "path information" dans l'url, situé juste après le nom
du binaire PHP, `/secret/doc.html' est
utilisé par convention pour spécifier le nom du fichier
qui doit être ouvert et interprété par le programe
CGI. Habituellement, des directives de configuration
du serveur web (pour le serveur Apache: Action) sont utilisées pour
rediriger les requêtes afin d'obtenir un document
`http://my.host/secret/script.php' par
l'interpréteur PHP. Dans une telle configuration, le serveur web
vérifie d'abord s'il a accès au répertoire
`/secret', et après cette
vérification redirige la requête vers
`http://my.host/cgi-bin/php/secret/script.php'.
Malheureusement, si la requête est faite directement sous cette forme,
aucune vérification d'accès n'est faite par le serveur web
pour le fichier `/secret/script.php',
mais uniquement pour le fichier `/cgi-bin/php'.
De cette manière, n'importe quel utilisateur qui peut accéder
au fichier `/cgi-bin/php' peut aussi
accéder aux documents protégés sur le serveur web.
Avec le PHP, l'option de compilation
--enable-force-cgi-redirect
et les options d'exécution doc_root
et user_dir peuvent être
utilisées pour prévenir ce genre d'attaques, si des restrictions
d'accès sont appliquées sur les documents du serveur. Voir
ci-dessous pour des explications plus complètes sur les
différentes combinaisons.
|
|
|
|