Un bug risque de faire fuiter l’historique de votre navigation sur iOS et macOS

Chrome ou Firefox sont loin d’être les seuls navigateurs à rencontrer des bugs ou des vulnérabilités. Safari aussi fait face ponctuellement à des failles ou des dysfonctionnements. La preuve : un ingénieur informatique spécialisé en sécurité a publié le 15 janvier sur le site FingerprintJS des éléments montrant de quelle façon le navigateur web d’Apple peut laisser fuiter des informations.

Une base de données pas si cloisonnée

Le problème ici touche une API appelée IndexedDB. Une API est une interface de programmation permettant à un logiciel d’obtenir des données issues d’une autre application, et dont il a besoin pour diverses tâches, dans les limites de ce que l’API autorise. IndexedDB n’est pas spécifique à Safari. On retrouve cette API aussi dans Chrome et Firefox par exemple.

En l’espèce, IndexedDB agit comme une base de données locale. Embarquée dans le navigateur, elle stocke, du côté de l’internaute, de grosses quantités de données structurées, lit-on dans la documentation technique de la fondation Mozilla, qui édite Firefox. IndexedDB est intéressante pour le stockage d’un grand nombre de données structurées.

En principe, la règle avec l’API IndexedDB est qu’elle respecte la politique dite de la « same-origin policy », que l’on pourrait traduire par politique de même origine. Il s’agit de restreindre « la manière dont un document ou un script chargé depuis une origine (comme un site web, NDLR) peut interagir avec une autre ressource chargée depuis une autre origine (un autre site web, NDLR) », détaille Mozilla.

Dans les grandes lignes, il s’agit d’éviter que les sites interagissent entre eux via IndexedDB, ou qu’ils lisent des informations stockées dans la base de données, quand celles-ci viennent d’un autre domaine. En clair, YouTube n’est censé accéder qu’à YouTube, Facebook à Facebook et Google à Google. Deux pages ont la même origine si le protocole, le port et l’hôte sont identiques.

Le problème mis en exergue par le site FingerprintJS porte sur la façon dont l’API IndexedDB a été implémenté dans Safari, via WebKit, le moteur de rendu HTML dont se sert Apple pour afficher des pages. Dans une vidéo de démonstration, il est dit que la base de données est dupliquée dans chaque onglet et chaque fenêtre lors de la même session de navigation sur Safari.

Or, FingerprintJS fait le constat qu’il est possible pour un site tiers de détecter si un site a été visité récemment, durant la session de navigation. Problème additionnel : si un interne s’identifie sur certains sites, par exemple YouTube, la fuite s’étend alors à l’identifiant unique qu’attribue Google à chaque internaute, car Google ajoute cette suite de caractères au nom de la base de données.

Une faiblesse capable d’identifier quelqu’un dans certaines circonstances

À partir de ce code, poursuit FingerprintJS, il est alors possible de tirer un fil pour aller chercher l’avatar de l’internaute via l’API People et ensuite s’en servir pour faire une recherche inversée afin de retrouver à qui appartient la photo. En clair, il devient possible de retrouver l’identité d’une personne, si cette photo est liée à un individu, quelque part sur le web — par exemple Facebook ou LinkedIn.

Les internautes utilisant la version Safari 15 sur macOS sont touchés , mais aussi les navigateurs dans leur ensemble sur iOS 15 et iPadOS 15. La raison ? Apple a fixé la règle selon laquelle il faut utiliser son moteur de rendu, WebKit, et non pas ceux qui sont conçus par Mozilla (Gecko pour Firefox) ou Google (Blink pour Chrome ainsi que plusieurs autres navigateurs).

Le problème relevé par FingerprintJS apparaît passablement contrariant pour les internautes compte des risques de « dé-anonymisation » que le bug entraîne, mais le risque à grande échelle est incertain : la défaillance requiert plusieurs étapes, mais dépend aussi de la longueur des sessions de navigation, des types de sites visités et de ce qu’il est possible de faire avec les données obtenues.

« Non seulement cela implique que les sites non fiables ou malveillants peuvent connaître l’identité d’un utilisateur, mais cela permet également de relier entre eux plusieurs comptes distincts utilisés par le même utilisateur », juge le site. Un outil de démonstration a été mis en ligne pour illustrer le souci si vous êtes sur Safari 15 sous macOS ou passez par iOS et iPadOS.

La navigation privée abaisse le risque en limitant le problème à tout ce qui se passe dans un même onglet, et pas entre onglets ou fenêtres. « Si vous visitez plusieurs sites web différents dans le même onglet, toutes les bases de données avec lesquelles ces sites web interagissent sont transmises à tous les sites web visités par la suite », prévient le site.

Comment réduire le risque ? Si la navigation privée réduit en partie l’exposition au problème, il peut être judicieux de migrer sur un autre navigateur sur macOS — mais ce genre de bascule est difficile à faire, à cause de la force des habitudes. Sur iOS et iPadOS, ce sera plus difficile, compte tenu des règles d’Apple avec WebKit. Le patch par Apple reste la meilleure piste sur ce dossier.

Le caractère critique du bug ne semble en tout cas pas perçu par Apple, puisque le site fait savoir que l’entreprise américaine ne l’a pas encore traité, alors qu’il a été remonté fin novembre 2021. FingerprintJS espère toutefois que la médiatisation de ses trouvailles va servir à régler le souci : car même si le péril n’est pas immédiat, il n’y a pas de raison de laisser l’implémentation d’IndexedDB dans cet état.