L'essai d'abandon de l'accès au réseau privé pour les contextes non sécurisés s'achève : implémentez l'invite d'autorisation PNA

Yifan Luo
Yifan Luo
GitHub

Chrome 124 inclut la fonctionnalité d'autorisation d'accès au réseau privé pour assouplir le contenu mixte. Un essai d'abandon est en cours pour les sites nécessitant plus de temps pour se préparer à ce changement. Toutefois, cet essai se termine avec Chrome 126, dont la date de lancement est prévue le 4 septembre 2024. Ce post explique ce changement, et décrit la conception de cette fonctionnalité, comment migrer vos sites Web actuels et comment tester votre implémentation.

Qu'est-ce qui change ?

Pour établir des connexions à des appareils sur un réseau privé qui ne possèdent pas de noms uniques et qui ne peuvent donc pas obtenir de certificats TLS, cette fonctionnalité introduit une nouvelle option dans fetch(), qui permet de déclarer l'intention d'un développeur de communiquer avec un tel appareil. Cela inclut une nouvelle fonctionnalité contrôlée par des règles pour contrôler l'accès de chaque site à cette fonctionnalité, ainsi que de nouveaux en-têtes pour la réponse préliminaire du serveur afin de fournir des métadonnées supplémentaires.

Qu'est-ce que l'accès au réseau privé ?

L'accès au réseau privé (PNA, anciennement CORS-RFC1918 et brièvement appelé Accès au réseau local) est une fonctionnalité de sécurité qui limite la capacité des sites Web à envoyer des requêtes aux serveurs sur des réseaux privés. Cela permet de protéger les utilisateurs et les réseaux internes contre les attaques potentielles telles que la falsification de requêtes intersites (CSRF). Chrome implémente progressivement la PNA, et la protection sera étendue dans les prochaines versions.

Pourquoi une invite d'autorisation est-elle nécessaire ?

Chrome 94 a introduit un blocage de l'accès aux réseaux privés à partir des sites Web publics non sécurisés. L' essai en cours d'abandon de l'accès au réseau privé depuis des contextes non sécurisés a révélé les défis liés à la migration des sites Web concernés vers HTTPS. Un problème courant est la difficulté de migrer des appareils privés vers HTTPS, ce qui entraîne des infractions lors de la vérification du contenu mixte.

Pour relever ce défi, une nouvelle invite d'autorisation a été ajoutée dans le cadre d'une phase d'évaluation à partir de Chrome 120 et en version stable à partir de Chrome 124.

Quand une demande d'autorisation est-elle nécessaire ?

Nous avions prévu de mettre fin à l'essai d'abandon des contextes non sécurisés quelques étapes après le lancement de la fonctionnalité d'invite d'autorisation. Pour assurer la compatibilité, vous devez migrer vos sites Web publics vers HTTPS. Si vous ne pouvez pas migrer votre serveur privé vers HTTPS, la nouvelle fonctionnalité d'invite d'autorisation vous permettra d'assouplir les vérifications de contenu mixte.

Voici un workflow type pour une requête d'accès au réseau privé avec invite d'autorisation.

Déclencher l'invite d'autorisation

Ajoutez le nouvel attribut targetAddressSpace en tant qu'option de récupération. La requête peut ensuite ignorer la vérification du contenu mixte.

fetch("http://router.local/ping", {
  targetAddressSpace: "private",
});

Conformément à la règle Accès au réseau privé: introduction des vérifications préliminaires, toute requête de réseau privé est précédée d'une requête préliminaire. Cette requête préliminaire comprend un nouvel en-tête, Access-Control-Request-Private-Network: true, et la réponse correspondante doit inclure l'en-tête Access-Control-Allow-Private-Network: true.

Pour s'adapter à la nouvelle invite d'autorisation, les appareils doivent intégrer deux nouveaux en-têtes de réponse: Private-Network-Access-Name et Private-Network-Access-ID.

  • Private-Network-Access-ID: valeur de 48 bits présentée sous forme de 6 octets hexadécimaux séparés par des deux-points.
  • Private-Network-Access-Name: nom valide sous forme de chaîne correspondant à l'expression régulière ECMAScript /^[a-z0-9_-.]+$/.. La longueur maximale du nom est de 248 unités de code UTF-8.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"

Démonstration

Vous pouvez consulter la version de démonstration à l'adresse https://private-network-access-permission-test.glitch.me/.

Vous devez démarrer votre serveur privé personnel pour utiliser le site Web de démonstration. Le serveur privé doit répondre avec l'en-tête HTTP Access-Control-Allow-Private-Network: true, ainsi que les en-têtes spécifiés par le serveur Private-Network-Access-ID et Private-Network-Access-Name. Si tout est correctement configuré, l'invite d'autorisation suivante doit s'afficher:

Quitter l'essai d'abandon du contexte non sécurisé

Pour les sites Web qui ont enregistré un essai d'abandon de l'accès au réseau privé pour les contextes non sécurisés, le moment est venu de migrer votre site Web avec notre nouvelle invite d'autorisation et de mettre fin à l'essai maintenant.

Après avoir mis à jour votre code, supprimez le jeton d'essai dans vos en-têtes HTML, JavaScript ou HTTP. Si vous ne vous souvenez pas où vous avez placé le jeton d'essai, consultez la section S'inscrire à un essai avec abandon de l'article de blog précédent.

Vous pouvez également supprimer le jeton sur la page de l'essai.

Étape suivante

La solution pour les requêtes provenant de fetch() hors API est toujours en cours d'exploration.

Plusieurs solutions ont été testées, par exemple l'utilisation de service workers ou la création d'un espace d'adressage cible en tant que nouvelle stratégie de sécurité du contenu. Toutefois, la forme finale des requêtes provenant de fetch() hors API est toujours en cours d'examen.

À l'avenir, les requêtes provenant de sous-frames pourront être prises en charge avec des règles d'autorisation.

À l'avenir, nous pourrions vouloir prendre en charge des règles d'autorisation pour assouplir cette fonctionnalité.

Commentaires sur les cas d'utilisation de réseaux privés

Si vous hébergez un site Web sur un réseau privé qui a besoin de requêtes provenant de réseaux publics, l'équipe Chrome a besoin de vos commentaires. Signalez un problème dans l'outil Chromium Issue Tracker (composant: Blink>SecurityFeature>CORS>PrivateNetworkAccess) ou dans le dépôt GitHub.

Ressources