CNAME Cloaking et Bounce Tracking Defense

Cet article de blog couvre plusieurs améliorations apportées à la prévention intelligente du suivi (ITP) dans Safari 14 sur macOS Big Sur, Catalina et Mojave, iOS 14 et iPadOS 14 pour répondre à nos dernières découvertes dans l’industrie du suivi.

Défense de dissimulation CNAME

ITP limite désormais l’expiration des cookies définis dans les réponses HTTP dites tierces CNAME masquées à 7 jours. Sur macOS, cette amélioration est spécifique à Big Sur.

Qu’est-ce que le camouflage CNAME ?

Aux yeux des navigateurs Web, la première partie d’un site Web est généralement définie par son domaine enregistrable. Cela signifie que www.blog.example et comments.blog.example sont considérés comme le même site et la même partie. Si l’utilisateur charge une page Web à partir de www.blog.example et que cette page fait une demande de sous-ressource à comments.blog.example, cette demande transportera tous les cookies définis pour couvrir le site blog.example, y compris les cookies de connexion et l’identité de l’utilisateur biscuits. De plus, la réponse à cette demande de sous-ressource comments.blog.example peut définir des cookies pour blog.example, et ces cookies seront des cookies propriétaires.

Entrez les CNAME. CNAME signifie enregistrement de nom canonique et mappe un nom de domaine à un autre dans le cadre du système de noms de domaine, ou DNS. Cela signifie qu’un propriétaire de site peut configurer l’un de ses sous-domaines, tel que sub.blog.example, pour résoudre en thirdParty.example, avant de résoudre en une adresse IP. Cela se produit sous la couche Web et est appelé cloaking CNAME – le domaine thirdParty.example est masqué en tant que sub.blog.example et a donc les mêmes pouvoirs que le véritable first party.

Cloaking et suivi CNAME

Les trackers intersites ont convaincu les propriétaires de sites de configurer le cloaking CNAME afin de contourner la prévention du suivi, comme le plafond d’expiration de 7 jours d’ITP pour les cookies définis dans JavaScript. Dans notre cas de blog, cela reviendrait à résoudre track.blog.example en tracker.example.

Un article récent de chercheurs de l’Université de Hautes Etudes Supérieures (Sokendai) et de l’Agence Nationale de la Cybersécurité (ANSSI) a trouvé 1762 sites Web CNAME dissimulant 56 trackers au total.

Cloaking CNAME et sécurité du site Web

Les propriétaires de sites qui configurent le cloaking CNAME risquent la prise de contrôle complète du site Web ou le piratage des cookies des clients si les enregistrements CNAME ne sont pas correctement gérés, par exemple si le cloaking CNAME n’est pas désactivé lorsqu’il n’est plus utilisé. Il a été récemment signalé que 250 sites Web de banques, d’entreprises de soins de santé, de chaînes de restaurants et de groupes de défense des droits civils avaient été compromis par une dissimulation mal gérée de la CNAME. En juin de cette année, Microsoft a documenté ces attaques et comment leurs clients cloud devraient les empêcher.

Défense de l’ITP contre le suivi du camouflage CNAME

ITP détecte désormais les demandes de cloaking CNAME tierces et limite l’expiration de tous les cookies définis dans la réponse HTTP à 7 jours. Cette limite est alignée sur la limite d’expiration d’ITP pour tous les cookies créés via JavaScript.

Le cloaking CNAME tiers est défini comme une sous-ressource propriétaire qui se résout via un CNAME différent du domaine propriétaire et différent du CNAME de l’hôte de la trame supérieure, s’il en existe un. Oui, l’ensemble du site peut être masqué CNAME, lorsqu’il utilise des serveurs dits de périphérie.

La meilleure façon d’expliquer cela est à travers un tableau (1p signifie first-party, 3p signifie tiers):

Hôte 1p, par ex. www.blog.example

Sous-domaine 1p autre que l’hôte 1p, par ex. track.blog.example

Expiration des cookies plafonnée ?

Pas de camouflage

Pas de camouflage

Pas de plafond

Pas de camouflage

other.blog.example (cloaking 1p)

Pas de plafond

Pas de camouflage

tracker.example (cloaking 3p)

Casquette 7 jours

abc123.edge.example (camouflage)

Pas de camouflage

Pas de plafond

abc123.edge.example (camouflage)

abc123.edge.example (cloaking correspondant)

Pas de plafond

abc123.edge.example (camouflage)

other.blog.example (cloaking 1p)

Pas de plafond

abc123.edge.example (camouflage)

tracker.example (cloaking 3p)

Casquette 7 jours

SameSite = prison de cookie stricte pour les traqueurs de rebond

