Fuites XS : ce qu’elles sont et comment les éviter

Les fuites intersites (fuites XS) sont une catégorie de vulnérabilités de sécurité Web qui permettent aux pirates d’obtenir des informations sensibles issues de la session de navigation d’un utilisateur sur d’autres sites Web ou applications Web. Les applications Web modernes partagent des données au moyen de diverses fonctionnalités et API, que les attaquants peuvent exploiter pour accéder à ces données utilisateur.

En définitive, les fuites XS entraînent la divulgation d’informations sensibles que des acteurs malveillants peuvent utiliser à de nombreuses fins illicites, comme obtenir un accès non autorisé à des systèmes ou bases de données confidentiels.

Dans cet article, nous allons voir plus en détail ce que sont les fuites XS et comment elles se produisent. Nous passerons ensuite en revue des exemples pratiques pour les prévenir. 

Comment se produisent les fuites XS

Les applications Web modernes sont extrêmement complexes et reposent sur plusieurs domaines présentant différents niveaux de confiance. Pour offrir une expérience fluide dans le navigateur, les sites Web doivent donc pouvoir partager des informations. Les développeurs ont certes sécurisé ces échanges dans une certaine mesure, mais les fonctionnalités des sites Web et des navigateurs présentent des vulnérabilités inhérentes.

Les fuites XS se produisent lorsque des attaquants exploitent ces vulnérabilités pour accéder sans autorisation aux données privées des utilisateurs. En manipulant diverses fonctionnalités Web — comme les cookies, les API JavaScript, les feuilles de style CSS et les éléments HTML — et en exploitant des canaux auxiliaires ainsi que des vulnérabilités propres aux applications, les attaquants peuvent extraire des informations sensibles d’autres sites Web consultés par un utilisateur. De plus, ces attaques se déroulent discrètement, à l’insu de l’utilisateur et sans son consentement.

Quels sont les différents types de fuites XS ?

Les attaquants peuvent exploiter plusieurs types de fuites XS. Voyons-en quelques-uns.

Attaques temporelles

Lors d’une attaque temporelle, un acteur malveillant tente de recueillir des informations sensibles sur un système en mesurant la durée de différentes opérations. Le pirate envoie au site ciblé des scripts spécialement conçus pour effectuer des appels API, des requêtes AJAX ou tenter de déclencher des requêtes de ressources nécessitant le partage de ressources entre origines (CORS). Il analyse ensuite la durée de ces opérations pour déduire des informations sur le fonctionnement du site Web ou la façon dont il traite les données.

Par exemple, un attaquant peut observer le temps nécessaire à la validation côté serveur de différents types de données — comme des combinaisons de noms d’utilisateur et de mots de passe — envoyées par des requêtes interorigines. Il peut ensuite exploiter les écarts de durée observables pour déterminer si une tentative de connexion a réussi ou si un utilisateur est administrateur ou simple utilisateur. Ces informations lui permettent de décider de la suite de son attaque.

Comptage des cadres

Lors d’attaques par comptage de cadres, le pirate crée plusieurs iFrames imbriquées pointant vers différentes URL d’un site ciblé. Il exploite ensuite la fonctionnalité CORS du site pour voir combien de cadres le navigateur de l’utilisateur charge lorsqu’il consulte les URL ciblées. 

Imaginons qu’un attaquant crée plusieurs iFrames imbriquées vers des sections protégées d’un site Web, comme les paramètres du compte et l’historique des commandes. Lorsqu’un utilisateur consulte une page contenant les iFrames injectées par l’attaquant, celui-ci compte les cadres qui se chargent correctement et ceux qui échouent. Il peut alors déduire d’éventuelles restrictions du compte — comme les exigences d’authentification ou le niveau d’adhésion — et savoir si un utilisateur donné dispose de droits d’accès ou a déjà consulté certaines sections du site ciblé.

Sondage du cache

Le sondage du cache exploite les caches des navigateurs, qui stockent du contenu Web en local sur les appareils des utilisateurs. Pour lancer cette attaque, le pirate crée un site malveillant qui demande des ressources spécifiques — comme des images ou des scripts — au site ciblé. Les ressources demandées possèdent des caractéristiques distinctives, par exemple une taille de fichier ou un temps de chargement inhabituel. 

