Google modifications à venir apportées à Chrome visant à améliorer la confidentialité. La première partie des modifications concerne la gestion des cookies et la prise en charge de l'attribut SameSite. A compter de la sortie de Chrome 76, attendue en juillet, il y aura le flag "same-site-by-default-cookies", qui, en l'absence de l'attribut SameSite dans l'en-tête Set-Cookie, fixera par défaut la valeur "SameSite=Lax", limitant l'envoi de Cookies pour les insertions de les sites tiers (mais les sites pourront toujours annuler la restriction en définissant explicitement la valeur SameSite=None lors du paramétrage du Cookie).
Attribut permet de définir les situations dans lesquelles il est permis d'envoyer un Cookie lorsqu'une demande est reçue d'un site tiers. Actuellement, le navigateur envoie un Cookie à toute demande adressée à un site pour lequel un Cookie a été installé, même si un autre site est initialement ouvert, et la demande est effectuée indirectement en chargeant une image ou via une iframe. Les réseaux publicitaires utilisent cette fonctionnalité pour suivre les mouvements des utilisateurs entre les sites, et
attaquants pour l'organisation (lorsqu'une ressource contrôlée par l'attaquant est ouverte, une demande est secrètement envoyée depuis ses pages vers un autre site sur lequel l'utilisateur actuel est authentifié, et le navigateur de l'utilisateur définit des cookies de session pour une telle demande). D'autre part, la possibilité d'envoyer des cookies à des sites tiers est utilisée pour insérer des widgets dans des pages, par exemple pour l'intégration avec YuoTube ou Facebook.
En utilisant l'attribut SameSit, vous pouvez contrôler le comportement des cookies et autoriser l'envoi de cookies uniquement en réponse aux demandes lancées depuis le site à partir duquel le cookie a été initialement reçu. SameSite peut prendre trois valeurs « Strict », « Lax » et « None ». En mode « Strict », les cookies ne sont envoyés pour aucun type de requêtes intersites, y compris tous les liens entrants provenant de sites externes. En mode « Lax », des restrictions plus souples sont appliquées et la transmission des cookies est bloquée uniquement pour les sous-demandes intersites, telles qu'une demande d'image ou le chargement de contenu via une iframe. La différence entre « Strict » et « Lax » se résume au blocage des Cookies lorsque l’on suit un lien.
Entre autres changements à venir, il est également prévu d'appliquer une restriction stricte interdisant le traitement de Cookies tiers pour les requêtes sans HTTPS (avec l'attribut SameSite=None, les Cookies ne peuvent être paramétrés qu'en mode sécurisé). En outre, il est prévu de mener des travaux de protection contre l'utilisation d'identifications cachées («browser Fingerprinting»), y compris des méthodes permettant de générer des identifiants à partir de données indirectes, telles que , liste des types MIME pris en charge, options spécifiques à l'en-tête ( и ), analyse des établis , disponibilité de certaines API Web spécifiques aux cartes vidéo rendu en utilisant WebGL et Canvas, avec CSS, analyse des fonctionnalités de travail avec и .
Également dans Chrome protection contre les abus liés à la difficulté de revenir à la page d'origine après un déplacement vers un autre site. Nous parlons de la pratique consistant à encombrer l'historique de navigation avec une série de redirections automatiques ou à ajouter artificiellement des entrées fictives à l'historique de navigation (via pushState), de sorte que l'utilisateur ne peut pas utiliser le bouton « Retour » pour revenir à l'historique de navigation. page originale après une transition accidentelle ou un renvoi forcé vers le site d'escrocs ou de saboteurs . Pour se protéger contre de telles manipulations, Chrome dans le gestionnaire du bouton Précédent ignorera les enregistrements associés au transfert automatique et à la manipulation de l'historique de navigation, ne laissant que les pages ouvertes en raison d'actions explicites de l'utilisateur.
Source: opennet.ru