Accès au réseau privé: introduction des vérifications préliminaires

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

Mises à jour

• 7 juillet 2022: mise à jour de l'état actuel et ajout de la définition de l'espace d'adressage IP.
• 27 avril 2022: mise à jour du calendrier annoncé.
• 7 mars 2022: annonce du rollback après la détection de problèmes dans Chrome 98.

Introduction

Chrome abandonne l'accès direct aux points de terminaison du réseau privé depuis des sites Web dans le cadre Accès au réseau privé (PNA) spécifique.

Chrome commencera à envoyer une requête CORS préliminaire avant toute requête de réseau privé pour une sous-ressource, ce qui demande pour obtenir une autorisation explicite du serveur cible. Cette requête préliminaire comporte un nouvel en-tête, Access-Control-Request-Private-Network: true, doit comporter un en-tête correspondant, Access-Control-Allow-Private-Network: true

L'objectif est de protéger les utilisateurs contre les attaques par falsification de requête intersites (CSRF). ciblant des routeurs et d'autres appareils sur des réseaux privés. Ces attaques ont touché des centaines de milliers d'utilisateurs, permettant aux attaquants de les rediriger vers des serveurs malveillants.

Plan de déploiement

Chrome déploiera ce changement en deux phases pour que les sites Web aient le temps de s'en rendre compte le changement et les ajuster en conséquence.

1. Dans Chrome 104:

   • Chrome expérimente en envoyant des requêtes préliminaires avant le réseau privé des requêtes de sous-ressources.
   • En cas d'échec des vérifications préliminaires, seuls les avertissements sont affichés dans les outils de développement. affectant les requêtes du réseau privé.
   • Chrome recueille des données de compatibilité et contacte les utilisateurs les plus concernés sites Web.
   • Elle devrait offrir une compatibilité étendue avec les sites Web existants.
   Avertissement:Pour limiter les effets sur les sites Web qui ne prennent pas encore en charge les requêtes préliminaires, le délai avant expiration est limité à 200 millisecondes dans Chrome 104. La restriction ne s'applique appliquée en mode avertissement. Le délai avant expiration spécial sera supprimé après activer le mode d'application en activant l'option "Respecter le résultat du réseau privé" Accéder aux requêtes préliminaires sur "Activé" dans chrome://flags, et la limite par défaut est de 5 secondes.

2. Au plus tôt dans Chrome 113:

   • Elle ne commencera que si et quand les données de compatibilité indiquent que la le changement est suffisamment sûr et nous avons contacté directement si nécessaire.
   • Chrome fait en sorte que les requêtes préliminaires doivent aboutir. Dans le cas contraire, les requêtes échouent. les demandes.
   • L'évaluation avant arrêt commence à tout en permettant aux sites Web concernés par cette phase de demander un une extension de temps. L'essai durera au moins six mois.

Remarque:Une tentative précédente a été effectuée pour déployer des avertissements dans Chrome 98 et Chrome 102, annoncé dans cet article de blog. Un rollback a été effectué après la stabilité des problèmes de compatibilité ont été découverts lors du déploiement. Les problèmes identifiés ont été résolus pour Chrome 104.

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

Accès au réseau privé (anciennement CORS-RFC1918) limite la capacité des sites Web à envoyer des requêtes aux serveurs sur des réseaux sociaux.

Chrome a déjà implémenté une partie de la spécification: à partir de Chrome 96, seuls les contextes sécurisés sont autorisés à effectuer des requêtes de réseau privé. Consultez notre article de blog précédent.

La spécification étend également le partage des ressources inter-origines (CORS, Cross-Origin Resource Sharing) de sorte que les sites Web doivent désormais demander explicitement une autorisation aux serveurs sur des réseaux privés avant d'être autorisés à envoyer des requêtes arbitraires.

Terme clé:les requêtes de réseau privé sont des requêtes dont l'adresse IP du serveur cible est plus privé que celui à partir duquel l'initiateur de la requête a été extrait. Par exemple : une requête provenant d'un site Web public (https://example.com) vers un site Web privé (http://router.local), ou une requête d'un site Web privé à localhost.

Comment PNA classe-t-elle les adresses IP et identifie-t-elle un réseau privé ?

Les adresses IP sont classées en trois espaces d'adresses IP: – public – private – local

L'espace d'adressage IP local contient des adresses IP au format IPv4. les adresses de bouclage (127.0.0.0/8) définies dans la section 3.2.1.3 de la RFC1122. ou les adresses de bouclage IPv6 (::1/128) définies dans la section 2.5.3 de la norme RFC4291.