Les attaquants mesurent la vitesse de chargement des ressources lorsqu’un utilisateur consulte leur site malveillant, qu’elles proviennent directement du serveur ciblé ou de versions mises en cache dans le navigateur de l’utilisateur. L’acteur malveillant s’appuie ensuite sur ces informations pour déterminer si ces ressources étaient déjà présentes dans le cache local du navigateur de l’utilisateur.

Comme le comptage des cadres, les informations obtenues par sondage du cache peuvent servir à personnaliser des campagnes d’hameçonnage, à découvrir les liens entre des comptes distincts utilisés sur plusieurs services et plateformes en ligne, et à coordonner des attaques plus sophistiquées.

Quels mécanismes se cachent derrière les fuites XS ?

Les attaques par fuite XS manipulent les fonctionnalités inhérentes aux navigateurs et utilisent des techniques d’observation indirecte pour accéder sans autorisation à des données sensibles. Les mécanismes qui contribuent à la réussite d’une attaque par fuite XS sont les suivants :

• Exploitation des fonctionnalités du navigateur — Les attaquants utilisent des fonctionnalités du navigateur telles que le préchargement, le pré-rendu et diverses API comme Fetch ou WebSockets. En manipulant ou en combinant ces fonctionnalités avec d’autres techniques, comme le sondage du cache, ils peuvent extraire des informations sensibles sur les utilisateurs sans enfreindre directement la politique de même origine (SOP).

• Canaux auxiliaires — Il s’agit de voies indirectes par lesquelles les attaquants recueillent des informations sensibles. Au lieu d’accéder directement aux données, ce que leur interdisent les restrictions de sécurité imposées par les politiques de même origine dans les applications Web, ils observent des variations comme le temps de rendu ou les schémas de chargement des ressources dans les navigateurs des utilisateurs.

• Communication interorigine — Les attaquants peuvent également cibler des mécanismes de communication interorigine comme l’API postMessage et les web workers. Ils peuvent alors intercepter ou manipuler les messages échangés entre différentes origines intégrées dans des iFrames sur une même page.

Vulnérabilités exploitées par les fuites XS

En s’appuyant sur les mécanismes décrits ci-dessus, les attaquants peuvent accéder à des informations sensibles sans enfreindre directement les politiques de sécurité comme CORS et SOP, utilisées par la plupart des sites Web modernes. 

Ces mesures n’empêchent pas les fuites XS de se produire. Les attaquants peuvent recourir aux canaux auxiliaires pour contourner les protections de la SOP, exploiter une mauvaise configuration de CORS et combiner d’autres vulnérabilités dans le cadre d’une attaque coordonnée.

CORS et SOP régissent les interactions entre les ressources de différentes origines. La SOP empêche les pages Web d’accéder aux données ou au contenu chargés depuis un autre domaine, afin que les scripts s’exécutent dans le contexte de leur origine. CORS étend cette politique en autorisant certaines requêtes interorigines, lorsque le serveur autorise explicitement l’accès à ses ressources au moyen d’en-têtes HTTP. En théorie, cette combinaison permet une communication sécurisée entre les sites Web et empêche les interactions malveillantes entre domaines, comme les attaques par falsification de requête intersite (CSRF) et l’accès non autorisé aux données.

Toutefois, comme les fuites XS exploitent les canaux auxiliaires et l’exposition indirecte des données, les attaquants peuvent contourner la SOP en déduisant des informations sensibles provenant d’une autre origine. De même, une mauvaise configuration ou une mise en œuvre non sécurisée de CORS dans une application Web peut entraîner une fuite d’informations.

Les acteurs malveillants peuvent également recourir aux fuites XS en enchaînant plusieurs vulnérabilités. Le cross-site scripting (XSS) est une attaque qui se combine efficacement avec les fuites XS. Après avoir exploité une vulnérabilité XSS, un attaquant peut aussi tenter de provoquer des fuites XS par le biais de diverses fonctionnalités du navigateur ou API qui exposent des informations via des canaux auxiliaires. 

Un acteur malveillant peut combiner ces deux vecteurs d’attaque pour obtenir des données sensibles du domaine compromis et recueillir d’autres informations interorigines sans enfreindre directement la SOP.

Quelles sont les conséquences des fuites XS ?

Les attaques par fuite XS peuvent avoir de graves conséquences, notamment la divulgation d’informations sensibles. Un attaquant peut accéder à des données confidentielles, comme des renseignements personnels ou des informations financières, puis manipuler, voler ou utiliser à mauvais escient les informations privées d’un utilisateur sans son consentement.

