Seguridad en PHP

[Gydion]

Introducción

 PHP es un poderoso lenguaje e intérprete, ya sea incluido como parte de un servidor web en forma de módulo o ejecutado como un binario CGI separado, es capaz de acceder a archivos, ejecutar comandos y abrir conexiones de red en el servidor. Estas propiedades hacen que cualquier cosa que sea ejecutada en un servidor web sea insegura por naturaleza. PHP está diseñado específicamente para ser un lenguaje más seguro para escribir programas CGI que Perl o C, y con la selección correcta de opciones de configuración en tiempos de compilación y ejecución, y siguiendo algunas prácticas correctas de programación, PHP le puede dar la combinación precisa de libertad y seguridad que usted necesita.

Ya que hay muchas maneras de utilizar PHP, existen varias opciones de configuración diseñadas para controlar su comportamiento . Un amplio rango de opciones le garantizan que pueda usar PHP para muchos propósitos distintos, pero también quiere decir que hay combinaciones de éstas opciones y configuracione s de servidor que pueden resultar en un entorno inseguro.

El nivel de flexibilidad en la configuración de PHP se compara quizás solo con su flexibilidad de desarrollo. PHP puede ser usado para escribir aplicaciones completas de servidor, con todo el poder de un usuario de un intérprete de comandos, o puede ser usado para inclusiones simples del lado del servidor con muy poco riesgo en un entorno minuciosamente controlado. Cómo construir ese entorno, y qué tan seguro es, básicamente depende del desarrollador PHP.

Este capítulo comienza con algunas recomendacione s generales de seguridad, explica las diferentes combinaciones de opciones de configuración y las situaciones en las que pueden ser usadas con seguridad, y describe diferentes consideracione s a la hora de programar para diferentes niveles de seguridad.

Extraido de: http://es.php.net

[Gydion]

Consideracione s Generales

 Un sistema completamente seguro es prácticamente un imposible, de modo que el enfoque usado con mayor frecuencia en la profesión de seguridad es uno que busque el balance adecuado entre riesgo y funcionalidad. Si cada variable enviada por un usuario requiriera de dos formas de validación biométrica (como rastreo de retinas y análisis dactilar), usted contaría con un nivel extremadamente alto de confiabilidad. También implicaría que llenar los datos de un formulario razonablemente complejo podría tomar media hora, cosa que podría incentivar a los usuarios a buscar métodos para esquivar los mecanismos de seguridad.

La mejor seguridad con frecuencia es lo suficientement e razonable como para suplir los requerimientos dados sin prevenir que el usuario realice su labor de forma natural, y sin sobrecargar al autor del código con una complejidad excesiva. De hecho, algunos ataques de seguridad son simples recursos que aprovechan las vulnerabilidad es de este tipo de seguridad sobrecargada, que tiende a erosionarse con el tiempo.

Una frase que vale la pena recordar: Un sistema es apenas tan bueno como el eslabón más débil de una cadena. Si todas las transacciones son registradas copiosamente basándose en la fecha/hora, ubicación, tipo de transacción, etc. pero la verificación del usuario se realiza únicamente mediante una cookie sencilla, la validez de atar a los usuarios al registro de transacciones es mermada severamente.

Cuando realice pruebas, tenga en mente que no será capaz de probar todas las diferentes posibilidades, incluso para las páginas más simples. Los datos de entrada que usted puede esperar en sus aplicaciones no necesariamente tendrán relación alguna con el tipo de información que podría ingresar un empleado disgustado, un cracker con meses de tiempo entre sus manos, o un gato doméstico caminando sobre el teclado. Es por esto que es mejor observar el código desde una perspectiva lógica, para determinar en dónde podrían introducirse datos inesperados, y luego hacer un seguimiento de cómo esta información es modificada, reducida o amplificada.

Internet está repleto de personas que tratan de crearse fama al romper la seguridad de su código, bloquear su sitio, publicar contenido inapropiado, y por lo demás haciendo que sus días sean más interesantes. No importa si usted administra un sitio pequeño o grande, usted es un objetivo por el simple hecho de estar en línea, por tener un servidor al cual es posible conectarse. Muchas aplicaciones de cracking no hacen distinciones por tamaños, simplemente recorren bloques masivos de direcciones IP en busca de víctimas. Trate de no convertirse en una.

Extraido de: http://es.php.net

[Gydion]

Instalación como un binario CGI

Posibles ataques

 El uso de PHP como un binario CGI es una opción para el tipo de situaciones en las que por alguna razón no se desea integrar PHP como módulo de algún software de servidor web (como Apache), o en donde se espera usar PHP con diferentes tipos de capas que envuelven el entorno CGI para crear ambientes chroot y setuid seguros para la ejecución de scripts. Esta configuración usualmente involucra la instalación de un binario ejecutable del intérprete PHP en el directorio cgi-bin del servidor web. El aviso de seguridad de CERT CA-96.11 recomienda que se evite la colocación de cualquier intérprete bajo cgi-bin. Incluso si el binario PHP puede ser usado como un intérprete independiente, PHP está diseñado para prevenir el tipo de ataques que esta configuración hace posible:

    * Acceso a archivos del sistema: http://mi.servidor/cgi-bin/php?/etc/passwd

      La información del query en una URL, la cual viene después del signo de interrogación (?), es pasada como argumentos de línea de comandos al intérprete por la interfaz CGI. Usualmente los intérpretes abren y ejecutan el archivo especificado como primer argumento de la línea de comandos.

      Cuando es invocado como un binario CGI, PHP se rehúsa a interpretar los argumentos de la línea de comandos.

    * Acceso a cualquier documento web en el servidor: http://mi.servidor/cgi-bin/php/zona_secreta/doc.html

      El segmento de la URL que sigue al nombre del binario de PHP, que contiene la información sobre la ruta /zona_secreta/doc.html es usada convencionalme nte para especificar el nombre de un archivo que ha de ser abierto e interpretado por el programa CGI. Usualmente, algunas directivas de configuración del servidor web (Apache: Action) son usadas para redireccionar peticiones de documentos como http://mi.servidor/zona_secreta/script.php al intérprete de PHP. Bajo este modelo, el servidor web revisa primero los permisos de acceso al directorio /zona_secreta, y después de eso crea la petición de redireccionami ento a http://mi.servidor/cgi-bin/php/zona_secreta/script.php. Desafortunadam ente, si la petición se hace originalmente en esta forma, no se realizan chequeos de acceso por parte del servidor web para el archivo /zona_secreta/script.php, únicamente para el archivo /cgi-bin/php. De este modo, cualquier usuario capaz de acceder a /cgi-bin/php es capaz también de acceder a cualquier documento protegido en el servidor web.

      En PHP, la configuración de tiempo de compilación --enable-force-cgi-redirect y las directivas de configuración en tiempo de ejecución doc_root y user_dir pueden ser usadas para prevenir este tipo de ataques, si el árbol de documentos del servidor llegara a tener directorio alguno con restricciones de acceso. Consulte las siguientes secciones para una explicación detallada de las diferentes combinaciones.