L'espace d'adressage IP privé contient des adresses IP qui n'ont de sens que au sein du réseau actuel, y compris 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16 défini dans la RFC1918, les adresses de liaison locale 169.254.0.0/16 définies dans la RFC3927 ; adresses unicast IPv6 locales uniques fc00::/7 définies dans la RFC4193 ; Adresses unicast de type lien-local IPv6 fe80::/10 définies dans la section 2.5.6 de la documentation RFC4291 et les adresses IPv6 mappées avec IPv4 où l’adresse IPv4 mappée est elle-même privée.

L'espace d'adresses IP publiques contient toutes les autres adresses qui n'ont pas été mentionnées précédemment.

Une adresse IP locale est considérée comme plus privée qu'une adresse IP privée, est considérée comme plus privée qu'une adresse IP publique.

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> Relation entre les réseaux publics, privés et locaux dans le réseau privé Accès (CORS-RFC1918)

.

Pour en savoir plus, consultez la section Commentaires voulus: CORS pour les réseaux privés (RFC1918).

Requêtes préliminaires

Contexte

Les requêtes préliminaires sont un mécanisme introduit par la norme CORS (Cross-Origin Resource Sharing) utilisée pour demander l'autorisation à un site Web cible avant de lui envoyer une requête HTTP qui pourraient avoir des effets secondaires. Cela garantit que le serveur cible comprend le protocole CORS et réduit considérablement le risque d'attaques CSRF.

La demande d'autorisation est envoyée sous la forme d'une requête HTTP OPTIONS avec des en-têtes de requête CORS spécifiques. décrivant la requête HTTP à venir. La réponse doit comporter des en-têtes de réponse CORS spécifiques. explicitement la demande à venir.

Nouveautés de l'accès au réseau privé

Une nouvelle paire d'en-têtes de requête et de réponse est introduite dans les requêtes préliminaires:

• Access-Control-Request-Private-Network: true est défini sur toutes les requêtes préliminaires PNA
• Access-Control-Allow-Private-Network: true doit être défini sur toutes les réponses de la requête préliminaire PNA

Les requêtes préliminaires pour PNA sont envoyées pour toutes les requêtes de réseau privé, quelle que soit la méthode de requête mode. Elles sont envoyées avant les requêtes en mode cors, ainsi que dans no-cors et dans tous les autres modes. Ce est que toutes les requêtes de réseau privé peuvent être utilisées pour des attaques CSRF, quel que soit le mode de requête et que le contenu de la réponse soit envoyé ou non à la disposition de l'initiateur.

Remarque:Si la requête de réseau privé est effectuée en mode cors, les en-têtes CORS doivent être défini sur la réponse finale, en plus de la réponse préliminaire.

Les requêtes préliminaires pour PNA sont également envoyées pour les requêtes de même origine, si le l'adresse IP cible est plus privée que l'initiateur. Ce n'est pas le cas CORS, où les requêtes préliminaires sont réservées aux requêtes multi-origines Requête préliminaire des requêtes de même origine afin d'éviter Attaques par reliaison DNS

Exemples

Le comportement observable dépend du mode de requête.

Mode sans CORS

Dites https://foo.example/index.html éléments intégrés <img src="https://bar.example/cat.gif" alt="dancing cat"/> bar.example renvoie 192.168.1.1, une adresse IP privée selon RFC 1918

Chrome envoie d'abord une requête préliminaire:

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

Pour que cette requête aboutisse, le serveur doit répondre par:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

Avertissement:Le serveur peut définir Access-Control-Allow-Origin: *, bien que cela soit dangereux et découragés. Les ressources d'un réseau privé devraient rarement être accessibles à tous Vous devez donc bien réfléchir aux risques liés à la définition d'un tel en-tête.

Chrome enverra ensuite la requête proprement dite:

HTTP/1.1 GET /cat.gif
...

auquel le serveur peut répondre normalement.

Mode CORS

Supposons que https://foo.example/index.html exécute le code suivant:

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

Supposons à nouveau que bar.example renvoie 192.168.1.1.

Chrome envoie d'abord une requête préliminaire:

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

Pour que cette requête aboutisse, le serveur doit répondre par:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

Chrome enverra ensuite la requête proprement dite:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

auquel le serveur peut répondre conformément aux règles CORS habituelles:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

Savoir si votre site Web est concerné

