|
7 grandes fallos de seguridad en php (parte I)
Hola a todos de nuevo.
Otra vez, navegando por ahi me acabo de encontrar con informacion la cual veo de mucha importancia para aquellos que estamos adentrandonos en el mundo de PHP.
Lean esto:
Cita:
PHP es un lenguaje magnífico para el desarrollo rápido de sitios dinámicos Web. También tiene múltiples características que son amigables para programadores que se están iniciando, tal como el hecho de que no se requiera la declaración de variables. Sin embargo, muchas de estas características pueden llevar a un programador inadvertidamente a permitir agujeros de seguridad para colarse en tu aplicación Web. Las populares listas de correo que pululan con notas de fallos identificados en aplicaciones PHP, pero PHP puede ser tan seguro como cualquier otro lenguaje una vez que entiendas los tipos básicos de "bugs" que las aplicaciones PHP tienden a exhibir.
En este artículo, detallaré muchos de los errores de programación más comunes en PHP que pueden resultar en agujeros de seguridad. Para enseñarte lo que no debes hacer, y como cada fallo particular puede ser explotado, espero que entenderás no sólo como evitar estos errores particulares, sino también porque se convierten en vulnerabilidades a la seguridad. Entender cada uno de los posibles fallos te ayudará a evitar cometer los mismos errores en tus aplicaciones PHP.
La Seguridad es un proceso, no un producto, y adoptar un método estricto respecto a la seguridad durante el proceso de desarrollo de la aplicación te permitirá producir código más robusto y ajustado.
Errores de Entradas no Validadas
Uno de los -- si no el-- más comunes fallos de seguridad PHP es el error de entradas no validadas. El usuario provee datos que simplemente no pueden ser fiables. Deberías asumir que cada uno de los usuarios de tu aplicación Web es malicioso, ya que es cierto que alguno de ellos lo será. Entradas no validadas o inapropiadamente validadas es la causa raíz de muchos de los "exploits" que discutiremos más adelante en este artículo.
Como ejemplo, puedes escribir el siguiente código que permite al usuario ver un calendario que muestra un mes específico llamando al comando UNIX cal.
$month = $_GET[month];
$year = $_GET[year];
exec("cal $month $year", $result);
print "";
foreach ($result as $r) { print "$r
"; }
print "";
Este código tiene un enorme agujero de seguridad, ya que las variables $_GET[month] y $_GET[year]no son validadas de ningún modo. La aplicación trabaja perfectamente, mientras que el mes especificado sea un número entre 1 y 12, y el años sea provisto como un año de cuatro dígitos correcto. Sin embargo, un usuario malicioso puede añadir ";ls -la" al valor del año y de ese modo podrá ver una lista de los directorios html de tu sitio web. Un usuario extremadamente maliciosos puede añadir ";rm -rf" al valor del año y ¡¡borrar tu sitio Web completo!!
El modo apropiado para corregir esto es asegurarte que la entrada que recibes del usuario es la que esperas que sea. No uses validación JavaScript para esto; tales métodos de validación son fácilmente eludidos por un "exploiter" que crea su propio formulario o deshabilita el javascript. Necesitas añadir código PHP para asegurarte que las entradas del mes y del año son dígitos y sólo dígitos, como se muestra abajo.
$month = $_GET[month];
$year = $_GET[year];
if (!preg_match("/^[0-9]{1,2}$/", $month)) die("Bad month, please re-enter.");
if (!preg_match("/^[0-9]{4}$/", $year)) die("Bad year, please re-enter.");
exec("cal $month $year", $result);
print "";
foreach ($result as $r) { print "$r
"; }
print "";
Este código puede ser usado de modo seguro sin preocuparse porque un usuario puede proveer una entrada que pudiera comprometer tu aplicación, o al servidor en el que se ejecuta. Las expresiones Regulares son una excelente herramienta para la validación de entradas. Puden ser difíciles de dominar, pero son extremadamente útiles en este tipo de situación.
Deberías siempre validar los datos provistos por tus usuarios rechazando cualquier otro que los datos esperados. Nunca uses el método de aceptar cualquier dato excepto aquellos que sabes que son dañinos (esta es una fuente común de fallos de seguridad). A veces, los usuarios maliciosos pueden eludir esta metodología, por ejemplo, incluyendo una mala entrada pero oscureciéndola con caracteres nulos. Tal entrada podría pasar tus controles, pero podría seguir teniendo un efecto dañino.
Deberías ser tan restrictivo como te sea posible cuando validas una entrada. Si algunos caracteres no necesitan ser incluidos, deberías probablemente bien eliminarlos, o rechazar la entrada completamente.
Errores de Control de Acceso
Otro tipo de errores que no está restringido necesariamente a aplicaciones PHP, pero que es importante no obstante, es la vulnerabilidad del tipo de control de acceso. Este error se hace más sobresaliente cuando tienes ciertas secciones de tu aplicación que deben ser restringidas a ciertos usuarios, tales como una página de administración que permite cambiar los datos de configuración, o mostrar información sensible.
Deberías comprobar las credenciales del usuario cada vez que cargas una página restringida de tu aplicación PHP. Si compruebas las credenciales del usuario sólo en la página de inicio, un usuario malicioso puede entrar directamente a una URL de una página más "profunda", con lo que se saltará ese proceso de comprobación de credencial.
Es también aconsejable para reforzar tu seguridad, por ejemplo, restringir el acceso de los usuarios en la base de la dirección IP del usuario así como su nombre de usuario, si es posible. Colocar tus páginas restringidas en un directorio separado que está protegido por un archivo .htaccess de apache es también una buena práctica.
Colocar tus archivos de configuración fuera del directorio Web- accesible. Un archivo de configuración puede contener contraseñas de base de datos y otra información que podría ser usada por usuarios maliciosos para penetrar o deshacer un sitio; nunca permitas que esos archivos sean accesibles a usuarios remotos. Usa la función PHP include para incluir estos archivos desde un directorio que no es accesible a través de la Web, posiblemente incluyendo un archivo .htaccess conteniendo "deny from any". Aunque sea una redundancia, añadir varias capas de seguridad es algo positivo.
Para mis aplicaciones PHP, prefiero una estructura de directorio basada en el ejemplo de abajo. Todas las librerías de funciones, clases y archivos de configuración están almacenados en el directorio includes. Siempre nombra estos archivos include con una extensión .php, de modo que incluso si todas las protecciones son superadas, el servidor Web analizará el código PHP, y no se lo mostrará al usuario. Los directorios www y admin son los únicos directorios cuyos archivos deben ser accesibles directamente por una URL; El directorio admin está protegido por un archivo .htaccess que permite a los usuarios entrar sólo si conocen un nombre de usuario y contraseña que está almacenado en el archivo .htpasswd en el directorio raíz del sitio.
/home
/httpd
/www.example.com
.htpasswd
/includes
cart.class.php
config.php
/logs
access_log
error_log
/www
index.php
/admin
.htaccess
index.php
Deberías configurar tu directorio Apache indexado a 'index.php', y mantener un archivo index.php en cada directorio. Configuralo para redireccionar a tu página principal si el directorio no debería ser navegable, tal como un directorio de imágenes o similar.
Nunca, en ningún caso, hacer un backup de un archivo php en tu directorio Web expuesto añadiendo .bak o cualquier otra extensión al nombre del archivo. Si haces esto, el código PHP en el archivo no será analizado por el servidor Web, y puede ser obtenido como fuente por un usuario que dé casualmente con la URL del archivo backup. si ese archivo contiene contraseñas u otras información sensible, esa información podría ser leída ¡¡e incluso podría ser indexada por Google si su "spider" acaba tropezándose con ellos!! renombrar los archivos para que tengan una extensión .bak.php es más seguro que convertir una extensión .bak en una .php, pero la mejor solución es usar un sistema CVS (Code Version Control). CVS puede ser complicado de aprender, pero el tiempo que gastes en eso lo ahorrarás luego de muchos modos. El sistema salva cada versión de cada archivo en tu proyecto, que pueden tener un gran valor cuando se hacen cambios que causen problemas más tarde.
Protección Session ID
El secuestro de una Session ID puede ser un problema con los sitios Web con PHP. El componente de rastreo de sesión de PHP usa una única ID para cada sesión de usuario, pero si esta ID es conocida por otro usuario, esa persona puede secuestrar la sesión de usuario y ver la información que debería ser confidencial. El secuestro de la sesión ID no puede ser prevenido completamente; deberemos conocer los riesgos para saber como mitigarlos.
Por ejemplo, incluso después que un usuario haya sido validado y se le haya asignado una ID de seseión, deberías revalidad a ese usuario cuando él o ella ejecute cualquier acción altamente sensible, tales como resetear la contraseña. Nunca permitas a un usuario con una sesión validada escribir una nueva contraseña sin también escribir su vieja contraseña, por ejemplo. Deberías también evitar mostrar datos realmente sensitivos, tales como números de tarjetas de crédito, a usuarios que han sido sólo validados por una ID de sesión.
Un usuario que crea una nueva sesión haciendo logging debería asignarsele un ID de sesión nueva usando la función session_regenerate_id. Un usuario secuestrador intentará configurar su ID de sesión antes de hacer login; esto puede evitarse si regeneras la ID al hacer login.
Si tu sitio está manejando información crítica tal como números de tarjeta de crédito, siempre usa una conexión segura SSL. Esto te ayudará a reducir las vulnerabilidades de secuestro de sesión ya que la ID de sesión no puede ser absorbida y secuestrada fácilmente.
Si tu sitio se está ejecutando en un servidor Web compartido, debes ser consciente que cualquier variable de sesión puede ser vista fácilmente por cualquier otro usuario del mismo servidor. Mitiga esta vulnerabilidad almacenando todos los datos sensitivos en en un registro de la base de datos que está vinculado a la ID de sesión mejor que a una variable de sesión. Si debes almacenar una contraseña en una variable de sesión, no almacenes la contraseña en texto claro; usa la función sha1( ) (PHP 4.3+) o la función md5( ) para almacenar el "hash" de la contraseña en su lugar.
if ($_SESSION[password] == $userpass) {
// do sensitive things here
}
El código de arriba no es seguro, ya que la contraseña está almacenada en texto plano en una variable de sesión. En su lugar, usa código más parecido a éste:
if ($_SESSION[sha1password] == sha1($userpass)) {
// do sensitive things here
}
El algoritmo SHA-1 no deja de tener sus fallos, y avances posteriores en el poder de los ordenadores han hecho posible general lo que se conoce como colisiones (diferentes strings con el el mismo sum SHA-1). De todos modos está técnica sigue siendo mucho más segura que almacenar contraseñas en texto plano. Usa MD5 si debes (ya que es superior a usar texto plano) salvar contraseñas, pero recuerda que desarrollos recientes han hecho posible generar colisiones MD5 en menos de una hora en hardware de PC standard. Idealmente, debería usarse una función que implementara SHA-256; pero como tal función no está incorporada de momento en PHP debe ser encontrada separadamente.
Para lecturas más en profundidad sobre colisiones hash, junto con otros temas relacionados con la seguridad, El sitio Web de Bruce Schneier es un gran recurso.
Autor: Pax Dickinson
traducido por: Jesús Conde
|
Estare al pendiente de la segunda parte, Saludos.
|
05-01-2006
.
)
Mode Lineal
