8. Security Considerations (Considérations de sécurité)

La politique de même origine est l'une des pierres angulaires de la sécurité pour de nombreux agents utilisateurs, y compris les navigateurs Web. Historiquement, certains agents utilisateurs ont essayé d'autres modèles de sécurité, notamment le suivi de contamination et la prévention de l'exfiltration, mais ces modèles se sont révélés difficiles à mettre en œuvre à l'époque (bien qu'il y ait eu récemment un regain d'intérêt pour la renaissance de certaines de ces idées).

L'évaluation de la sécurité de la politique de même origine est difficile car le concept d'origine lui-même joue un rôle si central dans le paysage de la sécurité. L'origine notionnelle elle-même n'est qu'une unité d'isolation, imparfaite comme le sont la plupart des notions universelles. Cela dit, il existe certaines faiblesses systémiques, discutées ci-dessous.

8.1 Reliance on DNS (Dépendance au DNS)

En pratique, la politique de même origine s'appuie sur le système de noms de domaine (DNS) pour la sécurité car de nombreux schémas d'URI couramment utilisés, tels que http, utilisent des autorités de nommage basées sur DNS. Si le DNS est partiellement ou entièrement compromis, la politique de même origine pourrait ne pas fournir les propriétés de sécurité requises par les applications.

Certains schémas d'URI, tels que https, sont plus résistants à la compromission DNS car les agents utilisateurs emploient d'autres mécanismes, tels que les certificats, pour vérifier la source du contenu récupéré depuis ces URI. D'autres schémas d'URI, tels que le schéma URI chrome-extension (voir Section 4.3 de [CRX]), utilisent une autorité de nommage basée sur une clé publique et sont entièrement sécurisés contre la compromission DNS.

Le concept d'origine Web isole le contenu récupéré depuis différents schémas d'URI; ceci est essentiel pour contenir les effets de la compromission DNS.

8.2 Divergent Units of Isolation (Unités d'isolation divergentes)

Au fil du temps, un certain nombre de technologies ont convergé vers le concept d'origine Web comme unité d'isolation pratique. Cependant, de nombreuses technologies en use aujourd'hui, telles que les cookies [RFC6265], sont antérieures au concept moderne d'origine Web. Ces technologies ont souvent des unités d'isolation différentes, conduisant à des vulnérabilités.

Une alternative consiste à utiliser uniquement le domaine "contrôlé par le registre" plutôt que le nom de domaine entièrement qualifié comme unité d'isolation (par exemple, "example.com" au lieu de "www.example.com"). Cette pratique est problématique pour plusieurs raisons et n'est PAS RECOMMANDÉE:

La notion de domaine "contrôlé par le registre" est une fonction de la pratique humaine entourant le DNS plutôt qu'une propriété du DNS lui-même. Par exemple, de nombreuses municipalités au Japon gèrent des registres publics assez profondément dans la hiérarchie DNS. Il existe des "listes de suffixes publics" largement utilisées, mais ces listes sont difficiles à maintenir à jour et varient entre les implémentations.
Cette pratique est incompatible avec les schémas d'URI qui n'utilisent pas d'autorité de nommage basée sur DNS. Par exemple, si un schéma d'URI donné utilise des clés publiques comme autorités de nommage, la notion de clé publique "contrôlée par le registre" est quelque peu incohérente. Pire encore, certains schémas d'URI, tels que nntp, utilisent la délégation en points dans la direction opposée au DNS (par exemple, alt.usenet.kooks), et d'autres utilisent le DNS mais présentent les étiquettes dans l'ordre inverse de l'ordre habituel (par exemple, com.example.www).

Au mieux, l'utilisation de domaines "contrôlés par le registre" est spécifique au schéma d'URI et à l'implémentation. Au pire, les différences entre les schémas d'URI et les implémentations peuvent conduire à des vulnérabilités.

8.3 Ambient Authority (Autorité ambiante)

Lors de l'utilisation de la politique de même origine, les agents utilisateurs accordent l'autorité au contenu en fonction de son URI plutôt qu'en fonction des objets que le contenu peut désigner. Ce découplage de la désignation et de l'autorité est un exemple d'autorité ambiante et peut conduire à des vulnérabilités.

Considérez, par exemple, le cross-site scripting dans les documents HTML. Si un attaquant peut injecter du contenu de script dans un document HTML, ces scripts s'exécuteront avec l'autorité de l'origine du document, permettant peut-être au script d'accéder à des informations sensibles, telles que les dossiers médicaux de l'utilisateur. Si, cependant, l'autorité du script était limitée aux objets que le script peut désigner, l'attaquant ne gagnerait aucun avantage en injectant le script dans un document HTML hébergé par un tiers.

8.4 IDNA Dependency and Migration (Dépendance et migration IDNA)

Les propriétés de sécurité de la politique de même origine peuvent dépendre de manière cruciale des détails de l'algorithme IDNA employé par l'agent utilisateur. En particulier, un agent utilisateur peut mapper certains noms de domaine internationalisés (par exemple, ceux impliquant le caractère U+00DF) à différentes représentations ASCII selon que l'agent utilisateur utilise IDNA2003 [RFC3490] ou IDNA2008 [RFC5890].

La migration d'un algorithme IDNA à un autre pourrait redessiner un certain nombre de frontières de sécurité, établissant potentiellement de nouvelles frontières de sécurité ou, pire encore, démolissant les frontières de sécurité entre deux entités qui se méfient mutuellement. Changer les frontières de sécurité est risqué car combiner deux entités qui se méfient mutuellement dans la même origine pourrait permettre à l'une d'attaquer l'autre.