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é permettant d'assouplir le contenu mixte. Une évaluation avant arrêt est en cours pour les sites qui ont besoin de plus de temps pour se préparer à ce changement. Toutefois, cette évaluation se termine avec Chrome 132, qui devrait être publié le 4 février 2025. Cet article explique le changement, la conception de la fonctionnalité, comment migrer vos sites Web actuels et comment tester votre implémentation.

Qu'est-ce qui change ?

Pour établir des connexions avec des appareils sur un réseau privé qui ne disposent pas de noms uniques globaux et ne peuvent donc pas obtenir de certificats TLS, cette fonctionnalité introduit une nouvelle option dans fetch() pour 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 de pré-vérification du serveur afin de fournir des métadonnées supplémentaires.

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

L'accès au réseau privé (PNA, anciennement appelé CORS-RFC1918 et brièvement "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ête intersite (CSRF). Chrome a progressivement implémenté 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 au réseau privé à partir de sites Web publics non sécurisés. L' essai de suppression de l'accès au réseau privé à partir de contextes non sécurisés en cours a révélé des difficultés à migrer les sites Web concernés vers le protocole HTTPS. Un problème courant est la difficulté de migrer des appareils privés vers HTTPS, ce qui entraîne des cas de non-respect de la vérification du contenu mixte.

Pour résoudre ce problème, une nouvelle invite d'autorisation a été ajoutée dans une phase d'évaluation de l'origine à partir de Chrome 120 et dans la version stable à partir de Chrome 124.

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

Nous avions prévu de mettre fin à l'essai de l'abandon des contextes non sécurisés quelques jalons après la mise à disposition 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 de vous détendre lors des 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 alors ignorer la vérification du contenu mixte.

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

Conformément à Accès au réseau privé: présentation des prévols, toute requête de réseau privé est précédée d'une requête préliminaire. Cette requête préliminaire inclura 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 prendre en charge 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 la forme de six 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émo

Vous pouvez consulter la démonstration sur 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 Private-Network-Access-ID et Private-Network-Access-Name spécifiés par le serveur. Si tout est correctement configuré, l'invite d'autorisation suivante devrait s'afficher:

Quitter l'essai de l'abandon des contextes non sécurisés

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

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 pour l'essai de l'abandon de l'article de blog précédent.

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

Étape suivante

Une solution pour les requêtes provenant de fetch() autres que des API est toujours à l'étude.

Plusieurs solutions ont été testées, par exemple en utilisant des service workers ou en définissant l'espace d'adresses cible comme une nouvelle règle Content-Security-Policy. Toutefois, la forme finale des requêtes provenant de fetch() non API est toujours à l'étude.

Les requêtes provenant de sous-cadres pourront être prises en charge par la stratégie d'autorisation à l'avenir.

À l'avenir, nous pourrions prendre en charge les règles d'autorisation pour assouplir les fonctionnalités des sous-cadres.

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

Si vous hébergez un site Web sur un réseau privé qui nécessite des requêtes provenant de réseaux publics, l'équipe Chrome aimerait connaître votre avis. Signalez un problème dans l'outil de suivi des problèmes Chromium (composant: Blink>SecurityFeature>CORS>PrivateNetworkAccess) ou dans le dépôt GitHub.

Ressources