Actualités
- 7 juillet 2022: mise à jour de l'état actuel et ajout de la définition de l'espace d'adresses IP.
- 27 avril 2022: annonce de la mise à jour du calendrier.
- 7 mars 2022: annonce du rollback après la découverte de problèmes dans Chrome 98.
Introduction
Chrome abandonne l'accès direct aux points de terminaison de réseau privé à partir de sites Web publics dans le cadre de la spécification Private Network Access (PNA).
Chrome commencera à envoyer une requête préliminaire CORS avant toute requête de réseau privé pour une sous-ressource, qui demande une autorisation explicite auprès du serveur cible. Cette requête préliminaire contiendra un nouvel en-tête, Access-Control-Request-Private-Network: true, et la réponse correspondante 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êtes intersites (CSRF) ciblant les routeurs et d'autres appareils sur des réseaux privés. Ces attaques ont touché des centaines de milliers d'utilisateurs, ce qui a permis aux pirates informatiques de les rediriger vers des serveurs malveillants.
Plan de déploiement
Chrome déploiera cette modification en deux phases pour laisser aux sites Web le temps de la remarquer et de s'y adapter.
Dans Chrome 104:
- Chrome teste l'envoi de requêtes préliminaires avant les requêtes de sous-ressources de réseau privé.
- Les échecs de prévol n'affichent que des avertissements dans DevTools, sans affecter les requêtes de réseau privé.
- Chrome collecte des données de compatibilité et contacte les plus grands sites Web concernés.
- Nous prévoyons que cette fonctionnalité sera largement compatible avec les sites Web existants.
Dans Chrome 113 au plus tôt:
- Cette procédure ne commencera que si et quand les données de compatibilité indiquent que le changement est suffisamment sûr et que nous avons contacté directement les développeurs concernés, le cas échéant.
- Chrome exige que les requêtes préliminaires réussissent, sinon elles échouent.
- Un essai d'abandon commence en même temps pour permettre aux sites Web concernés par cette phase de demander un délai supplémentaire. L'essai durera au moins six mois.
Qu'est-ce que l'accès à un réseau privé (PNA) ?
L'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 privés.
Chrome a déjà implémenté une partie de la spécification: depuis Chrome 96, seuls les contextes sécurisés sont autorisés à envoyer des requêtes réseau privées. Pour en savoir plus, consultez notre article de blog précédent.
La spécification étend également le protocole CORS (Cross-Origin Resource Sharing) afin que les sites Web doivent désormais demander explicitement une autorisation aux serveurs sur les réseaux privés avant d'être autorisés à envoyer des requêtes arbitraires.
Comment la 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'adresses IP locales contient des adresses IP qui sont des adresses de bouclage IPv4 (127.0.0.0/8) définies dans la section 3.2.1.3 de la RFC1122 ou des adresses de bouclage IPv6 (::1/128) définies dans la section 2.5.3 de la RFC4291.
L'espace d'adressage IP privé contient des adresses IP qui n'ont de sens que dans le réseau actuel, y compris 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16 définis dans la RFC1918, les adresses de liaison locale 169.254.0.0/16 définies dans la RFC3927, les adresses unicast IPv6 locales uniques fc00::/7 définies dans la RFC4193, les adresses unicast IPv6 de liaison locale fe80::/10 définies dans la section 2.5.6 de la RFC4291 et les adresses IPv6 mappées en IPv4 où l'adresse IPv4 mappée est elle-même privée.
L'espace d'adresses IP publiques contient toutes les autres adresses non mentionnées précédemment.
Une adresse IP locale est considérée comme plus privée qu'une adresse IP privée, qui est elle-même considérée comme plus privée qu'une adresse IP publique.
Pour en savoir plus, consultez Feedback wanted: CORS for private networks (RFC1918) (Commentaires demandés : 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 Cross-Origin Resource Sharing (CORS), qui permet de demander l'autorisation d'un site Web cible avant de lui envoyer une requête HTTP pouvant 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 requête d'autorisation est envoyée en tant que 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 acceptant explicitement la requête à venir.
Nouveautés de l'accès à un réseau privé
Une nouvelle paire d'en-têtes de requête et de réponse est introduite pour les requêtes préalables:
Access-Control-Request-Private-Network: trueest défini sur toutes les requêtes préliminaires PNA.Access-Control-Allow-Private-Network: truedoit être défini sur toutes les réponses de prévol PNA.
Les requêtes préliminaires pour le PNA sont envoyées pour toutes les requêtes de réseau privé, quelle que soit la méthode et le mode de la requête. Elles sont envoyées avant les requêtes en mode cors, ainsi qu'en mode no-cors et dans tous les autres modes. En effet, toutes les requêtes réseau privées 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 mis à la disposition de l'initiateur ou non.
Les requêtes de prévol pour la PNA sont également envoyées pour les requêtes de même origine, si l'adresse IP cible est plus privée que l'initiateur. Contrairement au CORS standard, les requêtes prévol ne sont destinées qu'aux requêtes inter-origines. Les requêtes de prévol pour les requêtes de même origine protègent contre les attaques par DNS rebinding.
Exemples
Le comportement observable dépend du mode de la requête.
Mode sans CORS
Supposons que https://foo.example/index.html intègre <img src="https://bar.example/cat.gif" alt="dancing cat"/> et que bar.example se résout en 192.168.1.1, une adresse IP privée conformément à la 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 avec:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true
Chrome envoie ensuite la requête réelle:
HTTP/1.1 GET /cat.gif
...
auxquelles 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 encore une fois que bar.example est résolu en 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 avec:
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 envoie ensuite la requête réelle:
HTTP/1.1 PUT /delete-everything
Origin: https://foo.example
À laquelle 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 préliminaire est envoyée avant elle. Si cette requête de prévol échoue, la requête finale sera toujours envoyée, mais un avertissement s'affichera dans le panneau des problèmes de DevTools.
Vous pouvez également afficher et diagnostiquer les requêtes de prévol concernées dans le panneau "Réseau" :
Si votre requête aurait déclenché une prévérification CORS standard sans règles d'accès au réseau privé, deux prévérifications peuvent apparaître dans le panneau de réseau, la première semblant toujours avoir échoué. Il s'agit d'un bug connu que vous pouvez ignorer en toute sécurité.
Pour examiner ce qui se passe si le succès de la prévalidation a été appliqué, vous pouvez transmettre l'argument de ligne de commande suivant à partir de Chrome 98:
--enable-features=PrivateNetworkAccessRespectPreflightResults
Toute requête préliminaire qui échoue entraîne un échec de la récupération. Vous pourrez ainsi tester si votre site Web fonctionnera après la deuxième phase de notre plan de déploiement. Les erreurs peuvent être diagnostiquées de la même manière que les avertissements à l'aide des panneaux DevTools mentionnés ci-dessus.
Que faire si votre site Web est affecté ?
Lorsque ce changement sera déployé dans Chrome 104, il ne devrait pas endommager un site Web. Toutefois, nous vous recommandons vivement de mettre à jour les chemins de requête concernés pour vous assurer que votre site Web continue de fonctionner comme prévu.
Deux solutions s'offrent à vous:
- Gérer les requêtes préliminaires côté serveur
- Désactiver les vérifications PNA avec des règles d'entreprise
Gérer les requêtes de vérification préliminaire côté serveur
Mettez à jour le serveur cible de toutes les récupérations concernées pour gérer les requêtes de prévol PNA. Commencez par implémenter la prise en charge des requêtes préliminaires CORS standards sur les routes concernées. Ajoutez ensuite la compatibilité avec les deux nouveaux en-têtes de réponse.
Lorsque votre serveur reçoit une requête préliminaire (une requête OPTIONS avec des en-têtes CORS), il doit vérifier la présence d'un en-tête Access-Control-Request-Private-Network: true. Si cet en-tête est présent dans la requête, le serveur doit examiner l'en-tête Origin et le chemin de la requête, ainsi que toute autre information pertinente (telle que Access-Control-Request-Headers) pour s'assurer que la requête peut être autorisée.
En règle générale, vous devez autoriser l'accès à une seule origine sous votre contrôle.
Une fois que votre serveur a décidé d'autoriser la requête, il doit répondre 204 No Content (ou 200 OK) avec les en-têtes CORS nécessaires et le nouvel en-tête PNA. Ces en-têtes incluent Access-Control-Allow-Origin et Access-Control-Allow-Private-Network: true, ainsi que d'autres si nécessaire.
Pour obtenir des exemples concrets, consultez les exemples.
Désactiver les vérifications de l'accès au réseau privé à l'aide de règles d'entreprise
Si vous disposez d'un contrôle administratif sur vos utilisateurs, vous pouvez désactiver les vérifications de l'accès au réseau privé à l'aide de l'une des règles suivantes:
Pour en savoir plus, 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 provenant de réseaux publics, l'équipe Chrome est intéressée par vos commentaires et vos cas d'utilisation.
Pour nous en informer, signalez un problème à 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 les nœuds de calcul Web : nœuds de calcul dédiés, nœuds de calcul partagés et nœuds de calcul de service. Nous prévoyons de commencer à afficher des avertissements à partir de Chrome 107.
Chrome étend 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 prévoyons de commencer à afficher des avertissements dans Chrome 108.
Dans les deux cas, nous procéderons prudemment à un déploiement par étapes similaire, afin de laisser aux développeurs Web le temps de s'adapter et d'estimer le risque de compatibilité.
Remerciements
Photo de couverture par Mark Olsen sur Unsplash.