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

Limitez les risques associés à l'exposition involontaire des appareils et des serveurs du réseau interne d'un client sur le Web.

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 depuis longtemps une menace. Par exemple, un pirate informatique peut modifier la configuration d'un routeur sans fil pour activer les attaques de l'Man-in-the-Middle. CORS-RFC1918 est une proposition visant à bloquer ces requêtes par défaut dans le navigateur et à exiger que les appareils internes activent les requêtes provenant de l'Internet public.

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

Quel est le problème avec le statu quo ?

De nombreux serveurs Web s'exécutent sur un réseau privé. Les routeurs sans fil, les imprimantes, les sites Web intranet, les services d'entreprise et les appareils IoT (Internet of Things) ne sont que quelques-uns des exemples. Ils peuvent sembler se trouver dans un environnement plus sûr que ceux exposés au public, mais ces serveurs peuvent être exploités par des pirates informatiques qui utilisent une page Web comme proxy. Par exemple, des 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é pharming par drive-by 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 propose CORS-RFC1918, un partage de ressources inter-origines (CORS) spécialisé pour les réseaux privés défini 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 autre origine. Pour ce faire, vous pouvez utiliser des en-têtes supplémentaires intégrés décrivant l'accès ou un mécanisme appelé requêtes de prévol, en fonction de la complexité. Pour en savoir plus, consultez Partage de ressources entre origines.

Avec CORS-RFC1918, le navigateur bloque le chargement de ressources sur le réseau privé par défaut, sauf celles 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 multi-origine en répondant avec les en-têtes CORS correspondants. (Les en-têtes CORS exacts sont toujours en cours de développement.)

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

  • 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 demandes 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 se résout à l'espace d'adressage privé défini dans la section 3 de la RFC1918 en IPv4, adresse IPv6 mappée en IPv4 où l'adresse IPv4 mappée est elle-même privée, ou adresse IPv6 en dehors des sous-réseaux ::1/128, 2000::/3 et ff00::/8.

Réseau local Destination qui se résout en espace "loopback" (127.0.0.0/8) défini dans la section 3.2.1.3 de la RFC1122 pour IPv4, espace "link-local" (169.254.0.0/16) défini dans la RFC3927 pour IPv4, préfixe "Unique Local Address" (fc00::/7) défini dans la section 3 de la RFC4193 pour IPv6 ou préfixe "link-local" (fe80::/10) défini dans la section 2.5.6 de la RFC4291 pour IPv6.

Un réseau public Toutes les autres.

Relation entre les réseaux publics, privés et locaux dans CORS-RFC1918
Relations 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 réseau privées ne sont autorisées que depuis des pages Web HTTPS

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

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

Les erreurs CORS-RFC1918 s'affichent comme des erreurs liées aux règles CORS dans la console.
Les erreurs CORS-RFC1918 s'affichent comme des erreurs de stratégie CORS dans la console.

Dans le panneau Network (Réseau) de Chrome DevTools, vous pouvez activer la case à cocher Blocked Requests (Requêtes bloquées) pour vous concentrer sur les requêtes bloquées:

Les erreurs CORS-RFC1918 sont également signalées comme erreurs CORS dans le panneau "Réseau".
Les erreurs CORS-RFC1918 sont également signalées comme erreurs CORS dans le panneau Network (Réseau).

Dans Chrome 87, les erreurs CORS-RFC1918 ne sont signalées dans la console DevTools que sous la forme ERR_INSECURE_PRIVATE_NETWORK_REQUEST.

Vous pouvez tester cette fonctionnalité vous-même sur ce site Web de test.

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

À l'avenir, chaque fois qu'un site Web public tentera d'extraire des ressources à partir d'un réseau privé ou local, Chrome enverra une requête de prévol 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 précis des accès. Le serveur peut répondre avec un en-tête Access-Control-Allow-Private-Network: true pour indiquer explicitement qu'il accorde l'accès à la ressource.

Commentaires souhaités

Si vous hébergez un site Web sur 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 faire deux choses pour l'aider:

  • 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 si vous avez des commentaires, signalez-les sur crbug.com et définissez le composant sur Blink>SecurityFeature>CORS>RFC1918.

Exemples de commentaires

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'agit de contenu mixte. Devrions-nous activer HTTPS sur le site Web de l'administrateur dans un réseau fermé ?

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

Image principale par Stephen Philips sur Unsplash.