Une faille sur la pseudo-classe :visited

Actualité par (Intégrateur du Dimanche, Strasbourg)
Créé le (17637 lectures)
Tags : css, visited, vulnérabilité, faille

La toute dernière génération de navigateurs (Firefox 3.7, Chrome 5, Safari 4.0.5) vient subitement de considérablement restreindre l’éventail des propriétés CSS applicables à la pseudo-classe :visited, vieille comme le Web et désignant un lien que l’on a déjà suivi.

Les seules propriétés dorénavant tolérées sur cet élément se limitent à la définition des couleurs (color, background-color, border-color, outline-color, column-rule-color, fill, et stroke).

lien visité sur Google

Cette restriction imposée par les navigateurs est due à une vulnérabilité de :visited découverte très récemment et permettant d’exploiter l’historique de navigation d’un visiteur. Le détail de cette faille est expliqué sur le blog du développer principal de Mozilla, David Baron à l’adresse dbaron.org/mozilla/visited-privacy.

En traitant ces données à l’aide des technologies dynamiques actuelles, il devient possible de récupérer un grand nombre d’informations véhiculées via les URL visitées, et de traiter un vaste champ de données personnelles telles que :

  • les visites de liens dits « sensibles » (banques, sites politiques, religieux ou adultes)
  • les recherches effectuées sur les moteurs (ex : http://www.google.fr/search?q=ma+recherche)
  • votre réseau social dans sa globalité (qui sont vos contacts sur Facebook, LinkedIn ou Twitter ? Où habitent-ils ? Quel est leur profil ?)
  • des informations relatives à votre vie privée, votre nom, vos coordonnées, éventuellement votre état de santé, votre orientation politique, etc.

Un site internet d’information anglophone sur ce sujet vous permettra d’en savoir à propos de cette faille et son exploitation en pratique : whattheinternetknowsaboutyou.com.

Si vous n'avez pas la chance de disposer d'une très récente version de navigateur, sachez que vous êtes exposé à ces risques de confidentialité.

What the Internet knows about you

Merci à Anthony Ricaud et Florent Verschelde pour leurs échanges constructifs à propos de cette vulnérabilité.

Sources :
http://dbaron.org/mozilla/visited-privacy
http://www.whattheinternetknowsaboutyou.com

Commentaires

durff33 a dit le

Très intéressant, merci pour l'info :)

Felipe a dit le

Faille récemment découverte > 2002 si on en croit bugzilla #147777 (lien présent sur la page de dbaron). Je suppose que ce sont les performances actuelles des moteurs JS permettant de tester des dizaines de milliers d'URL et l'apparition de Proof of Concepts qui ont précipité les choses ?

On peut d'ores et déjà se protéger avec Fx 3.5 et 3.6 de cet "hameçonnage" en se rendant dans about:config, en cherchant layout.css.visited_links_enabled et en double-cliquant (c'est expliqué sur la page de dbaron)

On ne peut pas directement apprendre "qui sont (n)os contacts sur Facebook" (pour ça Facebook se débrouille très mal tout seul huhu), seulement répondre à la question "est-ce que telle URL précise a été visitée ?" (avec la possibilité d'en tester rapidement des dizaines de milliers, mais pas moyen d'obtenir la liste complète des URL)

Djolhan a dit le

Merci pour l'info raph. Je fait tourner ;)

TonyArchambeau a dit le

Merci pour l'information.

Il me semble qu'il existe une faille similaire avec les images gardées en cache. Si je me souviens bien, si un site lambda affiche le logo de Google et si aucune requête HTTP n'est effectué pour demander cette image, cela signifie que l'image est dans le cache du navigateur et donc que le visiteur à déjà visité le site de Google.
En utilisant cette technique sur des centaines de logos de sites populaires il est possible de connaitre une partie de l'historique d'un internaute.

Ça reste tout de même moins performant que cette faille de la pseudo-classe :visited.

cooc a dit le

La faille est tout de même assez limité, en ce que il faut comparer une à une chaque page pour savoir si oui ou non l'utilisateur l'a visité auparavant. De plus on ne sait pas quand, ni combien de temps...

A tester, mais j'imagine que comparer une à une les adresses des millions de pages de contacts de Facebook pour savoir si oui ou non cette page a été visité... cela reste un petit peu long en JS. C'est carrément irréalisable pour les recherches Google (non récurrentes).

PS: bien entendu le risque est bien présent et c'est parfaitement normal de limiter cette faille.

Riku Asakura a dit le

Le risque est au final le même que celui d'une géolocalisation permanente grâce aux technologies embarquées des smartphones.
Grâce à un historique précis des habitudes d'une personne il y a moyen de dresser un profil plus ou moins précis.

http://www.lemonde.fr/technologies/article/20...

Il s'agit peut être d'une faille, mais son exploitation serait assez longue et laborieuse à mettre en place.
A moins d'avoir déjà développé un Sense Networks 2, ou de savoir ce qu'on recherche. (un développeur qui chercherait si son mari va visiter des sites.... enfin bref)
Enfin je dis ça... je dis rien ;)

Merci pour l'info Raph' !
Je fais tourner aussi ;)

