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, ce qui demande une autorisation explicite auprès du serveur cible. Cette requête préliminaire comportera un nouvel en-tête, Access-Control-Request-Private-Network: true, et la réponse à celui-ci 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 donner aux sites Web le temps de détecter la modification et de s'adapter en conséquence.
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.
Au plus tôt dans Chrome 113:
- 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 situés 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), de sorte que les sites Web doivent désormais demander explicitement une autorisation aux serveurs situés sur des réseaux privés avant de pouvoir envoyer des requêtes arbitraires.
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'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 norme RFC1918, les adresses de liaison locale 169.254.0.0/16 définies dans la norme RFC3927, les adresses unicast IPv6 locales uniques fc00::/7 définies dans la norme RFC4193, les adresses unicast IPv6 de liaison locale fe80::/10 définies dans la section 2.5.6 de la norme 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 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, ce qui peut 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 PNAAccess-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 préliminaires pour 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. Cela diffère des requêtes CORS standards, où les requêtes préliminaires ne concernent que les requêtes multi-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 de pré-vérification sera envoyée avant celle-ci. 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 vérification préalable CORS régulière sans règles d'accès au réseau privé, deux vérifications préalables 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 ayant échoué entraînera l'é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 des outils de développement 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é-vérification PNA. Tout d'abord, mettez en œuvre la compatibilité avec les requêtes CORS préliminaires 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 toute sécurité.
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.
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 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
Ensuite, Chrome étendra les vérifications d'accès au réseau privé afin de couvrir les nœuds de calcul Web : les nœuds de calcul dédiés, les nœuds de calcul partagés et les service workers. 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 visons provisoirement à ce que Chrome 108 commence à afficher des avertissements.
Dans les deux cas, nous procéderons prudemment avec 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.