Découvrez pourquoi l'isolation multi-origine est nécessaire pour utiliser des fonctionnalités puissantes telles que SharedArrayBuffer, performance.measureUserAgentSpecificMemory() et un minuteur haute résolution avec plus de précision.
Introduction
Dans le cours Faciliter l'isolement multi-origine de votre site Web à l'aide des protocoles COOP et COEP, nous avons expliqué comment adopter un état "isolé multi-origine" à l'aide des protocoles COOP et COEP. Il s'agit d'un article associé qui explique pourquoi l'isolation multi-origine est nécessaire pour activer des fonctionnalités puissantes sur le navigateur.
Contexte
Le Web repose sur une règle d'origine identique, une fonctionnalité de sécurité qui limite la manière dont les documents et les scripts peuvent interagir avec des ressources d'une autre origine. Ce principe limite la façon dont les sites Web peuvent accéder aux ressources multi-origines. Par exemple, un document issu de https://a.example ne peut pas accéder aux données hébergées à l'adresse https://b.example.
Cependant, la règle d'origine commune comporte quelques exceptions par le passé. Tout site Web peut:
- Intégrer des iFrames multi-origines
- Inclure des ressources multi-origines telles que des images ou des scripts
- Ouvrir des fenêtres pop-up multi-origines avec une référence DOM
Si le Web pouvait être conçu à partir de zéro, ces exceptions n'existeraient pas. Malheureusement, lorsque la communauté Web a pris conscience des avantages clés d'un règlement strict sur les mêmes origines, le Web s'appuyait déjà sur ces exceptions.
Les effets secondaires sur la sécurité d'une telle règle laxiste de même origine ont été corrigés de deux manières. L'une d'elles a été l'introduction d'un nouveau protocole appelé Cross-Origin Resource Sharing (CORS), dont l'objectif est de s'assurer que le serveur autorise le partage d'une ressource ayant une origine donnée. L'autre méthode consiste à supprimer implicitement l'accès direct du script aux ressources multi-origines tout en préservant la rétrocompatibilité. Ces ressources multi-origines sont appelées ressources "opaques". Par exemple, c'est pourquoi la manipulation des pixels d'une image multi-origine via CanvasRenderingContext2D échoue, sauf si CORS est appliqué à l'image.
Toutes ces décisions concernant les règles ont lieu dans un groupe de contexte de navigation.
Pendant longtemps, la combinaison de CORS et de ressources opaques a suffi à sécuriser les navigateurs. Parfois, des cas particuliers (tels que des failles JSON) ont été découverts et ont dû être corrigés. Cependant, dans l'ensemble, le principe qui consiste à ne pas autoriser l'accès en lecture directe aux octets bruts des ressources multi-origines a réussi.
Tout a changé avec Spectre, qui rend toutes les données chargées dans le même groupe de contexte de navigation que votre code potentiellement lisibles. En mesurant le délai de certaines opérations, les pirates informatiques peuvent deviner le contenu des caches de processeur et, par ce biais, le contenu de la mémoire du processus. Ces attaques temporelles sont possibles avec des minuteurs peu précis qui existent sur la plate-forme, mais peuvent être accélérées avec des minuteurs de haute précision, qu'ils soient explicites (comme performance.now()) et implicites (comme SharedArrayBuffer). Si evil.com intègre une image multi-origine, il peut utiliser une attaque Spectre pour lire ses données de pixels, ce qui rend les protections basées sur l'"opacité" inefficaces.
Idéalement, toutes les requêtes multi-origines doivent être explicitement validées par le serveur propriétaire de la ressource. Si l'approbation n'est pas fournie par le serveur propriétaire des ressources, les données ne seront jamais incluses dans le groupe de contexte de navigation d'un acteur maléfique. Elles resteront donc hors de portée de toute attaque Spectre sur une page Web. Nous appelons cela un état isolé multi-origine. C'est exactement ce qu'implique COOP+COEP.
Dans un état isolé multi-origine, le site à l'origine de la demande est considéré comme moins dangereux, ce qui permet de débloquer des fonctionnalités puissantes telles que SharedArrayBuffer et performance.measureUserAgentSpecificMemory(), ainsi que des minuteurs haute résolution avec une meilleure précision, qui pourraient sinon être utilisés pour des attaques de type Spectre. Cela empêche également de modifier document.domain.
Règle de l'intégrateur multi-origine
La règle COEP (Cross Origin Embedder Policy) empêche un document de charger des ressources multi-origines qui n'accordent pas explicitement l'autorisation du document (à l'aide de CORP ou CORS). Avec cette fonctionnalité, vous pouvez déclarer qu'un document ne peut pas charger de telles ressources.
Pour activer cette règle, ajoutez l'en-tête HTTP suivant au document:
Cross-Origin-Embedder-Policy: require-corp
Le mot clé require-corp est la seule valeur acceptée pour COEP. Cela permet d'appliquer la règle selon laquelle le document ne peut charger que des ressources de la même origine ou des ressources explicitement marquées comme pouvant être chargées à partir d'une autre origine.
Pour que les ressources puissent être chargées à partir d'une autre origine, elles doivent être compatibles avec le partage des ressources entre origines multiples (CORS, Cross Origin Resource Sharing) ou CORP (Cross-Origin Resource Policy).
Partage des ressources entre origines multiples
Si une ressource multi-origine est compatible avec le partage des ressources entre origines multiples (CORS), vous pouvez utiliser l'attribut crossorigin pour la charger sur votre page Web sans être bloquée par COEP.
<img src="https://third-party.example.com/image.jpg" crossorigin>
Par exemple, si cette ressource d'image est diffusée avec des en-têtes CORS, utilisez l'attribut crossorigin afin que la requête de récupération de la ressource utilise le mode CORS. Cela empêche également le chargement de l'image, sauf si elle définit des en-têtes CORS.
De même, vous pouvez extraire des données d'origines croisées via la méthode fetch(), qui ne nécessite pas de traitement particulier tant que le serveur répond avec les en-têtes HTTP appropriés.
Règle de ressource multi-origine
La règle CORP (Cross Origin Resource Policy) a été initialement introduite en tant qu'option permettant d'éviter que vos ressources ne soient chargées par une autre origine. Dans le contexte de COEP, CORP peut spécifier les règles du propriétaire de la ressource concernant les utilisateurs autorisés à charger une ressource.
L'en-tête Cross-Origin-Resource-Policy peut avoir trois valeurs:
Cross-Origin-Resource-Policy: same-site
Les ressources marquées same-site ne peuvent être chargées qu'à partir du même site.
Cross-Origin-Resource-Policy: same-origin
Les ressources marquées same-origin ne peuvent être chargées qu'à partir de la même origine.
Cross-Origin-Resource-Policy: cross-origin
Les ressources marquées cross-origin peuvent être chargées par n'importe quel site Web. (Cette valeur a été ajoutée aux spécifications CORP avec COEP.)
Règle d'ouverture multi-origine
La stratégie d'ouverture multi-origine (COOP) vous permet de vous assurer qu'une fenêtre de premier niveau est isolée des autres documents en les plaçant dans un groupe de contexte de navigation différent, afin qu'elles ne puissent pas interagir directement avec la fenêtre racine. Par exemple, si un document avec COOP ouvre un pop-up, sa propriété window.opener sera null. En outre, la propriété .closed de la référence à l'opener renvoie true.
L'en-tête Cross-Origin-Opener-Policy peut avoir trois valeurs:
Cross-Origin-Opener-Policy: same-origin
Les documents marqués same-origin peuvent partager le même groupe de contexte de navigation avec des documents de même origine qui sont également explicitement marqués same-origin.
Cross-Origin-Opener-Policy: same-origin-allow-popups
Un document de premier niveau avec same-origin-allow-popups conserve les références à l'un de ses pop-ups qui ne définissent pas la COOP ou qui désactive l'isolation en définissant une COOP sur unsafe-none.
Cross-Origin-Opener-Policy: unsafe-none
unsafe-none est la valeur par défaut et permet d'ajouter le document au groupe de contexte de navigation de son ouverture, sauf si celui-ci possède lui-même un COOP de same-origin.
Résumé
Si vous souhaitez garantir l'accès à des fonctionnalités puissantes telles que SharedArrayBuffer, performance.measureUserAgentSpecificMemory() ou des minuteurs haute résolution avec une meilleure précision, n'oubliez pas que votre document doit utiliser à la fois le COEP avec la valeur require-corp et COOP avec la valeur de same-origin. Sans l'une ou l'autre de ces fonctionnalités, le navigateur ne garantit pas une isolation suffisante pour activer ces fonctionnalités puissantes en toute sécurité. Vous pouvez déterminer la situation de votre page en vérifiant si self.crossOriginIsolated renvoie true.
Pour découvrir la procédure à suivre, consultez la section Rendre votre site Web "isolé multi-origine" à l'aide des protocoles COOP et COEP.