Le détournement de session est une autre conséquence possible des attaques par fuite XS. Il consiste pour un attaquant à prendre le contrôle de la session active d’un utilisateur et à effectuer potentiellement des modifications non autorisées en son nom. Ces conséquences menacent la confidentialité et la sécurité des utilisateurs et sapent la confiance envers les plateformes et services en ligne.

Il est important de noter que les fuites XS sont souvent considérées comme faisant partie de techniques d’attaque ou de vulnérabilités plus vastes. Les fuites de données très médiatisées ne sont pas nécessairement dues à une fuite XS comme vecteur d’attaque principal. Les attaquants malveillants peuvent toutefois exploiter les fuites XS pour mener des attaques plus coordonnées.

Bonnes pratiques pour réduire le risque d’attaques par fuite XS

Il n’existe pas de solution universelle pour prévenir les fuites XS, mais il est possible d’en réduire considérablement les risques. Les sections suivantes présentent les bonnes pratiques pour atténuer les fuites XS, avec des démonstrations pratiques de leur mise en œuvre.

Utilisez une politique de sécurité du contenu

Mettez en place une politique de sécurité du contenu (CSP) robuste pour limiter les sources de contenu que le navigateur peut charger sur vos sites. Cette pratique réduit les risques de fuite d’informations provoquée par l’exploitation de vulnérabilités XSS ou d’autres vulnérabilités par injection.

Vous pouvez mettre en œuvre une CSP à l’aide d’un en-tête de réponse HTTP appelé Content-Security-Policy, comme illustré ci-dessous :

1<meta http-equiv="Content-Security-Policy" content="
2    default-src 'none';
3    script-src 'self' https://ajax.googleapis.com;
4    img-src 'self';
5    style-src 'self' https://fonts.googleapis.com;
6    font-src 'self' https://fonts.gstatic.com;">

Dans cet exemple, aucune ressource externe ne peut être chargée (default-src), sauf si d’autres directives l’autorisent explicitement. Les scripts (script-src), les images (img-src), les feuilles de style (style-src) et les polices (font-src) ne peuvent être chargés que depuis notre domaine (self) ou l’API Google (googleapis.com).

Une CSP bien définie contribue à empêcher les requêtes interorigines non autorisées et l’exécution de code en ligne en précisant les sources autorisées pour les scripts, les images, les feuilles de style et d’autres contenus.

Imposez l’attribut SameSite pour les cookies

L’attribut SameSite d’un cookie indique au navigateur s’il doit inclure ce cookie dans les requêtes externes. En JavaScript, cela se présente par exemple ainsi :

document.cookie = "username=JohnDoe; path=/; Secure; SameSite=Strict";

Le cookie username contient la valeur JohnDoe, et le chemin / signifie que le cookie est accessible sur toutes les pages de notre domaine. Le mot-clé Secure garantit que le cookie est transmis uniquement via des connexions HTTPS. Enfin, nous définissons l’attribut SameSite sur l’une des valeurs suivantes :

• None — Le cookie est joint à la requête si celle-ci est envoyée via une connexion HTTPS sécurisée.

• Lax — Il s’agit du comportement par défaut des navigateurs basés sur Chromium. Le cookie est envoyé pour les requêtes GET effectuées lors d’une navigation de premier niveau,

• Strict — Le cookie n’est jamais envoyé en dehors de notre domaine.

Définir l’attribut SameSite des cookies sur Strict empêche leur envoi lors des requêtes intersites et atténue les risques de CSRF et de certaines attaques par fuite XS, notamment celles reposant sur des mesures de temps.

Limitez l’utilisation de données sensibles dans les URL

Limiter l’utilisation de données sensibles dans les URL est une bonne pratique essentielle en cybersécurité. Les données sensibles, comme les identifiants ou les informations personnelles identifiables (PII), ne doivent jamais figurer dans les URL, car les attaquants peuvent facilement y accéder par le biais de l’historique du navigateur, des journaux du serveur, des en-têtes de référent et des liens partagés non nettoyés.

Voici quelques moyens de limiter l’utilisation de données sensibles :

• Utiliser des requêtes POST avec HTTPS au lieu d’inclure des données sensibles dans les URL

• Utiliser des jetons de session au lieu de transmettre directement des identifiants ou des PII

Mettez en place une limitation du débit

