Storage Partitioning

Pour empêcher certains types de suivi intersites côté canal, Chrome a partitionné la plupart des API de stockage et de communication dans des contextes tiers.

État de l'implémentation

Cette fonctionnalité a été activée pour tous les utilisateurs de Chrome 115 et versions ultérieures. La proposition de partitionnement du stockage est ouverte à d'autres discussions.

Qu'est-ce que le partitionnement de l'espace de stockage ?

Pour empêcher certains types de suivi intersites côté canal, Chrome partitionne les API de stockage et de communication dans des contextes tiers.

Sans partitionnement de l'espace de stockage, un site peut joindre des données provenant de différents sites pour suivre l'utilisateur sur le Web. De plus, il permet au site intégré d'inférer des états spécifiques sur l'utilisateur sur le site de niveau supérieur à l'aide de techniques de canal auxiliaire telles que les attaques par cassage de chiffrement, les fuites XS et les attaques COSI.

Auparavant, le stockage n'était géré que par origine. Cela signifie que si un iFrame de example.com est intégré à a.com et b.com, il peut en savoir plus sur vos habitudes de navigation sur ces deux sites en stockant et en récupérant un ID à partir de l'espace de stockage. Lorsque le partitionnement du stockage tiers est activé, le stockage de example.com existe dans deux partitions différentes, l'une pour a.com et l'autre pour b.com.

Le partitionnement signifie généralement que les données stockées par des API de stockage telles que le stockage local et IndexedDB par une iFrame ne sont plus accessibles à tous les contextes de la même origine. Au lieu de cela, les données ne sont disponibles que pour les contextes ayant la même origine et le même site de premier niveau.

Avant

Diagramme des API de stockage sans partitionnement.
Avant le partitionnement de l'espace de stockage, example.com peut écrire des données lorsqu'il est intégré à a.com, puis les lire lorsqu'il est intégré à b.com.

Après

Schéma des API de stockage avec partitionnement.
Après le partitionnement de l'espace de stockage, example.com, lorsqu'il est intégré à b.com, ne peut pas accéder à l'espace de stockage d'example.com lorsqu'il est intégré à a.com.

Partitionnement du stockage sur des iFrames en chaîne

Lorsque qu'un iFrame contient un iFrame, les choses se compliquent. Cela est particulièrement vrai lorsque la même origine se trouve à plusieurs endroits de la chaîne.

Par exemple, A1 contient une iframe pour B, qui contient une iframe pour A2, et A1 et A2 se trouvent sur le même site. Si nous ne prenons en compte que les contextes de premier niveau et de niveau actuel lors du partitionnement, l'iFrame A2 peut être considérée comme propriétaire, car elle se trouve sur le même site que le niveau supérieur (A1) malgré l'iFrame tierce intervenant (B). Cela pourrait exposer A2 à des risques de sécurité tels que le hameçonnage de clics si A2 avait accès à un stockage non partitionné par défaut.

Pour y remédier, Chrome inclut un "bit d'ancêtre" supplémentaire dans la clé de partition de stockage, qui est défini si un document entre le contexte actuel et le contexte de niveau supérieur est intersite par rapport au contexte actuel. Dans ce cas, le site B est intersites. Le bit est donc défini pour A2 et son stockage est partitionné à partir d'A1.

Lorsque aucun contexte intersites n'est présent dans la chaîne, le stockage n'est pas partitionné. Par exemple, le site A1 contenant un iFrame pour A2 qui contient un iFrame pour A3 ne sera pas partitionné pour A1, A2 ni A3, car ils se trouvent tous sur le même site.

Pour les sites qui ont besoin d'un accès non partitionné sur des iFrames en chaîne, Chrome expérimente l'extension de l'API Storage Access pour permettre ce cas d'utilisation. Comme l'API Storage Access nécessite que le site encadré appelle explicitement l'API, cela réduit le risque de hameçonnage par clic.

API mises à jour

Les API affectées par le partitionnement peuvent être divisées en groupes comme suit:

