<?xml version="1.0" encoding="utf-8"?>

<chapter xml:id="security.cgi-bin" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">

<title>Instalado como CGI binario</title>

<sect1 xml:id="security.cgi-bin.attacks">

<title>Ataques posibles</title>

<simpara>

Usar PHP como un binario <acronym>CGI</acronym> 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 <acronym>CGI</acronym> para crear entornos

seguros <command>chroot</command> y <command>setuid</command> para scripts.

Esta configuración usualmente involucra la instalación del binario

ejecutable de <command>php</command> en el directorio <filename class="directory">cgi-bin</filename>

del servidor web. La recomendación <link xlink:href="&url.cert;">CA-96.11</link> del CERT recomienda

que está en contra de colocar cualquiera de los intérpretes dentro de <filename class="directory">cgi-bin</filename>.

Aún si el binario de <command>php</command> puede ser usado como un intérprete independiente, PHP está diseñado

para prevenir los ataques que esta configuración hace posible:

</simpara>

<itemizedlist>

<listitem>

<simpara>

Accediendo a los ficheros del sistema: <filename

role="url">http://mi.servidor/cgi-bin/php?/etc/passwd</filename>

</simpara>

<simpara>

La consulta de información en una URL después del signo de interrogación (<literal>?</literal>) es

pasado como argumento de la línea de comandos al intérprete por la interfaz

del CGI. Usualmente los intérpretes abren y ejecutan el fichero

especificado como el primer argumento en la línea de comandos.

</simpara>

<simpara>

Cuando es invocado como un binario de CGI, <command>php</command> se niega a interpretar los

argumentos de línea de comandos.

</simpara>

</listitem>

<listitem>

<simpara>

Accediendo a cualquier documento web en el servidor: <filename

role="url">http://mi.servidor/cgi-bin/php/directorio/secreto/doc.html</filename>

</simpara>

<simpara>

Parte de la ruta de información de la URL después del nombre del binario de PHP,

<filename role="uri">/directorio/secreto/doc.html</filename> es

convencionalmente utilizado para especificar el nombre del fichero

a ser abierto e interpretado por el programa <acronym>CGI</acronym>.

Usualmente las directivas de configuración de algunos servidores web (Apache:

<literal>Action</literal>) son utilizados para redirigir peticiones a los documentos como

<filename role="url">http://mi.servidor/directorio/secreto/script.php</filename> al

intérprete de PHP. Con esta configuración, el servidor web revisa primero

los permisos de acceso a los directorios <filename

role="uri">/directorio/secreto</filename>, y después crea la

petición redirigida <filename

role="url">http://mi.servidor/cgi-bin/php/directorio/secreto/script.php</filename>.

Desafortunadamente, si la petición es proporcionada originalmente en esta forma,

no se revisan los accesos a los directorios hechos por el servidor web <filename

role="uri">/directorio/secreto/script.php</filename>, sino solamente al fichero

<filename role="uri">/cgi-bin/php</filename>. De esta forma

<filename role="uri">/cgi-bin/php</filename> cualquier usuario está habilitado a acceder

a cualquier documento protegido en el servidor web.

</simpara>

<simpara>

En PHP, las directivas de configuración en tiempo de ejecución <link

linkend="ini.cgi.force-redirect">cgi.force_redirect</link>, <link

linkend="ini.doc-root">doc_root</link> y <link

linkend="ini.user-dir">user_dir</link> 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.

</simpara>

</listitem>

</itemizedlist>

</sect1>

<sect1 xml:id="security.cgi-bin.default">

<title>Caso 1: Ficheros públicos servidos solamente</title>

<simpara>

Si su servidor no tiene ningún contenido que no esté restringido

por contraseña o control de acceso basado en IP, no hay necesidad de

estas opciones de configuración. Si su servidor web no le permite

hacer redirecciones, o el servidor no tiene una forma de

comunicar al binario de PHP que la petición es una forma segura de

petición de redireccionada la solicitud, puedes habilitar la directiva ini <link linkend="ini.cgi.force-redirect">cgi.force_redirect</link>. Usted todavía tiene que asegurarse que sus

scripts de PHP no confían en una forma o en otra para llamar el script,

ni directamente <filename

role="php">http://my.host/cgi-bin/php/dir/script.php</filename>

ni por redirección <filename

role="php">http://my.host/dir/script.php</filename>.

</simpara>

<simpara>

La redirección puede ser configurada en Apache utilizando directivas

<literal>Action</literal> y <literal>AddHandler</literal> (vea más abajo).

</simpara>

</sect1>

<sect1 xml:id="security.cgi-bin.force-redirect">

<title>Caso 2: utilizando <literal>cgi.force_redirect</literal></title>

<simpara>

La directiva de configuración <link

linkend="ini.cgi.force-redirect">cgi.force_redirect</link>

previene a cualquiera que llame a PHP

directamente por medio de una URL como esta <filename

role="php">http://mi.servidor/cgi-bin/php/directoriosecreto/script.php</filename>.