Caso 1: sólo se sirven archivos públicos

Si su servidor no tiene contenido alguno que no esté restringido por contraseñas o control de acceso basado en direcciones ip, no hay ninguna necesidad de recurrir a estas opciones de configuración. Si su servidor web no le permite hacer redireccionami entos, o el servidor no tiene una forma de comunicarle al binario PHP que la petición de redireccionami ento es segura, puede especificar la opción --enable-force-cgi-redirect en el script de configuración. Aun así debe asegurarse de que sus scripts PHP no dependan de alguna forma especial de hacer llamados al script, ya sea directamente mediante http://mi.servidor/cgi-bin/php/dir/script.php ni por la redirección http://mi.servidor/dir/script.php.

Los redireccionami entos pueden ser configurados en Apache mediante el uso de directivas AddHandler y Action (vea más adelante).

Caso 2: uso de --enable-force-cgi-redirect

Esta opción en tiempo de compilación previene que cualquier persona haga llamados a PHP directamente mediante una URL como http://mi.servidor/cgi-bin/php/directorio_secreto/script.php. En lugar de esto, PHP analizará documentos de esta forma únicamente si han pasado por una regla de redirección del servidor web.

Por lo general, el redireccionami ento en la configuración de Apache es realizada con alguna de las siguientes directivas:

Código:

Action php-script /cgi-bin/php
AddHandler php-script .php

 Esta opción ha sido probada únicamente con el servidor web Apache, y depende de que Apache defina la variable de entorno no-estándar REDIRECT_STATU S a la hora de gestionar peticiones redirigidas. Si su servidor web no dispone de modo alguno de comunicar si la petición es directa o redirigida, no puede usar esta opción y debe recurrir a alguna de las otras formas documentadas aquí de ejecutar la versión CGI.

Extraido de: http://es.php.net

[Gydion]

Instalación como un binario CGI (Continuación)

Caso 3: configuración de doc_root o user_dir

Incluir contenido activo en los directorios de documentos del servidor web, como scripts y ejecutables, es considerada en ocasiones una práctica insegura. Si, por algún fallo de configuración, los scripts no llegaran a ser ejecutados sino desplegados como documentos HTML normales, esto podría resultar en la revelación de información crítica como trabajos cubiertos por normas de propiedad intelectual o datos de seguridad como contraseñas. Por lo tanto muchos administradore s de sistemas preferirán la configuración de otra estructura de directorios para los scripts que sean asequibles únicamente a través del CGI PHP, y por lo tanto deben ser interpretados siempre y no desplegados directamente.

Así mismo, si el método para asegurarse de que las peticiones no son redireccionada s, tal y como se describió en la sección anterior, no está disponible, es necesario entonces configurar un directorio raíz (doc_root) de scripts que sea diferente al directorio raíz de documentos web.

Puede definir el directorio raíz para scripts de PHP mediante la directiva de configuración doc_root en el archivo de configuración, o puede darle un valor a la variable de entorno PHP_DOCUMENT_R OOT. Si ésta está definida, la versión CGI de PHP construirá siempre el nombre del archivo a abrir con este doc_root y la información de la ruta dada en la petición, de modo que puede estar seguro de que ningún script será ejecutado por fuera de este directorio (excepto por aquellos indicados en user_dir, como se verá a continuación).

Otra opción que puede ser usada en este caso es user_dir. Cuando user_dir no está definida, lo único que controla la apretura de archivos es doc_root. Abrir una URL como http://mi.servidor/~usuario/doc.php no resulta en la apertura de un archivo bajo el directorio personal del usuario, sino de un archivo llamado ~usuario/doc.php bajo la ruta doc_root (así es, un directorio cuyo nombre comienza por el caracter de equivalencia [~]).

Si user_dir está definido como, por ejemplo, public_php, una petición como http://mi.servidor/~usuario/doc.php abrirá un archivo llamado doc.php bajo el directorio con el nombre public_php ubicado en el directorio personal del usuario. Si el directorio personal del usuario es /home/usuario, el archivo ejecutado es /home/usuario/public_php/doc.php.

La expansión del valor de user_dir ocurre independientem ente del parámetro doc_root, de modo que es posible controlar el directorio raíz de los documentos y el acceso a los directorios de los usuarios en forma separada.

Caso 4: intérprete PHP por fuera del árbol web

Una opción bastante segura es colocar el intérprete binario de PHP en alguna parte por fuera del árbol de archivos web. En /usr/local/bin, por ejemplo. El único inconveniente real con esta alternativa es que ahora usted tendrá que colocar una línea como esta:

Código:

#!/usr/local/bin/php

al comienzo de cualquier archivo que contenga etiquetas PHP. También tendrá que hacer cada archivo ejecutable. Esto quiere decir que debe tratarlo exactamente igual a como trataría cualquier otro script CGI escrito en Perl o sh o cualquier otro lenguaje de scripting común que usara el mecanismo de escape-shell #! para el lanzamiento del intérprete.

Para lograr que PHP gestione correctamente la información de PATH_INFO y PATH_TRANSLATE D con este tipo de configuración, el intérprete PHP debe haber sido compilado con la opción de configuración --enable-discard-path.

