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.

Falla 2: Control de acceso interrumpido

El proceso de control de acceso (conocido como autorización), es la manera en la que una aplicación web garantiza el acceso al contenido y la ejecución de funciones a algún usuario en particular.

Estas revisiones se hacen después de la autenticación y dictaminan qué es lo que los usuarios "autorizados" pueden hacer o no. ¿Así de entrada suena simple no lo crees? El problema es que no es tan sencillo implementar de manera correcta y eficientemente un sistema de autorización, ya que en primera, el modelo a seguir generalmente está estrechamente ligado con el contenido y las funcionalidades del sitio, y por otro lado, los usuarios pueden pertenecer a uno o varios grupos o roles cada uno con diferentes privilegios en el sistema.

Todo comienza cuando los desarrolladores desestiman la dificultad inherente en el proceso de la implementación de los mecanismos de control ya que en su mayoría los esquemas desarrollados no fueron deliberadamente designados para este propósito y fueron evolucionando junto con la aplicación web. En estos casos, se tienen varias versiones de las reglas de control de acceso regadas por todo el sitio, lo que ocaciona que a medida que el sitio crezca, la tarea de mantener toda esta colección de reglas va aumentanto hasta que se hace prácticamente insostenible y las reglas en sí dejan de tener sentido para los desarrolladores.

El problema continúa en virtud de que los controles de autorización, al estar tan íntimamente relacionados con la aplicación en sí, son difícilmente reutilizados o reimplementados en algún proyecto nuevo, lo que en su caso requerirá modificaciones.

Estos esquemas de control de acceso son fácilmente detectables y explotables por medio de llamadas a funciones o solicitudes de contenido que no debería proporcionarse. Resulta claro que las consecuencias son devastadoras puesto que además de ganar acceso a la visualización de contenido no autorizado, el atacante podría ejercer operaciones no autorizadas para cambiar o hasta eliminar los datos e incluso adueñarse de la administración del sitio.

Un ejemplo muy específico del problema del control de acceso son las interfaces que le permiten a los administradores manejar un sitio desde internet debido a que permiten controlar a los usuarios, los datos y el contenido del sitio. En algunos casos estos sitios implementan roles administrativos lo que permite una administración más fina. En virtud de todo el poder que concentran estas interfaces, se convierten comunmente en los objetivos primarios de cualquier ataque.

Virtualmente todos los sitios tienen algún mecanismo de control de acceso. Por esto es que es recomendable crear una política de control de acceso claramente documentada. Así mismo, la documentación de las etapas de diseño debería concentrarse en la implantación de dicha política.

Del mismo modo que con la política, el código que la implementa debe revisarse y después probarse mediante pruebas de penetración. Es recomendable que se diseñe para ser modular, estructurado y mayormente centralizado.

Finalmente, otra práctica importate es averiguar cómo se administran los sitios web, averigue cómo se hacen los cambios sobre las páginas, en dónde se prueban y cómo son transportados al servidor de producción. Si los administradores pueden hacer cambios de manera remota sería deseable saber cómo están protegidos esos canales.

4 de noviembre de 2005

Falla 4: Cross site scripting

Las vulnerabilidades de scripting de sitio cruzado (Cross-site scripting o simplemente XSS) ocurren cuando un atacante utiliza una aplicaciónb web para enviar código malicioso, generalmente en la forma de un script, a un usuario.

Estas fallas son bastante comunes y ocurren cuando una aplicación web utiliza (sin validar) los datos ingresados por un usuario a fin de generar la salida. En este caso, el navegador del usuario no tiene manera de saber que no se debería confiar en e script, por lo que eventualmente lo ejecutará y podrá acceder a cualquier sesión, cookies o alguna otra fuente de información sensible retenida en el navegador. Estos scripts pueden reescribir el contenido de la página HTML.

Los ataques XSS se pueden categorizar de la siguiente forma:

- Almacenados y
- Reflejados

Los araques almacenados son aquellos en los que el código inyectado reside permanentemente en los servidores que lo envían, ya sea en la base de datos, en un mensaje de un foro, en un log de un visitante, campo de comentario, etc.La víctima descarga el script malicioso del servidor cuando hace alguna solicitud de contenido.

Los ataques reflejados son aquellos donde el código inyectado es reflejado fuera del servidor, tal como en un mensaje de error, el resultado de una búsqueda o cualquier otra respuesta que incluya una parte de la entrada enviada al servidor como parte de una solicitud.

Los ataques reflejados son enviados a las víctimas por otras rutas tales como un correo electrónico u otro servidor web; en cuyo caso cuando el usuario da click sobre una liga o envía cierto tipo de forma, el código inyectado viaja al servidor web vulnerable, el que a su vez refleja el ataque al navegador del cliente, que ejecuta el código puesto que proviene de un servidor "seguro".

Las consecuencias de un ataque XSS son las mismas sin importar la variante del ataque del que se trate, la diferencia está en cómo llega al servidor el código malicioso. No hay que confiarse al pensar que un sitio de sólo lectura o "brochureware" no es vulnerable a los ataques XSS reflejados.
Los XSS pueden causar una variedad de problemas para el usuario final que van desde simples molestias en la navegación hasta compromisos completos de las cuentas en los sitios web. Los ataques más severos hacen pública la información de las cookies del usuario, permitiendo a los atacantes secuestrar la sesióny tomar el control de la misma. Otros ataques incluyen la divulgación de los archivos del usuario, la instalación de troyanos, la redirección del usuario a alguna otra página y la modificación de la presentación del contenido, como por ejemplo:

Un atacante podría modificar una comunicado de prensa que afecte la confianza de los consumidores o, en un sitio farmacéutico, podría modificar la información de dosificación de algún medicamento.

Los atacantes se ayudan de varios métodos para codificar la porción maliciosa del código, tal como el uso de Unicode, de ta forma que el request es menos sospechoso. Hay miles de variantes de estos ataques, que incluyen versiones que nisiquiera requeren de la inclusión de los símbolos <> (necesarios para definir scripts en las páginas web), por tanto es muy complicado filtrar exitosamente estos scripts. Lo que en todo caso se recomienda es la validación de la entrada contra una especificación clara de qué es lo que se espera. Los ataques XSS generalmente vienen desde scripts de JavaScript, aunque cualquier contenido activo incrustado (ActiveX,VBScript, Shockwave, Flash y muchos otros) es un peligro potencial.

Otros ataques se pueden presentar desde los mismísimos servidores de aplicaciones o de web subyacentes ya que éstos generan páginas muy simples en caso de que ocurran algunos errores como en el caso del error 404 (Page not found) o un error 500 (Internal server error). Si estas páginas reflejan información de la petición del usuario (tal como la URL de la cual se quiso acceder), podría ser vulnerable a un ataque XSS reflejado.

La probabilidad de que un sitio contenga vulnerabilidades XSS es extremadamente alta ya que hay una muy amplia variedad de formas de engañar a las aplicaciones web para que almacenen scripts maliciosos.

Los desarrolladores que traten de filtrar las partes maliciosas de estas peticiones están lejos de hacerlo efectivamente debido a las muchas codificaciones que se pueden usar.

Finalmente, no es difícil encontrar este tipo de debilidades, lo único que se necesita es un navegador y algo de tiempo, además de que hay muchas herramienta disponibles para ayudar a localizar las fallas y explotarlas a fin de inyectar ataques XSS en un sitio objetivo.