Seguridad en include()

#1 (**permalink**) 18/02/2004, 05:00

Hola a todos,

Tengo un pequeño gran problema. Resulta que quiero hacer una pagina imprimir.php a la cual se la pasen dos parametros por la URL que van a ser el titulo de la pagina y el fichero a mostrar.

Suponiendo que el codigo html de una pagina lo tengo en fichero.dat y quiero imprimir dicho fichero, entonces creo un link como este
http://miserver/imprimir.php?titulo=...le=fichero.dat
de tal forma que el fichero imprimir.php haga un include del fichero pasado por referencia.

Digamos que esta implementacion así como esta descrite es una chapuza grandísima xq si alguien ponde fichero=/etc/passwd o fichero=../../../../etc/passwd ...pues ya os imaginais el resultado de esta maravilla

Alguna posible solucion a este problema, vamos que como debo tratar el parametro de entrada file antes de hacer el include, para evitar esta "cagada".

Un saludo

Cluster · #2 (**permalink**) 18/02/2004, 07:01

Pues tienes vários métodos ...

1) usar un array asociativo (o Base de datos u otros médios) para almacenar la correspondencia "indice" -> "archivo (ruta/nombre). (podría servir hasta una estructura de control tipo switch() si son pocas las opciones de archivos a manejar)

De esta forma validas sólo los indices que tienes en tu array (BD .. etc) donde deberías incluir la lista completa de archivos que puedan ser accedidos por tu script.

2) Usar rutas absolutas completas y "limpiar" de la cadena (variable externa que usas para llamar a tu archivo) las secuencias de caracteres tipo: "../" y similares.

Esa limpieza se puede hacer con funciones de cadenas (str_replace() etc ..) o incluso mejor con un patrón de Expresion regular.

Ejemplos y várias propuestas similares tienes en los comentarios de los usuarios de la función include()

http://www.php.net/manual/en/function.include.php

Un saludo,

josemi · #3 (**permalink**) 18/02/2004, 07:08

Hola,

Solucion 1: si conoces la lista de ficheros que vienen en ese parametro, pon esa lista en un array, compruebas si el parametro esta en el array, y si no esta le mandas una sorpresa:

Código PHP:

  $ficheros=array("doc1.html","doc2.dat");

if (!in_array($_GET['file'],$ficheros)) {

  echo "INTRUSO, INTRUSO! Mandando bomba digital ;=)";

  exit;

}

Quien dice un array, dice una base de datos. Y quien dice que el parametro es el nombre del fichero, dice que es la clave de un indice de un array asociativo.

Solucion 2: si el parametro puede ser un nombre de fichero, y no puede ser una ruta, lo que puedes hacer es coger solo el nombre del fichero del parametro. Mira la funcion basename() (www.php.net/basename).

Solucion 3: si en el parametro puede venir nombre y ruta, tendrias que asegurarte que la ruta apunta a un directorio permitido. Para hallar el verdadero path, puedes usar la funcion realpath() (www.php.net/realpath). Eso resolvera todos los .. del parametro. Solo tendrias que comprobar que el resultado esta dentro de tus directorios permitidos.

Saludos.

Cluster · #4 (**permalink**) 18/02/2004, 07:14

Jeje ..y yo liandome con str_replace() o expresioens regulares .. No le había pretado suficiente atención al realpath() ..

Un saludo,

#5 (**permalink**) 18/02/2004, 07:14

lo que busco es la solucion 2 de cluster.. eso si limpiar la cadena o utilizar expresiones regulares, me va a costar un poco xq estoy un poco pez, si teneis algo de info pues sabeis... de todas formas buscare info al respecto y cuando lo obtenga pongo la solucion

Y la opcion 3 de josemi tambien se ajusta a lo que quiero

Jugare con ambas soluciones y ya os dire

