Chrome déconseille l’accès direct aux points de terminaison du réseau privé à partir de sites Web publics afin de protéger les utilisateurs contre les attaques de falsification de requêtes intersites (CSRF).

Deuxième partie de l’implémentation du navigateur du Accès au réseau privé (PNA), le mouvement est spécifiquement conçu pour bloquer les attaques CSRF qui ciblent les routeurs et autres appareils sur les réseaux privés.

« Ces attaques ont touché des centaines de milliers d’utilisateurs, permettant aux attaquants de les rediriger vers des serveurs malveillants », ont expliqué Titouan Rigoudy, ingénieur logiciel de Chrome, et Eiji Kitamura, défenseur des développeurs de Google. article de blog.

Contrôle avant le vol

Un déploiement en deux étapes du changement commencera avec Chrome 98 – qui devrait arriver début février – envoyant des demandes de contrôle en amont du partage de ressources d’origine croisée (CORS) avant les demandes de sous-ressources de réseau privé.

Indépendamment de la méthode et du mode de la requête de réseau privé, les requêtes en amont demanderont l’autorisation aux sites Web cibles d’envoyer des requêtes HTTP avec l’en-tête Access-Control-Request-Private-Network : vrai. Si l’autorisation est accordée, la réponse portera l’en-tête Access-Control-Allow-Private-Network : vrai.

« Cela garantit que le serveur cible comprend le protocole CORS et réduit considérablement le risque d’attaques CSRF », ont déclaré Rigoudy et Kitamura.

Déploiement progressif

Les échecs de contrôle en amont déclencheront des avertissements dans DevTools sans affecter autrement les demandes de réseau privé.

Cependant, à partir de Chrome 101 au plus tôt – en fonction des résultats des données de compatibilité de la première phase et du premier contact avec les plus grands sites Web concernés – les demandes de contrôle en amont rejetées seront bloquées.

Les administrateurs Web peuvent tester si leurs sites Web fonctionneront après cette deuxième phase avec un argument de ligne de commande – Access-Control-Allow-Private-Network : vrai – qui génère des échecs de récupération pour les demandes de contrôle en amont infructueuses.

Bien que l’équipe Chrome ne s’attende pas à ce que la première phase casse les sites Web, elle exhorte néanmoins les webmasters à mettre à jour les chemins de requête concernés en traitant les requêtes en amont côté serveur ou en désactivant les vérifications PNA avec les politiques d’entreprise.

Un essai de dépréciation d’une durée d’au moins six mois commencera au début de la phase deux pour permettre aux sites Web concernés de demander une prolongation de délai.

Calendrier de mise en œuvre du PNA

Anciennement connue sous le nom de CORS-RFC1918, la PNA limite la capacité des sites Web à envoyer des requêtes à des serveurs sur des réseaux plus privés que le réseau à partir duquel la requête est initiée.

Chrome a déjà mis en œuvre partie de la spécification dans Chrome 96, depuis quand seuls les contextes sécurisés ont été autorisés à faire des requêtes de réseau privé.

La spécification étend également le protocole CORS (Cross-Origin Resource Sharing) pour exiger que les sites Web demandent explicitement une autorisation aux serveurs sur les réseaux privés avant d’être autorisés à envoyer des demandes arbitraires.

L’équipe Chrome « vise provisoirement » à introduire des déploiements progressifs pour étendre davantage les vérifications PNA afin de couvrir les travailleurs Web dédiés, partagés et de service de Chrome 100, et de couvrir les navigations, y compris les iframes et les fenêtres contextuelles, de Chrome 102.

LIRE LA SUITE Firefox corrige un bogue de contournement des notifications en plein écran qui aurait pu mener à des campagnes de phishing convaincantes