En cambio, <command>php</command> solamente lo analizará en este modo si éste se ha ido a través de

una regla directa del servidor web.

</simpara>

<simpara>

Usualmente la redirección en la configuración de Apache se hace con

las siguientes directivas:

</simpara>

<programlisting role="apache-conf">

</programlisting>

<simpara>

Esta opción ha sido probada solamente con el servidor web Apache, y

se basa en que en Apache se configure en una variable de entorno no-estándar de CGI

<envar>REDIRECT_STATUS</envar> para peticiones de redirección. Si su

servidor web no soporta ninguna forma de decirle si la petición es

directa o redirigida, usted no puede utilizar esta opción y debe usar

una de las otras formas de ejecutar la versión CGI aquí documentadas.

</simpara>

</sect1>

<sect1 xml:id="security.cgi-bin.doc-root">

<title>Caso 3: Configurando doc_root o user_dir</title>

<simpara>

Para incluir contenido activo, como scripts y ejecutables, en los

directorios de documentos del servidor web es algunas veces considerado una práctica

insegura. Si, por el hecho del algún error de configuración, los scripts

no se ejecutan y son mostrados como documentos HTML regulares, esto

podría resultar en una fuga de información de propiedad intelectual

o de información de seguridad como las contraseñas. Por lo tanto muchos Administradores de Sistemas

preferirán configurar otra estructura de directorios para scripts que sean

accesibles solamente a través del CGI de PHP, y por lo tanto siempre interpretado y no desplegado como tal.

</simpara>

<simpara>

También si el método para asegurar las peticiones no es

redirigido, como se describió en la sección anterior, no está

disponible, es necesario configurar un script doc_root que sea

diferente de la raíz del documento web.

</simpara>

<simpara>

Usted puede configurar el script de la raíz de documento de PHP en la directiva

de configuración <link linkend="ini.doc-root">doc_root</link> en el

<link linkend="configuration.file">fichero de configuración</link>, o

puede configurar la variable de entorno <envar>PHP_DOCUMENT_ROOT</envar>.

Si éste es configurado, la versión del <acronym>CGI</acronym>

de PHP siempre construirá el nombre del fichero para abrir con este

<parameter>doc_root</parameter> y la ruta de información en la petición,

de tal forma que pueda estar seguro que ningún script será ejecutado fuera de

este directorio (excepto por <parameter>user_dir</parameter> que se encuentra

más abajo).

</simpara>

<simpara>

Otra opción utilizable es esta <link

linkend="ini.user-dir">user_dir</link>. Cuando user_dir no está configurado,

lo único que controla el fichero abierto es <parameter>doc_root</parameter>.

Al abrir una URL como <filename

role="url">http://mi.servidor/~usuario/documento.php</filename> no resulta

en la apertura de un fichero bajo el directorio personal de los usuarios, pero si

un fichero llamado <filename role="uri">~usuario/documento.php</filename> debajo de

doc_root (si, un nombre de directorio que inicia con una a tilde [<literal>~</literal>]).

</simpara>

<simpara>

Si <parameter>user_dir</parameter> es configurado, por ejemplo <filename

role="dir">public_php</filename>, una petición como <filename

role="url">http://mi.servidor/~usuario/doc.php</filename> abrirá un

fichero llamado <filename>doc.php</filename> bajo el directorio

llamado <filename role="dir">public_php</filename> debajo de el directorio

personal del usuario. Si el directorio personal del usuario es <filename

role="dir">/home/usuario</filename>, el fichero ejecutado será

<filename>/home/user/public_php/doc.php</filename>.

</simpara>

<simpara>

La expansión de <parameter>user_dir</parameter> sucede sin tomar en cuenta

la configuración de <parameter>doc_root</parameter>, así que usted puede

controlar el acceso a la raíz de los documentos y el directorio de los

usuarios separadamente.

</simpara>

</sect1>

<sect1 xml:id="security.cgi-bin.shell">

<title>Caso 4: El analizador de PHP fuera del árbol de la web</title>

<para>

Una opción muy segura es poner el binario analizador de PHP en algún lugar

fuera del árbol de ficheros de la web. En <filename

role="dir">/usr/local/bin</filename>, por ejemplo. El único inconveniente

real con esta opción es que ahora tendrá que poner una línea similar a:

<informalexample>

<programlisting>

</programlisting>

</informalexample>

como la primera línea de cualquier fichero que contenga etiquetas de PHP. También

necesitará hacer que el fichero sea ejecutable. Eso significa, tratarlo exactamente

como trataría cualquier otro script de CGI escrito en Perl, sh, bash, o cualquier

otro lenguaje común de script el cual utilice <literal>#!</literal> como mecanismo

de ejecución de si mismo.

</para>

<para>

Para que PHP maneje la información correctamente de <envar>PATH_INFO</envar> y

<envar>PATH_TRANSLATED</envar> con esta configuración, La directiva ini <link linkend="ini.cgi.discard-path">cgi.discard_path</link> debe estar habilitada..

</para>

</sect1>

</chapter>