Muchas gracias a los dos
P.D.: Me podeis ofrecer algun link donde hable de tratar cadenas o el uso de expresiones regulares (hata ahora lo único que he tocado en esto es el archivo httpd.conf para evitar servir ficheros con determinados tokens. Y lo que se es esto
http://desaweb.forosdelweb.com/s/msg183293.html )

Un saludo

Cluster · #6 (**permalink**) 18/02/2004, 07:20

Usa la opción 3 de josemi .. para tu caso es la más idonea y simple de implementar (y no por ello menos segura).

El tema de "Expresiones regulares" .. si bien no es própio de PHP, aquí te dejo un tutorial sobre el tema aplicado a PHP:

http://www.ignside.net/man/php/regex.php

Sobre el tema de manejo de cadenas (stings):
http://www.php.net/manual/en/ref.strings.php

Un saludo,

#7 (**permalink**) 18/02/2004, 07:24

Joder, ni mi madre me quiere tanto y tan rapido cuando la pido algo

Muchas gracias !!!!!!!!

#8 (**permalink**) 18/02/2004, 10:15

Bueno pues creo que ya tengo una solucion, a ver que os parece??
Lo que quiero es http://miserver/imprimir.php?ARG=El_fichero_a_imprimir

Y este es el codigo

$cfg_rootWeb=$_SERVER['DOCUMENT_ROOT'];
// Compruebo si la pagina ha sido cargada con argumento o no
if (array_key_exists("ARG", $HTTP_GET_VARS))
{
// Tratamos la cadena
$fichero=$cfg_rootWeb ."/" . $HTTP_GET_VARS["ARG"];

//Una posible solucion con expresion regular (no debe contener "../")
//if ( file_exists($fichero) ) AND !preg_match("#^\.\./#",$fichero) ) include($fichero);

// Otra forma con realpath(): Obtengo la ruta del fichero absoluta, es decir desde la raiz
// y sin cosas como "../"
$fichero=realpath($fichero);

//Ahora comprobamos que la ruta del fichero esta dentro de espacio que queremos
//Obtenemos la ruta
$rutaFichero=dirname($fichero);
// Y comprobamos que dicha ruta pertenece al document root
if (strncmp ( realpath($cfg_rootWeb), $fichero, strlen(realpath($cfg_rootWeb)))== 0)
{ //Ahora debemos comprobar que el fichero realmente exista
if (file_exists($fichero)) include ($fichero);
else echo "Fichero no encontrado";
}
else //No tiene la ruta del document root
{
echo "No hagas cosas feas!!! <br>";
}

}

#9 (**permalink**) 18/02/2004, 15:41

Hola otra vez,

Despues de haber dejado la pagina funcionando y publicada, me acaba de surgir una duda: sabeis si la funcion realpath traduce una ruta en la cual exista "../" pero codificada usando URL Encoding (RFC 1738) a la propia cadena "../" y luego la filtra...o por el contrario eso se lo "comería" y por tanto vuelvo a tener el mismo problema en mi implementacion, pudiendo navegar por el arbol de directorios??

Yo de todas formas mañana podre hacer las pruebas y os comentare los resultados.

Despues de esta duda me surge una nueva pregunta: ¿hay alguna forma que "enjaular" al PHP a una ruta y se solo pueda hacer cosas dentro de esa ruta??

Un saludo

josemi · #10 (**permalink**) 18/02/2004, 15:49

Por configuracion, open_basedir: http://www.php.net/manual/en/feature...i.open-basedir

Saludos.

<editado>Cluster, parece que hoy soy medio segundo mas rapido que tu contestando

</editado>

Cluster · #11 (**permalink**) 18/02/2004, 15:49

Con la directiva de configuración de PHP (php.ini):
open_base_dir

PHP sólo podrá acceder desde el directorio que ahí indiques hacia abajo. Eso afectará a las funciones como include() .. fopen() y todas las que accedan al sistema de archivos.

Un saludo,

#12 (**permalink**) 18/02/2004, 16:07

Pues como siempre gracias a los dos

Preguntas:

1.- Respecto a la implementacion que he puesto, alguna critica, mejora o algo??

2.- Respecto a lo del URL Encoding de realpath() sabeis algo??

3.- Digamos que lo del open_base_dir me ayuda algo, pero no del todo ya que tengo varias webs en el apache con el virtual host, es cierto que todas dependen de la misma ruta i.e. /var/www, con lo cual si pongo el open_base_dir a esa ruta el atacante no podría navegar por el arbol de directorios del sistema, pero si por la "webs vecinas". Hay alguna forma de hacer esto"dinanico" o "flexible" o coso se pueda calificar esto??

Un saludo,
P.D.: Por cierto, algun dia me tendreis que contar como coño se llega a poder responder a tantos post como vosotros 5000 y 12000 contribuciones son la leche... y encima me las creo xq cada vez que pongo un post me contestais... pues eso que sin animo de pelotear lo ya peloteado...que sois la leche.

Nos vemos

Cluster · #13 (**permalink**) 18/02/2004, 16:21

1) .. Yo no lo he probado .. en principio se "vé" bien .. pero como todo tema de seguridad hay que testearlo bien antes de estar seguro de algo (y ni así .. llegará otro personaje que sepa más que uno y nos tirará por tierra toda nuestra seguridad xDD)

