Fermer

janvier 31, 2020

Sitefinity, attribut SameSite de Chrome 80, cookies intersites


Nous avons mis à jour Sitefinity pour nous assurer que l'ensemble complet des fonctionnalités intégrées est parfaitement en phase avec les modifications imminentes de la façon dont les navigateurs Web les plus populaires gèrent les cookies interdomaines. Lisez la suite pour savoir ce qui a changé, comment obtenir et appliquer le dernier correctif pour votre version Sitefinity, et tout ce que vous devez faire pour assurer un fonctionnement continu.

Dans cet article, nous examinons quelles sont les nouvelles exigences sur le point d'être introduites dans Chrome 80, et la configuration et les configurations spécifiques à Sitefinity qui rendent ces derniers correctifs indispensables.

En bref, si vous utilisez l'authentification OpenID Connect dans un scénario à plusieurs domaines où l'un d'eux est un fournisseur d'identité (comme dans SSO), vous aurez besoin du correctif quelle que soit la version que vous exécutez .

Chrome 80, changements de cookies SameSite, cookies Sitefinity et mises à jour

Word est sorti il ​​y a quelques mois et vous êtes probablement bien au courant d'une prochaine mise à jour potentiellement perturbatrice qui frappera d'abord Chrome 80, avec d'autres navigateurs certains aussi. . Les modifications apportées à l'attribut SameSite visent à un niveau de sécurité encore plus strict contre la falsification de demandes intersites (CSRF).

Sitefinity est bien équipé en termes de protection des cookies grâce au module WebSecurity introduit en v11 et amélioré avec CSRF protection dans v12.1. Pourtant, la mise à jour à venir a un certain nombre d'implications potentielles pour l'authentification, votre configuration de développement et votre flux de travail, et toutes les intégrations tierces que vous exécutez et qui impliquent des cookies interdomaines. Leur portée varie en fonction de la version de Sitefinity sur laquelle vous vous trouvez.

Pour commencer, des correctifs sont disponibles pour les versions remontant à 10.2 . Bien que nous encouragions tout le monde à examiner attentivement le tableau à la fin de ce blog et à mettre à niveau, cela dépend de votre configuration spécifique, que le correctif soit essentiel aux opérations ou soit juste un choix judicieux pour maintenir votre système stable et à l'épreuve du temps. Dans tous les cas, nous vous recommandons fortement d'appliquer les correctifs.

En parlant de configurations spécifiques, certaines versions de Sitefinity sont … bien … plus égales que d'autres. Donc, si vous utilisez la version 12.1 ou supérieure et que vous avez activé le module WebSecurity, vous êtes en assez bonne forme, sauf si vous utilisez un fournisseur d'authentification externe OpenID Connect .

Pour les versions antérieures à 12.1, vous devez au minimum revoir, déconseiller et remplacer tous les cookies que vous pouvez utiliser entre sites pour l'intégration avec des services externes.

Avant d'entrer dans les détails, regardons revenir à ce qu'est l'agitation.

Pour mettre brièvement tout en contexte, un nouveau modèle sécurisé par défaut pour les cookies a été annoncé l'année dernière et est sur le point de commencer à être appliqué, mais avec quelques exemptions atténuantes sur une période de grâce non spécifiée, en février. Il s'agit de la période souscrite et communiquée par Google et Chrome mais d'autres fabricants de navigateurs ont également indiqué qu'ils adopteraient le nouveau modèle.

Au cours des deux derniers mois, vous avez peut-être régulièrement remarqué avertissements de la console concernant les cookies manquant l'attribut SameSite. Plusieurs versions de Chrome, remontant à la v76, fournissent un moyen de tester vos cookies par rapport aux nouvelles exigences. Plus de détails sur la façon de tester sont disponibles à la fin de ce blog.

 SameSite-cookies-console-log "title =" SameSite-cookies-console-log "/></p data-recalc-dims=

Les modifications visent à renforcer la protection des cookies contre les accès non autorisés et / ou malveillants et s'articule autour de l'attribut SameSite, qui spécifie l'utilisation prévue d'un cookie dans un contexte strictement du même site ou sur plusieurs domaines. Cela dit, notre préoccupation immédiate concerne les cookies impliqués dans l'authentification et c'est ce que nous allons approfondir dans le chapitre suivant.

