Skip to main content

Fugas XS: qué son y cómo evitarlas

Escrito por
feature buffer overflow

17 de julio de 2023

0 minutos de lectura

Las fugas entre sitios (fugas XS) son una clase de vulnerabilidades de seguridad web que permiten a los hackers obtener información confidencial de la sesión de navegación de un usuario en otros sitios web o aplicaciones web. Las aplicaciones web modernas comparten datos mediante diversas funciones y API, una característica que los atacantes pueden aprovechar para acceder a esos datos de usuario.

En última instancia, las fugas XS provocan la divulgación de información confidencial que los actores maliciosos pueden usar con diversos fines ilícitos, como obtener acceso no autorizado a sistemas o bases de datos confidenciales.

En este artículo, analizaremos en detalle qué son las fugas XS y cómo se producen. Después, veremos algunos ejemplos prácticos de cómo prevenirlas. 

Cómo se producen las fugas XS

Las aplicaciones web modernas son increíblemente complejas y están formadas por varios dominios con distintos niveles de confianza. Por eso, para ofrecer una experiencia fluida en el navegador, los sitios web necesitan compartir información. Aunque los desarrolladores han logrado que esta comunicación sea relativamente segura, las funciones de los sitios web y de los navegadores tienen algunas vulnerabilidades inherentes.

Las fugas XS se producen cuando los atacantes aprovechan estas vulnerabilidades para obtener acceso no autorizado a datos privados de los usuarios. Al manipular distintas funciones web, como cookies, API de JavaScript, hojas de estilo CSS y elementos HTML, y aprovechar canales laterales y vulnerabilidades específicas de las aplicaciones, los atacantes pueden extraer información confidencial de otros sitios web que visita un usuario. Además, estos ataques ocurren de manera silenciosa, sin que el usuario lo sepa ni dé su consentimiento.

¿Qué tipos de fugas XS existen?

Hay varios tipos de fugas XS que los atacantes pueden aprovechar. Veamos algunos.

Ataques de temporización

En un ataque de temporización, un actor malicioso intenta recopilar información confidencial del sistema midiendo cuánto tardan en realizarse distintas acciones. El hacker envía scripts especialmente diseñados al sitio objetivo para realizar llamadas a API, solicitudes AJAX o intentar activar solicitudes de recursos que requieren el uso compartido de recursos de origen cruzado (CORS). Luego, analiza cuánto duran estos procesos para deducir cómo funciona el sitio web o cómo maneja los datos.

Por ejemplo, un atacante podría observar cuánto tarda el proceso de validación del servidor en procesar distintos tipos de entradas, como combinaciones de nombres de usuario y contraseñas, mediante solicitudes de origen cruzado. Después, puede usar las diferencias de tiempo perceptibles para determinar si un intento de inicio de sesión tuvo éxito o para averiguar si un usuario es administrador o un usuario común. Esta información le permite decidir sus siguientes pasos.

Conteo de frames

En los ataques de conteo de frames, el hacker crea varios iFrames anidados que apuntan a distintas URL dentro de un sitio objetivo. Luego, aprovecha la funcionalidad CORS del sitio para ver cuántos frames carga el navegador del usuario cuando visita las URL objetivo. 

Imagina que un atacante crea varios iFrames anidados para secciones protegidas de un sitio web, como la configuración de la cuenta y el historial de pedidos. Cuando un usuario visita una página que contiene los iFrames inyectados por el atacante, este cuenta cuáles se cargan correctamente y cuáles no. Luego, puede usar esta información para deducir restricciones de la cuenta, como requisitos de autenticación o niveles de membresía, y averiguar si un usuario específico tiene permisos de acceso o interacciones previas con ciertas áreas del sitio objetivo.

Sondeo de caché

El sondeo de caché aprovecha las cachés del navegador, que almacenan contenido web de forma local en los dispositivos de los usuarios. Para ejecutar este ataque, el hacker crea un sitio web malicioso que solicita recursos específicos, como imágenes o scripts, del sitio objetivo. Los recursos solicitados tienen características particulares, como tamaños de archivo poco comunes o tiempos de carga distintivos. 