2) Ni idea .. pero ya sabes . .prueba con los &nosecuantos para codificar el URL y observa como se comporta la funcioncita ..

3) .. el open_basedir se puede ajustar para cada uno de tus sitos de tu servidor virtual. Puedes hacerlo en la definición del "virtual host" o bien con .htaccess para que sólo afecte esa configuración a ese servidor virtual (esa es la grácia de los servidores virtuales .. que pueden trabajar de forma independiente y compartiendo algunos otros recursos o configuración).

De todas formas .. la forma más "flexible" pero tal vez no tan segura sería la que implementastes a nivel "código" ..

Un saludo,

#14 (**permalink**) 18/02/2004, 16:32

Hola,

En respecta a mi tercera cuestion he visto dos cosas:

La primera es que debe leer con mas atencion, ya que cuando hable de open_baserdir al final pone "Note: Support for multiple directories was added in 3.0.7. " como lo cual puedo poner todos mis virtual host...lo que pasa que claro esto sería comun a todos, con lo cual no se soluciona lo de coger cosas de "webs vecinas"

La otra cosa que he visto es que en el hhtpd.conf de apache se puede poner esa variable para cada directorio que deseemos, en mi caso para cada virtual host.
Si mi interpretacion es correcta esta sería la mejor solucion, no???

<Directory /docroot>
php_admin_value open_basedir /docroot
</Directory>

#15 (**permalink**) 18/02/2004, 18:38

Hola, tras unas horitas trasteando he llegado a esto:

Con el safe_mode + open_basedir + safe_mode_include_dir se soluciona que los includes no salgan fuera de las rutas definidas, pero si pueden acceder a las "web vecinas"

Poniendo en el httpd.conf en cada virtual host:
<Directory "/var/www/host.example.com/">
php_admin_value open_basedir "/var/www/host.example.com/"
</Directory>
Se evita el problema de las webs vecinas

Por tanto con la suma de ambos metodos ==> objetivo cumplido

Me falta probar lo del url encoding... pero eso lo dejamos para mañana que hay que irse a dormir

Cluster · #16 (**permalink**) 19/02/2004, 06:16

