Serveur d'impression

Microsoft prévient que les modifications apportées aux cookies SameSite pourraient casser certaines applications – Redmondmag.com – Bien choisir son serveur d impression

Par Titanfall , le 3 mars 2020 - 9 minutes de lecture

Nouvelles

Microsoft prévient que les modifications apportées aux cookies SameSite pourraient interrompre certaines applications

Les professionnels de l'informatique pourraient être confrontés à des problèmes d'application Web dès le mois prochain avec la mise en œuvre d'un prochain changement de site Web SameSite, qui affectera la façon dont les cookies sont utilisés sur les sites.

Plus précisément, certains fabricants de navigateurs, principalement Google et Microsoft, commencent à appliquer un projet de proposition 2019 de l'Internet Engineering Task Force (IETF). Ce document, intitulé «Incrementally Better Cookies», décrit une approche rudimentaire pour mieux sécuriser les données des cookies sur les sites, ce qui implique un changement dans le fonctionnement d'un attribut d'en-tête de site Web appelé «SameSite».

L'idée est de résoudre quelque peu les problèmes de sécurité intersites, dans lesquels les données de cookies associées à un utilisateur peuvent être utilisées dans des attaques, généralement par des soi-disant «tiers».

Mise à jour 2/3: Pour une bonne procédure pas à pas à quoi s'attendre avec les modifications de SameSite, consultez cet article de blog du 3 janvier par Troy Hunt, un expert en sécurité logicielle et Microsoft Most Valuable Professional.

Mise à jour 2/6: La manière dont les modifications de SameSite affectent les sites Web ASP.NET est expliquée dans une série de billets de blog de support IIS, principalement par Paul Cociuba, ingénieur de l'équipe Microsoft ASP.NET. Les articles comprennent un aperçu, une explication par défaut de Lax et parlent de la logique de session.

Modifications apportées à SameSite
L'attribut SameSite peut avoir des valeurs "Strict", "Lax" ou "None". Strict conserve les données des cookies dans le domaine d'un site. Lax autorise le partage de données de cookies intersites mais évite la méthode HTTP POST non sécurisée pour le partage tiers. Aucun n'est une nouvelle valeur introduite par Google. Ces nuances sont quelque peu décrites dans ce document de l'IETF sur les cookies et la gestion des états HTTP.

Selon le document «Incrementally Better Cookies» de l'IETF, l'attribut SameSite prendra par défaut la valeur «Lax» pour les utilisateurs si cette propriété n'a pas été définie sur l'en-tête d'un site Web. Si la valeur "None" est spécifiée pour l'attribut SameSite sur un site, un attribut Secure doit également être spécifié, ce qui oblige les données de cookie à utiliser le protocole HTTPS plus sécurisé – sinon, un cookie partagé tiers obtiendra rejeté.

Les cookies sont des chaînes de texte utilisées par les sites Web («premières parties») pour ajouter un état persistant aux utilisateurs du navigateur, comme se souvenir qu'une personne a consulté une publicité particulière lors d'une précédente visite du site. Cependant, des tiers peuvent utiliser les données des cookies pour des efforts potentiellement malveillants, ce qui est connu sous le nom d'attaque de «contrefaçon de demande intersite».

Selon une définition de la Fondation OWASP, «Cross-Site Request Forgery (CSRF) est une attaque qui force un utilisateur final à exécuter des actions indésirables sur une application Web dans laquelle il est actuellement authentifié». Avec une petite ruse, un attaquant peut "forcer l'utilisateur à effectuer des demandes de changement d'état comme le transfert de fonds, le changement de son adresse e-mail, etc.", a-t-il expliqué.

Cependant, l'utilisation de la valeur Lax avec SameSite n'est pas une protection absolue contre les attaques CSRF. Les attaquants peuvent toujours faire apparaître de nouvelles fenêtres ou exploiter la pré-rendu du navigateur, l'IETF expliqué dans la section 5.3.7.1 de ses cookies et document de gestion d'état.

Google a décrit le nouveau changement de SameSite comme une «atténuation Lax + POST» et a indiqué dans un document de FAQ de SameSite que «ceci est une solution purement temporaire et sera supprimée à l'avenir».

Mise à jour 1/29: Un développeur de Chromium a précisé que c'est juste la méthode POST qui est temporaire et que les changements de SameSite sont «là pour rester». Voici comment cela a été expliqué:

Ce qui est temporaire est la partie "+ POST" du paramètre "Lax + POST", qui prévoit une exception spéciale pour certains cookies et certains types de demandes POST. Il est décrit plus en détail ici. Nous n'avons pas de calendrier concret pour déprécier "Lax + POST", mais nous avons déclaré depuis le début que ce n'est qu'une solution temporaire pour atténuer le blocage des cookies sur les requêtes POST critiques pour les flux de connexion.

Depuis octobre, "une quantité très modeste de casse" a été signalée avec les modifications de SameSite, basées sur des essais sur le terrain du navigateur, par ce post du 21 janvier sur le forum Chromium.

