Le clickjacking, ou « détournement de clic », est un terme apparu en 2008 pour désigner un type d’attaque ciblant les applications web. Ces attaques visent à tromper l’utilisateur sur l’élément sur lequel il clique, permettant in fine de lui faire réaliser des actions à son insu.
Comment se fait-on clickjacker ?
Pour mener une attaque par clickjacking, un attaquant va procéder de la manière suivante :
1- Il identifie sa cible, une page non-protégée contre ce type d’attaque, qui permet de réaliser une action en cliquant sur un lien ou un bouton.
2- Il intègre cette page dans une page malveillante qu’il maîtrise
3- Il s’arrange pour que, lorsque la victime clique sur un élément de la page, elle clique en réalité sur un bouton ou un lien provenant du site vulnérable
Par exemple, il peut utiliser les propriétés de style offerte par HTML/CSS pour rendre transparente la page vulnérable. Dans l’exemple ci-dessus, l’utilisateur verra le bouton « Jouer ! » mais cliquera en réalité sur le « Bouton 1 », provenant d’un site différent !
Les exemples les plus fréquents d’attaque par clickjacking sont les “likejacking” et “tweetbomb”. La première, ciblant le réseau social, a pour objectif de faire « liker » une page, c’est-à-dire d’augmenter sa popularité. La seconde vise à diffuser sur Twitter un message, la plupart du temps publicitaire.
Les risques se limitent-ils aux réseaux sociaux ?
Mais non ! Il est important de noter que les enjeux liés à ce type d’attaques ne s’arrêtent pas à la pollution de réseaux sociaux. De même que les attaques par rejeu de requête (XSRF), les attaques par clickjacking permettent d’exécuter des actions à l’insu de la victime.
Il est donc tout à fait imaginable d’employer ce type d’attaque afin, par exemple, d’ajouter des articles dans le panier des clients d’un site de e-commerce. Pour cela, il suffirait à l’attaquant de reprendre le scénario précédent, mais de remplacer les boutons « like » de Facebook par le bouton « Ajouter au panier » du site e-commerce. L’attaquant pourrait augmenter grandement les ventes de son produit !
Comment se protéger efficacement ?
La protection contre ce type d’attaques est à considérer du double point de vue de l’utilisateur et du responsable du site internet qui sert – involontairement – de support à l’attaque. La protection idéale nécessite donc sensibilisation et moyens techniques.
Pour les utilisateurs finaux en effet, se protéger implique d’avoir conscience du risque et de faire preuve de vigilance en surveillant ses fréquentations sur le web ! Il convient de rester méfiant à l’égard des liens commerciaux et des jeux ou concours qui promettent monts et merveilles.
Pour les équipes en charge de la sécurité des applications web, deux éléments sont à considérer pour mitiger le risque lié au clickjacking : l’utilisation d’en-têtes http spécifiques, et l’emploi de protections en JavaScript.
Utiliser les en-têtes http appropriés pour se protéger
Il est d’une part possible d’utiliser l’en-tête http « X-FRAME-OPTIONS », qui va indiquer au navigateur à quelles conditions le contenu du site peut être intégré dans une iframe. Il est possible de lui spécifier trois valeurs :
- « DENY », qui va interdire l’inclusion de la page ;
- « SAMEORIGIN », qui va autoriser uniquement les sites du même domaine à inclure la page ;
- « ALLOW-FROM », qui permet de spécifier le ou les domaines autorisés à inclure la page.
Utiliser JavaScript pour s’assurer que ses pages ne sont pas dissimulées
En complément, il est possible d’utiliser du code JavaScript pour se protéger. Pour cela, ces codes vont par exemple s’assurer que la page est bien au niveau supérieur et qu’elle sera visible. Il faut néanmoins reconnaître qu’aucun de ces codes n’est totalement fiable.
Pour des informations détaillées sur les implémentations de ces protections, le site de l’OWASP propose une page dédiée à ce sujet.
La réauthentification, meilleure arme de protection pour les actions sensibles
La solution la plus efficace reste de ré-authentifier l’utilisateur pour les actions sensibles, par exemple en lui redemandant son mot de passe ou en utilisant un second facteur d’authentification, comme cela est l’usage sur les sites de banque en ligne.
Ces protections sont-elles couramment déployées ?
En un mot : non. Malheureusement, ce type d’attaque n’est toujours pas, 4 ans après leur découverte, pris au sérieux par la plupart des développeurs / testeurs / équipes de sécurité, sans doute car elles n’ont pour l’instant pas été exploitées à grande échelle en dehors des réseaux sociaux.
Selon un article publié récemment sur le blog de Qualys, les protections standards décrites ci-dessus ne sont ainsi pas encore déployées systématiquement : près de 70% des 20 sites bancaires les plus fréquentés n’implémentent pas de protection efficace contre ce type d’attaque.
Il est fort à parier que l’emploi de ce type d’attaque va augmenter et se diversifier à l’avenir. En effet, les mesures de protection contre les attaques par rejeu de requête (XSRF) se généralisant, notamment par leur intégration dans les frameworks de développement, les attaquants se tourneront mécaniquement vers d’autres vulnérabilités, dont le clickjacking. Anticiper dès à présent reste le moyen le plus sûr d’éviter d’en être la victime.