Ojalá todo el mundo (incluido ISP's que dán servcios de hosting) configurasen PHP así (con el open_base_dir para su sitio sólo sobre todo cuando se usa hosting "compartido").

Te "asustarías" al ver la cantidad de servicios de hosting que tienen fallas de seguridad por ese motivo (y luego le hechan la culpa a "PHP" cuando es culpa de mala configuración por parte del administrador de ese servidor de turno ...)

Un saludo,

josemi · #17 (**permalink**) 19/02/2004, 06:27

Si, es una pena que algunos hosting no se den una vuelta por ini_set() (www.php.net/ini_set) para saber donde se pueden especificar las directivas de PHP.

Pero tambien es asombroso que haya hostings que no sean capaces de dejarte acceso a un subdirectorio por encima del raiz del sitio.

Por muy buena que sea una caja fuerte, si pones como contraseña 1234 creo que no se puede confiar en que no la habra nadie

Saludos.

PD: Luego hay hostings con admin muy capaces, y la gente se queja que son caros. La calidad se paga.

#18 (**permalink**) 19/02/2004, 07:40

Ya jugamos a "depurar" hace unos dias lei un articulo sobre las vulnerabilidades mas comunes en las aplicaciones hechas en PHP. La conclusion final de este articulo fue:

set register_globals off
set safe_mode on (y todas sus demas variables...)
set open_basedir
set display_erros off
set log_errors on
set allow_url_fopen off

recomendais alguna cosita mas a tener en cuenta, o disponeis de una plantilla php.ini a seguir??

Un saludo

Cluster · #19 (**permalink**) 19/02/2004, 07:47

Basicamente serían esas ... como para un servidor compartido y cuando vas a ofrecer servicios de hosting por ejemplo que no sabes que va entrar a ese servidor.

Para "intranets" por ejemplo donde tienes el control .. ahí puedes tener algo más de "manga ancha" y por ejemplo dejar a ON el allow_url_fopen ..

Pero, basicamente todo lo que ahí está a "OFF" se puede trabajar igualmente .. sólo que el método de implementarlo cambiará en algunas cosas.

Un saludo,

josemi · #20 (**permalink**) 19/02/2004, 08:08

Desde el punto de vista de un hosting, tambien es interesante una directiva que permite especificar una serie de funciones para que no se puedan usar. Ahora no recuerdo cual es, debe tener que ver con safe_mode. Porque desactivar url_fopen, pero permitir fsockopen(), como que casi da lo mismo.

Tambien seria bueno revisar las configuraciones de las sesiones. Por defecto se almacenan en el /tmp del sistema, las de todos los sitios. Ahora mismo no se si es posible, pero creo que un "vecino" de hosting podria "robar" el SID y acceder a los datos de tus sesiones (obviamente, no voy a poner aqui como creo que se podria hacer; de igual forma que prometo que no lo he hecho nunca, aunque ahora que lo pienso, quizas algun dia lo haga para valorar su riesgo real).

De la misma forma, tambien se deberia repasar todas las directivas que impliquen recursos compartidos entre los virtualhost.

Ademas de configurar PHP, tambien hay que tener en cuenta la configuracion de Apache (o el servidor web), el sistema operativo y el motor de base de datos.

En definitiva, que un hosting no lo puede montar el carnicero con un curso de dia y medio en administracion de servidores.

Saludos.

#21 (**permalink**) 19/02/2004, 08:23

Josemi la directiva para deshabilitar ciertas funciones es disable_functions, tb esta disable_classes muy interesante... digamos que al final configure el safe_mode enterito ... ya que nos ponemos...

Respecto al realpath y el url encoding...dios que bonito: Esto lo llaman Directory traversal, es decir llegar a directorios por debajo.

Bueno pues he hecho un pequeño ejemplo y aqui los resultados:

$fichero=$cfg_rootWeb ."/" . $HTTP_GET_VARS["ARG"];
echo "Esto es lo introducido concatenado con el root document: " . $fichero . "<br>";
$fichero=realpath($fichero);
echo "Esto es lo que devuelve el realpath despues de tratarlo: " . $fichero . "<br>";

Y al meter la siguiente entrada en la url:

http://misitio/prueba.php?ARG=%2e%2e...%2e/etc/passwd

me devuelve esto:

Esto es lo introducido concatenado con el root document: /var/www/misitio/../../../../../../etc/passwd
Esto es lo que devuelve el realpath despues de tratarlo: /etc/passwd
You must not do it!!! (esto es una comprobacion mia para saber si lo que quiere es usuario, yo quiero realmente darselo...

Conclusion: realpath() descadifica la cadena y luego la trata --> Por tanto una brecha menos.

Un saludo

P.D: Os vais a reir, pero llevo dos semanas intentanto hacer un portal de autentificacion (cluster creo que ya sabe de lo que hablo) y aún no he empezado casi con el codigo...solo se lo que no debo hacer...pero no que lo que hago sea lo correcto...menudo lio.
Creo que a este "carnicero" le queda por cortar mucha carne

Saludos.

P.D.2: Vosotros podriais cambiar el nombre del post a uno mas generico de seguridad...ya que al final el tema se esta desviando un poquito... pero creo que para bien

Bye

#22 (**permalink**) 19/02/2004, 09:14

una cosilla que creo que se puede salir del tema pero bueno:

he leido que no es muy bueno que MySQL este disponible remotamente y para ello comentan que se configure MySQL para que esuche en 127.0.0.1 (loopback) mediente bin-address en el my.cnf. La pregunta es esto tiene alguna implicacion negativa para el phpMyAdmin?? (todo esta corriendo en LINUX)

josemi · #23 (**permalink**) 19/02/2004, 09:21

127.0.0.1=loopback=localhost

Asi que solo permite conexiones desde localhost, es decir, el servidor donde esta instalado MySQL.

Asi que si usas en tu mysql_connect() localhost como host, no creo que tengas problemas.

Saludos.

PD: Si usas phpMyAdmin, tambien deberas configurar esa aplicacion de la forma mas segura posible

#24 (**permalink**) 19/02/2004, 09:30

el phpmyadmin directamente va a ir en un virtual host con https y con autentificacion basada en apache, para que no se pueda entrar, y digamos que el que entra debe saber lo que hace...a no ser que se cuele alguien...que todo es posible.

Salu2

josemi · #25 (**permalink**) 19/02/2004, 09:41

Hombre, se supone que el sistema es seguro si solo se puede entrar por donde se deja. Otra cosa es que le "roben" el user/pass al usuario y entren.

Saludos.

PD: Si se quiere tener un servidor 100% seguro, apagalo, desenchufalo de internet, y metelo en un bloque de hormigon que sea usado como base para un silo de misiles.

Cluster · #26 (**permalink**) 19/02/2004, 10:22

Sobre la configuración de Msyql .. puedes crear usuarios y a cada uno decirle dese que HOST puede entrar .. sean locales o remotos (y dentro del remoto .. a una(s) IP(s) concretas o bien a todo HOST % ...).

A mi por ejemplo cara a "usuario" de servicio de hosting me gustan las cuentas de mis BD con acceso remoto .. así las administro con mis própios GUI's (por ejemplo basados en windows ..) sin tener que acudir al phpMyadmin u otro administrador que coloques en tu sitio .. (no obastante debes tener un GUI basado en la web por defecto ..)

Un saludo,

#27 (**permalink**) 19/02/2004, 10:45

Hola,

Al final he encontrado un referencia muy buena (bajo mi opinion) para crear portales web con sistema de autentificacion basado en PHP, con ayuda de MySQL y con un la implementación de un sistema de descargas como el que yo quiero montar.

El documento en cuestion de unas 400 paginas se encuentra en http://www.rs-labs.com/papers/PFC.pdf y su lectura es muy amena.

Es del mismo autor que el articulo "Boinas negras: una solución al concurso" (tb descargable desde esa web), otro doc increiblemente bueno, por lo menos para mi ya que aprendi muchas cosas...o por lo menos las conocí.

Un saludo

#28 (**permalink**) 19/02/2004, 17:48

Hola,

En un mensaje privado con Cluster yo le habia comentado que en la pagina de autentificación al portal iva a hacer esto:

Ya he visto una cosa que no me gusta, enviar las contraseñas en texto plano desde el navegador del usuario. Yo voy a mandar un javascript en la pagina para que el usuario cuando escriba la contraseña, su javascript la pase a MD5 y luego la envie al servidor...y cositas como esas.

Y Cluster me respondió con esto:

No te lies con javascript .. que seguirá siendo igual de inseguro .. Usa SSL (Secure Socket layer) que para eso está. Encripta los datos que viajan entre el cliente y el servidor, es un standar de encriptación de 128 bits y es soportado por la mayoría (todos) los navegadores de hoy en dia. Eso es un módulo que tendras que instalar en tu servidor (HTTP, Apache) y si quieres que sea "confiable" a su vez tendas que registrar un certificado para ese servidor SSL. Esta capa de seguridad .. actua de forma transparente para tu programación PHP (y en general para cualquier lenguaje de programación que uses en tu servidor .. sea Perl, u otros ..). Los datos los recibe el servidor .. el los desencripta y se los pasa a PHP como si de un dato cualquiera se tratase ..

#29 (**permalink**) 19/02/2004, 17:55

Bueno en respuesta a lo que me escribio Cluster respecto al javascript quiero hacer una aclaración:

De momento no me interesa cifrar toda la información de peticiones/respuestas del portal, ya que lo único que quiero es que el portal sea robusto... lo de montar un https para un simple portal de usuarios me parece bastante (eso lo montare para el phpMyAdmin)

Yo lo que quiero evitar es que cuando el usuario rellene su nombre de usuario/contraseña la contraseña no viaje como texto plano si no que antes de ser enviado el POST esta contraseña sea pasada por una función MD5() la cual estará en la propia pagina de ingreso al portal.

...pero ya que hemos hablado de SSL... quiero aprender un poco. Ahora tengo montado un virtual host:443 sobre ssl y cuando me conecto me sale el típico mensaje qu si acepto el certificado. Me comentaron que para que no salga esto debo tener un certificado emitido por una empresa que se dedica a ello. La pregunta es: como se obtienen y cuanto cuestan mas o menos...ya que si el coste es "despreciable para una pyme" lo podría proponer... pero si se dispara mi jefe me va a decir...."mu bonito pero mu caro"

Un saludo

#30 (**permalink**) 19/02/2004, 17:57

si alguien lee mis post que no se ria mucho con mis faltas de ortografias, ya que he reliado a veces algo mio y ....dios hay algunas que hacen daño