Une autre bonne pratique consiste à limiter le débit sur les points de terminaison sensibles, en particulier ceux exposés aux tentatives d’énumération ou de force brute. Cette stratégie limite le nombre de requêtes qu’un attaquant peut effectuer pendant une période donnée et réduit l’efficacité des attaques par fuite XS. Plusieurs langages de programmation et frameworks Web proposent des bibliothèques ou des solutions de middleware pour mettre en place une limitation du débit. 

Dans Node.js avec Express, par exemple, vous devez installer le middleware express-rate-limit à l’aide de la commande npm install express-rate-limit. Vous pouvez ensuite configurer la limitation du débit côté serveur comme suit :

1const express = require('express');
2const app = express();
3const RateLimit = require('express-rate-limit');
4
5// Create a new limiter allowing 100 requests per hour from each IP address.
6// You can adjust these numbers based on desired limits.
7const apiLimiter = new RateLimit({
8  windowMs: 60 * 60 * 1000,
9    max: 100,
10    message: "Too many requests from this IP. Please try again after an hour."
11});
12
13app.use('/api/sensitive-endpoint', apiLimiter); // Apply limit to sensitive API endpoint.
14
15// Your other routes and middleware configurations here
16
17app.listen(3000, () => {
18 console.log("Server started on port ",3000);
19});

Notez que cette mesure est plus efficace lorsqu’elle est combinée à d’autres. Elle renforce votre sécurité face aux attaques par fuite XS qui reposent sur l’envoi d’un grand nombre de requêtes à votre serveur pour recueillir des informations.

Configurez correctement CORS

Veillez à configurer correctement CORS dans votre application afin d’empêcher les domaines non autorisés d’effectuer des requêtes inter-origines et d’accéder aux ressources protégées. Configurez les en-têtes CORS, tels que Access-Control-Allow-Origin, de manière appropriée pour que seules les origines de confiance puissent envoyer des requêtes inter-origines, sans utiliser de jokers (*) superflus dans les listes d’origines autorisées.

Si un serveur autorise toutes les origines (*) dans son en-tête Access-Control-Allow-Origin, ou utilise des origines générées dynamiquement sans validation appropriée des données saisies par l’utilisateur (comme un référent), des attaquants peuvent exploiter cette faille en envoyant des requêtes inter-origines depuis des sites malveillants.

Utilisez des intégrations telles que Snyk Code

Snyk Code vous aide à identifier et à corriger les vulnérabilités de sécurité en s’intégrant à votre workflow de développement. Il analyse les dépendances, vous alerte en cas de vulnérabilité, suggère et applique des correctifs, et surveille en continu votre projet pour détecter les problèmes de sécurité. Par exemple, lors de la création d’une application Node.js avec Express.js, Snyk Code peut vous aider à vous protéger contre les vulnérabilités liées à l’absence d’en-têtes de sécurité grâce à un processus simple :

1. Analysez les dépendances — Après avoir intégré Snyk à votre projet, vous pouvez analyser ses dépendances et rechercher les vulnérabilités connues dans vos packages.

2. Identifiez le problème — En l’absence d’en-têtes de sécurité, Snyk Code détecte cette vulnérabilité et vous en avertit. Par exemple, Snyk peut repérer l’absence de l’en-tête CSP dans votre application, qui contribue à vous protéger contre les attaques XSS.

3. Appliquez un correctif — Snyk recommande un correctif pour la vulnérabilité identifiée. Si des en-têtes de sécurité sont manquants, il peut vous suggérer d’ajouter le middleware helmet à votre application Express.js. Helmet est un package populaire qui configure par défaut différents en-têtes de sécurité pour votre application.

Snyk peut également continuer à surveiller votre projet afin de détecter toute nouvelle vulnérabilité ou mise à jour des vulnérabilités existantes. Vous recevrez des alertes en cas de nouveaux problèmes, ce qui vous permettra de garder en permanence la sécurité de votre projet sous contrôle.

Prévenir les fuites XS 

Les fuites XS permettent aux attaquants d’obtenir des informations sensibles à partir de la session de navigation d’un utilisateur sur un autre site web. Les pirates exploitent les fonctionnalités des navigateurs, les canaux auxiliaires et les communications inter-origines. Parmi les techniques courantes de fuite XS figurent les attaques temporelles, le comptage des frames et le sondage du cache.

Il n’existe pas de méthode garantie pour empêcher les fuites XS, mais l’application des bonnes pratiques présentées dans cet article peut réduire considérablement les risques et protéger les informations sensibles des utilisateurs contre tout accès ou toute divulgation non autorisés.