Clickjacking (correction de l'interface utilisateur)

Contexte

Le détournement de clic est une méthode malveillante qui repose sur une interface pour inciter un utilisateur à cliquer sur un contenu exploitable dissimulé sur un site Web en cliquant sur un autre contenu présent sur un site Web piégé. Pour illustrer, un internaute pourrait se rendre sur un site Web leurre (par exemple, via un lien reçu par e-mail) et cliquer sur un bouton pour tenter de gagner un prix. Sans le savoir, l'utilisateur a été trompé par un pirate informatique, car en cliquant sur ce bouton, il a en fait déclenché l'exécution d'une action cachée, telle qu'un paiement vers un autre site. Cette attaque nécessite l'intégration d'une ou plusieurs pages Web invisibles et exploitables contenant un bouton ou un lien masqué, qui peut être inséré dans une iframe. Cette iframe est superposée au-dessus du contenu de la page Web leurre que l'utilisateur s'attendait à voir. Contrairement à une attaque CSRF, où la falsification d'une demande entière se fait à l'insu de l'utilisateur, une attaque de détournement de clic nécessite que l'utilisateur effectue une action, telle qu'un clic sur un bouton.

La protection contre les attaques CSRF est souvent assurée par l'utilisation d'un jeton CSRF : un numéro spécifique à la session, à usage unique ou nonce. Cependant, les attaques de détournement de clic ne peuvent être évitées avec un jeton CSRF, car une session cible est établie avec du contenu chargé à partir d'un site Web légitime et toutes les demandes sont exécutées sur le même domaine. Les jetons CSRF sont inclus dans les requêtes et transmis au serveur dans le cadre d'une session normale, mais dans le cas d'une attaque de détournement de clic, le processus se déroule dans une iframe masquée, ce qui différencie cette attaque d'une session utilisateur normale.

Comment construire une attaque basique de détournement de clic

Les attaques de détournement de clic peuvent utiliser des techniques CSS pour créer et manipuler des calques. Dans ce type d'attaque, l'attaquant intègre le site Web cible en tant que couche iframe superposée sur le site Web leurre. Voici un exemple d'utilisation de la balise et des paramètres de style :

 <head>
	<style>
		#website {
			position:relative;
			width:130px;
			height:130px;
			opacity:0.00004;
			z-index:2;
			}
		#decoy_website {
			position:absolute;
			width:400px;
			height:400px;
			z-index:1;
			}
	</style>
</head>
...
<body>
	<div id="decoy_website">
	...decoy web ...
	</div>
	<iframe id="website" src="https://website.com">
	</iframe>
</body>

Dans le cadre d'une attaque de détournement de clic, l'attaquant positionne l'iframe du site Web cible dans le navigateur de manière à ce que l'action cible chevauche précisément le site Web leurre. Pour y parvenir, l'attaquant utilise des valeurs de position, de largeur et de hauteur appropriées pour les éléments, en utilisant des valeurs de position absolues et relatives pour garantir que le chevauchement est précis, indépendamment de la taille de l'écran, du navigateur et de la plate-forme utilisés. Le z-index est également utilisé pour déterminer l'ordre d'empilement des couches iframe et site Web.

Pour rendre l'iframe invisible aux yeux de l'utilisateur, l'attaquant définit la valeur d'opacité à 0.0 (ou proche de 0.0). Cette transparence peut être détectée par certaines fonctionnalités de protection contre le détournement de clic des navigateurs, qui peuvent appliquer une détection de transparence iframe basée sur un seuil. Par exemple, la version 76 de Chrome inclut cette fonctionnalité, mais pas Firefox. Pour éviter d'être détecté par ces fonctionnalités, l'attaquant sélectionne des valeurs d'opacité permettant d'obtenir l'effet souhaité sans déclencher de comportements de protection.

Clickjacking avec saisie de formulaire pré-remplie

Certains sites Web permettent aux utilisateurs de remplir et de soumettre des formulaires, et peuvent également offrir la possibilité de préremplir les entrées du formulaire à l'aide de paramètres GET avant la soumission. Dans d'autres cas, les sites Web peuvent exiger que l'utilisateur entre du texte avant de pouvoir soumettre le formulaire. Dans le cadre d'une attaque de détournement de clic, l'attaquant peut profiter de cette fonctionnalité pour modifier l'URL cible et incorporer les valeurs choisies par l'attaquant. Ensuite, un bouton transparent "Soumettre" peut être superposé sur le site leurre, simulant une action légitime pour l'utilisateur, alors que la véritable soumission du formulaire est effectuée sur le site cible sans le consentement de l'utilisateur.

Scripts de contournement de cadre

Les attaques de détournement de clics sont possibles sur tout site Web qui permet l'incorporation d'iframes. Pour se protéger contre ces attaques, une protection courante côté client est d'utiliser des scripts de rupture de trame ou de cadre. Ces scripts peuvent être implémentés via des add-ons ou des extensions JavaScript propriétaires pour les navigateurs Web, tels que NoScript.

Les scripts de rupture de cadre sont souvent conçus pour exécuter divers comportements de sécurité, notamment vérifier et imposer que la fenêtre courante de l'application soit la fenêtre principale ou supérieure, rendre tous les cadres visibles, empêcher de cliquer sur des cadres invisibles, intercepter et signaler les attaques potentielles de détournement de clic à l'utilisateur.

Cependant, les techniques de contournement de cadre sont souvent spécifiques au navigateur et à la plate-forme et, en raison de la flexibilité du HTML, elles peuvent être contournées par les attaquants. Par exemple, les frame busters étant écrits en JavaScript, les paramètres de sécurité du navigateur peuvent empêcher leur fonctionnement, ou même le navigateur peut ne pas prendre en charge le JavaScript.

