Apple a modifié son moteur de navigateur open-source WebKit dont Safari se sert pour prévenir les abus HSTS après avoir découvert des attaques contre les utilisateurs Safari.
La fonction première de l’HSTS (HTTP Strict Transport Security) était de permettre aux sites Web de rediriger automatiquement le trafic Web de l’utilisateur vers des pages sécurisées via HTTPS si l’utilisateur ouvre accidentellement une URL non sécurisée.
Hors, la norme de sécurité peut être utilisée via des « supercookie » pour suivre les utilisateurs quand ils surfent sans qu’ils le sachent. Et ce avec presque tous les navigateurs et malgré la navigation privée.
Le HSTS ne permet pas aux sites Web de stocker de l’information utilisateur sur le navigateur Web, à l’exception des informations de redirection sur l’activation ou non du protocole par l’utilisateur pour une réutilisation future. En se servant de cette information, un supercookie lisible par les serveurs de suivi interweb peut être créé et marquer les utilisateurs à travers leur séance de surf.
Voici comment fonctionne le HSTS :
Pour comprendre comment fonctionne le suivi des supercookies HSTS, voici un exemple simple :
- Pour suivre chaque utilisateur, les sites attribuent un numéro unique à chaque visiteur, par exemple 90909090 dont la conversion binaire en 32 caractères est 0000000000000000001101111101111111111100100100010.
- Pour définir ce nombre binaire pour un utilisateur spécifique, le site définit la politique HSTS pour ses 32 sous-domaines en conséquence (tr01.exemple.com, tr02.exemple.com…….et tr32.exemple.com) , où si HSTS pour un sous-domaine est activé alors la valeur est 1 et si ce n’est pas le cas, la valeur est 0.
- Maintenant, chaque fois que l’utilisateur visite le même site Web, il charge 32 « pixels invisibles » en arrière-plan pour chacun de ces sous-domaines qui représentent les bits du nombre binaire, signalant au serveur quels sous-domaines sont ouverts via HTTPS (1) et lesquels via HTTP (zéro).
Voila ! La combinaison des valeurs ci-dessus révèle la valeur binaire unique de l’utilisateur au serveur, aidant les sites Web/annonceurs à marquer les utilisateurs à travers les sites.
Apple a donc ajouté deux limiteurs à son moteur WebKit de Safari qui traite de deux côtés l’attaque : l’endroit où les identificateurs de suivi sont créés et l’utilisation subséquente de pixels invisibles pour suivre les utilisateurs.
Premier limiteur :
Il s’attaque au problème des super cookies et à la pratique consistant à configurer HSTS sur un large éventail de sous-domaines à la fois.
Safari limitera désormais l’HSTS soit au nom d’hôte chargé, soit au domaine de premier niveau plus un (TLD+1), et « WebKit plafonne également le nombre de redirections qui peuvent être enchaînées ensemble, ce qui place une limite supérieure sur le nombre de bits qui peuvent être définis, même si la latence a été jugée acceptable ».
« Cela empêche les trackers de régler efficacement le HSTS sur un grand nombre de bits différents ; au lieu de cela, ils doivent visiter individuellement chaque domaine représentant un bit actif dans l’identifiant de suivi « , explique Brent Fulgham, un développeur qui travaille sur le moteur Safari WebKit.
Alors que les annonceurs peuvent juger que la latence introduite par une seule redirection par une seule origine pour définir de nombreux bits est imperceptible pour un utilisateur, exiger des redirections vers 32 domaines ou plus pour définir les bits de l’identificateur serait perceptible pour l’utilisateur et donc inacceptable pour eux et les fournisseurs de contenu.
Second limiteur :
WebKit empêche les pixels invisibles de forcer une redirection HSTS, ce qui fait que les supercookies HSTS deviennent une chaîne de zéros seulement.
Cependant, Apple ne nomme aucune personne, organisation ou société de publicité qui utiliserait le supercookie tracking HSTS pour cibler les utilisateurs de Safari.
