29 de noviembre de 2005

Falla 8: Almacenamiento inseguro

Por lo general las aplicaciones Web necesitan almacenar información sensible, ya sea en una base de datos, en un sistema de archivos o en algún otro medio. Ésta podría ser contraseñas, números de tarjetas de crédito, registros contables o información propietaria que con frecuencia es encriptada para protegerla.

Mientras que la encriptación se ha vuelto relativamente fácil de implementar y usar, los desarrolladores frecuentemente comenten errores de implementación cuando la integran dentro de una aplicación Web ya que generalmenete se sobreestima la protección ganada por el uso de la encriptación y no se cuida el asegurar otros aspectos del sitio.


Algunas áreas donde se cometen errores serían:


  • Fallar en la encriptación de información crucial

  • Almacenamiento inseguro de llaves, certificados y contraseñas

  • Almacenamiento incorrecto de datos sensibles en la memoria.

  • Seleccionar fuentes pobres de aleatorización de datos

  • Elegir algoritmos débiles para encripción

  • Intentar inventar nuevos algoritmos de encriptación

  • Fallar al incluir soporte para cambios en las llaves de encriptación y otros procedimientos requeridos para el mantenimiento.


El impacto de estas debilidades puede ser devastador para la seguridad del sitio Web. La encriptación por lo regular se usa para proteger los activos más sensibles del sitio, los cuales pueden ser totalmente comprometidos por un error como los antes mencionados.


La mayoría de los ambientes de aplicación Web incluyen alguna forma de soporte criptográfico. En el raro caso que tal soporte no se disponga de él hay una gran variedad de productos que se pueden agregar. Sólo los sitios Web que usan encriptación para proteger información almacenada o en tránsito son susceptibles a estos ataques.

Descubrir fallas criptográficas sin acceso al código fuente puede tomar muchísimo tiempo. Sin embargo, es posible examinar tokens, id’s de sesión, cookies y otras credenciales para ver si son o no aleatorias. Todas las estrategias criptoanalíticas pueden ser usadas para intentar descubrir cómo es que un sitio Web usa las funciones criptográficas.

Por mucho, la estrategia más fácil es revisar el código para ver cómo están implementadas las funciones criptográficas por lo que se debe llevar a cabo un cuidadoso escrutinio de la estructura, calidad e implementación de los módulos criptográficos, revisando siempre las metodologías para que las llaves, contraseñas y otros secretos se almacenen, protejan, carguen, procesen y limpien de la memoria.


La manera más fácil de protegerse contra las fallas criptográficas es minimizar el uso de la encriptación y sólo mantener la información que es absolutamente necesaria. Por ejemplo, más que encriptar los números de tarjetas de crédito y guardarlos, simplemente pida a los usuarios que los introduzcan nuevamente. También, en lugar de guardar las contraseñas encriptadas con un algoritmo que utilice llaves, use una función de una vía como SHA-1 para encriptar las contraseñas.

Si se impone el uso de algún método criptografico, escoja siempre una biblioteca que ha sido expuesta al escrutinio público y asegúrese de que no hay vulnerabilidades abiertas. Encapsule las funciones criptográficas que son usadas y revise el código cuidadosamente. Asegúrese de que los secretos, como las llaves, certificados y contraseñas son almacenados de forma segura. Un método interesante podría ser el uso de un secreto maestro dividido en al menos dos ubicaciones que se ensamblara en tiempo de ejecución. Tales ubicaciones pueden incluir archivos de configuración, un servidor externo o dentro del código mismo.

22 de noviembre de 2005

Falla 7: Manejo inadecuado de errores

El manejo inadecuado de errores puede introducir variados problemas de seguridad a un sitio Web. El error mas común es cuando se le muestra al usuario (posiblemente un usuario mal intensionado), información detallada de mensajes reporte de problemas como rastreos de pila, volcados de BD y códigos de error. Éstos revelan detalles de la implementación que nunca deberían ser revelados.
Tales detalles pueden proveer a los piratas informáticos de pistas importantes sobre potenciales fallas en el sitio y tales mensajes de error son también perturbadores para los usuarios normales.

