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.
Ataques posibles
Usar PHP como un binario CGI es una opción para configuraciones que por alguna razón no desean integrar PHP como un módulo dentro del software de servidor (como Apache), o usarán PHP con diferentes tipos de envoltorios CGI para crear entornos seguros chroot y setuid para scripts. Esta configuración usualmente involucra la instalación del binario ejecutable de PHP en el directorio cgi-bin del servidor web. La recomendación » CA-96.11 del CERT recomienda que está en contra de colocar cualquiera de los intérpretes dentro de cgi-bin. Aún si el binario de PHP puede ser usado como un intérprete independiente, PHP está diseñado para prevenir los ataques que esta configuración hace posible:
- Accediendo a los ficheros del sistema: http://mi.servidor/cgi-bin/php?/etc/passwd La consulta de información en una URL después del signo de interrogación (?) es pasado como argumento de la línea de comandos al intérprete por la interface del CGI. Usualmente los intérpretes abren y ejecutan el fichero especificado como el primer argumento en la línea de comandos. Cuando es invocado como un binario de CGI, PHP se rehusa a interpretar los argumentos de línea de comandos.
- Accediendo a cualquier documento web en el servidor: http://mi.servidor/cgi-bin/php/directorio/secreto/doc.html Parte de la ruta de información de la URL después del nombre del binario de PHP, /directorio/secreto/doc.html es convencionalmente utilizado para especificar el nombre del fichero a ser abierto e interpretado por el programa CGI. Usualmente las directivas de configuración de algunos servidores web (Apache: Acción) son utilizados para redirigir peticiones a los documentos como http://mi.servidor/directorio/secreto/script.php al intérprete de PHP. Con esta configuración, el servidor web revisa primero los permisos de acceso a los directorios /directorio/secreto, y después crea la petición redirigida http://mi.servidor/cgi-bin/php/directorio/secreto/script.php. Desafortunadamente, si la petición es proporcionada originalmente en esta forma, no se revisan los accesos a los directorios hechos por el servidor web /directorio/secreto/script.php, sino solamente al fichero /cgi-bin/php. De esta forma /cgi-bin/php cualquier usuario está habilitado a acceder a cualquier documento protegido en el servidor web. En PHP, las directivas de configuración en tiempo de ejecución cgi.force_redirect, doc_root y user_dir pueden ser utilizadas para prevenir este ataque, si el árbol de documentos del servidor tiene cualquiera de estos directorios con restricciones de acceso. Véase más abajo para una explicación completa de las diferentes combinaciones.