API Storage

  • Système de quotas
    Le système de quota permet de déterminer la quantité d'espace disque allouée au stockage. Le système de quota gère chaque partition en tant que bucket distinct pour déterminer la quantité d'espace autorisée et quand elle est libérée.
    Le navigator.storage.estimate() renvoie les informations de la partition. Les API Chrome uniquement, telles que window.webkitStorageInfo et navigator.webkitTemporaryStorage, seront abandonnées.
    IndexedDB et le stockage en cache utilisent le nouveau système de quotas partitionné.
  • API Web Storage
    L'API Web Storage fournit des mécanismes permettant aux navigateurs de stocker des paires clé-valeur. Il existe deux mécanismes : le stockage local et le stockage de session. Elles ne sont pas actuellement gérées par quota, mais elles sont toujours partitionnées.
  • Origin Private File System
    L'API File System Access permet à un site de lire ou d'enregistrer des modifications directement dans les fichiers et dossiers de l'appareil une fois que l'utilisateur a accordé l'accès. Le système de fichiers privés d'origine permet à une origine de stocker sur disque du contenu privé auquel l'utilisateur peut facilement accéder et qui est partitionné.
  • API Storage Bucket
    L'API Storage Bucket est en cours de développement pour Storage Standard, qui consolide diverses API de stockage telles que IndexedDB et localStorage à l'aide d'un nouveau concept appelé buckets. Les données stockées dans les buckets et les métadonnées associées sont partitionnées.
  • En-tête Clear-Site-Data
    L'inclusion de l'en-tête Clear-Site-Data dans la réponse permet à un serveur de demander à effacer les données stockées dans le navigateur de l'utilisateur. Vous pouvez vider le cache, les cookies et l'espace de stockage DOM. L'utilisation de l'en-tête n'efface que l'espace de stockage d'une seule partition.
  • Stockage d'URL de blob
    Un blob est un objet qui contient des données brutes à traiter. Une URL de blob peut être générée pour accéder à la ressource. Les magasins d'URL blob ne sont pas partitionnés. Pour prendre en charge un cas d'utilisation permettant de naviguer dans un contexte de premier niveau vers n'importe quelle URL de blob (discussion), le magasin d'URL de blob peut être partitionné par le cluster d'agents plutôt que par le site de premier niveau. Cette fonctionnalité n'est pas encore disponible pour les tests, et le mécanisme de partitionnement peut changer à l'avenir.

API de communication

En plus des API de stockage, les API de communication qui permettent à un contexte de communiquer au-delà des limites d'origine sont également partitionnées. Les modifications affectent principalement les API qui permettent de découvrir d'autres contextes via la diffusion ou le rendez-vous de même origine.

Pour les API de communication suivantes, les iFrames tierces ne peuvent plus communiquer avec leur contexte de même origine:

  • Chaîne de diffusion
    L'API
    Broadcast Channel permet la communication entre les contextes de navigation (fenêtres, onglets ou iFrames) et les nœuds de calcul de la même origine.
    Les postMessage() iframe intersites où la relation entre les contextes est clairement définie ne sont pas proposés à être modifiés.
  • SharedWorker
    L'API
    SharedWorker fournit un nœud de calcul auquel on peut accéder dans les contextes de navigation de la même origine.
  • Serrures Web
    L'API Web Locks permet au code exécuté dans un onglet ou un nœud de calcul de la même origine d'acquérir un verrouillage pour une ressource partagée pendant l'exécution d'une tâche.

API Service Worker

L'API Service Worker fournit l'interface permettant d'effectuer des tâches en arrière-plan. Les sites créent des enregistrements persistants qui créent un nouveau contexte de worker pour répondre aux événements. Ce worker peut communiquer avec n'importe quel contexte de même origine. De plus, l'API Service Worker peut modifier le calendrier des requêtes de navigation, ce qui peut entraîner des fuites d'informations entre sites, telles que l'exploration de l'historique.

Par conséquent, les service workers enregistrés à partir d'un contexte tiers sont partitionnés.

API d'extension

Les extensions sont des programmes qui permettent aux utilisateurs de personnaliser leur expérience de navigation.

Les pages d'extension (pages avec un schéma chrome-extension://) peuvent être intégrées sur des sites sur le Web. Dans ce cas, elles conservent l'accès à leur partition de niveau supérieur. Ces pages peuvent également intégrer d'autres sites. Dans ce cas, ces sites auront accès à leur partition de premier niveau tant que l'extension dispose des autorisations d'hôte pour ce site.

Pour en savoir plus, consultez la documentation de l'extension.

Démonstration: Tester le partitionnement de l'espace de stockage

Site de démonstration: https://storage-partitioning-demo-site-a.glitch.me/

Capture d'écran du site de démonstration montrant toutes les coches vertes à gauche et les croix rouges à droite pour chaque test.
Capture d'écran de la démonstration, montrant la sortie d'un navigateur avec partitionnement de l'espace de stockage à gauche et sans partitionnement de l'espace de stockage à droite.

La démonstration utilise deux sites: le site A et le site B.

  • Lorsque vous accédez au site A dans le contexte de niveau supérieur, il définit des données à l'aide de différentes méthodes de stockage.
  • Le site B intègre une page du site A, et cette intégration tente de lire les options de stockage définies précédemment.
  • Lorsque le site A est intégré au site B, il n'a pas accès à ces données lorsque le stockage est partitionné. Les lectures échouent donc.
  • La démonstration utilise le succès ou l'échec de chaque lecture pour indiquer si les données sont partitionnées.

Pour le moment, vous pouvez désactiver le partitionnement de l'espace de stockage dans Chrome à l'aide de l'option de ligne de commande --disable-features=ThirdPartyStoragePartitioning.

Vous pouvez également tester d'autres navigateurs de la même manière pour connaître leur état de partitionnement.

Interagir et envoyer des commentaires