WebSockets: una dura lección

  • Por
En qué consiste WebSockets del HTML 5, los problemas de seguridad que actualmente tiene el protocolo y cómo afectan a los desarrolladores que confiaron la nueva tecnología de manera precipitada.
Bajo el paraguas de HTML5 han ido apareciendo, en los últimos meses, una gran cantidad de tecnologías que prometen dotar de una potencia a las aplicaciones web nunca vista antes. Una de estas tecnologías, WebSockets, se ha visto salpicada esta semana por una noticia tan relevante como triste: varios navegadores han tenido que desactivar su implementación al haberse descubierto un grave fallo de seguridad. En este artículo repasaremos los acontecimientos que han llevado a este hecho e intentaremos extraer una conclusión para el futuro.

Qué es WebSockets

WebSockets es una nueva tecnología que, en palabras del W3C, "permite a las aplicaciones web mantener una comunicación bidireccional con procesos en el lado del servidor". La primera aparición de un borrador de trabajo sobre esta tecnología data de Abril de 2009 y, aunque más de año y medio después sigue en el mismo estado, ha sido una tecnología que ha levantado grandes expectativas, hasta el punto de ser calificada como "el TCP de la Web". Esta tecnología venía a sustituir en buena a medida a XMLHttpRequest como forma de comunicación con el servidor, prometiendo simplificar el actual modelo.

Entras las características que hacen interesante a WebSockets se encuentra la promesa de ofrecer una API simple para comunicar con el servidor así como la posibilidad de que estas comunicaciones sean bidireccionales, es decir, que puedan iniciarse en el lado del servidor; todo ello con una mejora en la latencia que actualmente soportan esta clase de comunicaciones.

Los antecedentes

En Diciembre de 2009, apenas 8 meses después del primer borrador del W3C, Google Chrome se convertía en el primer navegador en ofrecer soporte para WebSockets. No tardaría en seguirle Safari, mientras que la gente de Firefox, Opera e Internet Explorer prefirió mantener una postura más conservadora al respecto, esperando a que la especificación fuera más firme y clara. Sin ir más lejos, un año después de que Chrome ya implementara Firefox, la gente de Mozilla se planteaba introducirlo en Firefox, pero concluían que esperarían a tener una versión más madura del futuro estándar, puesto que aún se cernían sobre él números interrogantes.

Sin embargo, para Diciembre de este año tanto Firefox como Opera habían, finalmente, implementado WebSockets (desde la versión 10.70 en Opera y desde la Beta 7 de Firefox 4), desdiciéndose de algún modo de sus palabras previas. Sólo la gente de Internet Explorer mantenía su idea original: esperar a una versión más estable de la especificación.

La noticia

Esta semana hemos conocido que Adam Barth y otros colegas han publicado un documento demostrando que el protocolo sobre el que funciona WebSockets es vulnerable. Esta vulnerabilidad afecta a todas las implementaciones de WebSockets, incluidas las que hicieron Java y Flash de esta nueva API, y que algunos desarrolladores han venido utilizando como sustitutivo en los navegadores que aún no la soportaban.

Esta vulnerabilidad es lo suficientemente grave como para haber llevado al equipo de Firefox y Opera a deshabilitar su implementación sobre WebSockets. La gente de Chrome y Safari aún no se habían pronunciado al respecto al momento de redactarse este artículo, aunque dada la gravedad del asunto no se esperaba otra reacción diferente que la que han tomado otros fabricantes.

El problema

El problema no es sólo el hecho de que WebSockets se haya demostrado gravemente vulnerable. La gran dificultad aquí se la van a encontrar los muchos desarrolladores que confiaron en que WebSockets era un estándar maduro, una tecnología sobre la que podían empezar a construir sus nuevas aplicaciones.

Estos desarrolladores se encontrarán, a partir de esta semana, con que casi ningún navegador va a seguir ofreciendo soporte a WebSockets, con lo que deberán reprogramar sus aplicaciones web. Aquellos que hayan utilizado la detección de características y se hayan apoyado en Java y Flash en los casos en que el navegador no implementara la tecnología tampoco habrán resuelto el problema puesto que estarán confiando en una implementación igual de insegura que la que sufren los navegadores, y que no sería de extrañar que también termine siendo desactivada en breve.

Algunos han decidido tomárselo con humor, haciendo circular por la Red un vídeo de humor al respecto de lo que está pasando con WebSockets. Otros, probablemente, no se lo han tomando con tanta filosofía.

La crítica

La situación que se ha creado en torno a WebSockets ha merecido una reflexión en algunos casos y una crítica en otros, dada su gravedad. Las primeras críticas no son actuales, se remontan al punto en el tiempo en que Chrome y Safari ya implementaban WebSockets, y Firefox y Opera estaban en proceso de hacerlo. Estas críticas afectaron a IE9 y su equipo de desarrollo y venían a señalar que el navegador de Microsoft era el menos respetuoso con los estándares. Todo lo ocurrido en el pasado con IE6 ha impedido a muchos ver que, con el desarrollo de IE9, Microsoft está siendo tanto o más respetuosa con los estándares que sus rivales, hasta el punto de haber sacado la mejor nota en los recientes tests sobre HTML5 que la W3C publicó hace unas semanas.

Quizás para poder comprender mejor porqué se ha llegado a este punto, deberíamos re-examinar el concepto de estándar. En un artículo anterior desgranamos los pasos que se tienen que seguir para que una especificación se convierta en Recomendación por parte del W3C, es decir, el estado de estándar. Obviamente los fabricantes de navegadores no pueden esperar a este estadio último para empezar a implementar la especificación en su software, pues de lo contrario tampoco se alcanzaría nunca el nivel de Recomendación, dado que es necesaria la existencia previa de dos implementaciones interoperables entre sí.

