Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas comunitarias más avanzadas del mundo.\
<summary><strong>Aprende hacking en AWS desde cero hasta experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
* **Web Vulnerable**: El sitio web objetivo del cual se pretende extraer información.
* **Web del Atacante**: El sitio web malicioso creado por el atacante, que la víctima visita, alojando el exploit.
* **Método de Inclusión**: La técnica empleada para incorporar la Web Vulnerable en la Web del Atacante (por ejemplo, window.open, iframe, fetch, etiqueta HTML con href, etc.).
* **Técnica de Fuga**: Técnicas utilizadas para discernir diferencias en el estado de la Web Vulnerable basadas en la información recopilada a través del método de inclusión.
* **Estados**: Las dos condiciones potenciales de la Web Vulnerable, que el atacante busca distinguir.
* **Diferencias Detectables**: Variaciones observables en las que el atacante se basa para inferir el estado de la Web Vulnerable.
* **Código de Estado**: Distinguir entre **varios códigos de estado de respuesta HTTP** de origen cruzado, como errores de servidor, errores de cliente o errores de autenticación.
* **Uso de API**: Identificar **el uso de APIs web** en las páginas, revelando si una página de origen cruzado emplea una API web específica de JavaScript.
* **Redirecciones**: Detectar navegaciones a diferentes páginas, no solo redirecciones HTTP, sino también aquellas desencadenadas por JavaScript o HTML.
* **Contenido de la Página**: Observar **variaciones en el cuerpo de la respuesta HTTP** o en los subrecursos de la página, como el **número de marcos incrustados** o disparidades de tamaño en imágenes.
* **Encabezado HTTP**: Notar la presencia o posiblemente el valor de un **encabezado de respuesta HTTP específico**, incluidos encabezados como X-Frame-Options, Content-Disposition y Cross-Origin-Resource-Policy.
* **Temporización**: Observar disparidades de tiempo consistentes entre los dos estados.
* **Elementos HTML**: HTML ofrece varios elementos para **inclusión de recursos de origen cruzado**, como hojas de estilo, imágenes o scripts, obligando al navegador a solicitar un recurso no HTML. Una recopilación de posibles elementos HTML para este propósito se puede encontrar en [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks).
* **Marcos**: Elementos como **iframe**, **object** y **embed** pueden incrustar recursos HTML directamente en la página del atacante. Si la página **carece de protección de enmarcado**, JavaScript puede acceder al objeto window del recurso enmarcado a través de la propiedad contentWindow.
* **Pop-ups**: El método **`window.open`** abre un recurso en una nueva pestaña o ventana, proporcionando un **identificador de ventana** para que JavaScript interactúe con métodos y propiedades siguiendo la SOP. Los pop-ups, a menudo utilizados en inicio de sesión único, evitan las restricciones de enmarcado y cookies de un recurso objetivo. Sin embargo, los navegadores modernos restringen la creación de pop-ups a ciertas acciones del usuario.
* **Solicitudes JavaScript**: JavaScript permite solicitudes directas a recursos objetivo utilizando **XMLHttpRequests** o la **Fetch API**. Estos métodos ofrecen un control preciso sobre la solicitud, como optar por seguir redirecciones HTTP.
* **Manejador de Eventos**: Una técnica de fuga clásica en XS-Leaks, donde los manejadores de eventos como **onload** y **onerror** proporcionan información sobre el éxito o fracaso de la carga de recursos.
* **Mensajes de Error**: Las excepciones de JavaScript o páginas de error especiales pueden proporcionar información de fuga directamente desde el mensaje de error o diferenciando entre su presencia y ausencia.
* **Límites Globales**: Las limitaciones físicas de un navegador, como la capacidad de memoria u otros límites impuestos por el navegador, pueden indicar cuándo se alcanza un umbral, sirviendo como técnica de fuga.
* **Estado Global**: Las interacciones detectables con los **estados globales de los navegadores** (por ejemplo, la interfaz History) pueden ser explotadas. Por ejemplo, el **número de entradas** en el historial de un navegador puede ofrecer pistas sobre las páginas de origen cruzado.
* **API de Rendimiento**: Esta API proporciona **detalles de rendimiento de la página actual**, incluidos los tiempos de red para el documento y los recursos cargados, permitiendo inferencias sobre los recursos solicitados.
* **Atributos Legibles**: Algunos atributos HTML son **legibles de origen cruzado** y pueden utilizarse como técnica de fuga. Por ejemplo, la propiedad `window.frame.length` permite a JavaScript contar los marcos incluidos en una página web de origen cruzado.
XSinator es una herramienta automática para **verificar navegadores contra varios XS-Leaks conocidos** explicados en su documento: **[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)**
**XS-Leaks Excluidos**: Tuvimos que excluir XS-Leaks que dependen de **service workers** ya que interferirían con otras fugas en XSinator. Además, elegimos **excluir XS-Leaks que dependen de configuraciones incorrectas y errores en una aplicación web específica**. Por ejemplo, configuraciones incorrectas de Compartir Recursos de Origen (CORS), filtraciones de postMessage o Cross-Site Scripting. Además, excluimos XS-Leaks basados en tiempo ya que a menudo sufren de ser lentos, ruidosos e inexactos.
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas comunitarias más avanzadas del mundo.\
Algunas de las siguientes técnicas van a utilizar el tiempo como parte del proceso para detectar diferencias en los posibles estados de las páginas web. Hay diferentes formas de medir el tiempo en un navegador web.
**Relojes**: La API [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) permite a los desarrolladores obtener medidas de tiempo de alta resolución.\
Hay una cantidad considerable de APIs que los atacantes pueden abusar para crear relojes implícitos: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast\_Channel\_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), animaciones CSS y otros.\
* **Resumen**: si se intenta cargar un recurso, los eventos onerror/onload se activan cuando el recurso se carga con éxito/no con éxito, es posible averiguar el código de estado.
* **Ejemplo de código**: [https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](https://xsinator.com/testing.html#Event%20Handler%20Leak%20\(Script\))
El ejemplo de código intenta **cargar objetos de scripts desde JS**, pero **otros tags** como objetos, hojas de estilo, imágenes, audios también podrían ser utilizados. Además, también es posible inyectar directamente la **etiqueta** y declarar los eventos `onload` y `onerror` dentro de la etiqueta (en lugar de inyectarla desde JS).
* **Resumen:** La [**API performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) se puede utilizar para medir cuánto tiempo se tarda en realizar una solicitud. Sin embargo, se podrían utilizar otros relojes, como la [**API PerformanceLongTaskTiming**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming) que puede identificar tareas que se ejecutan durante más de 50 ms.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) otro ejemplo en:
Esta técnica es similar a la anterior, pero el **atacante** también **forzará** alguna acción para que tome un **tiempo relevante** cuando la **respuesta sea positiva o negativa** y medirá ese tiempo.
* **Resumen:** El reloj [SharedArrayBuffer](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) se puede utilizar para medir cuánto tiempo se tarda en realizar una solicitud. Se podrían utilizar otros relojes.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
El tiempo necesario para recuperar un recurso se puede medir utilizando los eventos [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event) y [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event). El evento **`beforeunload`** se dispara cuando el navegador está a punto de navegar a una nueva página, mientras que el evento **`unload`** ocurre cuando la navegación realmente está teniendo lugar. La diferencia de tiempo entre estos dos eventos se puede calcular para determinar la **duración que el navegador pasó recuperando el recurso**.
* **Resumen:** La [API performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) se puede utilizar para medir cuánto tiempo se tarda en realizar una solicitud. Se podrían utilizar otros relojes.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
Se ha observado que en ausencia de [Protecciones de Enmarcado](https://xsleaks.dev/docs/defenses/opt-in/xfo/), un atacante puede medir el tiempo requerido para que una página y sus subrecursos se carguen a través de la red. Esta medición es típicamente posible porque el controlador `onload` de un iframe se activa solo después de completarse la carga de recursos y la ejecución de JavaScript. Para evitar la variabilidad introducida por la ejecución de scripts, un atacante podría emplear el atributo [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) dentro del `<iframe>`. La inclusión de este atributo restringe numerosas funcionalidades, especialmente la ejecución de JavaScript, facilitando así una medición que está predominantemente influenciada por el rendimiento de la red.
```javascript
// Example of an iframe with the sandbox attribute
* **Resumen**: Si puedes hacer que la página genere un error cuando se accede al contenido correcto y que cargue correctamente cuando se accede a cualquier contenido, entonces puedes hacer un bucle para extraer toda la información sin medir el tiempo.
Puedes hacer que la víctima busque el archivo que contiene "_**flag**_" usando un **Iframe** (explotando un CSRF, por ejemplo). Dentro del Iframe, sabes que el _**evento onload**_ se **ejecutará siempre al menos una vez**. Luego, puedes **cambiar** la **URL** del **iframe** pero cambiando solo el **contenido** del **hash** dentro de la URL.
Si la primera URL se **cargó correctamente**, entonces, al **cambiar** la **parte hash** de la URL, el evento **onload****no se activará** nuevamente. Pero **si** la página tuvo algún tipo de **error** al **cargar**, entonces, el evento **onload** se **activará nuevamente**.
* **Resumen:** Si la **página** está **devolviendo** el **contenido sensible**, **o** un **contenido** que puede ser **controlado** por el usuario. El usuario podría establecer **código JS válido en el caso negativo**, y **cargar** cada intento dentro de las etiquetas **`<script>`**, por lo que en los casos **negativos** el código de los atacantes **se ejecuta**, y en los casos **afirmativos** no se ejecutará **nada**.
* **Resumen**: **Cross-Origin Read Blocking (CORB)** es una medida de seguridad que evita que las páginas web carguen ciertos recursos sensibles de origen cruzado para protegerse contra ataques como **Spectre**. Sin embargo, los atacantes pueden explotar su comportamiento protector. Cuando una respuesta sujeta a **CORB** devuelve un `Content-Type` protegido por **CORB** con `nosniff` y un código de estado `2xx`, **CORB** elimina el cuerpo y los encabezados de la respuesta. Los atacantes que observan esto pueden inferir la combinación del **código de estado** (indicando éxito o error) y el `Content-Type` (indicando si está protegido por **CORB**), lo que lleva a una posible fuga de información.
Es posible **cargar una página** dentro de un **iframe** y usar el **`#id_value`** para hacer que la página se **enfoque en el elemento** del iframe con el id indicado, luego si se activa una señal **`onblur`**, el elemento ID existe.\
* **Resumen**: Recopilar información sensible de un postMessage o utilizar la presencia de postMessages como un oráculo para conocer el estado del usuario en la página.
Las aplicaciones utilizan con frecuencia las transmisiones de [`postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) para comunicarse entre diferentes orígenes. Sin embargo, este método puede exponer inadvertidamente **información sensible** si el parámetro `targetOrigin` no está correctamente especificado, lo que permite que cualquier ventana reciba los mensajes. Además, el simple acto de recibir un mensaje puede actuar como un **oráculo**; por ejemplo, ciertos mensajes solo podrían enviarse a usuarios que hayan iniciado sesión. Por lo tanto, la presencia o ausencia de estos mensajes puede revelar información sobre el estado o la identidad del usuario, como si están autenticados o no.
* **Resumen:** En las Afirmaciones de Seguridad (SA), los mensajes de error de CORS exponen inadvertidamente la URL completa de las solicitudes redirigidas.
Esta técnica permite a un atacante **extraer el destino de la redirección de un sitio de origen cruzado** explotando cómo los navegadores basados en Webkit manejan las solicitudes CORS. Específicamente, cuando se envía una solicitud **habilitada para CORS** a un sitio objetivo que emite una redirección basada en el estado del usuario y el navegador posteriormente niega la solicitud, la **URL completa del destino de la redirección** se revela dentro del mensaje de error. Esta vulnerabilidad no solo revela el hecho de la redirección, sino que también expone el punto final de la redirección y cualquier **parámetro de consulta sensible** que pueda contener.
* **Resumen:** En las Afirmaciones de Seguridad (SA), los mensajes de error de CORS exponen inadvertidamente la URL completa de las solicitudes redirigidas.
Un atacante puede explotar **mensajes de error detallados** para deducir el tamaño de las respuestas de origen cruzado. Esto es posible debido al mecanismo de Integridad de Subrecursos (SRI), que utiliza el atributo de integridad para validar que los recursos recuperados, a menudo de CDNs, no hayan sido manipulados. Para que SRI funcione en recursos de origen cruzado, estos deben estar **habilitados para CORS**; de lo contrario, no están sujetos a comprobaciones de integridad. En las Afirmaciones de Seguridad (SA), al igual que el error de CORS XS-Leak, un mensaje de error puede ser capturado después de que falle una solicitud de recuperación con un atributo de integridad. Los atacantes pueden **provocar deliberadamente este error** asignando un **valor de hash falso** al atributo de integridad de cualquier solicitud. En SA, el mensaje de error resultante revela inadvertidamente la longitud del contenido del recurso solicitado. Esta fuga de información permite a un atacante discernir variaciones en el tamaño de la respuesta, allanando el camino para ataques sofisticados de XS-Leak.
* **Resumen:** Al permitir solo el sitio de la víctima en la CSP, si intentamos acceder y se redirige a un dominio diferente, la CSP generará un error detectable.
Un XS-Leak puede utilizar la CSP para detectar si un sitio de origen cruzado fue redirigido a un origen diferente. Esta fuga puede detectar la redirección, pero además, se filtra el dominio del destino de la redirección. La idea básica de este ataque es **permitir el dominio objetivo en el sitio del atacante**. Una vez que se emite una solicitud al dominio objetivo, este se **redirige** a un dominio de origen cruzado. La CSP **bloquea** el acceso a él y crea un **informe de violación utilizado como técnica de fuga**. Dependiendo del navegador, **este informe puede filtrar la ubicación objetivo de la redirección**.\
Los navegadores pueden usar una caché compartida para todos los sitios web, independientemente de su origen, es posible deducir si una página de destino ha **solicitado un archivo específico**.
Si una página carga una imagen solo si el usuario ha iniciado sesión, puedes **invalidar** el **recurso** (para que ya no esté en caché si lo estaba, ver más información en los enlaces), **realizar una solicitud** que podría cargar ese recurso e intentar cargar el recurso **con una solicitud incorrecta** (por ejemplo, usando un encabezado de referente demasiado largo). Si la carga del recurso **no desencadena ningún error**, es porque estaba **en caché**.
Una característica novedosa en Google Chrome (GC) permite a las páginas web **proponer una Política de Seguridad de Contenido (CSP)** configurando un atributo en un elemento iframe, con directivas de política transmitidas junto con la solicitud HTTP. Normalmente, el contenido incrustado debe **autorizar esto a través de un encabezado HTTP**, o se muestra una **página de error**. Sin embargo, si el iframe ya está gobernado por una CSP y la política recién propuesta no es más restrictiva, la página se cargará normalmente. Este mecanismo abre un camino para que un atacante **detecte directivas CSP específicas** de una página de origen cruzado identificando la página de error. Aunque esta vulnerabilidad se marcó como solucionada, nuestros hallazgos revelan una **nueva técnica de fuga** capaz de detectar la página de error, lo que sugiere que el problema subyacente nunca se abordó completamente.
* **Resumen:** Los recursos asegurados con la Política de Recursos de Origen Cruzado (CORP) generarán un error al ser recuperados desde un origen no permitido.
El encabezado CORP es una característica de seguridad de plataforma web relativamente nueva que cuando se establece **bloquea las solicitudes de origen cruzado no-cors al recurso dado**. La presencia del encabezado puede ser detectada, porque un recurso protegido con CORP **generará un error al ser recuperado**.
### Error de CORS en la mala configuración de Reflexión de Origen <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
* **Resumen**: Si el encabezado de Origen se refleja en el encabezado `Access-Control-Allow-Origin`, es posible verificar si un recurso ya está en la caché.
* **Ejemplo de Código**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
En caso de que el **encabezado de Origen** se esté **reflejando** en el encabezado `Access-Control-Allow-Origin`, un atacante puede abusar de este comportamiento para intentar **recuperar** el **recurso** en modo **CORS**. Si no se **desencadena un error**, significa que se **recuperó correctamente del sitio web**, si se **desencadena un error**, es porque se **accedió desde la caché** (el error aparece porque la caché guarda una respuesta con un encabezado CORS que permite el dominio original y no el dominio del atacante)**.**\
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.
Un atacante es capaz de deducir la presencia del encabezado de Política de Apertura de Origen Cruzado (COOP) en una respuesta HTTP de origen cruzado. COOP es utilizada por aplicaciones web para impedir que sitios externos obtengan referencias de ventana arbitrarias. La visibilidad de este encabezado se puede discernir intentando acceder a la referencia **`contentWindow`**. En escenarios donde COOP se aplica condicionalmente, la propiedad **`opener`** se convierte en un indicador revelador: es **indefinida** cuando COOP está activa, y **definida** en su ausencia.
* **Resumen:** Detecta diferencias en las respuestas debido a que la longitud de la respuesta de redirección podría ser demasiado grande y el servidor responde con un error y se genera una alerta.
Si una redirección del lado del servidor utiliza **entrada de usuario dentro de la redirección** y **datos adicionales**. Es posible detectar este comportamiento porque por lo general los **servidores** tienen un **límite de longitud de solicitud**. Si los **datos del usuario** tienen esa **longitud - 1**, porque la **redirección** está usando **esos datos** y **agregando** algo **extra**, desencadenará un **error detectable a través de Eventos de Error**.
Si de alguna manera puedes establecer cookies a un usuario, también puedes realizar este ataque **configurando suficientes cookies** ([**bomba de cookies**](hacking-with-cookies/cookie-bomb.md)) para que con el **aumento del tamaño de la respuesta correcta** se genere un **error**. En este caso, recuerda que si activas esta solicitud desde un mismo sitio, `<script>` enviará automáticamente las cookies (así que puedes verificar los errores).\
Un ejemplo de **bomba de cookies + XS-Search** se puede encontrar en la solución prevista de este informe: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
* **Resumen:** Detecta diferencias en las respuestas debido a que la longitud de la respuesta de redirección podría ser demasiado grande para una solicitud que se pueda notar una diferencia.
* **Ejemplo de Código**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
Contar el **número de frames en una web** abierta mediante `iframe` o `window.open` puede ayudar a identificar el **estado del usuario en esa página**.\
Además, si la página siempre tiene el mismo número de frames, verificar **continuamente** el número de frames puede ayudar a identificar un **patrón** que podría filtrar información.
Un ejemplo de esta técnica es que en Chrome, un **PDF** puede ser **detectado** con el **conteo de frames** porque se utiliza internamente un `embed`. Hay [Parámetros de URL Abierta](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) que permiten cierto control sobre el contenido como `zoom`, `view`, `page`, `toolbar`, donde esta técnica podría ser interesante.
La filtración de información a través de elementos HTML es una preocupación en la seguridad web, especialmente cuando se generan archivos multimedia dinámicos basados en información del usuario, o cuando se agregan marcas de agua, alterando el tamaño del medio. Esto puede ser explotado por atacantes para diferenciar entre estados posibles mediante el análisis de la información expuesta por ciertos elementos HTML.
[Leer más sobre HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
- **HTMLVideoElement**: Expone `videoHeight` y `videoWidth`. En algunos navegadores, propiedades adicionales como `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount` y `webkitDecodedFrameCount` están disponibles, ofreciendo información más detallada sobre el contenido multimedia.
[Leer más sobre HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
- **getVideoPlaybackQuality()**: Esta función proporciona detalles sobre la calidad de reproducción de video, incluyendo `totalVideoFrames`, que puede indicar la cantidad de datos de video procesados.
[Leer más sobre getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
- **HTMLImageElement**: Este elemento filtra la `altura` y `ancho` de una imagen. Sin embargo, si una imagen es inválida, estas propiedades devolverán 0, y la función `image.decode()` será rechazada, indicando la falla al cargar la imagen correctamente.
[Leer más sobre HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)
Las aplicaciones web pueden cambiar el **estilo del sitio web** dependiendo del estado del usuario. Los archivos CSS de origen cruzado pueden ser incrustados en la página del atacante con el **elemento de enlace HTML**, y las **reglas** se aplicarán a la página del atacante. Si una página cambia dinámicamente estas reglas, un atacante puede **detectar** estas **diferencias** dependiendo del estado del usuario.\
Como técnica de filtración, el atacante puede usar el método `window.getComputedStyle` para **leer CSS** propiedades de un elemento HTML específico. Como resultado, un atacante puede leer propiedades CSS arbitrarias si se conoce el elemento afectado y el nombre de la propiedad.
* **Ejemplo de Código**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)
El selector CSS `:visited` se utiliza para aplicar estilos diferentes a las URL si han sido visitadas previamente por el usuario. En el pasado, el método `getComputedStyle()` se podía utilizar para identificar estas diferencias de estilo. Sin embargo, los navegadores modernos han implementado medidas de seguridad para evitar que este método revele el estado de un enlace. Estas medidas incluyen devolver siempre el estilo calculado como si el enlace hubiera sido visitado y restringir los estilos que se pueden aplicar con el selector `:visited`.
A pesar de estas restricciones, es posible discernir el estado visitado de un enlace de forma indirecta. Una técnica implica engañar al usuario para que interactúe con un área afectada por CSS, específicamente utilizando la propiedad `mix-blend-mode`. Esta propiedad permite la mezcla de elementos con su fondo, revelando potencialmente el estado visitado en función de la interacción del usuario.
Además, la detección se puede lograr sin interacción del usuario explotando los tiempos de renderizado de los enlaces. Dado que los navegadores pueden renderizar enlaces visitados y no visitados de manera diferente, esto puede introducir una diferencia de tiempo medible en el renderizado. Se mencionó un ejemplo de concepto (PoC) en un informe de error de Chromium, demostrando esta técnica utilizando múltiples enlaces para amplificar la diferencia de tiempo, haciendo así que el estado visitado sea detectable mediante análisis de tiempo.
Para más detalles sobre estas propiedades y métodos, visita sus páginas de documentación:
-`:visited`: [Documentación de MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
-`getComputedStyle()`: [Documentación de MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
-`mix-blend-mode`: [Documentación de MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)
* **Resumen:** En Google Chrome, se muestra una página de error dedicada cuando se bloquea una página para ser incrustada en un sitio de origen cruzado debido a restricciones de X-Frame-Options.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)
En Chrome, si una página con la cabecera `X-Frame-Options` establecida en "deny" o "same-origin" se incrusta como un objeto, aparece una página de error. Chrome devuelve de manera única un objeto de documento vacío (en lugar de `null`) para la propiedad `contentDocument` de este objeto, a diferencia de los iframes u otros navegadores. Los atacantes podrían explotar esto al detectar el documento vacío, revelando potencialmente información sobre el estado del usuario, especialmente si los desarrolladores establecen de manera inconsistente la cabecera X-Frame-Options, a menudo pasando por alto las páginas de error. La conciencia y la aplicación consistente de las cabeceras de seguridad son cruciales para prevenir tales filtraciones.
* **Resumen:** Un atacante puede discernir descargas de archivos aprovechando iframes; la accesibilidad continua del iframe implica una descarga de archivo exitosa.
La cabecera `Content-Disposition`, específicamente `Content-Disposition: attachment`, instruye al navegador a descargar el contenido en lugar de mostrarlo en línea. Este comportamiento puede ser explotado para detectar si un usuario tiene acceso a una página que desencadena una descarga de archivo. En los navegadores basados en Chromium, existen algunas técnicas para detectar este comportamiento de descarga:
- Cuando se descarga un archivo en los navegadores basados en Chromium, aparece una barra de descarga en la parte inferior de la ventana del navegador.
- Al monitorear los cambios en la altura de la ventana, los atacantes pueden inferir la aparición de la barra de descarga, lo que sugiere que se ha iniciado una descarga.
- Cuando una página desencadena una descarga de archivo usando la cabecera `Content-Disposition: attachment`, no provoca un evento de navegación.
- Cargando el contenido en un iframe y monitoreando los eventos de navegación, es posible verificar si la disposición del contenido provoca una descarga de archivo (sin navegación) o no.
- Similar a la técnica de iframe, este método implica usar `window.open` en lugar de un iframe.
- Monitorear los eventos de navegación en la ventana recién abierta puede revelar si se desencadenó una descarga de archivo (sin navegación) o si el contenido se muestra en línea (ocurre navegación).
En escenarios donde solo los usuarios autenticados pueden desencadenar estas descargas, estas técnicas pueden usarse para inferir indirectamente el estado de autenticación del usuario en función de la respuesta del navegador a la solicitud de descarga.
* **Resumen:** Un atacante puede discernir descargas de archivos aprovechando iframes; la accesibilidad continua del iframe implica una descarga de archivo exitosa.
* **Ejemplo de Código**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (de [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
Por eso esta técnica es interesante: Chrome ahora tiene **particionamiento de caché**, y la clave de caché de la página recién abierta es: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx)`, pero si abro una página de ngrok y uso fetch en ella, la clave de caché será: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`, la **clave de caché es diferente**, por lo que la caché no se puede compartir. Puedes encontrar más detalles aquí: [Ganando seguridad y privacidad mediante la partición de la caché](https://developer.chrome.com/blog/http-cache-partitioning/)\
Si un sitio `ejemplo.com` incluye un recurso de `*.ejemplo.com/recurso` entonces ese recurso tendrá la **misma clave de caché** que si el recurso fuera solicitado directamente a través de la navegación de nivel superior. Esto se debe a que la clave de caché está compuesta por _eTLD+1_ de nivel superior y _eTLD+1_ del marco.
Dado que acceder a la caché es más rápido que cargar un recurso, es posible intentar cambiar la ubicación de una página y cancelarla 20ms (por ejemplo) después. Si el origen cambió después de la parada, significa que el recurso estaba en caché.\
O simplemente **enviar algún fetch a la página potencialmente en caché y medir el tiempo que tarda**.
* **Resumen:** Es posible intentar cargar un recurso y abortar antes de que se cargue la carga. Dependiendo de si se desencadena un error, el recurso estaba o no en caché.
* **Ejemplo de Código**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
Usa _**fetch**_ y _**setTimeout**_ con un **AbortController** para detectar si el **recurso está en caché** y para eliminar un recurso específico de la caché del navegador. Además, el proceso ocurre sin almacenar en caché contenido nuevo.
Por lo tanto, lo que puedes hacer es **agregar una gran cantidad de caracteres basura** (por ejemplo, **miles de "W"**) para **llenar la página web antes del secreto o agregar algo como**`<br><canvas height="1850px"></canvas><br>.`\
Entonces, si por ejemplo nuestra **inyección aparece antes de la bandera**, la **imagen** se **cargará**, pero si aparece **después** de la **bandera**, la bandera + la basura **evitarán que se cargue** (tendrás que jugar con la cantidad de basura a colocar). Esto es lo que sucedió en [**este writeup**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/).
Lo que este texto hará es hacer que el bot acceda a cualquier texto en la página que contenga el texto `SECR`. Como ese texto es el secreto y está justo **debajo de la imagen**, la **imagen solo se cargará si el secreto adivinado es correcto**. Así que ahí tienes tu oráculo para **filtrar el secreto carácter por carácter**.
Algunos ejemplos de código para explotar esto: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
Si **no es posible cargar una imagen externa** que podría indicar al atacante que la imagen se cargó, otra opción sería intentar **adivinar el carácter varias veces y medir eso**. Si la imagen se carga, todas las solicitudes tomarían más tiempo que si la imagen no se carga. Esto es lo que se usó en la [**solución de este informe**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **resumido aquí:**
Si se utiliza `jQuery(location.hash)`, es posible averiguar a través del tiempo si existe algún contenido HTML, esto se debe a que si el selector `main[id='site-main']` no coincide, no es necesario verificar el resto de los **selectores**:
Hay mitigaciones recomendadas en [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) también en cada sección del wiki [https://xsleaks.dev/](https://xsleaks.dev/). Echa un vistazo allí para obtener más información sobre cómo protegerse contra estas técnicas.
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén la [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Utiliza [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas comunitarias **más avanzadas** del mundo.\
