Ripley

Tal vez al leer este título hayas pensado rápidamente en Alien, el Octavo pasajero. Otro de esos personajes de culto de los que tengo libros, comics y todas las películas en versión original, extendida, y montaje del director en una edición especial que se llama Quadrology.

Si he de ser sincero creo que el que el proyecto se llame Ripley algo debe de tener que ver con dicha película ya que Ripley, incluso con su muerte o con esa relación materno-filial que mantuvieron en una de las entregas, siempre ha vencido al Alien.

Tal vez por eso los investigadores de Microsoft Research le pusieron este nombre al proyecto en el que se intenta, por medio de una nueva aproximación, vencer al Alien que se introduce entre la aplicación web y el servidor o tal vez porque es por medio de un clon, como en Alien Resurection, con el que se quiere ganar la batalla.

La idea de la arquitectura en tres niveles, o en tres capas, divide las responsabilidades de cada elemento de forma clara. El almacén de datos debe cuidar de la integridad de la información, la lógica de negocio que corra en el servidor de aplicaciones y la interfaz de usuario en el cliente. Si bien esta división de Navegador, Servidor Web y Motor de Base de datos con funcionalidades repartidas ha evolucionado a una mayor granularidad con la división interna en otras capas de las funciones, apareciendo capas de acceso a datos, componentes distribuidos, servicios y todo lo que lleva el diseño moderno de servicios, sigue siendo más que valido este modelo para definir las aplicaciones web a alto nivel.

Si se da por perdido el navegador, es decir, por totalmente infectado, malévolo, interceptado o directamente como principal enemigo, el servidor web debe tomar todas las entradas como potencialmente maliciosas. Este comportamiento se basa en el principio de Defensa en Profundidad de las reglas de la fortificación de sistemas por las que se asume que todo elemento adyacente puede estar comprometido.

La aproximación hasta el momento se ha centrado en validar los datos y es ahí donde los atacantes se han esforzado en evolucionar, hacia la forma de crear nuevos patrones válidos de entrada que se salten las medidas de seguridad establecidas en el servidor. Esta aproximación a la solución obvia por completo la existencia del elemento principal del cliente: El interfaz de usuario.

Para ello, el proyecto Ripley propone hacer un clon del interfaz de usuario y reproducir las acciones realizadas por el usuario en el interfaz pero en el servidor. Es decir, si un usuario realiza una secuencia de 10 clics en 10 zonas distintas de la interfaz para generar un listado de datos, tradicionalmente se convierte en una llamada a un procedimiento de un servidor con una serie de parámetros. En un entorno de ataque, es probable que esa llamada no se haya producido haciendo clics en el interfaz, sino manipulando las llamadas.

Con Ripley la idea es que se validen los 10 clics en un clon que va a correr en el servidor y que va a permitir saber si esa acción que está realizando el cliente está permitida por el interfaz de usuario o no. Para poder validar la interfaz se ejecutará el clon del navegador, escrito en .NET en esta prueba de concepto, en el servidor web y sobre dicho clon se probarán las acciones recibidas desde el cliente. Si las acciones funcionan en el clon se continuará adelante con la aplicación. Si no funcionan en el clon no se ejecutarán en el servidor.

Esta aproximación a la solución de validación es un punto más en la fortificación de aplicaciones y una nueva aproximación a la seguridad de de las mismas. Abre muchas interrogantes sobre la carga de cómputo en el servidor, sobre meter una nueva capa de software que también puede ser víctima de ataques o de que no reproduzca fielmente la interfaz. Esto es especialmente delicado en el usao de plug-ins o componentes corriendo en el navegador. De momento es un proyecto del mundo académico, pero desde luego es una idea curiosa.

Puedes leer el Paper de Ripley y tienes más información en Segu-Info.

Saludos Malignos!