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 votre exécutable dans le répertoire cgi-bin de votre serveur web. CERT CA-96.11 recommande de ne placer aucun interpréteur à l'intérieur du répertoire cgi-bin. Même si le programme PHP peut être utilisé comme interpréteur indépendant, PHP a été pensé afin de rendre impossible les attaques que ce type d'installation rend habituellement possible : Accès au système de fichiers : 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, PHP refuse d'interpréter les arguments de la ligne de commande. Accès à n'importe quel 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 de l'exécutable 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 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. Si votre serveur n'a aucun document dont l'accès n'est pas restreint par un mot de passe ou un système de vérification de l'adresse IP, vous n'avez aucun besoin de ce type de configuration. Si votre serveur web ne permet pas les redirections, ou si votre serveur web n'a aucun besoin de communiquer avec le binaire PHP de manière sécurisée, vous pouvez activer la directive INI cgi.force_redirect Vous devez tout de même vous assurer que vos scripts PHP ne dépendent pas d'un appel de manière directe comme http://my.host/cgi-bin/php/dir/script.php, ou de manière indirecte, par redirection, http://my.host/dir/script.php. Avec Apache, les redirections peuvent être configurées en utilisant les directives "AddHandler" et "Action" (voir ci-dessous). La directive de configuration cgi.force_redirect évite qu'un appel direct à un script PHP avec une URL comme http://my.host/cgi-bin/php/secretdir/script.php ne soit possible. À la place, PHP analysera le fichier uniquement s'il y a eu redirection. Habituellement, la redirection est effectuée grâce aux directives suivantes dans la configuration du serveur Apache : Cette option a uniquement été testée avec Apache, et compte sur Apache pour affecter la variable d'environnement non-standard REDIRECT_STATUS pour les requêtes redirigées. Dans le cas où votre serveur web ne supporte aucune manière d'indiquer si la requête a été redirigée ou non, vous ne pourrez pas utiliser cette option de compilation. Vous devrez alors utiliser une des autres méthodes d'exploitation de la version binaire CGI de PHP, comme exposé ci-dessous. Ajouter un contenu interactif, comme des scripts ou des exécutables, dans les répertoires de documents votre serveur web, est parfois considéré comme une pratique non-sécurisée. Si, à cause d'une erreur de configuration, le script n'est pas exécuté mais affiché comme une page HTML classique, il peut en résulter une fuite de propriété intellectuelle ou d'informations liées à la sécurité, comme, typiquement, des mots de passe. En conséquence, un bon nombre d'administrateurs préfèrent mettre en place un répertoire spécial pour les scripts, qui soit uniquement accessible par le biais du binaire CGI de PHP, ce qui signifie que tous les fichiers de ce répertoire seront interprétés et jamais affichés tels quels. De plus, si vous ne pouvez pas utiliser la méthode qui permet de s'assurer que les requêtes ne sont pas redirigées, comme présentée ci-dessus, il est nécessaire de mettre en place un répertoire de scripts "doc_root" différent du répertoire "document root" de votre serveur web. Pour indiquer la racine des scripts PHP, vous pouvez utiliser la directive doc_root dans le fichier de configuration, ou vous pouvez affecter la variable d'environnement PHP_DOCUMENT_ROOT. Si cette information est renseignée, le binaire CGI de PHP construira toujours le nom de fichier à ouvrir avec doc_root et le "path information" de la requête, et vous serez donc sûr qu'aucun script ne sera exécuté en dehors du répertoire prédéfini (à l'exception du répertoire désigné par la directive user_dir - voir ci-dessous). Une autre option possible ici est la directive user_dir. Lorsque cette directive n'est pas spécifiée, seuls les fichiers contenus dans le répertoire doc_root peuvent être ouverts. Ouvrir un fichier possédant l'url http://my.host/~user/doc.php ne correspondra pas à l'ouverture d'un fichier sous le répertoire racine de l'utilisateur, mais à l'ouverture du fichier ~user/doc.php sous le répertoire "doc_root" (oui, un nom de répertoire commençant par un tilde [~]). Si la directive "user_dir" est activée, par exemple à la valeur public_php, une requête du type http://my.host/~user/doc.php ouvrira un fichier appelé doc.php dans le répertoire appelé public_php sous le répertoire racine de l'utilisateur. Si le répertoire racine de l'utilisateur est /home/user, le fichier exécuté sera /home/user/public_php/doc.php. user_dir et doc_root sont deux directives totalement indépendantes, et vous pouvez donc contrôler l'accès au répertoire "document root" séparément des répertoires "user directory". Une solution extrêmement sécurisée est de mettre l'exécutable PHP à l'extérieur de l'arborescence du serveur web. Dans le répertoire /usr/local/bin, par exemple. Le seul véritable inconvénient de cette méthode est que vous aurez à rajouter une ligne comme celle-ci : au début de chaque fichier contenant des balises PHP. Vous devrez aussi rendre les scripts PHP exécutable. En somme, traitez le fichier exactement comme si vous aviez un autre script écrit en Perl ou en sh ou en un autre langage de script qui utilise #! comme mécanisme pour lancer l'interpréteur lui-même. Pour que l'exécutable PHP prenne en compte les variables d'environnement PATH_INFO et PATH_TRANSLATED correctement avec cette configuration, la directive INI cgi.discard_path doit être activé.