Los atacantes miden la rapidez con que se cargan los recursos cuando un usuario visita su sitio malicioso, ya sea directamente desde el servidor objetivo o desde las versiones almacenadas en caché en el navegador del usuario. Luego, el actor malicioso usa esta información para deducir si esos recursos ya estaban en la caché local del navegador del usuario.

Al igual que el conteo de frames, la información obtenida mediante el sondeo de caché puede servir para personalizar campañas de phishing, descubrir relaciones entre distintas cuentas utilizadas en varios servicios y plataformas en línea, y coordinar ataques más sofisticados.

¿Qué mecanismos hay detrás de las fugas XS?

Los ataques de fugas XS manipulan funciones inherentes de los navegadores y emplean técnicas de observación indirecta para obtener acceso no autorizado a datos confidenciales. Entre los mecanismos que contribuyen al éxito de un ataque de fuga XS se encuentran:

  • Aprovechamiento de las funciones del navegador — Los atacantes usan funciones del navegador como la precarga, el prerenderizado y distintas API, como Fetch o WebSockets. Pueden extraer información confidencial de los usuarios sin infringir directamente la política del mismo origen (SOP), al manipular o combinar estas funciones con otras técnicas, como el sondeo de caché.

  • Canales laterales — Son vías indirectas por las que los atacantes recopilan información confidencial. Lo hacen observando variaciones en factores como el tiempo de renderizado o los patrones de carga de recursos en los navegadores de los usuarios, en lugar de acceder directamente a los datos, debido a las restricciones de seguridad que las políticas SOP imponen en las aplicaciones web.

  • Comunicación de origen cruzado — Los atacantes también pueden apuntar a métodos de comunicación de origen cruzado, como la API postMessage y los web workers. Después, pueden interceptar o manipular mensajes entre distintos orígenes integrados en iFrames de una misma página.

Vulnerabilidades que aprovechan las fugas XS

Mediante los mecanismos descritos anteriormente, los atacantes pueden obtener acceso a información confidencial sin infringir directamente políticas de seguridad como CORS y SOP, que utilizan la mayoría de los sitios web modernos. 

Estas medidas no impiden que se produzcan fugas XS. Los atacantes pueden usar canales laterales para sortear las barreras de SOP, aprovechar errores de configuración de CORS y combinar otras vulnerabilidades para lanzar un ataque más coordinado.

CORS y SOP controlan cómo interactúan los recursos de distintos orígenes. SOP impide que las páginas web accedan a datos o contenido cargados desde otro dominio, lo que garantiza que los scripts se ejecuten en el contexto de su origen. CORS amplía esta política al permitir solicitudes específicas de origen cruzado, en las que el servidor autoriza explícitamente el acceso a sus recursos mediante encabezados HTTP. En teoría, esta combinación permite una comunicación segura entre sitios web y evita interacciones maliciosas entre dominios, como los ataques de falsificación de solicitudes entre sitios (CSRF) y el acceso no autorizado a los datos.

Sin embargo, como las fugas XS aprovechan canales laterales y la exposición indirecta de datos, los atacantes pueden eludir SOP al deducir información confidencial de otro origen. Del mismo modo, si CORS está mal configurado o implementado de forma insegura en una aplicación web, puede producirse una filtración de información.

Otra forma en que los actores maliciosos pueden ejecutar técnicas de fugas XS es combinar la explotación de vulnerabilidades. El cross-site scripting (XSS) es un ataque que funciona bien junto con las fugas XS. Después de aprovechar una vulnerabilidad XSS, un atacante también puede intentar provocar fugas XS mediante diversas funciones o API del navegador que exponen información a través de canales laterales. 

Un actor malicioso puede combinar estos dos vectores de ataque para obtener datos confidenciales del dominio comprometido y recopilar información adicional entre orígenes sin infringir directamente SOP.

¿Cuáles son las consecuencias de las fugas XS?

Los ataques de fugas XS pueden tener consecuencias graves, como la divulgación de información confidencial, cuando un atacante obtiene acceso a datos privados, incluidos datos personales o financieros. Luego, puede manipular, robar o usar indebidamente la información privada de un usuario sin su consentimiento.

Además, el secuestro de sesión es otra posible consecuencia de los ataques de fugas XS. Consiste en que un atacante toma el control de la sesión activa de un usuario y posiblemente realiza cambios no autorizados en su nombre. Estas consecuencias ponen en riesgo la privacidad y la seguridad de los usuarios, y socavan la confianza en las plataformas y los servicios en línea.

