Utiliser PHP comme un exĂ©cutable CGI est une possibilitĂ© pour les cas oĂč l'on ne veut pas l'utiliser comme un module du serveur web (comme Apache), ou bien lorsque l'on souhaite l'utiliser en combinaison avec un gestionnaire 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 l'exĂ©cutable php sera installĂ© dans le rĂ©pertoire du serveur web cgi-bin. Le conseil de sĂ©curitĂ© CERT » CA-96.11 recommande de ne pas placer d'interprĂ©teurs dans le rĂ©pertoire cgi-bin. MĂȘme si le binaire php peut ĂȘtre utilisĂ© comme interprĂ©teur autonome, PHP est conçu pour prĂ©venir les attaques que cette configuration peut rendre possibles :
?), 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, php refuse
d'interpréter les arguments de la ligne de commande.
Action) sont utilisées pour
rediriger des requĂȘtes vers des documents comme
http://my.host/secret/script.php vers
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 redirige ensuite 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 à n'importe quel document protégé sur le serveur web.
Avec PHP, les options d'exécution
cgi.force_redirect,
doc_root et
user_dir peuvent ĂȘtre
utilisées pour prévenir ce genre d'attaque, 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.