Une dernière note avant d'y arriver. Microsoft a publié une mise à jour pertinente pour le .Net Framework en décembre pour tenir compte des modifications apportées à SameSite gestion des cookies dans Chrome. Et maintenant, nous avons également fait notre part en mettant en œuvre les modifications requises pour mettre Sitefinity en conformité avec la nouvelle norme et ses exigences.

Si vous hébergez Sitefinity dans le cloud, vous serez heureux de connaître le .NET Framework Sam Des correctifs eSite sont ajoutés à Azure App Service .

Authentification et cookies inter-domaines, fournisseur OpenID Connect

Le modèle d'authentification Sitefinity est basé sur OAuth2 et le protocole OpenID Connect. En plus des options par défaut, vous pouvez activer l'authentification via des fournisseurs d'identité externes qui prennent également en charge le protocole OpenID Connect. Pour une autre couche d'extensibilité supplémentaire, il existe un support, dès la sortie de la boîte, pour la configuration d'un certain nombre de fournisseurs externes tels que les comptes de réseaux sociaux, Google, Microsoft et ADFS, entre autres, pour l'authentification Sitefinity.

Ces derniers sont des services tiers indépendants et donc totalement hors du champ de cette mise à jour. Il incombe à la plate-forme respective et ces fournisseurs d'identité sont présumés déjà (ou imminents) compatibles avec les exigences du modèle de cookie sécurisé par défaut.

Quoi qu'il en soit, les correctifs que nous venons de publier sont recommandés si vous utilisez l'authentification OpenID Connect dans une configuration multi-domaines, où l'un des multiples domaines est utilisé comme fournisseur d'identité à connexion unique pour tous les autres.

Pour vous assurer que la fonctionnalité prête à l'emploi est entièrement intacte, les correctifs fournis modifient les cookies OpenIdConnect.nonce pour également transporter les attributs SameSite = None et Secure requis lorsqu'ils sont destinés à des applications croisées. utilisation du site, par exemple dans la configuration multisite décrite ci-dessus.

Maintenant, après avoir pris en compte les implications que ce changement peut potentiellement avoir sur votre flux de travail, nous avons ajouté une couche de configuration supplémentaire pour vous permettre d'exempter le cookie OpenIDConnect.nonce du comportement par défaut dans scénarios spécifiques à votre opération Sitefinity.

Supposons que votre environnement de développement ne soit pas sécurisé par SSL ou que vous développiez localement (ce qui est probablement le scénario le plus courant). L'option de sécurité la plus élevée, qui indique que toutes les demandes nécessitent le cookie OpenIdConnect.nonce pour l'authentification n'est pas applicable en l'absence de SSL.

Vous pouvez donc spécifier que les demandes distantes nécessitent le cookie d'authentification OpenIdConnect.nonce, mais les demandes vers et depuis localhost pas. Vous pouvez même le désactiver complètement si vous avez un cas d'utilisation valide qui ne pose pas de risque de sécurité significatif. Vous pouvez en savoir plus dans un article dûment mis à jour de notre documentation.

Nous pensons que ces paramètres supplémentaires sont la bonne chose à faire pour vous permettre de continuer à développer localement ou sous HTTP. Mais comme il s'agit essentiellement d'exceptions ayant certaines implications en termes de sécurité, il était logique de donner aux administrateurs de Sitefinity un outil pour toujours les surveiller. Le widget System Status a été mis à jour en conséquence pour toujours afficher les avertissements du fournisseur d'authentification non sécurisé.

 system-status-widget "title =" system-status-widget "/></p data-recalc-dims=

Protection des cookies et module Sitefinity WebSecurity

Dans votre Projet Sitefinity, vous utilisez peut-être des cookies intersites avec divers services externes et intégrations tierces. Il va sans dire que ces cookies doivent également être conformes aux nouvelles exigences.