Extraido de: http://es.php.net

[Gydion]

Instalación como módulo de Apache

Cuando PHP es usado como un módulo de Apache, hereda los permisos del usuario de Apache (generalmente los del usuario "nobody"). Este hecho representa varios impactos sobre la seguridad y las autorizaciones . Por ejemplo, si está usando PHP para acceder a una base de datos, a menos que tal base de datos disponga de un control de acceso propio, usted tendrá que hacer que la base de datos sea asequible por el usuario "nobody". Esto quiere decir que un script malicioso podría tener acceso y modificar la base de datos, incluso sin un nombre de usuario y contraseña. Es completamente posible que un archivador automatizado de documentos web pudiera toparse con la página web de administración de una base de datos, y eliminar todas sus bases de datos. Usted puede protegerse de este tipo de situaciones mediante mecanismos de autorización de Apache, o puede diseñar su propio modelo de acceso usando LDAP, archivos .htaccess, etc. e incluir ese código como parte de sus scripts PHP.

Con frecuencia, una vez la seguridad se ha establecido en un punto en donde el usuario de PHP (en este caso, el usuario de apache) tiene asociada una muy leve capacidad de riesgo, se descubre que PHP se encuentra ahora imposibilitado de escribir archivos en los directorios de los usuarios. O quizás se le haya desprovisto de la capacidad de acceder o modificar bases de datos. Se ha prevenido exitosamente que pudiera escribir tanto archivos buenos como malos, o que pudiera realizar transacciones buenas o malas en la base de datos.

Un error de seguridad cometido con frecuencia en este punto es darle permisos de administrador (root) a apache, o incrementar las habilidades del usuario de apache de alguna otra forma.

Escalar los permisos del usuario de Apache hasta el nivel de administrador es extremadamente peligroso y puede comprometer al sistema entero, así que el uso de entornos sudo, chroot, o cualquier otro mecanismo que sea ejecutado como root no debería ser una opción viable para aquellos que no son profesionales en seguridad.

Existen otras soluciones más simples. Mediante el uso de open_basedir usted puede controlar y restringir aquellos directorios que podrían ser usados por PHP. También puede definir áreas solo-Apache, para restringir todas las actividades basadas en web a archivos que no son de usuarios, o del sistema.

Extraido de: http://es.php.net

[Universal SAC]

Que buena informaciòn haz colocado... me es extraño que siendo un muy continuo visitante de esa web no me haya percatado de ese texto, el cual me interesa bastante.
Làstima que se ha quedado hasta ahì, buscarè màs textos en la pàgina e informaciòn sobre aquellos temas y funciones que no explicaron con profundidad... como la opciòn open_basedir que se menciona al final.

Gracias Gydion.

[Gydion]

De nada, me alegra que os sea util. Esta noche colgaré el resto de ese tema (del que solo tuve tiempo de colgar la mitad). Y si quereis alguna cosa mas en concreto, ya miraré a ver si encuentro algo. Y si no, lo preparamos nosotros.

[CiberPunk]

JeJeJe seguridad.

Excelente vamos a ver si es cierto por lo que yo se el .php es el mas hackeable.

pero bueno la seguridad es muy bueno.

Greetings:::

[Gydion]

Seguridad del sistema de archivos

 PHP está sujeto a la seguridad misma de la mayoría de sistemas de servidores en lo que a permisos sobre archivos y directorios se refiere. Esto le permite controlar cuáles archivos en el sistema de archivos pueden ser leídos. Debe tenerse cuidado con aquellos archivos que tengan permisos de lectura globales, para asegurarse de que su contenido es seguro y no represente peligro el que pueda ser leído por todos los usuarios con acceso al sistema de archivos.

Ya que PHP fue diseñado para permitir acceso al nivel de usuarios al sistema de archivos, es completamente posible escribir un script PHP que le permita leer archivos del sistema como /etc/passwd, modificar sus conexiones tipo ethernet, enviar trabajos de impresión masivos, etc. Esto tiene algunas implicaciones obvias, en el sentido en que usted tiene que asegurarse de que los archivos desde lo que lee y hacia los que escribe datos, sean los correctos.

Considere el siguiente script, en donde un usuario indica que quisiera eliminar un archivo ubicado en su directorio personal. Este caso asume que se trata de una situación en donde se usa normalmente una interfaz web que se vale de PHP para la gestión de archivos, así que el usuario de Apache tiene permitido eliminar archivos en los directorios personales de los usuarios.

Ejemplo 26-1. Un chequeo pobre de variables nos lleva a...

Código:

<?php
// eliminar un archivo del directorio personal del usuario

$nombre_usuario = $_POST['nombre_enviado_por_el_usuario'];
$directorio    = "/home/$nombre_usuario";

$archivo_a_eliminar = "$archivo_de_usuario";

unlink ("$directorio/$archivo_de_usuario");

echo "&iexcl;El archivo $archivo_a_eliminar ha sido eliminado!";
?>

Ya que el nombre de usuario es enviado desde un formulario de usuario, cualquiera puede enviar un nombre de usuario y archivo propiedad de otra persona, y eliminar archivos. En este caso, usted querrá usar otro método de autenticación. Considere lo que sucede si las variables enviadas son "../etc/" y "passwd". El código entonces se ejecutaría efectivamente como:

Ejemplo 26-2. ... un ataque al sistema de archivos

Código:

<?php
// elimina un archivo de cualquier parte del disco duro al que el
// usuario de PHP tiene acceso. Si PHP tiene acceso de root:

$nombre_usuario = "../etc/";
$directorio    = "/home/../etc/";

$archivo_a_eliminar = "passwd";

unlink ("/home/../etc/passwd");

echo "&iexcl;El archivo /home/../etc/passwd ha sido eliminado!";
?>

Hay dos importantes medidas que usted debe tomar para prevenir estas situaciones.

    * Otorgarle únicamente permisos limitados al usuario web del binario PHP.
    * Chequear todas las variables que son enviadas por usuarios.

