régulières
- 7 juillet 2022: mise à jour de l'état actuel et ajout de la définition de l'espace d'adressage IP.
- 27 avril 2022: annonce concernant le nouveau calendrier.
- 7 mars 2022: annonce du rollback après la découverte de problèmes dans Chrome 98.
Introduction
Dans le cadre de la spécification d'accès au réseau privé (PNA), Chrome abandonne l'accès direct aux points de terminaison du réseau privé à partir des sites Web publics.
Chrome commence à envoyer une requête CORS préliminaire avant toute requête de réseau privé pour une sous-ressource, qui demande une autorisation explicite au serveur cible. Cette requête préliminaire comporte un nouvel en-tête, Access-Control-Request-Private-Network: true, et la réponse 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 des routeurs et d'autres appareils sur des réseaux privés. Ces attaques ont touché des centaines de milliers d'utilisateurs, permettant ainsi à des pirates informatiques de les rediriger vers des serveurs malveillants.
Plan de déploiement
Chrome déploiera cette modification en deux phases afin de laisser aux sites Web le temps de prendre en compte le changement et de s'adapter en conséquence.
Dans Chrome 104:
- Chrome effectue des tests en envoyant des requêtes préliminaires avant les requêtes de sous-ressources réseau privées.
- Les échecs des vérifications préliminaires n'affichent que des avertissements dans les outils de développement, sans affecter les requêtes réseau privées.
- Chrome recueille des données sur la compatibilité et contacte les plus grands sites Web concernés.
- Cette fonctionnalité devrait être compatible avec les sites Web existants.
Dans Chrome 113 au plus tôt:
- Cette opération ne commencera que si les données de compatibilité indiquent que la modification est suffisamment sûre et que nous avons contacté directement les services en cas de besoin.
- Chrome exige que les requêtes préliminaires aboutissent, 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 au réseau privé (PNA, Private Network Access) ?
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à mis en œuvre une partie de la spécification: à partir de Chrome 96, seuls les contextes sécurisés sont autorisés à effectuer des requêtes réseau privées. Consultez notre article de blog précédent pour en savoir plus.
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 d'être autorisés à 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 local contient des adresses IP qui sont soit des adresses de bouclage IPv4 (127.0.0.0/8), définies dans la section 3.2.1.3 de la norme RFC1122,
soit des adresses de bouclage IPv6 (::1/128) définies dans la section 2.5.3 du RFC4291.
L'espace d'adresses IP privées 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 RFC3927, les adresses IPv6 unicast locales uniques fc00::/7 définies dans RFC4193, les adresses IPv6 de liaison-localisées {RFC141}, et les adresses IPv6 unicast de type lien-local défini dans fe80::/10.RFC4291
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, laquelle est considérée comme plus privée qu'une adresse IP publique.
Pour en savoir plus, consultez la page Commentaires sur le 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 de partage des ressources entre origines multiples (CORS) qui permet de demander l'autorisation d'un site Web cible avant de lui envoyer une requête HTTP susceptible d'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 acceptant explicitement la requête à 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: trueest défini sur toutes les requêtes préliminaires PNAAccess-Control-Allow-Private-Network: truedoit être défini sur toutes les réponses préliminaires PNA
Les requêtes préliminaires pour PNA sont envoyées pour toutes les requêtes de réseau privé, quels que soient la méthode de requête et le mode. Elles sont envoyées avant les requêtes en mode cors, dans no-cors et dans tous les autres modes. En effet, 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 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 du CORS standard, où les requêtes préliminaires ne concernent que les requêtes multi-origines. Les requêtes préliminaires pour les requêtes de même origine offrent une protection contre les attaques par reliaison DNS.
Exemples
Le comportement observable dépend du mode de la requête.
Mode no-CORS
Supposons que https://foo.example/index.html intègre <img src="https://bar.example/cat.gif" alt="dancing cat"/> et que bar.example soit résolu en 192.168.1.1, une adresse IP privée conforme à 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 comme suit:
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
...
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',
})
Là encore, supposons 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 comme suit:
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
Le serveur peut répondre conformément aux règles CORS habituelles:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example
Comment 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 sera envoyée avant celle-ci. Si cette requête préliminaire échoue, la requête finale sera tout de même envoyée, mais un avertissement s'affichera dans le panneau des problèmes liés aux outils de développement.
Vous pouvez également afficher et diagnostiquer 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 vérifications préliminaires peuvent s'afficher dans le panneau "Réseau", la première ayant toujours échoué. Il s'agit d'un bug connu que vous pouvez ignorer.
Pour examiner ce qui se passe si la réussite préliminaire est appliquée, 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 un échec de la récupération. Cela vous permet de vérifier 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 "Outils de développement" mentionnés ci-dessus.
Que faire si votre site Web est concerné ?
Lorsque ce changement sera déployé dans Chrome 104, il ne devrait pas affecter de site Web. Toutefois, nous vous encourageons vivement à mettre à jour les chemins de requête concernés pour vous assurer que votre site Web continue de fonctionner comme prévu.
Deux solutions sont à votre disposition:
- 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 préliminaires côté serveur
Mettez à jour le serveur cible de toutes les récupérations concernées pour gérer les requêtes PNA préliminaires. Tout d'abord, mettez en œuvre la compatibilité avec les requêtes CORS préliminaires standards sur les routes concernées. Ensuite, ajoutez la prise en charge des deux nouveaux en-têtes de réponse.
Lorsque votre serveur reçoit une requête préliminaire (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 sur 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 (comme 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.
Reportez-vous aux exemples pour 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 d'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.
Donnez-nous votre avis
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.
Signalez-nous votre problème en signalant un problème avec Chromium à l'adresse crbug.com et définissez le composant sur Blink>SecurityFeature>CORS>PrivateNetworkAccess.
Étapes suivantes
Ensuite, Chrome étendra les vérifications de l'accès au réseau privé aux nœuds de calcul Web (dédiés, partagés et service workers). Pour le moment, nous prévoyons que Chrome 107 commence à afficher des avertissements.
Chrome étend ensuite les vérifications de l'accès au réseau privé aux navigations, y compris les iFrames et les pop-ups. Pour le moment, nous prévoyons que Chrome 108 affiche des avertissements.
Dans les deux cas, nous allons procéder avec précaution à un déploiement par étapes similaire, afin de laisser aux développeurs Web le temps d'ajuster et d'estimer le risque de compatibilité.
Remerciements
Photo de couverture par Mark Olsen sur Unsplash.