Riesgos de seguridad al cargar contenido externo en tu web

Desde hace algún tiempo, en todas las webs que auditamos con nuestro sistema de pentesting persistente Faast, una de las cosas que miramos es la lista de todas las fuentes de contenido externo que cargan en el sitio web. No solo lo que se carga en la página principal, sino lo que se carga en todas y cada una de las URLs de la web. Esto es importante, pues el ataque a los clientes de un sitio puede venir por un fallo en cualquiera de los servidores que están sirviendo código en la web que visualiza el cliente.

Los riesgos para un cliente pueden ser muchos, como el intento de distribución de malware o la inserción dentro de una Botnet JavaScript, pero también para el servidor, que al permitir que se cargue contenido se está abriendo la puerta a ataques de ClickJacking, Defacements, CSRF, etcétera, por lo que hay que tener mucho cuidado con qué contenido estás cargando en tu web.

El ataque de lo SEA a la web de la RSA Conference

Uno de los casos más recientes de ataque a una web mediante el compromiso de fuentes de contenido externo tuvo lugar en el defacement de la web de la RSA Conference, una de las conferencias de seguridad de más prestigio en el mundo. Para poder realizar el ataque, el grupo SEA (Syrian Electronic Army), aprovecho que se cargaba un fichero JavaScript desde un servidor web perteneciente a otro dominio. Este fichero se utilizaba para llevar las estadísticas de las visitas a la web y el grupo atacante busco la manera de que se cargara el fichero JavaScript que ellos querían. 

Figura 1: Esquema del ataque de SEA a la web de la RSA Conference

Para ello tenían que conseguir que el nombre de dominio del servidor remoto apuntara a una dirección IP controlada por ellos, por lo que revisaron en qué proveedor estaba registrado el dominio del servidor de las estadísticas e hicieron un ataque de phishing a los empleados del registrador - que buscaron por Linkedin - para robar credenciales de acceso a la gestión de los dominios.

Figura 2: Defacement mostrado por el fichero JavaScript malicioso cargado remotamente

Con una de esas identidades robadas fueron capaces de gestionar el DNS del dominio al que pertenecía el servidor de las estadísticas y hacer que el nombre del servidor que cargaba el fichero JavaScript en la web de la RSA Conference apuntara a un servidor web controlado por ellos, desde el que cargaron un fichero JavaScript distinto que mostraba el mensaje que ya se ha hecho famoso que puedes ver en la Figura 2.

El Malvertising o la distribución de malware por redes de publicidad

El termino de Malvertising viene de Malicious Advertising, o lo que es lo mismo, contratar con una empresa de publicidad una campaña en la que puedes meter contenido Flash o JavaScript. Esto ha demostrado ser una forma perfecta para para los amigos del Fraude Online de distribuir contenido JavaScript malicioso a través de los propios ficheros JavaScript de la red de publicidad que muchos sitios webs utilizan para ganar dinero. 

Figura 3: Esquema de Malvertising utilizado a través de Yahoo! Ad Network

Esto ha sucedido muchas veces en el paso, y la empresa FOX IT - donde trabajan algunos de los mejores investigadores de e-crime españoles - reportaron este año un caso de malvertising utilizando la red de Ads de Yahoo! para distribuir bots de diferentes tipos a través de un Kit de Exploits.

El Hot-linking de imágenes

No podía terminar esta recolección de ejemplos de porque puede ser malo utilizar contenido externo en tu web, sin hablar del Hot Linking. Cargar una imagen - por ejemplo para decorar un artículo en la página de noticias de la compañía o en el blog corporativo - puede terminar con un cambio de imagen en el servidor original que afecte a la reputación del sitio que incrusta la imagen.

Figura 4: Un mensaje típico de una web enfadada por el Hot-Linking

Este es un error muy de novato, y que en tiempos en los que el ancho de banda era más costoso para los servidores web estaba muy mal visto. Si tienes un blog corporativo evita este tipo de acciones para evitar problemas.

La privacidad de los usuarios

Cuando se carga contenido externo de una web remota, el uso de ese fichero JavaScript podría llevar a que se accediera a mucha información de la navegación de los usuarios. Es utilizado habitualmente por servicios de estadísticas, pero también mucho proveedores de tecnología hacen un seguimiento excesivo de la navegación de los usuarios.

Figura 5: Cómo Facebook espía la navegación de sus usuarios

Facebook está siendo investigado por la Unión Europea por espiar la navegación de los usuarios y Google ya fue demandado en Estados Unidos por espiar a sus usuarios. Ponerles sus librerías es abrir esa puerta de acceso a datos de tus clientes.

La carga de contenido externo hace menos segura tu web

Al final, cuando en una web se carga contenido remoto se está confiando en la seguridad de ese dominio, y no siempre es lo más adecuado, ya que los clientes del sitio web principal podrían verse atacados por un fallo en la seguridad de la gestión de cualquiera de los servidores remotos.

Por eso, cuando revisamos una web hay que mirar qué contenido se carga, y por qué se carga ese contenido. Al final, en la mayoría de los casos un fichero JavaScript o CSS podría cargarse desde el propio servidor y no dejar que un cambio en ese fichero JavaScript pudiera generar un fallo nada deseable, o una caída de servicio en alguno de esos servidores.

Figura 6: Contenido externo cargado en una web, visto con el inspector de contenido de Google Chrome

A lo largo de este tiempo hemos visto sitios que cargan ficheros JavaScript de efectos para el interfaz de usuario desde repositorios de código controlados por desarrolladores que ni son conocidos. Si ese desarrollador cierra, o lo que es peor, se vuelve malicioso y vende ese JavaScript a la distribución de malware, todos los sitios que lo incluyan estarán atacando a todos sus clientes.

Si es un fichero JavaScript para conseguir una determinada función en el interfaz de usuario o fichero CSS de una plantilla de la web, lo más sencillo sería copiar esos ficheros al servidor web principal y reducir al máximo el número de problemas que se deben afrontar.

Contenido externo y rendimiento

Una de las cosas que pueden llevar a alguien a cargar contenido desde servidores remotos es el límite de conexiones concurrentes paralelas que se pueden hacer desde un navegador de Internet a un servidor web. Esto no debería de ser un problema. En el caso de los límites del servidor web, eres tú el que lo controlas y configuras, así que haz tunning de tu servidor web y listo.

Figura 7: Tabla de conexiones concurrentes por hostname en cada navegador

En el caso del navegador del cliente sí que hay límites, pero los límites son por hostname, y como puede verse, estas son muchas. Si el rendimiento es un issue y necesitas paralelizar, lo mejor es que optimices el contenido que vas a cargar al cliente, uses ficheros JavaScript comprimidos y en bundle, y si son muchos los archivos que necesitas, pues que montes tu propia CDN con distintos hostnames o uses una CDN de confianza como servicio, pero cargar contenido de "por ahí" tiene sus riegos, así que evita todos los que puedas.

Saludos Malignos!