Faiblesses connues

Utiliser 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 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 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, 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.php Le "path information" dans l'url, situ� juste apr�s le nom de l'ex�cutable PHP, /secret/doc.php 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 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.