Un programa de Microsoft clona el entorno de trabajo del ordenador del usuario.
Hoy día resulta muy sencillo para los desarrolladores crear
aplicaciones que se ejecuten dentro de los navegadores. Mantener esas
aplicaciones a salvo de los hackers es otra cuestión distinta.
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 California, 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 entorno 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
entorno 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.”
Autor: Christopher Mims
Traducido por Francisco Reyes (Opinno)
Fuente: Technology Review
No hay comentarios.:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!