Si vous utilisez Sitefinity version 12.1 et supérieure et avez activé le module de sécurité Web et activé la protection des cookies vous avez les moyens de configurer facilement les politiques minimales de sécurité des cookies à l'échelle du projet, ainsi que de définir des exceptions selon les besoins. Vous souhaiterez généralement exclure les cookies des politiques de sécurité lorsqu'ils sont destinés à une utilisation intersite pour prendre en charge les fonctionnalités partagées sur plusieurs domaines.

La grande chose à propos de l'utilisation d'un Sitef récent La version inity (12.1 et 12.2) est que la protection des cookies prête à l'emploi est entièrement compatible avec les modifications à venir de SameSite. La protection des cookies a été développée et affinée sur plusieurs versions consécutives et a été minutieusement testée par rapport aux nouvelles exigences.

Donc, si votre configuration implique des cookies intersites et qu'ils fonctionnent jusqu'à présent sans problème avec les paramètres par défaut du module Web Security, vous pouvez être sûr qu'ils continueront à le faire après que les modifications de SameSite auront commencé à être appliquées.

La chose importante à noter ici est que le module de sécurité Web définit la valeur SameSite sur LAX par défaut . Si vous avez configuré le module différemment, assurez-vous d'examiner attentivement et de mettre à jour la protection des cookies à l'échelle du projet et toutes les exceptions personnalisées, afin qu'elles répondent aux nouvelles exigences.

Maintenant, cela va de soi pour les versions 10.2 à 12.0. Si c'est ce que vous exécutez, vous devez examiner attentivement et mettre à jour tous les cookies utilisés entre les sites pour vous assurer qu'ils sont conformes au modèle sécurisé par défaut: SameSite = Lax est la nouvelle valeur par défaut si aucun attribut SameSite n'est spécifié. La valeur SameSite = None nécessite un nouvel attribut "Secure".

 Cookies "title =" Cookies "/></p data-recalc-dims=

Wrap-up

Vous avez peut-être déjà remarqué les correctifs dans votre compte sous les téléchargements. Avant de vous laisser sur ce point, juste un petit mot sur la façon de tester le comportement actuel des cookies avant d'appliquer un correctif. Votre version de Chrome, en supposant qu'elle est assez récente, vous permet de tester les cookies par rapport aux nouvelles exigences. Les cookies du même site par défaut et les cookies # cookies sans le même site doivent être sécurisés dans les paramètres du navigateur reproduiront le comportement attendu dans Chrome 80.

Je dois noter que Chrome a a confirmé une période de grâce en quelque sorte, pendant laquelle la nouvelle norme ne sera pas strictement appliquée pour les cookies de moins de 2 minutes. Pour être précis, les cookies définis il y a moins de 2 minutes sans attribut SameSite seront toujours autorisés en haut- demandes de publication intersites de niveau. La période de grâce non spécifiée est une mesure d'atténuation

Voici un rappel sur la façon de télécharger des correctifs et la procédure de mise à niveau en général, si vous avez besoin de remettre sur la bonne voie. Cookies SameSite si vous voulez d'abord que la théorie soit écartée.

Lorsque vous êtes prêt à continuer, soyez assuré que le support Sitefinity est prêt à répondre si vous rencontrez des problèmes de correction votre version spécifique de Sitefinity. Cliquez sur l'image ci-dessous pour agrandir le tableau.

 sitefinity-patch-samesite-cookies-thumb "title =" sitefinity-patch-samesite-cookies-thumb "/> </a data-recalc-dims=

Versions Sitefinity antérieures à 10.2 don ' t prend en charge l'authentification Open ID Connect prête à l'emploi. Si vous exécutez une version Sitefinity antérieure à 10.2 et avez une implémentation personnalisée d'un fournisseur d'authentification OpenID Connect, nous vous recommandons de tester votre flux de connexion de manière approfondie par rapport aux nouvelles exigences et mettre à jour tous les cookies impliqués qui pourraient être affectés. Il en va de même pour les projets utilisant des cookies intersites pour des intégrations tierces ou des services externes. Nous ne publions pas de correctifs pour ces anciennes versions.

Nous vous recommandons fortement de envisagez la mise à niveau, car les versions plus récentes de Sitefinity offrent de multiples avantages en termes de performances et un niveau de sécurité plus élevé.




Source link