Sin embargo, muchos fabricantes de navegadores se han lanzado últimamente a una carrera por ser el que "más soporta los estándares" que les ha llevado a implementar especificaciones que, como WebSockets, no era más que un borrador de trabajo susceptible de todo tipo de modificaciones. La propia implementación que de WebSockets ha hecho Chrome ya había sufrido un cambio muy importante meses atrás, consecuencia de una de las revisiones que de WebSockets estaba haciendo su equipo de trabajo.

Y es precisamente balancear entre la prontitud a la hora de implementar una especificación susceptible de convertirse en estándar y la estabilidad suficiente para no hacer la vida más difícil a los desarrolladores de aplicaciones web, lo que debemos exigir a los fabricantes de navegadores. Nosotros no debemos ser, de nuevo, las víctimas de un nuevo escenario de "guerra de navegadores" en la que la amenaza de "no ser compatible" se convierta en arma arrojadiza entre Apple, Google, Microsoft, Mozilla y Opera.

La solución

En el caso concreto de WebSockets, es demasiado tarde para una solución. Pero podemos aprender para el futuro que, antes de empezar a utilizar una nueva API basada en un futuro estándar, no debemos dejarnos llevar por la parafernalia marketinera. En su lugar, debemos investigar directamente del W3C o el organismo estandarizador que corresponda, en qué estado de madurez se encuentra la especificación y evaluar si la ventaja que supone su uso merece la pena el riesgo de cambios sin compatibilidad hacia atrás o que, como en un caso grave como el de WebSockets, lleven a la desactivación total de la funcionalidad en los navegadores.

Otra posible solución es el ejercicio de su responsabilidad por parte de los fabricantes de navegadores, como generador de un soporte de plataforma como son, a la hora de implementar nuevas características. En concreto algunas voces piden que, cuando un fabricante decida "arriesgarse" e implementar una especificación que no está cerca de ser estable, lo haga bajo su propio etiquetado. Es decir, que las APIs correspondientes lleven un prefijo que las identifiquen unívocamente como propias del vendedor, al no estar respaldadas por ningún estándar. En Microsoft, por ejemplo, han seguido esta aproximación a la hora de implementar la API que sirve para medir los tiempos de carga de una aplicación web.

De este modo, un desarrollador que haga uso de esta API sabrá, sin género de duda, que esta tecnología es propia de Microsoft, puesto que no existe realmente un estándar maduro que la abale ni se tiene porqué esperar que los demás fabricantes de navegadores vayan a incluirlas de la forma en que Microsoft las ha implementado.

Bibliografía:

Autor

Javier Holguera

Desarrollador senior con tecnología .NET en Payvision.

Compartir

Comentarios

enrique_bran

04/1/2011
Imparcialidad
Reciban todos un cordial saludo, a mi parecer, este artículo a diferencia de la gran mayoría de esta excelente web, está muy notoriamente inclina a favor de Microsoft, solo faltó "QUE VIVA MICROSOFT", debo aceptar que parte del artículo tiene mucha razón, principalmente cuando se refiere a lo prematuros que podemos ser en algunos casos, pero con respecto a que Microsoft fue más prudente lo cambiaría por el hecho que MS suele considerar como estándares solo las tecnologías desarrolladas por ellos mismos, caso XML, con todo lo que se hizo.
Mi conclusión, buen artículo (como noticia), mal enfoque al tratar de favorecer a alguien que de sobra es conocido por su lentitud para implementar estándares.

PakoDiaz

04/1/2011
Los "Estandares" Que no son tan estadar
no creo que el articulo pretenda poner en lo alto a MS, mas si es una llamada de atención para conocer como funciona la estandarización de las tecnologías y aprender que no por que algo este disponible ya en su fase de borrador y se puedan hacer cosas bajo estas tecnologías sea viable crear algún proyecto real(con clientes y compromisos por ende), he visto sobretodo con CSS3 y HTML5 un ímpetu desbordado por implementar estos "estándares"(en borrador) lo mas potro posible por muchos desarrolladores que por lo bonito y las promesas de las nuevas tecnologías se emocionan y desean crear a la "ya!" su desarrollo olvidando muchas cosas como las compatibilidades hacia atrás, no estoy en contra de la implementación y que CSS3 y HTML5 sean el "futuro" mas si creo que falta para que estas tecnologías las podamos implementar confiados de su funcionamiento al 100% como un estándar real, hoy día aun los estándares no son estándares muchos son borradores y los que están ya marcados como estándares final ha sido mal implementados por los exploradores, que si la culpa lo tienen los exploradores!, pues si la tienen pero eso hace que la idea "estándar" no funcione en nuestros días, esto es un proceso que llevara su tiempo no hay nada mas difícil que ponernos de acuerdo, mientras tanto no esta de mas hacer experimentos con estas nuevas tecnologías darle probaditas al futuro haciendo experimentos, mas no una implementación formal en nuestros compromisos profesionales, por que de allí nos podemos llevar sorpresas como esta

Juan

27/3/2011
¿y el problema?
Todo un artículo hablando sobre un "problema", pero no se dice cuál es éste.

Nelton Rivera

04/2/2014
WebSockets problema? solucion?
muy bonita redaccion y presentacion, pero no describe exactamente cual es el problema de WebSockets en terminos de seguridad, tampoco encontre en el parrafo solucion algo que me indique que pasos seguir; solamente encuentro una advertencia para no usarlo.

... bueno, seguire esperando, de repente los desarrolladores corrigen el bug....

saludos!

jagarsoft

21/2/2016
y node.js?
¿No usa Node.js también los websockets? ¿También se ve afectado?