Atténuer les risques associés à une exposition involontaire des appareils et des serveurs situés sur le réseau interne d'un client au Web en général
Les sites Web malveillants envoyant des requêtes à des appareils et des serveurs hébergés sur un réseau privé représentent depuis longtemps une menace. Les pirates informatiques peuvent, par exemple, modifier la configuration d'un routeur sans fil pour permettre les attaques Man-in-the-Middle. CORS-RFC1918 est une proposition visant à bloquer par défaut de telles requêtes sur le navigateur et à exiger que les appareils internes acceptent les requêtes provenant de l'Internet public.
Pour comprendre l'impact de ce changement sur l'écosystème Web, l'équipe Chrome souhaite recueillir 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 au sein d'un réseau privé. Les routeurs sans fil, les imprimantes, les sites intranet, les services d'entreprise et les appareils IoT (Internet des objets) n'en font pas partie. Ils peuvent sembler se trouver dans un environnement plus sûr que ceux exposés au public, mais ils peuvent être détournés par des pirates informatiques utilisant 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 JavaScript), tente de modifier les paramètres du serveur DNS sur le routeur haut débit du domicile de la victime. Ce type d'attaque, appelé Drive-By Pharming, est apparu en 2014. Plus de 300 000 routeurs sans fil vulnérables ont été exploités en modifiant leurs paramètres DNS et en permettant à des pirates informatiques de rediriger les utilisateurs vers des serveurs malveillants.
CORS-RFC1918
Pour réduire la menace d'attaques similaires, la communauté Web apporte CORS-RFC1918 : le partage des ressources entre origines multiples (CORS, Cross Origin Resource Sharing), 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 acceptent le chargement depuis une origine différente. Pour ce faire, soit avec des en-têtes supplémentaires intégrés 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 la section Partage des ressources entre origines multiples.
Avec CORS-RFC1918, le navigateur bloque par défaut le chargement des ressources sur le réseau privé, à l'exception de celles explicitement autorisées par le serveur à l'aide du CORS et du HTTPS. Le site Web qui envoie des requêtes à ces ressources doit envoyer des en-têtes CORS, et le serveur doit 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 encore en cours de développement.)
Les développeurs de ces appareils ou serveurs seront invités à:
- Assurez-vous que le site Web qui envoie des requêtes à un réseau privé est diffusé via HTTPS.
- Configurez la compatibilité du serveur avec la norme CORS-RFC1918 et répondez avec les en-têtes HTTP attendus.
Quels types de requêtes sont concernés ?
Requêtes concernées:
- Requêtes depuis le 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
Un réseau privé
Une destination qui résout l'espace d'adressage privé défini à la section 3 de la norme RFC1918 sur 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.
Un réseau local
Une destination qui correspond à l'espace de "bouclage" (127.0.0.0/8) défini dans la section 3.2.1.3 de la RFC1122 d'IPv4, l'espace "lien-local" (169.254.0.0/16) défini dans la RFC3927 d'IPv4, le préfixe "Adresse locale unique" (fc00::/7) défini à la section 3 de la section {RFC/93, 2.1} du préfixeRFC4193fe80::/10RFC4291
Un réseau public Tous les autres.
Chrome prévoit d'activer la norme CORS-RFC1918
Chrome applique la norme CORS-RFC1918 en deux étapes:
Étape 1: Les requêtes vers des ressources du réseau privé ne seront autorisées qu'à partir de pages Web HTTPS
Chrome 87 ajoute un indicateur qui exige que les sites Web publics envoyant des requêtes à des ressources réseau privées soient sur HTTPS. Vous pouvez accéder à about://flags#block-insecure-private-network-requests pour l'activer. Lorsque cette option est activée, toutes les requêtes adressées à une ressource de réseau privé depuis un site Web HTTP sont bloquées.
À partir de Chrome 88, les erreurs CORS-RFC1918 seront signalées en tant qu'erreurs liées aux règles CORS dans la console.
Dans le panneau Réseau des outils pour les développeurs Chrome, vous pouvez cocher la case Requêtes bloquées pour vous concentrer sur les requêtes bloquées:
Dans Chrome 87, les erreurs CORS-RFC1918 sont uniquement signalées dans la console DevTools sous la forme ERR_INSECURE_PRIVATE_NETWORK_REQUEST.
Vous pouvez essayer par vous-même en utilisant ce site Web de test.
Étape 2: Envoyer des requêtes préliminaires avec un en-tête spécial
À l'avenir, chaque fois qu'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 d'autres en-têtes de requête CORS. Entre autres, ces en-têtes identifient l'origine à l'origine de la requête, ce qui permet un contrôle des accès ultraprécis. 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 demandé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 sera intéressée par vos commentaires et des cas d'utilisation. Pour cela, vous pouvez procéder de deux façons:
- 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 un problème sur crbug.com et définissez le composant sur
Blink>SecurityFeature>CORS>RFC1918.
Exemple de commentaire
Notre routeur sans fil dessert un site Web d'administration pour le même réseau privé, mais via HTTP. Si HTTPS est requis pour les sites Web qui intègrent le site Web d'administration, il s'agit d'un contenu mixte. Devons-nous activer HTTPS sur le site Web d'administration d'un réseau fermé ?
C'est exactement le type de commentaires que nous recherchons sur Chrome. Veuillez signaler un problème concernant votre cas d'utilisation concret sur crbug.com. Votre avis sur Chrome est toujours le plus adapté.
Image principale de Stephen Philips sur Unsplash.