Ladytron a dit le

Autant désactiver l'historique ou le vider systématiquement à chaque fermeture, en ce cas. Pas historique, pas de faille ;)

Victor BRITO a dit le

Et la navigation privée dans tout ça ? Peut-elle servir de parade ? :-/

agui a dit le

Cette histoire avait déjà beaucoup fait parler en 2007 avec SpyJax (http://www.merchantos.com/makebeta/tools/spyjax/) inspiré de ça http://www.kerouac3001.com/cache/

Alcmene a dit le

Comme pas mal d'autres l'ont déjà dit, absolument rien de nouveau sous le soleil (voir par exemple, plus récent (2008) mais avec du code utilisable : http://davidwalsh.name/ajax-evil-spyjax )…

Par contre, je ne vois pas trop en quoi les mises à jour citées changent quoi que ce soit au problème… Les anciennes méthodes se contentaient de vérifier la couleur des ancres, donc tant que la propriété color (ou, à vrai dire, n'importe laquelle…) est modifiable en :visited et lisible en JS, pas de parade !
La seule solution que je voie consiste en refuser la lecture en JS de la couleur des liens visités (ou plutôt, de renvoyer la couleur d'un lien non visité).

jpvincent a dit le

@TonyArchambeau : tu parles d'une technique pouvant utiliser le cache des browsers. Mais depuis JS, je ne vois pas comment savoir si une image inclue vient du disque ou du réseau. Tu te souviens de la technique utilisée ?

@Alcmene : mentir sur la valeur de la propriété des liens :visited, c'est exactement ce que Mozilla voulait faire : http://hacks.mozilla.org/2010/03/privacy-rela...

en tout cas ça n'est pas une mauvaise chose pour contrer d'éventuels abuseurs, mais pour les sites légitimes qui essayaient de faire quelque chose d'intelligent avec l'historique, c'est dommage : je pense à un cas très spécifique où un site voudrait par exemple proposer plusieurs authentifications tierces (autre que uniquement Facebook Connect) ou a un de ces widgets qui permettent de relayer un article vers twitter, delicio.us et la centaine de sites similaires.
La technique était utilisable pour mettre en avant les sites préférés de l'utilisateur.

Pour ces cas précis, il y a maintenant XAuth : http://xauth.org/info/ mais il y a un nombre limité de browsers et de réseau sociaux qui l'utilisent

jpvincent a dit le

@Victor BRITO : oui la navigation privée sert de parade dans ce genre de cas car le browser n'enregistre pas l'historique, et donc ne met pas les liens en :visited

TonyArchambeau a dit le

@jpvincent: Malheureusement je ne me souviens plus la source où j'avais vu cela. Mais la personne qui avait dévoilé la faille avait fais un outil similaire à whattheinternetknowsaboutyou.com.
La technique consistait à un site de charger des images de sites connu. Pour chacune des images, le temps de chargement est calculé. Si le temps de chargement est anormalement extrêmement rapide, cela signifie que l'utilisateur avait déjà l'image en cache et donc que le visiteur avait déjà visité le site en question.

Pour la technique je pense à un code du type:
1) Initialiser un chronomètre
2) Ouvrir l'image 1 (en hotlinking) dans une iframe
3) En AJAX dès que readyState est égal à 4 (= page chargée) > stopper le chronomètre
4) Si la vitesse de chargement est très rapide > image 1 déjà présent dans le cache.
5) Recommencer pour une autre image.

J'espère ne pas avoir dit trop de bêtises.

Tony Monast a dit le

Bonjour,

J'avais déjà entendu parler de cette faille, ça doit faire quelques années déjà. Le gars envoyait un lien à ses copains avec leur nom en paramètre, puis il détectait les sites "coquins" qu'ils avaient visités. Ensuite, pour se foutre de leur gueule, il affichait leur nom et leur historique sur la page d'accueil.

En ciblant des sites avec certaines thématiques, c'est plutôt facile de dresser une liste pour espionner l'historique.

SeRiaL- a dit le

(Lien censuré par un modérateur)

Victor BRITO a dit le

@SeRiaL- : Fournir un lien contenant des annonces publicitaires orientées vers les adultes avertis (par exemple, une pub pour un site de rencontres gay quand il ne s'agit pas d'un site d'escort-girls), ainsi qu'un lien affichant une liste de liens vers des sites a priori porno, c'est très intelligent, surtout quand des mineurs sont susceptibles de fréquenter Alsacréations… :-/

Tony Monast a dit le

En effet Victor, j'ai retiré le lien en question, même si ça complétait très bien mon commentaire. ;)

SeRiaL- a dit le

L'url que j'ai posté est à caractère "humoristique" et non pornographique.
Ce site vous dis si vous avez regarder du porn ou non ;)

Il utilise la même technique, grâce au :visited.

Ciao

Tony Monast a dit le

SeRiaL-, oui, c'est humoristique, mais si tu creuses juste un petit peu, tu verras un nombre impressionnant de liens (pubs et watch some) vers des sites purement pornographiques. D'où l'intérêt de ne pas publier ce type de site "humoristique", même si ça cadrait parfaitement avec le sujet.