Las aplicaciones Web frecuentemente generan condiciones de error durante su operación normal. Falta de memoria,
excepciones por punteros nulos, llamadas fallidas a sistema, BD no disponible, tiempo de espera de red agotado y cientos
de otras condiciones comunes pueden causar que los errores sean generados. Estos errores deben ser manejados de
acuerdo a un esquema bien pensado que provea al usuario de un mensaje de error con sentido, información de diagnostico
para quienes mantienen el sitio, y ninguna información útil para un atacante.

Incluso cuando los mensajes de error no proveen muchos detalles, las inconsistencias en tales mensajes pueden revelar
pistas importantes de cómo funciona un sitio y qué información esta presente bajo la cubierta. Por ejemplo, cuando un
usuario trata de acceder a un archivo que no existe, el mensaje de error tradicionalmente indica “archivo no encontrado”.
Cuando se accede a un archivo al que el usuario no está autorizado, se indica “acceso negado”. Se supone que el usuario
no debe saber siquiera si existe el archivo, pero tales inconsistencias claramente revelan la presencia o ausencia de
archivos inaccesibles o la estructura de directorios del sitio.

Un problema común de seguridad causado por el manejo inadecuado de errores es la prueba de seguridad de apertura de
archivos. Todos los mecanismos de seguridad deben negar el acceso hasta que sea específicamente otorgado, y no otorgar
acceso hasta que sea negado, lo cual es una razón común de porque ocurren los errores de apertura de archivos. Otros
errores pueden causar que el sistema se caiga o consuma recursos significativos, negando o reduciendo efectivamente el
servicio a usuarios legítimos.

Un buen mecanismo de manejo de errores debe ser capaz de manejar cualquier conjunto de entradas posible, mientras
fomenta una seguridad apropiada. Mensajes de error simples deben ser producidos y registrados de tal manera que su
causa, ya sea un error en el sitio o un intento de ataque, pueda ser revisada. El manejo de errores debe no sólo enfocarse
en las entradas proveídas por el usuario, sino que deben también incluir cualquier error que pueda ser generado por
componentes internos tales como llamadas al sistema, consultas de BD o cualquier otra función interna.

Tradicionalmente una revisión simple puede determinar cómo responde su sitio a varios tipos de errores de entrada.
Pruebas más profundas son usualmente requeridas para hacer que ocurran errores internos y ver cómo se comporta el sitio.
Otra estrategia importante es tener una revisión detallada del código que busque en éste la lógica en el manejo de errores.
El manejo de errores debe ser consistente a través de todo el sitio y cada pieza debe ser parte de un esquema bien
diseñado. Una revisión de código revelará cómo pretende el sistema manejar varios tipos de errores. Si encuentra que no hay organización en el esquema de manejo de errores o que parece que hay muchos esquemas diferentes, muy
posiblemente hay un problema.

Una política especifica de cómo manejar errores debería ser documentada, Incluyendo los tipos de errores a ser manejados
y, para cada uno de ellos, qué información debe ser reportada al usuario y qué información será registrada. Todos los
desarrolladores necesitan entender la política y asegurarse que su código la siga.

En la implementación, asegúrese de que el sitio está construido para manejar elegantemente todos los posibles errores.
Cuando los errores ocurran, el sitio debe responder con un resultado específicamente diseñado que sea de ayuda al
usuario, sin que revele detalles internos innecesarios. Ciertas clases de errores deben ser registrados para ayudar a detectar
errores de implementación en el sitio y/o intentos de ataque.

Muy pocos sitios tienen alguna habilidad de detección de intrusos en su aplicación Web, pero es ciertamente concebible que
una aplicación Web pueda rastrear repetidos intentos fallidos y generar alertas. Note que la vasta mayoría de ataques a
aplicaciones Web no son detectados nunca porque muy pocos sitios tienen la capacidad para hacerlo. Por lo tanto, el éxito
de los ataques contra la seguridad de aplicaciones Web parece ser seriamente subestimado.