Es importante tener en cuenta que las fugas XS suelen considerarse parte de técnicas de ataque o vulnerabilidades más amplias. Las filtraciones de datos de alto perfil que reciben mucha atención de los medios quizá no indiquen que las fugas XS hayan sido el ataque principal. Sin embargo, los atacantes maliciosos pueden usarlas para llevar a cabo ataques más coordinados.

Prácticas recomendadas para reducir el riesgo de ataques de fugas XS

Aunque no existe una solución única para prevenir las fugas XS, hay formas de reducir considerablemente los riesgos asociados. En las siguientes secciones, repasaremos las prácticas recomendadas para mitigarlas y mostraremos de manera práctica cómo implementarlas.

Usa una política de seguridad de contenido

Implementa una política de seguridad de contenido (CSP) sólida para limitar las fuentes de contenido que el navegador puede cargar en tus sitios. Esta práctica reduce las posibles filtraciones de información causadas por atacantes que aprovechan XSS u otras vulnerabilidades basadas en inyección.

Puedes implementar CSP mediante un encabezado de respuesta HTTP llamado Content-Security-Policy, como se muestra a continuación:

<meta http-equiv="Content-Security-Policy" content="
    default-src 'none';
    script-src 'self' https://ajax.googleapis.com;
    img-src 'self';
    style-src 'self' https://fonts.googleapis.com;
    font-src 'self' https://fonts.gstatic.com;">

En este ejemplo, no se permite cargar recursos externos (default-src), a menos que otras directivas lo indiquen explícitamente. Solo podemos cargar scripts (script-src), imágenes (img-src), hojas de estilo (style-src) y fuentes (font-src) desde nuestro dominio (self) o desde Google API (googleapis.com).

Una CSP bien definida ayuda a evitar solicitudes de origen cruzado no autorizadas y la ejecución de código integrado, ya que especifica las fuentes permitidas para contenido como scripts, imágenes, hojas de estilo y otros.

Aplica el atributo SameSite a las cookies

El atributo SameSite de una cookie le indica al navegador si debe incluirla en solicitudes externas. Por ejemplo, en JavaScript se ve así:

document.cookie = "username=JohnDoe; path=/; Secure; SameSite=Strict";

La cookie username contiene JohnDoe como valor, y la ruta / significa que la cookie estará disponible en todas las páginas de nuestro dominio. La palabra clave Secure garantiza que la cookie solo se transmita a través de conexiones HTTPS. Por último, establecemos el atributo SameSite en uno de estos valores:

  • None — La cookie se adjuntará si se envía a través de un canal HTTPS seguro.

  • Lax — Es el comportamiento predeterminado de los navegadores basados en Chromium. La cookie se enviará con las solicitudes GET que se realicen durante la navegación de nivel superior,

  • Strict — La cookie nunca se enviará fuera de nuestro dominio.

Establecer el atributo SameSite de las cookies en Strict impide que se envíen durante solicitudes entre sitios y mitiga los ataques CSRF y algunos ataques de fugas XS, como los que implican mediciones de tiempo.

Reduce al mínimo el uso de datos confidenciales en las URL

Reducir al mínimo el uso de datos confidenciales en las URL es una práctica recomendada fundamental de ciberseguridad. Nunca incluyas datos confidenciales, como credenciales de usuario o información de identificación personal (PII), en las URL, ya que los atacantes pueden acceder a ellos fácilmente mediante el historial del navegador, los registros del servidor, los encabezados de referencia y los enlaces compartidos sin depurar.

Algunas formas de reducir al mínimo el uso de datos confidenciales son:

  • Usar solicitudes POST con HTTPS en lugar de incluir datos confidenciales en las URL

  • Usar tokens de sesión en lugar de enviar directamente credenciales de usuario o PII

Implementa límites de frecuencia

Otra práctica recomendada es aplicar límites de frecuencia en los endpoints confidenciales, en especial los vulnerables a intentos de enumeración o de fuerza bruta. Esta estrategia limita la cantidad de solicitudes que puede realizar un atacante en un periodo determinado y reduce la eficacia de los ataques de fugas XS. Hay bibliotecas o soluciones de middleware para implementar límites de frecuencia en distintos lenguajes de programación y frameworks web. 

