Vous voulez une bonne nouvelle ?
Tranquillement et sans fanfare Apple a mis en place un changement dans son navigateur Safari, en réduisant en miettes l’un des “super cookies” les plus avancés du web !
Les soi-disant “super cookies” sont des méthodes de suivi qui reposent sur des éléments ésotériques tels que les empreintes digitales du navigateur, les ETags, le stockage local et les Flash LSOs plutôt que sur les cookies eux-mêmes. Ils sont populaires auprès des individus qui veulent vraiment absolument vous suivre, car ils sont beaucoup plus difficiles à bloquer, à purger ou à gérer, que les anciens cookies classiques.
Il y a quelques années, j’ai écrit au sujet d’un super cookie théorique qui pouvait déjouer le mode Incognito en contournant le HSTS, une technologie conçue pour rendre votre navigation plus sécurisée.
Contourner le HSTS permettrait à ces super cookies imaginaires de se cacher à la vue de tous, car les supprimer entraînerait une dégradation de la sécurité. Face à ces cookies HSTS dans la nature, les utilisateurs et les éditeurs de navigateurs seraient forcés de mettre en concurrence la protection de la vie privée et la sécurité.
À l’époque, nous ne savions pas qu’ils étaient réellement utilisés.
Mais aujourd’hui la situation a bien changé, et Apple a répondu.
Comment le HSTS peut être utilisée pour le suivi
Le HSTS est une instruction simple que les sites web peuvent envoyer aux navigateurs et qui dit, en effet, “souvenez-vous de ne pas me parler d’une manière non sécurisée“.
Après avoir reçu une instruction HSTS d’un site web, un navigateur utilisera le HTTPS, la forme chiffrée du protocole HTTP, pour parler au site en question, et ce même si un utilisateur clique sur ou saisi un lien qui utilise le HTTP non sécurisé.
Tout comme un cookie, une instruction HSTS est une information qu’un site web peut demander à un navigateur de mémoriser.
Cependant, pour suivre un navigateur, vous devez être capable de lui attribuer un identifiant unique, et une simple instruction HSTS ne contient pas assez d’informations pour le faire.
Alors qu’un cookie peut contenir des milliers de bits de données, une seule instruction HSTS ne contient qu’un seul bit (car il est tout simplement activé ou désactivé).
Cependant, si une personne peut demander à votre navigateur d’émettre des requêtes HTTP vers une poignée de sites, et ce sous le contrôle de ces derniers (facilement réalisable en intégrant une quantité de petites images au sein d’une page web, par exemple), ils peuvent alors installer suffisamment de commutateurs HSTS on/off au sein de votre navigateur pour stocker un identifiant.
Une série de 30 images serait suffisante pour suivre un peu plus d’un milliard d’identifiants différents.
Voici comment cela fonctionne…
Un visiteur se rend sur une page web avec un code de suivi HSTS malveillant fourni par Evil Marketing Corp Inc.
Le code exige 30 images différentes en provenance de 30 sites web différents sous le contrôle de Evil Marketing Corp. Les images sont toutes récupérées en utilisant le HTTP, certaines répondent avec une instruction HSTS, et d’autres non.
Le schéma spécifique reposant sur 30 réponses on/off constitue l’identifiant unique de ce visiteur.
La prochaine fois que ce même visiteur se rendra sur une page contenant le code de suivi, son navigateur demandera les mêmes images sur les mêmes sites que précédemment. Cette fois-là cependant, le navigateur se souviendra des instructions HSTS et demandera certaines images via HTTPS au lieu de HTTP.
Le schéma de requêtes HTTPS/HTTP, reçu par Evil Marketing Corp à travers ses 30 sites web, correspond au schéma de réponses on/off qu’il a envoyé précédemment, à savoir l’identifiant unique du visiteur.
Pour un exemple détaillé du suivi HSTS, consultez mon article sur la façon dont les “supercookies” HSTS vous oblige à choisir entre la confidentialité ou la sécurité.
Comment Apple a “mangé” le cookie
WebKit est le moteur de navigateur open source qui anime le navigateur Safari d’Apple. En écrivant sur le blog WebKit, Brent Fulgham a laissé entendre que le suivi HSTS avait récemment évolué de la théorie vers la pratique.
Récemment nous avons pris conscience que cette attaque théorique commençait à être déployée et ciblait les utilisateurs de Safari. Nous avons donc développé une solution équilibrée qui protège le trafic web sécurisé tout en atténuant le suivi.
Se retrouvant donc face au dilemme vie privée versus sécurité, Apple a cherché un moyen de tordre le cou des suiveurs, sans compromettre les avantages de la technologie HSTS.
En observant précisément la façon dont la HSTS était contournée en pratique, Apple a trouvé deux tactiques.
Tout d’abord, pour empêcher les codes de suivi d’utiliser un ensemble de sites web pour définir les instructions HSTS, Safari bloque désormais les instructions HSTS de tout autre site que celui sur lequel vous vous trouvez, ou utilisant son domaine racine (ou encore le domaine de premier niveau + 1, comme cela est expliqué sur le blog WebKit).
Donc, si vous visitez tracking.website.example.org alors vous pouvez seulement obtenir des instructions HSTS de tracking.website.example.org (le nom d’hôte sur lequel vous vous trouvez) et example.org (le domaine racine).
Cela reflète le fait que le suivi HSTS utilisait des gammes de sous-domaines connexes, comme ceux-là :
http://a.tracking.website.example.org http://b.tracking.website.example.org http://c.tracking.website.example.org http://d.tracking.website.example.org
Ou comme ceux-là :
http://a.tracking.website.example.org http://b.a.tracking.website.example.org http://c.b.a.tracking.website.example.org http://d.c.b.a.tracking.website.example.org
La deuxième contre-mesure de Safari consiste à ignorer les instructions HSTS provenant de sites web dont “Intelligent Tracking Protection” bloque les cookies.
Après avoir déployé et suivi ces changements, Fulgham a écrit qu’Apple avait réussi à contourner le problème de confidentialité et de sécurité que nous craignions :
La télémétrie recueillie lors des tests de régression interne, nos seeds publics et la version finale du logiciel public indiquent que les deux atténuations décrites ci-dessus ont empêché la création et la lecture de super cookies HSTS, sans dégrader les objectifs de sécurité du contenu de la première partie.
Espérons que ces mesures seront suffisantes pour empêcher le suivi HSTS de progresser dans la nature, en lui rendant son statut de simple curiosité théorique !
Billet inspiré de Apple burns the HSTS super cookie, sur Sophos nakedsecurity.
Qu’en pensez-vous ? Laissez un commentaire.