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 vous installerez l'exécutable php 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.