Une solution de contournement efficace contre les frame busters consiste à utiliser l'attribut sandbox iframe HTML5. Cela permet de limiter les capacités de l'iframe, empêchant ainsi l'attaque de détournement de clic de se produire.

 <iframe id="website" src="https://website.com" sandbox="allow-forms"></iframe>

En utilisant l'attribut sandbox de l'iframe HTML5, les valeurs allow-forms et allow-scripts permettent à certaines actions spécifiées de s'exécuter dans l'iframe, tout en désactivant la navigation de niveau supérieur. Cela permet de bloquer les comportements de rupture de trame tout en autorisant la fonctionnalité au sein du site ciblé.

L'attribut allow-forms permet l'utilisation de formulaires dans l'iframe, tandis que l'attribut allow-scripts permet l'exécution de scripts dans l'iframe. En limitant la portée de ces fonctionnalités au sein de l'iframe, les risques de détournement de clics et autres attaques similaires sont réduits, car les scripts malveillants ne peuvent pas affecter la navigation du site principal.

Combiner le détournement de clic avec une attaque DOM XSS

Le détournement de clic a longtemps été considéré comme une attaque autonome, généralement utilisée pour des comportements tels que la stimulation des "j'aime" sur une page Facebook. Toutefois, la véritable puissance de cette technique réside dans son utilisation comme support pour d'autres attaques, comme l'attaque DOM XSS. En effet, en combinant le détournement de clic avec un exploit XSS préalablement identifié, il devient relativement simple d'exécuter une attaque DOM XSS. Pour ce faire, l'exploit XSS est associé à l'URL cible d'un iframe, incitant l'utilisateur à cliquer sur un bouton ou un lien et permettant ainsi l'exécution de l'attaque DOM XSS.

Clickjacking en plusieurs étapes

La manipulation des entrées d'un site Web cible peut impliquer plusieurs étapes pour un attaquant. Par exemple, l'attaquant peut chercher à tromper un utilisateur en le faisant acheter quelque chose sur un site de vente en ligne, ce qui peut nécessiter l'ajout d'articles au panier avant que la commande ne soit passée. Pour ce faire, l'attaquant peut utiliser plusieurs divisions ou iframes. Toutefois, ces attaques requièrent une grande précision et une attention particulière de la part de l'attaquant afin d'être efficaces et de passer inaperçues.

Comment prévenir les attaques de détournement de clic

Nous avons abordé le sujet des scripts de contournement de trame comme étant une mesure courante de prévention côté navigateur contre le détournement de clics. Cependant, ces protections sont souvent faciles à contourner pour un attaquant expérimenté. Pour cette raison, des protocoles pilotés par le serveur ont été développés pour limiter l'utilisation des iframes dans le navigateur et pour atténuer le détournement de clics.

Le succès ou l'échec du détournement de clic dépend de la fonctionnalité du navigateur et de sa conformité aux normes et aux meilleures pratiques en matière de sécurité web. Pour offrir une protection efficace contre cette attaque, des contraintes doivent être définies et communiquées pour limiter l'utilisation de certains composants tels que les iframes. Toutefois, la mise en œuvre de cette protection dépend de la conformité du navigateur et de l'application de ces contraintes. Deux mécanismes couramment utilisés pour la protection contre le détournement de clic côté serveur sont X-Frame-Options et Content Security Policy.

X-Frame-Options

X-Frame-Options a été initialement introduit comme un en-tête de réponse non officiel dans Internet Explorer 8, mais il a rapidement été adopté par d'autres navigateurs. L'objectif de cet en-tête est de permettre aux propriétaires de sites Web de contrôler l'utilisation des iframes et des objets, en leur permettant d'interdire l'inclusion d'une page Web dans un cadre en utilisant la directive "deny". Alternativement, le cadrage peut être limité à la même origine que le site Web en utilisant la directive sameorigin ou allow-from;

 X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from https://website.com

Bien que l'implémentation de X-Frame-Options puisse varier entre les navigateurs, cette technique peut offrir une protection efficace contre les attaques de détournement de clic lorsqu'elle est correctement appliquée conjointement avec une politique de sécurité de contenu dans le cadre d'une stratégie de défense multicouche.

Politique de sécurité du contenu ( CSP )

La politique de sécurité de contenu (CSP) est un mécanisme de prévention et de détection qui offre une protection contre les attaques telles que le détournement de clic et les attaques XSS. Pour ce faire, la CSP est généralement mise en place au niveau du serveur Web sous la forme d'un en-tête renvoyé avec le formulaire :

 Content-Security-Policy: policy

Le CSP utilise une chaîne de directives de politique séparées par des points-virgules pour fournir au navigateur client des informations sur les sources autorisées de ressources Web, ce qui permet de détecter et d'intercepter les comportements malveillants.

Pour se protéger contre le détournement de clic, il est recommandé d'incorporer la directive frame-ancestors dans la politique de sécurité de contenu de l'application. Si la valeur 'none' est utilisée, cette directive aura un comportement similaire à la directive X-Frame-Options "deny". Toutefois, pour autoriser l'inclusion de trames provenant du même domaine, il est possible de mettre en liste blanche ces trames en utilisant le CSP suivant :

 Content-Security-Policy: frame-ancestors 'self';
Content-Security-Policy: frame-ancestors website.com;

Alternativement, le cadrage peut être limité aux sites nommés.