Demande de commentaires: CORS pour les réseaux privés (RFC1918)

Atténuez les risques associés à l'exposition involontaire d'appareils et de serveurs sur le réseau interne d'un client au Web en général.

Eiji Kitamura

Les sites Web malveillants qui envoient des requêtes à des appareils et des serveurs hébergés sur un réseau privé constituent une menace depuis longtemps. Man-in-the-Middle CORS-RFC1918 est une proposition visant à bloquer ces requêtes par défaut sur le navigateur et à exiger que les appareils internes acceptent les requêtes provenant de l'Internet public.

Pour comprendre l'impact de cette modification sur l'écosystème Web, l'équipe Chrome recherche les commentaires des développeurs qui créent des serveurs pour les réseaux privés.

Quel est le problème avec le statu quo ?

De nombreux serveurs Web s'exécutent au sein d'un réseau privé : routeurs sans fil, imprimantes, sites Web intranet, services d'entreprise et appareils IoT (Internet des objets) ne sont que quelques exemples. Ils peuvent sembler être dans un environnement plus sûr que ceux exposés au public, mais ces serveurs peuvent être utilisés à mauvais escient par des pirates informatiques à l'aide d'une page Web comme proxy. Par exemple, les sites Web malveillants peuvent intégrer une URL qui, lorsqu'elle est simplement consultée par la victime (sur un navigateur compatible avec JavaScript), tente de modifier les paramètres du serveur DNS sur le routeur haut débit domestique de la victime. Ce type d'attaque est appelé "Drive-By Pharming" et s'est produit en 2014. Plus de 300 000 routeurs sans fil vulnérables ont été exploités en modifiant leurs paramètres DNS,ce qui a permis aux pirates informatiques de rediriger les utilisateurs vers des serveurs malveillants.

CORS-RFC1918

Pour atténuer la menace d'attaques similaires, la communauté Web introduit CORS-RFC1918—un partage des ressources cross-origin (CORS) spécialisé pour les réseaux privés définis dans la RFC1918.

Les navigateurs qui implémentent CORS vérifient auprès des ressources cibles si elles peuvent être chargées à partir d'une origine différente. Cela se fait soit avec des en-têtes supplémentaires en ligne décrivant l'accès, soit à l'aide d'un mécanisme appelé requêtes préliminaires, en fonction de la complexité. Pour en savoir plus, consultez Partage des ressources cross-origin.

Avec CORS-RFC1918, le navigateur bloque par défaut le chargement des ressources sur le réseau privé, à l'exception de celles qui sont explicitement autorisées par le serveur à l'aide de CORS et via HTTPS. Le site Web qui envoie des requêtes à ces ressources devra envoyer des en-têtes CORS, et le serveur devra indiquer explicitement qu'il accepte la requête cross-origin en répondant avec les en-têtes CORS correspondants. (Les en-têtes CORS exacts sont encore en cours de développement.)

Les développeurs de ces appareils ou serveurs devront effectuer deux opérations :

Assurez-vous que le site Web qui envoie des requêtes à un réseau privé est diffusé via HTTPS.
Configurez la prise en charge du serveur pour CORS-RFC1918 et répondez avec les en-têtes HTTP attendus.

Quels types de requêtes sont concernés ?

Les requêtes concernées sont les suivantes :

Requêtes du réseau public vers un réseau privé
Requêtes d'un réseau privé vers un réseau local
Requêtes du réseau public vers un réseau local

Réseau privé Destination qui correspond à l'espace d'adressage privé défini dans la section 3 de la RFC1918 dans IPv4, une adresse IPv6 mappée sur IPv4 où l'adresse IPv4 mappée est elle-même privée, ou une adresse IPv6 en dehors des sous-réseaux ::1/128, 2000::/3 et ff00::/8.