Aquí hay una versión mejorada del script:

Ejemplo 26-3. Un chequeo de nombres de archivos más seguro

Código:

<?php
// elimina un archivo de cualquier parte del disco duro al que el
// usuario de PHP tiene acceso.

$nombre_usuario = $_SERVER['REMOTE_USER']; // uso de un mecanismo de
                                           // autenticacion

$directorio = "/home/$nombre_usuario";

$archivo_a_eliminar = basename("$archivo_de_usuario"); // remover rutas
unlink ($directorio/$archivo_a_eliminar);

$fp = fopen("/home/registros/eliminacion.log","+a"); // registrar el proceso

$cadena_de_registro = "$nombre_usuario $directorio $archivo_a_eliminar";

fwrite ($fp, $cadena_de_registro);
fclose($fp);

echo "&iexcl;El archivo $archivo_a_eliminar ha sido eliminado!";
?>

Sin embargo, incluso este caso no está libre de problemas. Si su sistema de autenticación le ha permitido a los usuarios la creación de sus propios nombres en el sistema, y un usuario elige "../etc/", el sistema se encuenrta nuevamente expuesto. Por esta razón, puede que uster prefiera escribir un chequeo más personalizado:

Ejemplo 26-4. Chequeo de nombres de archivos aun más seguro

Código:

<?php
$nombre_usuario = $_SERVER['REMOTE_USER']; // uso de un mecanismo de
                                           // autenticacion

$directorio = "/home/$nombre_usuario";

if (!ereg('^[^./][^/]*$', $archivo_de_usuario))
     die('nombre de archivo inv&aacute;lido'); // finalizar,
                                               // no ejecutar el proceso

if (!ereg('^[^./][^/]*$', $nombre_usuario))
     die('nombre de archivo inv&aacute;lido'); // finalizar,
                                               // no ejecutar el proceso

//etc...
?>

Dependiendo de su sistema operativo, existe una amplia variedad de archivos sobre los que usted debería estar atento, incluyendo las entradas de dispositivos (/dev/ o COM1), archivos de configuración (archivos /etc/ y los archivos .ini), areas conocidas de almacenamiento de datos (/home/, Mis Documentos), etc. Por esta razón, usualmente es más sencillo crear una política en donde se prohíba toda transacción excepto por aquellas que usted permita explícitamente.

Extraido de: http://es.php.net

[Gydion]

Seguridad de Bases de Datos

 Hoy en día, las bases de datos son componentes cardinales de cualquier aplicación basada en web, permitiendo que los sitios web provean contenido dinámico. Debido a que información considerableme nte sensible o secreta puede ser almacenada en una base de datos, usted debe considerar seriamente la protección de sus bases de datos.

Para recuperar o almacenar cualquier información necesita conectarse a la base de datos, enviar una consulta válida, recoger el resultado y cerrar la conexión. Hoy en día, el lenguaje de consultas usado comúnmente en estas interacciones es el Lenguaje de Consultas Estructurado (SQL por sus siglas en Inglés). Puede apreciar cómo un atacante puede intentar acometidas con una consulta SQL.

Como puede suponer, PHP no puede proteger su base de datos por sí solo. Las siguientes secciones están dirigidas a servir de introducción a los conceptos básicos de cómo acceder y manipular bases de datos desde scripts PHP.

Mantenga en mente esta simple regla: protección en profundidad. Entre más acciones tome para incrementar la protección de su base de datos, menor será la probabilidad de que un atacante tenga éxito exponiendo o abusando de cualquier información almacenada. Un buen diseño del esquema de la base de datos y de la aplicación basta para lidiar con sus mayores temores.

Diseño de Bases de Datos

 El primer paso siempre es crear la base de datos, a menos que desee usar una creada por alguien más. Cuando una base de datos es creada, ésta es asignada a un dueño, quien ejecutó la sentencia de creación. Usualmente, únicamente el dueño (o un super-usuario) puede hacer cualquier cosa con los objetos de esa base de datos, y para que otros usuarios puedan usarla, deben otorgarse privilegios.

Las aplicaciones nunca deberían conectarse a la base de datos bajo el usuario correspondient e a su dueño, o como un super-usuario, ya que éstos usuarios pueden, por ejemplo, ejecutar cualquier consulta a su antojo, modificando el esquema (p. ej. eliminando tablas) o borrando su contenido completo.

Usted puede crear diferentes usuarios de la base de datos para cada aspecto de su aplicación con derechos muy limitados sobre los objetos de la base de datos. Tan solo deben otorgarse los privilegios estrictamente necesarios, y evitar que el mismo usuario pueda interactuar con la base de datos en diferentes casos de uso. Esto quiere decir que si un intruso gana acceso a su base de datos usando las credenciales de sus aplicaciones, él solo puede efectuar tantos cambios como su aplicación se lo permita.

Es buena idea que no implemente toda la lógica del asunto en la aplicación web (es decir, en su script); en su lugar, hágalo en el esquema de la base de datos usando vistas, disparadores o reglas. Si el sistema evoluciona, se espera que nuevos puertos sean abiertos a la aplicación, y tendrá que re-implementar la lógica para cada cliente de la base de datos. Por sobre todo, los disparadores pueden ser usados para gestionar de forma transparente todos los campos automáticamente, lo cual con frecuencia provee información útil cuando se depuren problemas de su aplicación, o se realicen rastreos sobre transacciones particulares.

Conexión con la Base de Datos

Puede que desee establecer las conexiones sobre SSL para encriptar las comunicaciones cliente/servidor, incrementando el nivel de seguridad, o puede hacer uso de ssh para encriptar la conexión de red entre los clientes y el servidor de la base de datos. Si cualquiera de estos recursos es usado, entonces monitorear su tráfico y adquirir información sobre su base de datos será difícil para un atacante potencial.

Modelo de Almacenamiento Encriptado

 SSL/SSH protege los datos que viajan desde el cliente al servidor, SSL/SSH no protege los datos persistentes almacenados en la base de datos. SSL es un protocolo sobre-el-cable.

