Binaires CGI
Under possible attacks, there are attacks on the php file themselves. Some php viruses, (injecktor and variations) scan the visible directory tree for php and/or html files, then inject code (such as spam-ware to generate fraudulent page hits) into otherwise harmless and useful .php scripts. One way to block this is by using open_basedir to restrict the visible file system directories to directory tree(s) which do NOT contain any .php scripts. (see doc page "Description of core php.ini directives" Note under open_basedir to tighten open_basedir scope from /www/ which would contain .php scripts to /www/tmp/ which would protect any scripts in /www/ from modification.) If the php.ini is outside the open_basedir tree, than a malware php script has no way to alter the core web site files, even if it were succesfully uploaded via ftp or other mechanism. The damage done by the spam-ware may seem trivial, but as browsers and virus programs eventually recognize the spam-ware the web site becomes effectively completely blocked and un-browsable.
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 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 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 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 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, les options d'exécution cgi.force_redirect, 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.
add a note
User Contributed Notes
Faiblesses connues
bill1 at nospam dot windhome dot com
04-Feb-2012 09:48