Réseau local Destination qui correspond à l'espace de « bouclage » (127.0.0.0/8) défini dans la section 3.2.1.3 de RFC1122 d'IPv4, l'espace « liaison locale » (169.254.0.0/16) défini dans RFC3927 d'IPv4, le préfixe « Adresse locale unique » (fc00::/7) défini dans la section 3 de RFC4193 d'IPv6, ou le préfixe « liaison locale » (fe80::/10) défini dans la section 2.5.6 de RFC4291 d'IPv6.

Réseau public : tous les autres.

Relation entre les réseaux publics, privés et locaux dans CORS-RFC1918.

Plans de Chrome pour activer CORS-RFC1918

Chrome introduit CORS-RFC1918 en deux étapes :

Étape 1 : Les requêtes adressées aux ressources du réseau privé ne seront autorisées que depuis les pages Web HTTPS

Chrome 87 ajoute un indicateur qui exige que les sites Web publics qui envoient des requêtes aux ressources du réseau privé soient en HTTPS. Vous pouvez accéder à about://flags#block-insecure-private-network-requests pour l'activer. Lorsque cet indicateur est activé, toutes les requêtes adressées à une ressource de réseau privé à partir d'un site Web HTTP sont bloquées.

À partir de Chrome 88, les erreurs CORS-RFC1918 seront signalées comme des erreurs de règle CORS dans la console.

Les erreurs CORS-RFC1918 seront signalées comme des erreurs liées à la règle CORS dans la console. — Les erreurs CORS-RFC1918 seront signalées comme des erreurs de règle CORS dans la **console**.

Dans le panneau Réseau des outils de développement Chrome, vous pouvez cocher la case Requêtes bloquées pour vous concentrer sur les requêtes bloquées :

Les erreurs CORS-RFC1918 seront également signalées comme des erreurs CORS dans le panneau "Réseau". — Les erreurs CORS-RFC1918 seront également signalées comme des erreurs CORS dans le panneau **Réseau**.

Dans Chrome 87, les erreurs CORS-RFC1918 ne sont signalées que dans la console des outils de développement sous la forme ERR_INSECURE_PRIVATE_NETWORK_REQUEST.

Vous pouvez l'essayer vous-même à l'aide de ce site Web de test.

Étape 2 : Envoyer des requêtes préliminaires avec un en-tête spécial

À l'avenir, lorsqu'un site Web public tentera d'extraire des ressources d'un réseau privé ou local, Chrome enverra une requête préliminaire avant la requête réelle.

La requête inclura un en-tête Access-Control-Request-Private-Network: true en plus des autres en-têtes de requête CORS. Entre autres, ces en-têtes identifient l'origine de la requête, ce qui permet un contrôle d'accès précis. Le serveur peut répondre avec un Access-Control-Allow-Private-Network: true en-tête pour indiquer explicitement qu'il accorde l'accès à la ressource.

Commentaires souhaités

Si vous hébergez un site Web au sein d'un réseau privé qui attend des requêtes provenant de réseaux publics, l'équipe Chrome est intéressée par vos commentaires et vos cas d'utilisation. Vous pouvez nous aider de deux manières :

Accédez à about://flags#block-insecure-private-network-requests, activez l'indicateur et vérifiez si votre site Web envoie des requêtes à la ressource de réseau privé comme prévu.
Si vous rencontrez des problèmes ou avez des commentaires, signalez-les sur crbug.com et définissez le composant sur Blink>SecurityFeature>CORS>RFC1918.

Exemple de commentaire

Notre routeur sans fil diffuse un site Web d'administration pour le même réseau privé, mais via HTTP. Si le protocole HTTPS est requis pour les sites Web qui intègrent le site Web d'administration, il s'agira de contenu mixte. Devons-nous activer HTTPS sur le site Web d'administration dans un réseau fermé ?

C'est exactement le type de commentaires que Chrome recherche. Veuillez signaler un problème avec votre cas d'utilisation concret sur crbug.com. Chrome serait ravi de vous entendre.