À partir de Chrome 104, si une requête de réseau privé est détectée, une requête la requête sera envoyée avant. Si cette requête préliminaire échoue, sera tout de même envoyée, mais un avertissement s'affichera dans des problèmes.

Vous pouvez également afficher et analyser les requêtes préliminaires concernées dans le panneau "Network" :

Si votre requête aurait déclenché une requête préliminaire CORS standard sans règles d'accès au réseau privé, deux requêtes préliminaires peuvent apparaître réseau, le premier apparaissant toujours comme ayant échoué. Il s'agit d'un bug connu et que vous pouvez ignorer.

Pour savoir ce qui se passe si l'application réussit, vous pouvez transmettez l'argument de ligne de commande suivant : à partir de Chrome 98:

--enable-features=PrivateNetworkAccessRespectPreflightResults

Toute requête préliminaire ayant échoué entraînera l'échec de la récupération. Cela peut vous permettre pour tester si votre site Web fonctionnera après la deuxième phase de notre plan de déploiement. Les erreurs peuvent être diagnostiquées dans de la même manière que les avertissements affichés dans les panneaux des outils de développement mentionnés ci-dessus.

Que faire si votre site Web est concerné ?

Lorsque cette modification sera déployée dans Chrome 104, sur votre site Web. Toutefois, nous vous encourageons vivement à mettre à jour les chemins de requêtes concernés pour les rendre vous assurer que votre site Web continue de fonctionner comme prévu.

Deux solutions s'offrent à vous:

1. Gérer les requêtes préliminaires côté serveur
2. Désactiver les vérifications PNA à l'aide des règles d'entreprise

Gérer les requêtes préliminaires côté serveur

Mettre à jour le serveur cible de toutes les extractions concernées pour gérer la requête préliminaire PNA requêtes. Tout d'abord, implémentez la prise en charge des requêtes CORS préliminaires standards sur de routes concernées. Ajoutez ensuite la prise en charge de deux nouveaux en-têtes de réponse.

Lorsque votre serveur reçoit une requête préliminaire (une requête OPTIONS avec CORS en-têtes), le serveur doit vérifier la présence d'un Access-Control-Request-Private-Network: true. Si cet en-tête est présentes dans la requête, le serveur doit examiner l'en-tête Origin et les chemin de la requête, ainsi que toute autre information pertinente (comme Access-Control-Request-Headers) pour vous assurer que la requête peut être autorisée sans risque. En règle générale, vous devez autoriser l'accès à une seule origine sous votre contrôle.

Avertissement:Méfiez-vous des origines non sécurisées (non HTTPS), car elles ne sont pas authentifiées. Un sur le chemin pirate informatique pourrait se faire passer pour une telle origine.

Une fois que votre serveur a décidé d'autoriser la requête, il doit répondre 204 No Content (ou 200 OK) par les en-têtes CORS nécessaires et le nouveau PNA ; en-tête. Ces en-têtes incluent Access-Control-Allow-Origin et Access-Control-Allow-Private-Network: true, et d'autres si nécessaire.

Consultez les exemples pour découvrir des scénarios concrets.

Désactiver les vérifications de l'accès au réseau privé à l'aide de règles d'entreprise

Si vous avez un contrôle administratif sur vos utilisateurs, vous pouvez désactiver Les vérifications de l'accès au réseau sont effectuées à l'aide de l'une des règles suivantes:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Pour plus d'informations, consultez Fonctionnement de la gestion des règles Chrome.

Envoyez-nous vos commentaires.

Si vous hébergez un site Web sur un réseau privé qui attend des requêtes de réseaux publics, l'équipe Chrome aimerait connaître votre avis et vos cas d'utilisation. Signalez-nous le problème que vous rencontrez avec Chromium sur crbug.com et définissez le composant sur Blink>SecurityFeature>CORS>PrivateNetworkAccess.

Étape suivante

Chrome étendra ensuite les vérifications de l'accès au réseau privé pour couvrir Nœuds de calcul Web: les travailleurs dédiés, les travailleurs partagés et les service workers. Nous visons timidement pour Chrome 107 commence à afficher des avertissements.

Chrome étendra ensuite les vérifications de l'accès au réseau privé pour couvrir les navigations, y compris les iFrames et les pop-ups. Nous visons provisoirement le lancement de Chrome 108 affichant des avertissements.

Dans les deux cas, nous procéderons à un déploiement par étapes similaire avec précaution. afin de donner aux développeurs Web le temps d'ajuster et d'estimer le risque de compatibilité.

Remerciements

Photo de couverture de Mark Olsen prise le Unsplash.