Con esto en mente, un grupo de científicos dentro de la rama de investigación de Microsoft han desvelado una nueva forma de asegurar aplicaciones web complejas mediante la clonación efectiva del navegador del usuario y su ejecución remota.
Muchas de las aplicaciones web más recientes dividen el código ejecutable entre el servidor y el cliente. El problema se da a la hora de detectar si el código que se ejecuta en el PC del usuario ha sido vulnerado de algún modo. La nueva solución de Microsoft, llamada Ripley, fue hecha pública hoy en la Conferencia de Seguridad Informática y de las Comunicaciones de la Asociación de Maquinaría de Computación en Chicago.
Ripley da un paso más allá en comparación con sus antedecesores a la hora de asegurar la integridad de las aplicaciones web. “Lleva la protección de la integridad a su extremo lógico,” afirma Adam Barth, investigador de la Universidad de Califo ia, Berkeley, y especializado en la seguridad de las aplicaciones web. No estuvo involucrado en el proyecto. “En vez de simplemente verificar que las peticiones provienen de la página web apropiada, Ripley verifica que las acciones del usuario están realmente permitidas por la interfaz de usuario de la aplicación.”
Ripley evita que los usuarios maliciosos o hackers remotos alteren el comportamiento del código que se ejecuta dentro del navegador web mediante la creación de una copia exacta del ento o computacional y la ejecución de dicha copia en el servidor. Después, Ripley envía todas las acciones del usuario, incluyendo los clics del ratón, las teclas pulsadas y otros registros de entrada, en un “flujo de eventos” comprimido desde el cliente al servidor. Este flujo se ejecuta a través de la aplicación clonada en el servidor, y el comportamiento de esa copia se compara con el de la aplicación que se está ejecutando en el navegador del usuario en casa. Si se da alguna discrepancia, Ripley desconecta al cliente.
“No puedes confiar en nada de lo que ocurra en el extremo del cliente,” afirma Ben Livshits, desarrollador principal del proyecto Ripley en Microsoft Research. “Desde el punto de vista del desarrollador, es como hablar del demonio disfrazado bajo la apariencia del navegador.”
Ripley es invisible para el usuario final y no afecta a la función normal de la aplicación web. “Sólo se tienen que preocupar los usuarios maliciosos de lo que ocurra una vez que envíen un resultado,” afirma Livshits.
Uno de los retos a los que se enfrentaron tanto Livshits como su colaborador en Microsoft, Emre Kiciman, a la hora de construir Ripley fue el modo de crear una copia del ento o completo del cliente—la aplicación web y el motor de software que la ejecuta—que fuese lo suficientemente pequeña como para que resultase práctica desde el punto de vista de un servidor web de alto volumen y la administración de peticiones de cientos de miles de usuarios al mismo tiempo.
En el servidor, según señala Livshits, “si tuvieses que ejecutar la réplica dentro de un navegador, incurrirías en una huella de memoria de entre 50 y 50 megabytes por cada instancia del navegador.” La solución que tanto él como Kiciman diseñaron consiste en ejecutar un “navegador sin cabeza”—un emulador que simula sólo las funciones del navegador web que son esenciales para Ripley. Esto hizo bajar la huella de memoria del navegador clonado y la aplicación hasta alcanzar un megabyte o un megabyte y medio por cada aplicación.
Al reducir el tamaño del clon de la aplicación ejecutada en el navegador del usuario y alojada en el servidor, Livshits y Kiciman redujeron aún más los problemas de rendimiento de Ripley. De un total de cinco aplicaciones experimentales, entre las que se incluían un carro de la compra, varios juegos y un motor de blogging, el incremento medio de la latencia debida al incremento de los esfuerzos de la CPU del servidor fue de alrededor de un milisegundo.
En algunos casos, Ripley incluso mejoró el rendimiento de las apliaciones web, puesto que el clon alojado en el servidor de la aplicación del cliente se reescribe en .Net, un lenguaje de programación que es de 10 a 100 veces más rápido que el JavaScript que se ejecuta en la zona del cliente. A veces esto permite a Ripley predecir cuál será la próxima petición de la aplicación por parte del cliente, incluso antes de que el cliente haya realizado dicha petición, con lo que los datos se envían al cliente con antelación.
“Si lo piensas, esta es una situación mágica,” afirma Livshits. “Nos lleva hasta una situación en la que la latencia es cero.”
En la actualidad, los desarrolladores interesados en utilizar Ripley para asegurar sus aplicaciones web tendrían que reimplementar en sus propios esquemas de aplicaciones web favoritos las ideas descritas en el estudio presentado sobre Ripley. Sin embargo, Livshits y Kiciman creen que en el futuro Ripley podría ayudar a democratizar una parte esencial de la seguridad de las aplicaciones web, haciendo que esté al alcance de aquellos desarrolladores menos expertos.
“Creo que hasta este momento la gente ha intentado atacar a estos problemas de forma manual,” afirma Kiciman. “Los expertos hacen las aplicaciones a medida para que se enfrenten a estos retos, pero esto es algo que no se puede escalar fácilmente, y no resulta demasiado ágil a la hora de hacer cambios. Lo que estamos intentando hacer es llevar la plataforma de desarrollo web a un punto en el que cualquiera pueda aprovecharse de las ventajas que ofrecen estos tipos de tecnologías que utilizan los expertos.”
Barth, desde la UC Berkeley, afirma que Ripley es parte de una tendencia mayor dentro de las soluciones diseñadas para proteger la integridad del código ejecutado por el cliente, una tendencia que consiste en asegurarse de que no se va a producir ningún tipo de comportamiento no autorizado en dicho código. “Creo que Ripley es más un experimento de pensamiento: ¿Qué ocurriría si el servidor validase todo?” afirma. “El estudio sugiere que la seguridad se vería beneficiada si validásemos más de lo que validamos hoy día.”