Una vez el atacante adquiere acceso directo a su base de datos (evitando el paso por el servidor web), los datos críticos almacenados pueden estar expuestos o malutilizados, a menos que la información esté protegida en la base de datos misma. La encriptación de datos es una buena forma de mitigar esta amenaza, pero muy pocas bases de datos ofrecen este tipo de mecanismo de encriptación de datos.

La forma más sencilla de evitar este problema es crear primero su propio paquete de encriptación, y luego utilizarlo desde sus scripts de PHP. PHP puede ayudarle en este sentido con varias extensiones, como Mcrypt y Mhash, las cuales cubren una amplia variedad de algoritmos de encriptación. El script encripta los datos antes de insertarlos en la base de datos, y los decripta cuando los recupera. Vea las referencias para consultar más ejemplos de cómo opera la encriptación.

En el caso de datos realmente escondidos, si su representación original no se necesita (es decir, no debe ser desplegada), los resúmenes criptográficos pueden llegar a considerarse también. El ejemplo clásico de gestión de resúmenes criptográficos es el almacenamiento de secuencias MD5 de una contraseña en una base de datos, en lugar de la contraseña misma. Vea también crypt() y md5().

Ejemplo 27-1. Uso de un campo de contraseñas encriptado

Código:

<?php

// almacenamiento de resumen criptografico de la contrasenya
$consulta  = sprintf("INSERT INTO usuarios(nombre,contr) VALUES('%s','%s');",
                     addslashes($nombre_usuario), md5($contrasenya));
$resultado = pg_query($conexion, $consulta);


// consulta de verificacion de la contrasenya enviada
$consulta  = sprintf("SELECT 1 FROM usuarios WHERE nombre='%s' AND contr='%s';",
                     addslashes($nombre_usuario), md5($contrasenya));
$resultado = pg_query($conexion, $consulta);

if (pg_num_rows($resultado) > 0) {
   echo '&iexcl;Bienvenido, $nombre_usuario!';
}
else {
   echo 'No pudo autenticarse a $nombre_usuario.';
}

?>

Extraido de: http://es.php.net

[Gydion]

Seguridad de Bases de Datos (Continuacion)

Inyección de SQL

 Muchos desarrolladore s web no son conscientes de cómo pueden manipularse las consultas SQL, y asumen que una consulta SQL es un comando confiable. Esto representa que las consultas SQL pueden burlar los controles de acceso, y de este modo evitar los chequeos estándares de autenticación y autorización, y a veces las consultas SQL pueden incluso permitir acceso a comandos al nivel del sistema operativo de la máquina huésped.

La Inyección Directa de Comandos SQL es una técnica en la cual un atacante crea o altera comandos SQL existentes para exponer datos escondidos, o sobrescribir datos críticos, o incluso ejecutar comandos del sistema peligrosos en la máquina en donde se encuentra la base de datos. Esto se consigue cuando la aplicación toma información de entrada del usuario y la combina con parámetros estáticos para construir una consulta SQL. Los siguientes ejemplos, desafortunadam ente, están basados en historias reales.

Debido a la falta de validación de la información de entrada y el establecimient o de conexiones con la base de datos desde un super-usuario o aquel que puede crear usuarios, el atacante podría crear un super-usuario en su base de datos.

Ejemplo 27-2. Paginación del conjunto de resultados ... y creación de super-usuarios (PostgreSQL)

Código:

<?php

$offset  = $argv[0]; // atencion, no se valida la entrada!
$consulta = "SELECT id, nombre FROM productos ORDER BY nombre LIMIT 20 " .
           "OFFSET $offset;";

$resultado = pg_query($conexion, $consulta);

?>

Los usuarios normales pulsan sobre los enlaces 'siguiente' y 'anterior', en donde el desplazamiento ($offset) se encuentra codificado en la URL. El script espera que el valor entrante $offset sea un número decimal. Sin embargo, qué sucede si alguien intenta un ataque añadiendo una forma codificada (urlencode()) de lo siguiente en la URL

0;
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
    select 'crack', usesysid, 't','t','crack'
    from pg_shadow where usename='postgres';
--

Si esto ocurriera, entonces el script le presentaría un acceso de superusuario al atacante. Note que 0; es usado para ofrecer un desplazamiento válido a la consulta original y finalizarla.

    Nota: Es una técnica común obligar al analizador sintáctico de SQL a que ignore el resto de la consulta escrita por el desarrollador mediante --, el cual es el signo de comentarios en SQL.

Una forma viable de adquirir contraseñas es jugar con las páginas de resultados de búsquedas. Lo único que necesita el atacante es ver si existen variables enviadas por el usuario que sean usadas en sentencias SQL, y que no sean tratadas apropiadamente . Estos filtros pueden ubicarse por lo general previos a cláusulas WHERE, ORDER BY, LIMIT y OFFSET en sentencias SELECT para personalizar la instrucción. Si su base de datos soporta la construcción UNION, el atacante puede intentar añadir una consulta completa a la consulta original para generar una lista de contraseñas desde una tabla cualquiera. El uso de campos encriptados de contraseñas es altamente recomendable.

Ejemplo 27-3. Listado de artículos ... y algunas contraseñas (en cualquier base de datos)

Código:

<?php

$consulta  = "SELECT id, nombre, insertado, tam FROM productos
                 WHERE tam = '$tam'
                 ORDER BY $orden LIMIT $limite, $offset;";
$resultado = odbc_exec($conexion, $consulta);

?>

La parte estática de la consulta puede combinarse con otra sentencia SELECT la cual revela todas las contraseñas:

'
union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;
--