En juin 2018, nous avons annoncé une mise à jour d’ITP pour détecter et se défendre contre les traqueurs de rebond propriétaires. En mars 2020, nous avons annoncé une amélioration pour détecter également le suivi des rebonds retardés. Depuis lors, nous avons reçu un rapport sur un site Web spécifique engagé dans le suivi des rebonds, tout en étant susceptible d’interagir fréquemment avec les utilisateurs. Pour lutter contre ces problèmes, nous avons proposé au W3C Privacy Community Group ce que nous appelons une prison SameSite = Strict ainsi que d’autres escalades.

Ce que fait la prison SameSite = strict est de détecter le suivi des rebonds et, à un certain seuil, de réécrire tous les cookies du domaine de suivi en SameSite = strict. Cela signifie qu’ils ne seront pas envoyés dans des navigations internes intersites et qu’ils ne pourront plus être utilisés pour un simple suivi des rebonds basé sur des redirections.

Notre implémentation est plutôt détendue, avec le seuil fixé à 10 redirections uniques de navigation et de première partie (uniques dans le sens d’aller vers des domaines uniques), et une réinitialisation automatique de ce compteur une fois que les cookies sont réécrits en SameSite = strict. Cela donne automatiquement au domaine une nouvelle chance afin qu’il puisse se désengager du suivi des rebonds et « sortir de prison ».

Notre liste actuelle des domaines soumis à cette protection est vide car le domaine qui nous a été signalé a arrêté leur suivi des rebonds. Mais cette protection reste dans notre boîte à outils.

IndexedDB éphémère partitionné

Jusqu’à présent, WebKit a bloqué IndexedDB d’origine croisée. WebKit autorise désormais IndexedDB tiers partitionné et éphémère dans le but de s’aligner sur d’autres navigateurs maintenant qu’ils sont également intéressés par le partitionnement du stockage. Vous pouvez participer à l’effort de normalisation en cours pour le partitionnement du stockage sur GitHub.

Partitionné signifie une instance IndexedDB unique par site propriétaire et éphémère signifie en mémoire uniquement, c’est-à-dire disparaît à la fermeture du navigateur.

Blocage des cookies tiers et API d’accès au stockage dans la navigation privée

La navigation privée dans Safari est basée sur les sessions éphémères de WebKit où rien n’est conservé sur le disque. Cela signifie qu’ITP ne serait pas en mesure d’apprendre des choses entre les lancements de Safari. De plus, la navigation privée utilise également une session éphémère distincte pour chaque nouvel onglet ouvert par l’utilisateur. Pour maintenir cette séparation entre les onglets, ITP ne serait pas en mesure de classer les trackers intersites à partir de la navigation complète de l’utilisateur, même en mémoire.

Cependant, le blocage complet des cookies tiers n’a pas besoin de classification et est désormais activé par défaut dans la navigation privée. Cela peut sembler simple à prendre en charge, mais le défi consistait à faire fonctionner l’API d’accès au stockage avec la séparation par onglets susmentionnée. Voici comment cela fonctionne: dites identityProvider.example veut demander un accès au stockage en tant que tiers sur la page de connexion de social.example dans l’onglet A. Interagir avec identityProvider.example en tant que site Web propriétaire dans l’onglet B ne suffira pas à l’autoriser pour demander l’accès au stockage dans l’onglet A car cela entraînerait une fuite d’état entre les sessions éphémères séparées. Ainsi, l’utilisateur doit interagir avec identityProvider.example dans le même onglet que celui où identityProvider.example demande ultérieurement l’accès au stockage en tant que tiers. Cela garantit que les flux de connexion où deux parties différentes sont impliquées et que l’accès aux cookies tiers est requis est possible en mode de navigation privée.

Domaine d’application Web de l’écran d’accueil exempt d’ITP

En mars 2020, lorsque nous avons annoncé la limite de 7 jours d’ITP pour tout le stockage inscriptible par script, les développeurs ont posé des questions sur les applications Web de l’écran d’accueil et si elles étaient exemptées de cette limite de 7 jours. Nous avons expliqué comment le compteur ITP des « jours d’utilisation » et la capture de l’interaction des utilisateurs garantissaient efficacement que la première partie des applications Web de l’écran d’accueil ne serait pas soumise au nouveau plafond de 7 jours. Pour rendre cela plus clair, nous avons implémenté une exception explicite pour le domaine propriétaire des applications Web de l’écran d’accueil afin de nous assurer qu’ITP ignore toujours ce domaine dans son algorithme de suppression de données de site Web.

En outre, les données du site Web des applications Web de l’écran d’accueil sont isolées de Safari et ne seront donc pas affectées par la classification d’ITP du comportement de suivi dans Safari.

Merci à mes collègues

Les mises à jour ci-dessus de WebKit et ITP n’auraient pas été possibles sans l’aide de Kate, Jiten, Scott, Tommy, Sihui et David. Merci !

Tags: , ,