En Node.js con Express, por ejemplo, tendrás que instalar el middleware express-rate-limit con el comando npm install express-rate-limit. Después, puedes configurar el limitador de solicitudes del lado del servidor así:

const express = require('express');
const app = express();
const RateLimit = require('express-rate-limit');

// Create a new limiter allowing 100 requests per hour from each IP address.
// You can adjust these numbers based on desired limits.
const apiLimiter = new RateLimit({
  windowMs: 60 * 60 * 1000,
    max: 100,
    message: "Too many requests from this IP. Please try again after an hour."
});

app.use('/api/sensitive-endpoint', apiLimiter); // Apply limit to sensitive API endpoint.

// Your other routes and middleware configurations here

app.listen(3000, () => {
 console.log("Server started on port ",3000);
});

Ten en cuenta que esta medida es más eficaz cuando se combina con otras. Refuerza tu perfil de seguridad frente a los ataques de filtración XS que se basan en enviar muchas solicitudes a tu servidor para recopilar información.

Usa configuraciones de CORS adecuadas

Asegúrate de que tu aplicación tenga configuraciones de CORS adecuadas para impedir que dominios no autorizados envíen solicitudes de origen cruzado y accedan a recursos protegidos. Configura correctamente los encabezados de CORS, como Access-Control-Allow-Origin, para que solo los orígenes de confianza puedan enviar solicitudes de origen cruzado y evitar el uso de comodines (*) innecesarios en las listas de orígenes permitidos.

Si un servidor permite cualquier origen (*) en su encabezado Access-Control-Allow-Origin o usa orígenes generados dinámicamente sin validarlos correctamente según la entrada del usuario (como un referente), los atacantes podrían aprovecharlo para enviar solicitudes de origen cruzado desde sitios web maliciosos.

Usa integraciones como Snyk Code

Snyk Code te ayuda a identificar y corregir vulnerabilidades de seguridad al integrarse en tu flujo de trabajo de desarrollo. Analiza dependencias, te alerta sobre vulnerabilidades, sugiere y aplica correcciones, y supervisa continuamente tu proyecto para detectar problemas de seguridad. Por ejemplo, al crear una aplicación con Node.js y Express.js, Snyk Code puede ayudar a protegerla frente a vulnerabilidades causadas por la falta de encabezados de seguridad mediante un proceso sencillo:

  1. Analiza las dependencias — Después de integrar Snyk en tu proyecto, puedes analizar sus dependencias y buscar vulnerabilidades conocidas en tus paquetes.

  2. Identifica el problema — Si faltan encabezados de seguridad, Snyk Code detectará esta vulnerabilidad y te alertará. Por ejemplo, Snyk podría identificar que a tu aplicación le falta el encabezado CSP, que puede ayudar a protegerla frente a ataques XSS.

  3. Sugiere una corrección — Snyk recomendará una corrección para la vulnerabilidad identificada. Si faltan encabezados de seguridad, podría sugerir agregar el middleware helmet a tu aplicación Express.js. Helmet es un paquete popular que ayuda a configurar varios encabezados de seguridad para tu aplicación de forma predeterminada.

Snyk también puede seguir supervisando tu proyecto para detectar nuevas vulnerabilidades o actualizaciones de las existentes. Recibirás alertas si surgen otros problemas, lo que te permitirá mantenerte al tanto de la seguridad de tu proyecto de forma continua.

Cómo controlar las filtraciones XS 

Las filtraciones XS permiten a los atacantes obtener información confidencial de la sesión de navegación de un usuario en otro sitio web. Los hackers aprovechan funciones del navegador, canales laterales y comunicaciones de origen cruzado. Algunas técnicas comunes de filtración XS incluyen ataques de sincronización, conteo de marcos y sondeo de caché.

No existe un método garantizado para prevenir las filtraciones XS, pero aplicar las prácticas recomendadas que se describen en este artículo puede reducir significativamente los riesgos y proteger la información confidencial de los usuarios frente al acceso o la divulgación no autorizados.

Comienza con Capture the Flag

Aprende a resolver desafíos de Capture the Flag con nuestro taller virtual 101 a pedido.