Le document «Incrementally Better Cookies» de l'IETF ne perçoit pas un remplacement de cookie à l'horizon immédiat, c'est pourquoi il a proposé une mesure incrémentielle avec les modifications de SameSite. Les cookies sont considérés par l'IETF comme un "mécanisme primitif" pour atteindre l'état pendant les sessions. Ils sont "visibles par tous sur le réseau" et présentent l'inconvénient supplémentaire d'être utilisés pour une "surveillance omniprésente".

Malgré ces limites et les limites du nouveau comportement de SameSite, les professionnels de l'informatique pourraient être confrontés à des problèmes lors du déploiement de ces nouvelles modifications de SameSite.

Plans de déploiement de SameSite
L'implémentation de SameSite de Google pour son navigateur Chrome sera bientôt disponible. Il prévoit de lancer Chrome version 80 dès le mois prochain (février) avec l'application des nouveaux paramètres, mais ils ne seront en vigueur qu'avec la version de navigateur "stable", selon le document "SameSite Updates" du projet Chromium. La modification de SameSite ne sera pas apportée aux navigateurs Chrome sur iOS, a expliqué Google dans son document FAQ SameSite.

Voici comment Google a expliqué le changement à venir dans un article de blog Chromium du 23 octobre:

Avec Chrome 80 en février, Chrome traitera les cookies qui n'ont pas de valeur SameSite déclarée comme des cookies SameSite = Lax. Seuls les cookies avec SameSite = None; Les paramètres sécurisés seront disponibles pour l'accès externe, à condition qu'ils soient accessibles à partir de connexions sécurisées.

Microsoft a suivi un cours similaire avec ses navigateurs Microsoft Edge et Internet Explorer. La prise en charge du changement SameSite est en place avec ces navigateurs depuis les versions de Windows Update de juin 2018, a expliqué la société dans un article de blog. Le changement de SameSite dans Edge sera livré "en même temps ou plus tard que Google", a indiqué Microsoft dans ce document.

Le blog de Google Chromium du 23 octobre a suggéré que Microsoft avait commencé à implémenter les modifications avec le navigateur "Microsoft Edge 80". Il a ajouté que "Mozilla a affirmé son soutien au nouveau modèle de classification des cookies" dans une future version du navigateur Firefox.

Applications OpenID cassées
Microsoft a très tôt averti que les modifications apportées à SameSite pouvaient endommager les sites et les applications qui dépendent de la fédération basée sur OpenID.

«Nous adorons l'intention et l'esprit de ce changement, mais nous avons déterminé assez rapidement que cela brise un grand nombre de nos sites en utilisant l'authentification Azure Active Directory (AAD) et Microsoft Account (MSA) en utilisant le contrat tel que défini ici», a écrit Erik Anderson dans un article du Chromium Forum du 23 juillet sur l'utilisation des cookies avec SameSite. "Nous soupçonnons que d'autres fournisseurs d'authentification fédérés basés sur OpenID pourraient voir des scénarios similaires être interrompus", a-t-il ajouté.

Google a averti les professionnels de l'informatique dans son article de blog Chromium du 23 octobre qu'il pourrait y avoir des problèmes avec les applications internes et les implémentations d'authentification unique:

Les administrateurs informatiques d'entreprise peuvent avoir besoin de mettre en œuvre politiques spéciales pour rétablir temporairement le navigateur Chrome au comportement hérité si certains services tels que l'authentification unique ou les applications internes ne sont pas prêts pour le lancement en février.

Avertissements IT Pro
Microsoft a émis un avertissement spécifique concernant les modifications à venir de SameSite. Des effets peuvent être ressentis lors de l'utilisation des applications clientes Microsoft Teams. Il existe des considérations pour les sites qui utilisent ASP.NET. Exchange Server, SharePoint Server et le client Skype Entreprise devront tous avoir les dernières mises à jour installées.

En ce qui concerne le client Teams, Microsoft a averti dans ce document sur les cookies Microsoft Teams et SameSite que "les applications exécutées dans le client de bureau Teams sont incompatibles avec l'attribut SameSite = None, et elles ne fonctionneront pas comme prévu." Le document proposait quelques options de «contournement». Il a également expliqué que l'attribut Secure doit être utilisé lorsque la valeur de l'attribut SameSite est définie sur None pour garantir que les cookies tiers ne seront pas rejetés.

Pour les sites utilisant ASP.NET ou ASP.NET Core, Microsoft a averti dans un article de blog ASP.NET du 18 octobre que les nouvelles modifications de SameSite seront en vigueur avec ".NET 4.7.2 et .NET Core 2.1 et supérieur" et ils pourraient briser les connexions OpenIDConnect. Les mises à jour de .NET publiées en décembre et novembre ont ajouté la prise en charge du nouveau comportement SameSite.

Le post ASP.NET a également proposé une estimation du moment où les modifications du navigateur Chrome seront activées.

"Chrome 80 devrait activer le nouveau comportement en février ou mars 2020, y compris une atténuation temporaire ajoutée dans Chrome 79 Beta", a indiqué le blog ASP.NET.

Essentiellement, «chaque composant ASP.NET qui émet des cookies doit décider si SameSite est approprié», a conseillé Microsoft dans son document, intitulé «Travailler avec les cookies SameSite dans ASP.NET». Une attention particulière est offerte aux sites utilisant des iframes.

Click to rate this post!
[Total: 0 Average: 0]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.