Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y automatizar fácilmente flujos de trabajo con las herramientas comunitarias más avanzadas del mundo.\
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres que tu **empresa sea anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**merchandising oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
* **Método de inclusión**: Es el método utilizado para cargar la web vulnerable desde la web del atacante (como window.open, iframe, fetch, etiqueta HTML con href...).
* **Técnica de filtración**: Después de acceder a la web vulnerable, se utilizará una técnica para diferenciar entre los posibles estados de la web con la información obtenida del método de inclusión utilizado.
* **Código de estado**. Un atacante puede distinguir **diferentes códigos de estado de respuesta HTTP** de origen cruzado (por ejemplo, errores del servidor, errores del cliente o errores de autenticación).
* **Uso de API**. Esta diferencia detectable permite a un atacante detectar el **uso de API web** en diferentes páginas, lo que le permite inferir si una página de origen cruzado está utilizando una API web JavaScript específica.
* **Redirecciones**. Es posible detectar si una aplicación web ha **redirigido al usuario a una página diferente**. Esto no se limita a las redirecciones HTTP, sino que también incluye redirecciones desencadenadas por JavaScript o HTML.
* **Contenido de la página**. Estas **diferencias detectables aparecen en el cuerpo de la respuesta HTTP** en sí o en los subrecursos incluidos por la página. Por ejemplo, esto podría ser el **número de frames incluidos** (cf. XS-Leak en Gitlab) o diferencias de tamaño de imágenes.
* **Encabezado HTTP**. Un atacante puede detectar la presencia de un **encabezado de respuesta HTTP específico** y puede ser capaz de recopilar su valor. Esto incluye encabezados como X-Frame-Options, Content-Disposition y Cross-Origin-Resource-Policy.
* **Elementos HTML**. HTML ofrece una variedad de elementos que permiten la **inclusión de recursos de origen cruzado**. Elementos como hojas de estilo, imágenes o scripts obligan al navegador de la víctima a solicitar un recurso no HTML especificado. Hay una lista que enumera los posibles elementos HTML para este propósito disponible en línea ([https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks)).
* **Frames**. Elementos como **iframe**, **object** y **embed** pueden incrustar recursos HTML adicionales directamente en la página del atacante. Si la página no utiliza protección de enmarcado, el código JavaScript puede acceder al objeto window del recurso enmarcado a través de la propiedad contentWindow.
* **Ventanas emergentes**. El método **`window.open`** carga un recurso en una nueva pestaña o ventana del navegador. El método devuelve un **identificador de ventana** que el código JavaScript puede usar para acceder a métodos y propiedades que cumplen con la SOP. Estas ventanas emergentes se utilizan a menudo en inicio de sesión único. Los navegadores modernos solo permiten ventanas emergentes si son desencadenadas por ciertas interacciones del usuario. Para los ataques XS-Leak, este método es especialmente útil porque **evita las restricciones de enmarcado y cookies para un recurso objetivo**. Las versiones más recientes de los navegadores recientemente agregaron medios para aislar los identificadores de ventana.
* **Solicitudes de JavaScript**. JavaScript permite enviar solicitudes directamente a recursos objetivo. Hay dos formas diferentes para este propósito: **XMLHttpRequests** y su sucesor **Fetch****API**. A diferencia de los métodos de inclusión anteriores, un atacante tiene un control detallado sobre la solicitud emitida, por ejemplo, si se debe seguir automáticamente una redirección HTTP.
### Técnicas de filtración
* **Manejador de eventos**. El manejador de eventos puede considerarse como la técnica clásica de filtración para XS-Leaks. Son una fuente conocida de varias piezas de información. Por ejemplo, el desencadenante de **onload** indica una carga exitosa de recursos en contraste con el evento onerror.
* **Mensajes de error**. Además de los manejadores de eventos, los mensajes de error pueden ocurrir como **excepciones de JavaScript** y **páginas de error especiales**. Los mensajes de error pueden ser lanzados en diferentes pasos, por ejemplo, directamente por la técnica de filtración. La técnica de filtración puede usar **información adicional** contenida directamente en el mensaje de error, o distinguir entre la **aparición y ausencia de un mensaje de error**.
* **Límites globales**. Cada computadora tiene sus límites físicos, al igual que un navegador. Por ejemplo, la cantidad de memoria disponible limita las pestañas en ejecución de un navegador. Lo mismo ocurre con otros límites del navegador que se aplican a todo el navegador. Si un atacante puede determinar **cuándo se alcanza el límite, esto puede usarse como una técnica de filtración**.
* **Estado global**. Los navegadores tienen **estados globales con los que todas las páginas pueden interactuar**. Si esta interacción es detectable desde el sitio web de un atacante, puede usarse como una técnica de filtración. Por ejemplo, la interfaz **History** permite la manipulación de las páginas visitadas en una pestaña o marco. Esto crea un estado global porque el **número de entradas** permite a un atacante sacar conclusiones sobre las páginas de origen cruzado.
* **API de rendimiento**. La API de rendimiento se utiliza para acceder a la **información de rendimiento de la página actual**. Sus entradas incluyen datos detallados de temporización de red para el documento y cada recurso cargado por la página. Esto permite a un atacante sacar **conclusiones sobre los recursos solicitados**. Por ejemplo, identificamos casos en los que los navegadores no crearán entradas de rendimiento para algunas solicitudes.
* **Atributos legibles**. HTML tiene varios **atributos que se pueden leer de origen cruzado**. Este acceso de lectura se puede utilizar como una técnica de filtración. Por ejemplo, el código JavaScript puede leer el número de marcos incluidos en una página web de origen cruzado con la propiedad window.frame.length.
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()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) permite a los desarrolladores obtener mediciones de tiempo de alta resolución.\
Hay una cantidad considerable de API que los atacantes pueden abusar para crear relojes implícitos: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast\_Channel\_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), animaciones CSS y otros.\
Para más información: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/).
XSinator es una herramienta automática para **verificar navegadores contra varias filtraciones XS conocidas** explicadas en su documento: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)\
**Filtraciones XS excluidas**: Tuvimos que excluir filtraciones XS que dependen de **service workers** ya que interferirían con otras filtraciones en XSinator. Además, elegimos **excluir filtraciones XS que dependen de una configuración incorrecta 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 filtraciones XS basadas en el tiempo ya que a menudo sufren de ser lentas, ruidosas e inexactas.
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** con las herramientas comunitarias más avanzadas del mundo.\
* **Resumen**: si se intenta cargar un recurso, los eventos onerror/onload se desencadenan cuando el recurso se carga exitosamente/no exitosamente, lo que permite determinar el código de estado.
* **Ejemplo de código**: [https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](https://xsinator.com/testing.html#Event%20Handler%20Leak%20\(Script\))
El ejemplo de código intenta **cargar objetos de script desde JS**, pero también se pueden usar **otros tags** como objetos, hojas de estilo, imágenes, audios. Además, también es posible inyectar directamente la **etiqueta** y declarar los eventos `onload` y `onerror` dentro de la etiqueta (en lugar de inyectarla desde JS).
* **Resumen**: La API **performance.now()** se puede utilizar para medir cuánto tiempo se tarda en realizar una solicitud. Sin embargo, también se pueden utilizar otros relojes, como la API **PerformanceLongTaskTiming**, que puede identificar tareas que se ejecutan durante más de 50 ms.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) otro ejemplo en:
Esta técnica es similar a la anterior, pero el **atacante** también **forzará** alguna acción para que tome un **tiempo relevante** cuando la **respuesta sea positiva o negativa** y medirá ese tiempo.
* **Resumen**: El reloj [SharedArrayBuffer](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) se puede utilizar para medir cuánto tiempo se tarda en realizar una solicitud. También se pueden utilizar otros relojes.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
Los eventos [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event) y [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event) se pueden utilizar para medir el tiempo que tarda en obtener un recurso. Esto funciona porque **`beforeunload`** se activa cuando el navegador realiza una nueva solicitud de navegación, mientras que **`unload`** se activa cuando esa navegación realmente ocurre. Debido a este comportamiento, es posible calcular la diferencia de tiempo entre estos dos eventos y medir el tiempo que tardó el navegador en completar la obtención del recurso.
* **Resumen**: La API **performance.now()** se puede utilizar para medir cuánto tiempo se tarda en realizar una solicitud. También se pueden utilizar otros relojes.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
Si una página no tiene implementadas [Protecciones de enmarcado](https://xsleaks.dev/docs/defenses/opt-in/xfo/), un atacante puede medir cuánto tiempo tarda en cargarse la página y todos los recursos secundarios a través de la red. Por defecto, el controlador `onload` de un iframe se invoca después de que se hayan cargado todos los recursos y se haya completado la ejecución de JavaScript. Sin embargo, un atacante puede eliminar el ruido de la ejecución de scripts incluyendo el atributo [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) en el `<iframe>`. Este atributo bloquea muchas funciones, incluida la ejecución de JavaScript, lo que resulta en una medición casi pura de la red.
* **Diferencia detectable**: Contenido de la página
* **Más información**:
* **Resumen**: Si puedes hacer que la página genere un error cuando se accede al contenido correcto y hacer 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**_" utilizando 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 cambiando solo el **contenido** del **hash** dentro de la URL.
Si la primera URL se **cargó correctamente**, entonces, al **cambiar** la parte del **hash** de la URL, el evento **onload** no se **activará nuevamente**. Pero si la página tuvo algún tipo de **error** al **cargarse**, entonces el evento **onload** se **activará nuevamente**.
* **Resumen**: Si la **página** devuelve el contenido **sensible**, o un contenido que puede ser controlado por el usuario. El usuario podría establecer un **código JS válido en el caso negativo**, y cargar cada intento dentro de etiquetas **`<script>`**, de modo que en los casos **negativos** se ejecute el **código** del atacante, y en los casos **afirmativos** no se ejecutará **nada**.
* **Resumen**: Los atacantes pueden observar cuando se aplica CORB si una respuesta devuelve un `Content-Type` protegido por CORB (y `nosniff`) con el código de estado `2xx`, lo que resulta en que CORB elimine el cuerpo y los encabezados de la respuesta. Detectar esta protección permite a un atacante **filtrar** la combinación tanto del **código de estado** (éxito vs. error) como del **`Content-Type` (protegido por CORB o no).**
Es posible **cargar una página** dentro de un **iframe** y usar el **`#id_value`** para hacer que la página se **enfoque en el elemento** del iframe indicado, luego, si se activa una señal **`onblur`**, el elemento ID existe.\
Puedes realizar el mismo ataque con etiquetas **`portal`**.
* **Resumen**: Recopilar información confidencial de un postMessage o utilizar 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 a menudo utilizan [postMessage broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) para compartir información con otros orígenes. Al escuchar estos mensajes, uno podría encontrar **información confidencial** (potencialmente si no se utiliza el parámetro `targetOrigin`). Además, el hecho de recibir algún mensaje puede ser **utilizado como un oráculo** (solo recibes este tipo de mensaje si has iniciado sesión).
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** con las herramientas comunitarias más avanzadas del mundo.\
* **Resumen**: Agotar el límite de conexiones WebSocket filtra el número de conexiones WebSocket de una página de origen cruzado.
* **Ejemplo de código**: [https://xsinator.com/testing.html#WebSocket%20Leak%20(FF)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(FF\)), [https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(GC\))
Es posible identificar si, y cuántas, **conexiones WebSocket utiliza 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 WebSocket.
Si un **origen** utiliza la **cantidad máxima de objetos de conexión 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 del atacante abre el sitio web objetivo en una ventana emergente o iframe y luego, después de que se haya cargado el sitio web objetivo, intenta crear el número máximo de conexiones WebSocket posibles. El **número de excepciones lanzadas** es el **número de conexiones WebSocket utilizadas por la ventana del sitio web objetivo**.
### Payment API
* **Métodos de inclusión**: Marcos, Ventanas emergentes
Debido a que **solo puede haber una solicitud de pago activa** al mismo tiempo, si el sitio web objetivo está utilizando la API de solicitud de pago, cualquier **intento posterior de mostrar esta API fallará** y provocará una **excepción de JavaScript**. El atacante puede aprovechar esto **intentando periódicamente mostrar la interfaz de la API de pago**. Si un intento provoca una excepción, significa que el sitio web objetivo la está utilizando. El atacante puede ocultar estos intentos periódicos cerrando inmediatamente la interfaz de usuario después de crearla.
El modelo de concurrencia de JavaScript se basa en un [bucle de eventos de un solo hilo](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop), lo que significa que **solo puede ejecutar una tarea a la vez**.\
Inferir **cuánto tiempo tarda en ejecutarse el código de un origen diferente** midiendo cuánto tiempo tarda en ejecutarse el siguiente en el grupo de eventos. El atacante sigue enviando eventos al bucle de eventos con propiedades fijas, que eventualmente se despacharán si el grupo está vacío. Otros orígenes despachan eventos al mismo grupo, y aquí es donde un **atacante infiere la diferencia de tiempo al detectar si ocurrió un retraso con una de sus tareas**.
{% hint style="warning" %}
En una medición de tiempo de ejecución, es posible **eliminar** los **factores de red** para obtener **mediciones más precisas**. Por ejemplo, cargando los recursos utilizados por la página antes de cargarla.
{% endhint %}
### Bucle de Eventos Ocupado <a href="#busy-event-loop" id="busy-event-loop"></a>
* **Métodos de Inclusión**:
* **Diferencia Detectable**: Tiempo (generalmente debido al contenido de la página, código de estado)
* **Resumen**: Mide el tiempo de ejecución de una web bloqueando el bucle de eventos de un hilo y cronometrando **cuánto tiempo tarda en estar disponible nuevamente el bucle de eventos**.
Una de las principales ventajas de esta técnica es su capacidad para eludir el Aislamiento del Sitio, ya que un origen atacante puede influir en la ejecución de otro origen.
En una medición de tiempo de ejecución, es posible **eliminar** los **factores de red** para obtener **mediciones más precisas**. Por ejemplo, cargando los recursos utilizados por la página antes de cargarla.
* **Resumen**: Un atacante podría bloquear todos los sockets excepto uno, cargar la página objetivo y al mismo tiempo cargar otra página, el tiempo hasta que la última página comienza a cargarse es el tiempo que la página objetivo tardó en cargarse.
Los navegadores utilizan sockets para comunicarse con los servidores. Como el sistema operativo y el hardware en el que se ejecuta tienen recursos limitados, **los navegadores tienen que imponer un límite**. Para explotar la existencia de este límite, los atacantes pueden:
1. Verificar cuál es el límite del navegador, por ejemplo, 256 sockets globales.
2. Bloquear 255 sockets durante un largo período de tiempo realizando 255 solicitudes a diferentes hosts que simplemente cuelgan la conexión.
3. Utilizar el socket 256 realizando una solicitud a la página objetivo.
4. Realizar una solicitud 257 a otro host. Dado que todos los sockets están siendo utilizados (en los pasos 2 y 3), esta solicitud debe esperar hasta que el pool reciba un socket disponible. Este período de espera proporciona al atacante el tiempo de sincronización de red del socket 256, que pertenece a la página objetivo. Esto funciona porque los 255 sockets en el paso 2 todavía están bloqueados, por lo que si el pool recibió un socket disponible, fue causado por la liberación del socket en el paso 3. El tiempo de liberación del socket 256 está directamente relacionado con el tiempo que tarda en completarse la solicitud.
Para obtener más información: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
* **Resumen**: Es como la técnica anterior, pero en lugar de utilizar todos los sockets, Google **Chrome** establece un límite de **6 solicitudes simultáneas al mismo origen**. Si **bloqueamos 5** y luego **lanzamos una sexta** solicitud, podemos **cronometrarla** y si logramos hacer que la página **víctima envíe** más **solicitudes** al mismo punto final para detectar un **estado** de la **página**, la **sexta solicitud** tardará **más tiempo** y podremos detectarlo.
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** con las herramientas comunitarias más avanzadas del mundo.\
La [`API de Rendimiento`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) proporciona acceso a información relacionada con el rendimiento mejorada por los datos de la [`API de Tiempo de Recursos`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API), que proporciona los tiempos de las solicitudes de red, como la duración, pero cuando el servidor envía una cabecera `Timing-Allow-Origin: *`, también se proporciona el tamaño de transferencia y el tiempo de búsqueda de dominio.\
Estos datos se pueden acceder utilizando [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) o [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName). También se puede utilizar para obtener el tiempo de ejecución utilizando la diferencia de [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now), sin embargo, esto parece ser menos preciso para una solicitud de Chrome porque solo proporciona los milisegundos.
Esta API se puede utilizar para medir el tiempo de una solicitud o para detectar el uso de X-Frame-Options, ya que la página bloqueada no se agregará al objeto `performance` en Chrome.
### Fuga de Errores
* **Métodos de Inclusión**: Marcos, Elementos HTML
* **Resumen**: Una solicitud que produce errores no creará una entrada de tiempo de recurso.
* **Ejemplo de código**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)
Es posible **diferenciar entre los códigos de estado de respuesta HTTP** porque las solicitudes que conducen a un **error** no crean una entrada de rendimiento.
* **Resumen**: Debido a un error del navegador, las solicitudes que producen errores se cargan dos veces.
* **Ejemplo de código**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)
En la técnica anterior también se identificaron dos casos en los que los errores en la recolección de basura del navegador provocan que los recursos se carguen dos veces cuando no se pueden cargar. Esto resultará en múltiples entradas en la API de Rendimiento y, por lo tanto, se pueden detectar.
* **Resumen:** Las solicitudes que resultan en un error no se pueden fusionar.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
La técnica se encontró en una tabla en el documento mencionado, pero no se encontró una descripción de la técnica en él. Sin embargo, puedes encontrar el código fuente que lo verifica en [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
* **Resumen:** Las respuestas vacías no crean entradas de temporización de recursos.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)
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 de XSS-Auditor**
* **Métodos de Inclusión**: Marcos
* **Diferencia Detectable**: Contenido de la Página
* **Resumen:** Detecta la presencia de elementos específicos en una página web con el XSS-Auditor en SA.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)
En SA, es posible detectar si se activó el XSSAuditor y, por lo tanto, filtrar información confidencial. El XSS-Auditor es una función incorporada de SA y GC (ahora eliminada) diseñada para mitigar los ataques de Cross-Site Scripting (XSS). En 2013, Braun y Heiderich \[7] demostraron que el XSS-Auditor se puede utilizar para bloquear scripts benignos con falsos positivos. Basándose en su técnica, los investigadores filtran información y detectan contenido específico en una página de origen cruzado. Estas XS-Leaks se describieron por primera vez en un informe de errores de Terada y luego en una publicación de blog de Heyes. Sin embargo, las técnicas descubiertas solo se aplican al XSS-Auditor en GC y no funcionan en SA. Descubrimos que las páginas bloqueadas no crearán entradas de Performance API. Esto significa que un atacante aún puede filtrar información confidencial con el XSS-Auditor en SA.
* **Resumen:** Un recurso con el encabezado X-Frame-Options no crea una entrada de temporización de recursos.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)
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 se utiliza una etiqueta **embed**.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)
Similar a la XS-Leak descrita, un **recurso que se descarga** debido al encabezado ContentDisposition, tampoco crea una entrada de rendimiento. Esta técnica funciona en todos los navegadores principales.
Encontramos una instancia de XS-Leak 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 de destino, consultando la **Performance API** y verificando los datos de temporización de **redirectStart**.
* **Resumen:** La duración de las entradas de temporización es negativa cuando ocurre un redireccionamiento.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)
En GC, la **duración** de las solicitudes que resultan en un **redireccionamiento** es **negativa** y, por lo tanto, se puede **distinguir** de las solicitudes que no resultan en un redireccionamiento.
* **Resumen**: Los recursos protegidos con CORP no crean entradas de tiempo de recurso.
* **Ejemplo de código**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)
En algunos casos, la **entrada nextHopProtocol** se puede utilizar como técnica de fuga. En GC, cuando se establece el **encabezado CORP**, el nextHopProtocol estará **vacío**. Tenga en cuenta que SA no creará ninguna entrada de rendimiento para los recursos habilitados para CORP.
Los trabajadores 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 sin conexión.\
Si un **recurso almacenado en caché** por un **trabajador de servicio** se accede a través de un **iframe**, el recurso se cargará desde la caché del trabajador de servicio.\
Para detectar si el recurso se cargó desde la caché del trabajador de servicio, se puede utilizar la **API de rendimiento**.\
Esto también se puede hacer con un ataque de temporización (consulte el documento para obtener más información).
Para obtener más información: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
## Técnica de mensajes de error
### Error de medios
* **Métodos de inclusión**: Elementos HTML (Video, Audio)
La propiedad de mensaje de la interfaz **`MediaError`** contiene una **cadena diferente para los recursos que se cargan correctamente**. Esto permite a un atacante inferir el estado de respuesta de un recurso de origen cruzado.
CORS permite que los recursos web de acceso público se lean y utilicen desde cualquier sitio web. En los navegadores basados en Webkit, es posible **acceder a los mensajes de error de CORS cuando falla una solicitud CORS**. Un atacante puede enviar una solicitud habilitada para CORS a un sitio web objetivo que **redirige** según el estado del usuario. Cuando el navegador deniega la solicitud, la **URL completa del destino de la redirección se filtra** en el mensaje de error. Con este ataque, es posible detectar redirecciones, filtrar ubicaciones de redirección y parámetros de consulta sensibles.
El atributo de integridad define un hash criptográfico mediante el cual el navegador puede verificar que un recurso recuperado no ha sido manipulado. Este mecanismo de seguridad se llama Integridad de Subrecursos (SRI). Se utiliza para la verificación de integridad de recursos servidos desde redes de entrega de contenido (CDN). Para evitar fugas de datos, los recursos de origen cruzado deben estar **habilitados para CORS**. De lo contrario, la respuesta no es elegible para la validación de integridad. Similar al error de CORS XS-Leak, es posible capturar el **mensaje de error después de una solicitud fetch con un atributo de integridad que falla**. Un atacante puede provocar **intencionalmente** este **error** en cualquier solicitud especificando un **valor de hash falso**. En SA, este mensaje de error revela la longitud del contenido del recurso solicitado. Un atacante puede utilizar esta filtración para detectar diferencias en el tamaño de la respuesta, lo que permite poderosos ataques XS-Leak.
* **Resumen**: Si solo se permite el sitio web de la víctima en el CSP y se intenta redirigir a un dominio diferente, el CSP activará un error detectable.
* **Ejemplo de código**: [https://xsinator.com/testing.html#CSP%20Violation%20Leak](https://xsinator.com/testing.html#CSP%20Violation%20Leak), [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation)
Un XS-Leak puede utilizar el CSP para detectar si un sitio de origen cruzado fue redirigido a un origen diferente. Esta filtración puede detectar la redirección, pero además, se filtra el dominio del destino de la redirección. 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 se **redirige** a un dominio de origen cruzado. El CSP **bloquea** el acceso a él y crea un **informe de violación utilizado como técnica de filtración**. 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.
* **Resumen**: Borra el archivo de la caché. Abre la página objetivo y verifica si el archivo está presente en la caché.
* **Ejemplo de código:**
Los navegadores pueden utilizar 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 información adicional), **realizar una solicitud** que podría cargar ese recurso e intentar cargar el recurso **con una solicitud incorrecta** (por ejemplo, utilizando un encabezado de referer demasiado largo). Si la carga del recurso **no desencadena ningún error**, es porque está **en caché**.
Una nueva función en GC permite que las páginas web propongan un CSP estableciendo un atributo en un elemento iframe. Las directivas de política se transmiten junto con la solicitud HTTP. Normalmente, el contenido incrustado debe permitir esto explícitamente con un encabezado HTTP, **de lo contrario se muestra una página de error**. Sin embargo, si el iframe ya envía un CSP y la nueva política no es más estricta, la página se mostrará normalmente.
Esto permite a un atacante detectar directivas CSP específicas de una página de origen cruzado, si es posible **detectar la página de error**. Aunque este error ahora está marcado como solucionado, encontramos una **nueva técnica de filtración que puede detectar la página de error, porque el problema subyacente nunca se solucionó**.
* **Resumen**: Un recurso protegido con CORP arroja un error al ser obtenido.
* **Ejemplo de código**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)
El encabezado CORP es una característica de seguridad relativamente nueva en la plataforma web que, cuando se establece, **bloquea las solicitudes de origen cruzado sin cors al recurso especificado**. La presencia del encabezado puede ser detectada, ya que un recurso protegido con CORP **arrojará un error al ser obtenido**.
* **Resumen**: CORB puede permitir a los atacantes detectar si el encabezado `nosniff` está presente en la solicitud.
* **Ejemplo de código**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)
Consulte el enlace de más información para obtener más detalles sobre el ataque.
### Error CORS en la mala configuración de reflexión de origen <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
* **Resumen**: Si el encabezado de origen se refleja en el encabezado `Access-Control-Allow-Origin`, es posible verificar si un recurso ya está en la caché.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
En caso de que el encabezado de origen se esté **reflejando** en el encabezado `Access-Control-Allow-Origin`, un atacante puede aprovechar este comportamiento para intentar **obtener** el **recurso** en modo **CORS**. Si no se produce un **error**, significa que se **obtuvo correctamente desde la web**; si se produce un **error**, es porque se **accedió 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).\
* **Resumen**: GC y SA permiten verificar el tipo de respuesta (`opaque-redirect`) después de que se haya completado la redirección.
* **Ejemplo de código**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)
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.
Las aplicaciones web pueden implementar el encabezado de respuesta COOP para evitar que otros sitios web obtengan referencias de ventana arbitrarias de la aplicación. Sin embargo, este **encabezado puede ser detectado fácilmente** al intentar leer la **referencia `contentWindow`**. Si un sitio solo implementa **COOP en un estado**, esta propiedad (`opener`) es **indefinida**, **de lo contrario** está **definida**.
* **Resumen**: Detectar diferencias en las respuestas debido a que la longitud de la respuesta de redirección puede ser demasiado grande y el servidor responde con un error, generando una alerta.
* **Ejemplo de código**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)
Si una redirección del lado del servidor utiliza **datos 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** tienen esa **longitud - 1**, debido a que la **redirección** está utilizando **esos datos** y **agregando** algo **adicional**, se producirá un **error detectable a través de eventos de error**.
Si de alguna manera puede establecer cookies para un usuario, también puede realizar este ataque mediante **configuración suficiente de cookies** ([**cookie bomba**](hacking-with-cookies/cookie-bomb.md)) para que con el **aumento del tamaño de respuesta** de la **respuesta correcta** se genere un **error**. En este caso, recuerde que si desencadena esta solicitud desde el mismo sitio, `<script>` enviará automáticamente las cookies (para que pueda verificar los errores).\
Un ejemplo de **cookie bomba + 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](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
`SameSite=None` o estar en el mismo contexto generalmente se necesita para este tipo de ataque.
* **Resumen**: Detecta diferencias en las respuestas debido a que la longitud de la respuesta de redireccionamiento puede ser demasiado grande para una solicitud, de manera que se pueda notar una diferencia.
* **Ejemplo de código**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
Según la [documentación de Chromium](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url\_display\_guidelines/url\_display\_guidelines.md#URL-Length), 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 problemas de denegación de servicio en la comunicación entre procesos.
Por lo tanto, si la **URL de redireccionamiento responde con un tamaño mayor en uno de los casos**, es posible hacer que se redireccione 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` arroja 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 **`origin`** de la ventana sigue siendo el del **padre**, lo cual 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**.
Si el número **máximo** de **redirecciones** que puede seguir un navegador es de **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 produce un **error**, significa que la página intentaba **redirigir a la víctima**.
La API de historial permite que el código JavaScript manipule el historial del navegador, que **guarda las páginas visitadas por un usuario**. Un atacante puede usar la propiedad de longitud como método de inclusión: para detectar la navegación de JavaScript y HTML.\
Al **verificar `history.length`**, haciendo que un usuario **navegue** a una página, **cambiándola** de nuevo a la misma origen y **verificando** el nuevo valor de **`history.length`**.
Un atacante podría usar código JavaScript para **manipular la ubicación del marco/pop-up a una supuesta** y **cambiarla inmediatamente a `about:blank`**. Si la longitud del historial aumenta, significa que la URL era correcta y tuvo tiempo de **aumentar porque la URL no se recarga si es la misma**. Si no aumenta, significa que **intentó cargar la URL supuesta** pero debido a que **inmediatamente después** cargamos **`about:blank`**, la **longitud del historial nunca aumentó** al cargar la URL supuesta.
Contar el **número de marcos en una página web** abierta mediante `iframe` o `window.open` puede ayudar a identificar el **estado del usuario en esa página**. Además, si la página siempre tiene 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** se puede **detectar** con el **conteo de marcos** porque se utiliza internamente un `embed`. Hay [Parámetros de URL abiertos](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) que permiten cierto control sobre el contenido, como `zoom`, `view`, `page`, `toolbar`, donde esta técnica podría ser interesante.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%20Leak](https://xsinator.com/testing.html#Media%20Duration%20Leak)
Algunas páginas web pueden **generar dinámicamente archivos multimedia** según la información del usuario o agregar marcas de agua que cambian el tamaño del medio. Un atacante puede utilizar la información filtrada por esos elementos HTML para distinguir entre posibles estados.
Algunos HTMLElements filtrarán información a través de orígenes cruzados, como el tipo de medio que son:
* [HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement) filtra la `duración` del medio y los tiempos `buffered`.
* [HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement) filtra `videoHeight` y `videoWidth`, algunos navegadores también pueden tener `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount` y `webkitDecodedFrameCount`.
* [HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement) filtra `height` y `width`, pero si la imagen no es válida, serán 0 y [`image.decode()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode) será rechazado.
Las aplicaciones web pueden cambiar el **estilo del sitio web según el estado del usuario**. Los archivos CSS de origen cruzado se pueden incrustar en la página del atacante con el **elemento de enlace HTML**, y las **reglas** se **aplicarán** a la página del atacante. Si una página cambia dinámicamente estas reglas, un atacante puede **detectar** estas **diferencias** según el estado del usuario.\
Como técnica de filtración, el atacante puede utilizar el método `window.getComputedStyle` para **leer las 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.
* **Ejemplo de código**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)
{% hint style="info" %}
Según [**esto**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/), esto no funciona en Chrome sin cabeza.
Usando el selector CSS [`:visited`](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited), es posible aplicar un estilo diferente a las URL que han sido visitadas.\
Anteriormente era posible utilizar [`getComputedStyle()`](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle) para detectar esta diferencia, pero ahora los navegadores lo impiden devolviendo siempre valores como si el enlace hubiera sido visitado y limitando los estilos que se pueden aplicar utilizando el selector.\
Por lo tanto, puede ser necesario engañar al usuario para que haga clic en un área en la que el CSS haya afectado esto se puede hacer utilizando [`mix-blend-mode`](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode).\
También hay formas de hacerlo sin interacción del usuario, como abusar de los tiempos de renderizado, esto funciona porque lleva tiempo pintar los enlaces de un color diferente.\
Se proporcionó una prueba de concepto en un informe de Chromium que funciona utilizando varios enlaces para aumentar la diferencia de tiempo.
* **Resumen:** En GC, cuando una página no está permitida para ser incrustada en una página de origen cruzado debido a **X-Frame-Options, se muestra una página de error**.
* **Ejemplo de código**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)
En Chrome, cuando una página no está permitida para ser incrustada en una página de origen cruzado, porque el encabezado **X-FrameOptions** (XFO) está configurado en deny o same-origin, en su lugar se muestra una **página de error**. Para los objetos, esta página de error se puede **detectar verificando la propiedad `contentDocument`**. Por lo general, esta propiedad devuelve null porque no se permite el acceso a un documento incrustado de origen cruzado. Sin embargo, debido a la **representación de Chrome** de la página de error, se devuelve un **objeto de documento vacío** en su lugar. Esto no funciona para iframes ni en otros navegadores. Los desarrolladores pueden olvidar configurar X-Frame-Options para todas las páginas y especialmente las páginas de error a menudo carecen de este encabezado. Como técnica de fuga, un atacante puede diferenciar entre diferentes estados de usuario verificando esto.
* **Resumen:** El atacante puede detectar descargas utilizando iframes. Si el iframe sigue siendo accesible, significa que el archivo se descargó.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)
El encabezado `Content-Disposition` ([`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)) indica si el navegador debe descargar el contenido o mostrarlo en línea.
Si solo un usuario con sesión iniciada pudiera **acceder a una página que descargará un archivo** porque está utilizando el encabezado. Es posible detectar ese comportamiento.
#### Barra de descarga <a href="#download-bar" id="download-bar"></a>
En los navegadores basados en Chromium, cuando se descarga un archivo, se muestra una vista previa del proceso de descarga **en una barra en la parte inferior**, integrada en la ventana del navegador. Al **monitorear la altura de la ventana**, los atacantes pueden detectar si se abrió la "barra de descarga".
#### Navegación de descarga (con iframes) <a href="#download-navigation-with-iframes" id="download-navigation-with-iframes"></a>
Otra forma de probar el encabezado [`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) es **verificar si ocurrió una navegación**. Si una carga de página provoca una descarga, no se activa una navegación y la **ventana permanece dentro del mismo origen**.
#### Navegación de descarga (sin iframes) <a href="#download-navigation-without-iframes" id="download-navigation-without-iframes"></a>
La misma técnica que la anterior, pero utilizando `window.open` en lugar de iframes.
### Bypass de caché HTTP particionada <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>
* **Resumen:** El atacante puede detectar descargas utilizando iframes. Si el iframe sigue siendo accesible, significa que el archivo se descargó.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (de [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
{% hint style="warning" %}
Por eso 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 de 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 se puede compartir. Puedes encontrar más detalles aquí: [Ganando seguridad y privacidad mediante la partición de la caché](https://developer.chrome.com/blog/http-cache-partitioning/)\
(Comentario de [**aquí**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
{% endhint %}
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 se solicitara directamente a través de una navegación de nivel superior. Esto se debe a que la clave de caché está compuesta por el _eTLD+1_ de nivel superior y el _eTLD+1_ del 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 cambió después de la interrupción, significa que el recurso se almacenó en caché.\
O simplemente **enviar algunas solicitudes fetch a la página potencialmente en caché y medir el tiempo que tarda**.
* **Resumen**: Es posible intentar cargar un recurso y abortar antes de que se cargue. Dependiendo de si se desencadena un error, el recurso se almacenó en caché o no.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
[**`AbortController`**](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) se puede combinar con _**fetch**_ y _**setTimeout**_ para detectar si el **recurso está en caché** y para eliminar un recurso específico de la caché del navegador. Una característica interesante de esta técnica es que la exploración se realiza sin almacenar en caché nuevo contenido en el proceso.
* **Resumen**: Cuando se incluye un **script de origen cruzado** en una página, no es posible leer directamente su contenido. Sin embargo, si un script **utiliza alguna función incorporada**, es posible **sobrescribirlas** y leer sus argumentos, lo que podría **filtrar información valiosa**.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
### Service Workers <a href="#service-workers" id="service-workers"></a>
* **Resumen**: Medir el tiempo de ejecución de una web utilizando service workers.
* **Ejemplo de código**:
1. El atacante registra un service worker en uno de sus dominios (attacker.com).
2. En el documento principal, el atacante emite una navegación (window.open) al sitio web objetivo e instruye al Service Worker para que inicie un temporizador.
3. Cuando la nueva ventana comienza a cargarse, el atacante navega la referencia obtenida en el paso 2 a una página manejada por el Service Worker.
4. Cuando la solicitud realizada en el paso 3 llega al service worker, devuelve una respuesta 204 (No Content), lo que aborta la navegación.
5. En este punto, el Service Worker recopila una medida del temporizador iniciado en el paso 2. Esta medida se ve afectada por el tiempo que JavaScript bloqueó la navegación.
{% hint style="warning" %}
En una medición de 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.
* **Resumen**: La API [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) se puede utilizar para medir cuánto tiempo se tarda en realizar una solicitud. Se pueden utilizar otros relojes.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
* **Resumen**: La API [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) se puede utilizar para medir cuánto tiempo se tarda en realizar una solicitud utilizando `window.open`. Se pueden utilizar otros relojes.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** con las herramientas comunitarias más avanzadas del mundo.\
Aquí encontrarás técnicas para exfiltrar información de un HTML de origen cruzado **inyectando contenido HTML**. Estas técnicas son interesantes en casos en los que, por alguna razón, puedes **inyectar HTML pero no puedes inyectar código JS**.
Sin embargo, si por alguna razón **DEBES** hacerlo **carácter por carácter** (tal vez la comunicación se realiza a través de una coincidencia en la caché), puedes utilizar 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 se carga la página:
Por lo tanto, lo que puedes hacer es **agregar una gran cantidad de 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á**, pero si aparece **después** de la **bandera**, la bandera + la basura **evitarán que se cargue** (tendrás que jugar con la cantidad de basura que colocar). Esto es lo que sucedió en [**este informe**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/).
Otra opción sería utilizar el **scroll-to-text-fragment** si está permitido:
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 **filtrar el secreto carácter por carácter**.
Algunos ejemplos de código para explotar esto: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
Si **no es posible cargar una imagen externa** que pueda indicar al atacante que la imagen se cargó, otra opción sería intentar **adivinar el carácter varias veces y medir eso**. Si la imagen se carga, todas las solicitudes tomarán más tiempo que si la imagen no se carga. Esto es lo que se utilizó en la [**solución de este informe**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **resumido aquí:**
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 es necesario verificar el resto de los **selectores**:
En esta sección puedes encontrar parte de las mitigaciones recomendadas en [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf), sin embargo, hay más mitigaciones en cada sección de la wiki [https://xsleaks.dev/](https://xsleaks.dev/). Echa un vistazo allí para obtener más información sobre cómo protegerse contra estas técnicas.
* **Elementos HTML**. Puede utilizar el **encabezado CORP para controlar si las páginas pueden incrustar un recurso**. CORP puede establecerse en same-origin o same-site y bloquea cualquier solicitud de origen cruzado o de sitio cruzado a ese recurso. En el **lado del cliente**, los navegadores basados en Chromium utilizan el algoritmo **CORB** para decidir si se deben permitir o denegar las solicitudes de recursos de origen cruzado.
* **Marcos**. La principal defensa para **evitar que los elementos iframe** carguen recursos HTML es el uso de **X-Frame-Options**. Alternativamente, la directiva **frame-ancestors de CSP** puede lograr un resultado similar. Si se niega la incrustación, el método de inclusión no puede detectar una diferencia en las respuestas.
* **Ventanas emergentes**. Para restringir el acceso a `window.opener`, el encabezado de respuesta HTTP **COOP** define tres valores diferentes: unsafe-none (predeterminado), same-origin-allow-popups y same-origin. Estos valores se pueden utilizar para **aislar las pestañas de navegación y las ventanas emergentes** y, por lo tanto, mitigar las técnicas de filtración basadas en ventanas emergentes.
* **Solicitudes de JavaScript**. Las solicitudes de JavaScript de origen cruzado se utilizan a menudo en ataques de XS-Leak, porque un atacante tiene un control detallado sobre la solicitud emitida. Sin embargo, dado que estas solicitudes no tienen habilitado CORS, están sujetas a las mismas restricciones que las solicitudes enviadas por elementos HTML, como scripts o imágenes. Por lo tanto, el impacto de esta técnica de filtración también se puede **mitigar mediante CORP y CORB**.
* **Metadatos de búsqueda**. Estas cabeceras de solicitud permiten a los propietarios del servidor comprender mejor cómo el navegador del usuario causó una solicitud específica. En Chrome, las cabeceras Sec-Fetch-\* se agregan automáticamente a cada solicitud y proporcionan metadatos sobre la procedencia de la solicitud. Por ejemplo, Sec-Fetch-Dest: image se activó desde un elemento de imagen. Las aplicaciones web pueden elegir bloquear solicitudes en función de esa información.
* **Cookies Same-Site**. La marca Same-Site en las cookies permite a los sitios web declarar **si una cookie debe estar restringida al mismo sitio o al contexto de primer nivel**. Todos los principales navegadores admiten cookies Same-Site. En Chrome, las cookies sin el atributo ahora son Lax de forma predeterminada. Para XS-Leaks, **las cookies Same-Site limitan drásticamente las posibilidades de ataque de filtración**. Por otro lado, las técnicas de filtración que dependen de **`window.open` aún funcionan con `SameSite=Lax`**. Los sitios web que utilizan **otros métodos de autenticación**, como certificados en el lado del cliente y autenticación HTTP, **siguen siendo vulnerables**.
* **Desvinculación de Identificadores de Origen Cruzado (COIU)**. COIU, también conocido como Aislamiento de Primera Parte (FPI), es una función de seguridad opcional que los usuarios pueden habilitar en la configuración avanzada de FF (about:config) y que se introdujo inicialmente en el navegador Tor. En una vista abstracta, es un contexto de mismo sitio extendido. **Vincula múltiples recursos** (por ejemplo, cookies, caché, almacenamiento en el lado del cliente) **a la primera parte** en lugar de compartirlos entre todos los sitios web visitados. Si se habilita, COIU disminuye drásticamente la aplicabilidad de XS-Leaks, ya que solo son posibles los métodos que utilizan ventanas emergentes para cumplir con el requisito de primera parte de la política.
* **Protecciones de seguimiento**. Apple implementó un mecanismo de privacidad llamado **Prevención de seguimiento inteligente (ITP)** en SA que tiene como objetivo combatir el seguimiento entre sitios limitando las capacidades de las cookies y otras API web. En versiones más recientes de SA, ITP bloquea todas las cookies de terceros de forma predeterminada sin excepciones \[74]. Este bloqueo evita todas las filtraciones que no se basan en ventanas emergentes. FF adoptó un enfoque similar con la Prevención de seguimiento mejorada (ETP), pero solo bloquean cookies de terceros específicas pertenecientes a proveedores de seguimiento. En el contexto de XS-Leaks, ETP solo mitiga las técnicas de filtración que apuntan a estos dominios de seguimiento.
* **Extensiones del navegador**. Los usuarios conscientes de la seguridad pueden utilizar **extensiones del navegador para prevenir ciertos métodos de inclusión**.
### Mitigaciones de Técnicas de Filtración
* **Controlador de eventos**. La **mitigación más efectiva** para esta técnica de filtración sería **denegarlos todos**, pero esto rompería la mayoría de las aplicaciones web en Internet. Por lo tanto, proponemos **reducir la cantidad de información necesaria que se puede recopilar dentro de los eventos**. Por ejemplo, el evento de violación de CSP no debe contener la URL de destino de redirección en el campo blockedURI. Este comportamiento está implementado en FF y en versiones más recientes de GC, solo SA sigue siendo vulnerable.
* **Mensajes de error**. Para mitigar las filtraciones de XS-Leaks basadas en la técnica de filtración de mensajes de error, hay dos requisitos principales. En primer lugar, **los mensajes de error no deben contener información detallada**, de manera similar a los mensajes de controlador de eventos. En segundo lugar, los navegadores deben **minimizar la aparición de mensajes de error**. XS-Leaks como SRI Error, ContentDocument XFO o Fetch Redirect detectan si se lanza un mensaje de error o no.
* **Límites globales**. La corrección de las técnicas de filtración que abusan de los límites globales es relativamente compleja porque se basan en restricciones físicas. La recomendación general es **restringir los límites globales en función de cada sitio de manera pequeña**. Si el límite global es 1, como en el caso de la API de pago, el atacante puede intentar activar silenciosamente la interfaz de pago web en cualquier momento, lo cual solo tiene éxito si la interfaz no se está utilizando simultáneamente en ninguna otra pestaña. Recomendamos acceder a la API de pago solo cuando se haya utilizado un evento confiable. De esta manera, el límite global se establece en cero a menos que el usuario dé su consentimiento, como un clic izquierdo del mouse en una ventana de diálogo, lo que establece el límite global en uno.
* **Estado global**. **No se debe acceder a ninguna propiedad del estado global del navegador**. Por ejemplo, FF es el único navegador que actualiza el historial del estado global cuando ocurre una redirección, lo que resulta en la lectura de history.length. Los navegadores deben crear una nueva propiedad de historial cuando ocurre una redirección en lugar de almacenarla globalmente. Otros ejemplos son los recursos compartidos, como las cachés. Las filtraciones de caché abusan de la caché compartida utilizada para todos los sitios web abiertos en un navegador. Para mitigar por completo las técnicas de filtración de caché, la caché HTTP debe estar particionada en función de cada sitio, como lo implementan SA, GC y FF. Tenga en cuenta que en SA, los iframes no se ven afectados por la partición de la caché.
* **API de rendimiento**. Demostramos que la API de rendimiento es una excelente técnica de filtración. En muchos XS-Leaks, pudimos detectar la diferencia entre si la respuesta de una solicitud de origen cruzado tiene o no una entrada de rendimiento. Como unificación, recomendamos asegurarnos de que todas las solicitudes creen dicha entrada y que solo se registre el subconjunto correcto de información de temporización para las solicitudes de origen cruzado.
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** con las herramientas comunitarias más avanzadas del mundo.\