Si esta consulta (la cual juega con ' y --) fuera asignada a una de las variables usadas en $consulta, la bestia de la consulta habrá despertado.

Las sentencias UPDATE de SQL son también susceptibles a ataque. Éstas consultas también se encuentran amenazadas por un posible acotamiento y adición de una consulta completamente nueva. Pero en este caso el atacante puede amañar la información de una cláusula SET. En este caso se requiere contar con cierta información sobre el esquema de la base de datos para poder manipular la consulta satisfactoriam ente. Esta información puede ser adquirida mediante el estudio de los nombres de variables de los formularios, o simplemente por fuerza bruta. No existen demasiadas convenciones para nombrar campos de contraseñas o nombres de usuario.

Ejemplo 27-4. De restablecer una contraseña ... a adquirir más privilegios (con cualquier servidor de base de datos)

Código:

<?php
$consulta = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";
?>

Pero un usuario malicioso envía el valor ' or uid like'%admin%'; -- como $uid para cambiar la contraseña del administrador, o simplemente establece $pwd a "hehehe', admin='yes', trusted=100 " (con un espacio al inicio) para adquirir más privilegios. En tal caso, la consulta sería manipulada:

Código:

<?php

// $uid == ' or uid like'%admin%'; --
$consulta = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --";

// $pwd == "hehehe', admin='yes', trusted=100 "
$consulta = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ...;"

?>

 Un horrible ejemplo de cómo puede accederse a comandos del nivel del sistema operativo en algunas máquinas anfitrionas de bases de datos.

Ejemplo 27-5. Ataque al sistema operativo de la máquina anfitriona de la base de datos (MSSQL Server)

Código:

<?php

$consulta  = "SELECT * FROM productos WHERE id LIKE '%$prod%'";
$resultado = mssql_query($consulta);

?>

Si el atacante envía el valor a%' exec master..xp_cmd shell 'net user test testpass /ADD' -- a $prod, entones la $consulta  será:

Código:

<?php

$consulta  = "SELECT * FROM productos
                   WHERE id LIKE '%a%'
                   exec master..xp_cmdshell 'net user test testpass /ADD'--";
$resultado = mssql_query($consulta);

?>

MSSQL Server ejecuta sentencias SQL en el lote, incluyendo un comando para agregar un nuevo usuario a la base de datos de cuentas locales. Si esta aplicación estuviera corriendo como sa y el servicio MSSQLSERVER está corriendo con los privilegios suficientes, el atacante tendría ahora una cuenta con la que puede acceder a esta máquina.

    Nota: Algunos de los ejemplos anteriores están atados a un servidor de base de datos específico. Esto no quiere decir que un ataque similar sea imposible con otros productos. Su base de datos puede ser vulnerable de forma semejante, en alguna otra manera.

Técnicas de protección

Usted puede argumentar con justa razón que el atacante debe poseer cierta cantidad de información sobre el esquema de la base de datos en la mayoría de ejemplos que hemos visto. Tiene razón, pero usted nunca sabe cuándo y cómo puede filtrarse esta información, y si ocurre, su base de datos estará expuesta. Si está usando un paquete de gestión de bases de datos de código abierto, o cuyo código fuente está disponible públicamente, el cual puede pertenecer a algún sistema de administración de contenido o foro, los intrusos pueden producir fácilmente una copia de un trozo de su código. También puede ser un riesgo de seguridad si es un segmento de código pobremente diseñado.

Estos ataques se basan principalmente en la explotación del código que no ha sido escrito pensando en la seguridad. Nunca confíe en ningún tipo de información de entrada, especialmente aquella que proviene del lado del cliente, aun si lo hace desde una caja de selección, un campo de entrada hidden o una cookie. El primer ejemplo le muestra que una consulta así de descuidada puede causar desastres.

    * Nunca se conecte a la base de datos como un super-usuario o como el dueño de la base de datos. Use siempre usuarios personalizados con privilegios muy limitados.

    * Revise si la entrada recibida es del tipo apropiado. PHP posee un amplio rango de funciones de validación de datos, desde los más simples encontrados en Funciones sobre variables y en Funciones de tipo de caracter (p. ej. is_numeric(), ctype_digit() respectivament e) hasta el soporte para Expresiones Regulares compatibles con Perl.

    * Si la aplicación espera alguna entrada numérica, considere la verificación de información con is_numeric(), o modifique silenciosament e su tipo usando settype(), o utilice su representación numérica, dada por sprintf().

      Ejemplo 27-6. Una forma más segura de generar una consulta para paginado

Código:

<?php

settype($offset, 'integer');
$consulta = "SELECT id, nombre FROM productos ORDER BY nombre " .
           "LIMIT 20 OFFSET $offset;";

// note el simbolo %d en la cadena de formato, usar %s no tendria sentido
$consulta = sprintf("SELECT id, nombre FROM productos ORDER BY nombre" .
                   "LIMIT 20 OFFSET %d;", $offset);

?>

    * Ubique cada valor no-numérico que entrega el usuario y que sea pasado a la base de datos entre comillas con la función de escape de cadenas específica a su base de datos (p.ej. mysql_escape_s tring(), sql_escape_str ing(), etc.). Si no hay disponible un mecanismo de escape de cadenas específico a la BD, las funciones addslashes() y str_replace() pueden ser útiles (dependiendo del tipo de base de datos). Vea el primer ejemplo. Como se ve allí, agregar comillas a la parte estática de la consulta no es suficiente, haciéndola fácilmente manipulable.
   
 * No imprima ninguna información específica sobre la base de datos, especialmente sobre su esquema, ya sea por razones justas o por equivocaciones . Vea también Reporte de Errores y Gestión de Errores y Funciones de Registro.
 
  * Puede usar procedimientos almacenados y cursores previamente definidos para abstraer el acceso a las bases de datos, de modo que los usuarios no tengan acceso directo a las tablas o vistas, aunque esta solución tiene otros impactos.

Además de estas acciones, usted puede beneficiarse del registro explícito de las consultas realizadas, ya sea desde su script o por la base de datos misma, si ésta soporta la gestión de registros. Por supuesto, el registro de acciones no puede prevenir cualquier intento peligroso, pero puede ser útil para rastrear cuáles aplicaciones han sido usadas para violar la seguridad. El registro en sí no es útil; lo es la información que contiene. Por lo general, es mejor contar con más detalles que con menos.

http://es.php.net

[Gydion]

Reporte de Errores

 Hablando de la seguridad en PHP, hay dos caras en lo que se concierne al reporte de errores. Una es benéfica al incremento de la seguridad, la otra va en dirección de su detrimento.

Una táctica de ataque típica involucra la acumulación de un perfil de datos del sistema alimentándolo con datos inapropiados, y luego chequear los tipos de errores que son devueltos, y sus contextos. Esto permite que el cracker del sistema pueda adquirir información del servidor, para así determinar posibles debilidades. Por ejemplo, si un atacante ha recogido información sobre una página creada a partir de los datos de un formulario, él podría intentar sobrescribir las variables, o modificarlas:

Ejemplo 28-1. Ataque a Variables con una página HTML personalizada

<form method="post" action="destino_del_at aque?username=badfoo&amp;password=badfoo">
<input type="hidden" name="username" value="badfoo" />
<input type="hidden" name="password" value="badfoo" />
</form>

 Los errores de PHP que son devueltos normalmente pueden ser bastante útiles para un desarrollador que esté tratando de depurar un script, indicando cosas como la función o archivo que falló, el archivo PHP y el número de línea en donde ocurren los fallos. Toda esta es información de la que puede sacarse provecho. No es extraño que un desarrollador php use show_source(), highlight_stri ng(), o highlight_file() como medida de depuración, pero en un sitio en producción, esta acción puede exponer variables ocultas, sintaxis sin chequear, y otra información peligrosa. Algo especialmente peligroso es ejecutar código que proviene de fuentes bien conocidas con gestores de depuración incorporados, o que usan técnicas de depuración comunes. Si el atacante puede determinar qué técnica general está usando, puede intentar un ataque de fuerza bruta sobre una página, enviando varias cadenas comunes de depuración:

Ejemplo 28-2. Explotación de variables comunes de depuración

<form method="post" action="destino_del_at aque?errors=Y&amp;showerrors=1&amp;debug=1">
<input type="hidden" name="errors" value="Y" />
<input type="hidden" name="showerrors" value="1" />
<input type="hidden" name="debug" value="1" />
</form>

 Independientem ente del método de gestión de errores, la capacidad de conseguir que un sistema revele sus posibles estados de error representa un camino para darle información al atacante.

Por ejemplo, el estilo mismo de un error de PHP genérico indica que el sistema está ejecutando PHP. Si el atacante estuviera viendo una página .html, y quisiera consultar qué está siendo usado para la generación de ella por detrás (en busca de debilidades conocidas en el sistema), podría determinar que el sistema fue creado usando PHP alimentándolo con información equivocada.

Un error de función puede indicar si el sistema está ejecutando un tipo particular de motor de base de datos, o dar pistas sobre cómo fue programada o diseñada una página web. Esto facilita posteriores investigacione s en determinados puertos abiertos de bases de datos, o en busca de fallos específicos o debilidades en una página web. Al entregar diferentes trozos de datos inválidos al sistema, por ejemplo, un atacante puede determinar el orden de autenticación en un script, (a partir de los números de línea de los errores) así como averiguar sobre vulnerabilidad es que pueden aprovecharse en diferentes puntos del script.

Un error del sistema de archivos o en general de PHP puede indicar qué permisos tiene el servidor web, así como la estructura y organización de los archivos en el servidor web. Algún código de gestión de errores escrito por el desarrollador puede agravar este problema, llevando a la fácil explotación de información hasta entonces "escondida".

Existen tres soluciones principales a este problema. La primera es revisar cuidadosamente todas las funciones, y tratar de compensar por la mayoría de errores encontrados. La segunda es deshabilitar el reporte de errores completamente del código que está siendo ejecutado. La tercera es usar las funciones de gestión de errores personalizable s de PHP para crear su propio gestor de errores. Dependiendo de su política de seguridad, puede encontrar que todas ellas pueden ser aplicables a su situación.

Una forma de detectar este problema por adelantado es hacer uso del reporte de errores propio de PHP (error_reportin g()), para ayudarle a asegurar su código y encontrar uso de variables que pueda ser peligroso. Al probar su código, previamente a su entrega final, con E_ALL, puede encontrar rápidamente áreas en donde sus variables pueden estar abiertas a la manipulación y explotación en distintas formas. Una vez esté listo para liberar su código, es buena idea que deshabilite el reporte de errores por completo definiendo error_reportin g() a 0, o desactive la impresión de errores usando la opción de php.ini display_errors, de modo que pueda aislar su código de ataques potenciales. Si elige la última opción, debe definir también la ruta a su archivo de registro usando la directiva ini error_log, y habilitar log_errors.

Ejemplo 28-3. Detección de variables peligrosas con E_ALL

Código:

<?php
if ($nombre_usuario) {  // Variable no inicializada o chequeada antes de su uso
   $login_correcto = 1;
}
if ($login_correcto == 1) { // Si la condicion anterior falla, esta variable
                           // no se encuentra inicializada ni validada
                           // antes de su uso

   readfile ("/informacion/altamente/confidencial/index.html");
}
?>

Extraido de: http://es.php.net

[Gydion]

Uso de Register Globals

 Quizás el cambio más controversial en la historia de PHP se ha dado cuando la directiva register_globa ls pasó de tener como valor por defecto ON al valor OFF en PHP 4.2.0. La dependencia sobre esta directiva era bastante común y muchas personas nisiquiera estaban enteradas de que existía y asumían que ese era el modo en que PHP trabajaba. Esta página explicará cómo puede llegar a escribirse código inseguro con esta directiva pero tenga en mente que no es la directiva misma la que es insegura sino el uso inapropiado de ella.

Cuando se encuentra activa, la directiva register_globa ls inyectará sus scripts con todo tipo de variables, como variables de peticiones provenientes de formularios HTML. Esto junto con el hecho de que PHP no requiere la inicialización de variables significa que es muy fácil escribir código inseguro. Fue una decisión difícil, pero la comunidad de PHP decidió desahibilar esta directiva por defecto. Cuando está habilitada, las personas usan variables sin saber con seguridad de dónde provienen y solo queda asumir. Las variables internas que son definidas en el script mismo son mezcladas con los datos enviados por los usuarios y al deshabilitar register_globa ls se modifica este comportamiento . Demostremos este caso con un ejemplo del uso incorrecto de register_globa ls:

Ejemplo 29-1. Ejemplo del uso inapropiado de register_globa ls = on

Código:

<?php
// definir $autorizado = true solo si el usuario ha sido autenticado

if (usuario_autenticado()) {
   $autorizado = true;
}

// Ya que no inicializamos $autorizado como false, esta podria estar
// definida a traves de register_globals, como en el caso de GET
// auth.php?autorizado=1

// De modo que cualquier persona podria verse como autenticada!

if ($autorizado) {
   include "/datos/muy/importantes.php";
}
?>

 Cuando register_globa ls = on, nuestra lógica anterior podría verse comprometida. Cuando la directiva está deshabilitada, $autorizado no puede definirse a través de peticiones, así que no habrá ningún problema, aunque es cierto que siempre es una buena práctica de programación inicializar las variables primero. Por ejemplo, en nuestro ejemplo anterior pudimos haber realizado primero algo como $authorized = false. Hacer esto representa que el código anterior podría funcionar con register_globa ls establecido a on u off ya que los usuarios no serían autorizados por defecto.

Otro ejemplo es aquel de las sesiones. Cuando register_globa ls = on, podríamos usar también $nombre_usuario en nuestro siguiente ejemplo, pero nuevamente usted debe notar que $nombre_usuario puede provenir de otros medios, como GET (a través de la URL).

Ejemplo 29-2. Ejemplo del uso de sesiones con register_globa ls on u off

Código:

<?php
// No sabriamos de donde proviene $nombre_usuario, pero sabemos que
// $_SESSION es para datos de sesion

if (isset($_SESSION['nombre_usuario'])) {

   echo "Hola <b>{$_SESSION['nombre_usuario']}</b>";

} else {

   echo "Hola <b>Invitado</b><br />";
   echo "&iquest;Quisiera iniciar su sesi&oacute;n?";

}
?>

Incluso es posible tomar medidas preventivas para advertir cuando se intente falsificar la información. Si usted sabe previamente con exactitud el lugar de donde debería provenir una variable, usted puede chequear si los datos enviados provienen de una fuente inadecuada. Aunque esto no garantiza que la información no haya sido falsificada, esto requiere que un atacante adivine el medio apropiado para falsificar la información. Si no le importa de dónde proviene la información, puede usar $_REQUEST ya que allí se incluye una mezcla de variables que provienen de datos GET, POST y COOKIE. Consulte también la sección del manual sobre el uso de variables desde fuera de PHP.

Ejemplo 29-3. Detección de envenenamiento simple de variables

Código:

<?php
if (isset($_COOKIE['COOKIE_MAGICA'])) {

   // COOKIE_MAGICA proviene de una cookie.
   // Asegurese de validar los datos de la cookie!

} elseif (isset($_GET['COOKIE_MAGICA']) || isset($_POST['COOKIE_MAGICA'])) {

   mail("admin@example.com", "Posible intento de intromision",
       $_SERVER['REMOTE_ADDR']);
   echo "Violaci&oacute;n de seguridad, el administrador ha sido alertado.";
   exit;

} else {

   // COOKIE_MAGICA no fue definida en este REQUEST

}
?>

 Por supuesto, deshabilitar register_globa ls no quiere decir que su código vaya a ser seguro. Por cada trozo de datos que sea enviado por el usuario, éste debe ser chequeado en otras formas. ¡Siempre valide los datos de los usuarios e inicialice sus variables! Para chequear por variables no inicializadas, usted puede usar error_reportin g() para mostrar errores del nivel E_NOTICE.

Para más información sobre la emulación del valor On u Off de register_globa ls, consulte este FAQ.

    Superglobals: Nota de disponibilidad: Desde 4.1.0, están disponibles algunas matrices superglobales tales como $_GET, $_POST, y $_SERVER, etc. Para más información puede consultar la sección superglobals.

Extraido de: http://es.php.net

[Gydion]

Datos Enviados por el Usuario

Las mayores debilidades de muchos programas PHP no son inherentes al lenguaje mismo, sino simplemente un problema generado cuando se escribe código sin pensar en la seguridad. Por esta razón, usted debería tomarse siempre el tiempo para considerar las implicaciones de cada pedazo de código, para averiguar el posible peligro involucrado cuando una variable inesperada es enviada.

Ejemplo 30-1. Uso Peligroso de Variables

Código:

<?php
// eliminar un archivo del directorio personal del usuario .. o
// quizas de alguien mas?

unlink ($variable_malvada);

// Imprimir el registro del acceso... o quizas una entrada de /etc/passwd?
fwrite ($desc_archivo, $variable_malvada);

// Ejecutar algo trivial.. o rm -rf *?
system ($variable_malvada);
exec ($variable_malvada);

?>

Usted debería examinar siempre, y cuidadosamente su código para asegurarse de que cualquier variable siendo enviada desde un navegador web sea chequeada apropiadamente, y preguntarse a sí mismo:

* ¿Este script afectará únicamente los archivos que se pretende?

* ¿Puede tomarse acción sobre datos inusuales o indeseados?

* ¿Puede ser usado este script en formas malintencionad as?
   
* ¿Puede ser usado en conjunto con otros scripts en forma negativa?
 
* ¿Serán adecuadamente registradas las transacciones?

Al preguntarse adecuadamente estas preguntas mientras escribe su script, en lugar de hacerlo posteriormente, usted previene una desafortunada re-implementación del programa cuando desee incrementar el nivel de seguridad. Al comenzar con esta mentalidad, no garantizará la seguridad de su sistema, pero puede ayudar a mejorarla.

Puede que también desee considerar la deshabilitación de register_globa ls, magic_quotes, u otros parámetros convenientes que pueden causar confusión sobre la validez, fuente o valor de una determinada variable. Trabajar con PHP en modo error_reportin g(E_ALL) también puede ayudarle a advertir variables que están siendo usadas antes de ser chequeadas o inicializadas (de modo que puede prevenir que datos inusuales produzcan operaciones inadvertidas).

Extraido de: http://es.php.net

[Gydion]

Re: Seguridad en PHP