Emulación de librerías Javascript externas mediante pharming u otras técnicas de ataque.

Actualmente los frameworks de Javascript como jQuery, Mootools, YUI, Google Web Toolkit y otros, se han convertido más que en un accesorio en una necesidad. Son impresionantes los plugins pre-elaborados y las mejoras que podemos aplicar en las interfaces de usuarios con estas librerías, y un desarrollo web que no las contemple puede cargar a cuestas un serio "handicap" en relación con sus competidores.

No me opongo para nada al uso de las mismas, si bien como todo desarrollo pueden tener problemas de seguridad, estos son evaluados por profesionales expertos y en caso de descubrirse una vulnerabilidad sabemos que automáticamente estarían corrigiéndola. Sin embargo a lo que me opongo es a la moda muy peligrosa de incluir estas librerías directamente desde la fuente, o lo que es lo mismo sin utilizar una copia local, llamando a la librería correspondiente desde la fuente directa. Esto se suele hacer para poder tener a mano siempre la versión más actualizada, lo cual en principio no es una mala idea.

El problema con esta idea es puede ser más grave el daño que el beneficio que aporta, ya que bastaría con infectar el archivo "hosts" del equipo de la víctima mediante "pharming local" con una dirección que  sustituya la dirección en la que se puede obtener el código de la librería de javascript usada en nuestra aplicación y así la victima estaría descargando una copia con código adicional infectado.

Se podría obtener mucha información con solo colocar al final del código de una de estas librerías funciones adicionales que capturen la  información delicada y la hagan llegar al atacante mediante AJAX usando inclusive funciones de la librería que se está emulando. Todo esto sin que el usuario detecte absolutamente nada extraño. Para mostrar mi punto solo pregúntense si el usuaruio sabe o no si una página determinada está siendo evaluada por Google Analytics. Este es un caso legal, pero solo necesitan extrapolar la idea.

Lo peligroso de este ataque es que no existe forma práctica por parte de la víctima de detectarlo, el estaría accediendo a las páginas de sus aplicaciones preferidas sin que se emulara ningún componente (excepto las librerías que para el son transparentes).

Si bien existe una política de seguridad en los navegadores para el control de llamada a funciones y componentes del DOM desde sitios cruzados, es importante recordar que en este caso puede no ser muy útil, ya que lo que esta política evita es el llamar a una función o componentes del DOM desde otro página de otro dominio o sub-dominio, la librería de conexión está en capacidad de enviar cualquier cosa si es llamada desde la misma página.

Si esto último no fuera cierto siempre se podría hacer una llamada con parámetros desde un "tag" de imagen, una llamada javascript o un simple enlace. En HTML5 inclusive se pueden utilizar "websockets" para enviar los datos. Y aunque lográramos por políticas de seguridad que simplemente fuera imposible enviar datos, siempre podríamos generar una redirección no deseada a otra página.

Por tanto la recomendación a seguir para evitar este problema es muy sencilla:

No cargar librerías Javascript, plugins u otro tipo de scripts, desde sitios externos independientes en páginas donde se trate con información delicada. En estos casos es siempre preferible tener copia de dicha librería o plugin en nuestro servidor y cargarlos desde allí.

Hasta la próxima!