Clickjacking: une alternative au Phishing

Principe de l'attaque Clickjacking

Le Clickjacking est une attaque de type sacm assez récente qui cible les pages Web et applications mobiles. Elle se substitue à l'attaque Phishing qui a fait un nombre incalculable de dégâts (et continue à le faire mais avec un taux moins important).

Le Phishing (ou hameçonnage) consiste à créer une page falsifiée identique à une page qui demande des informations confidentielles (comme une page d'authentification d'un site Web). Le pirate incite ensuite la victime à visiter cette page falsifiée (généralement en lui envoyant un email). Si la victime n'était pas attentif alors elle pourrait bien mordre à l'"hameçon" et saisir ses informations privées sur la page falsifiée et envoyer ainsi ces informations-là au pirate.

Cependant, la phishing classique se confronte à deux obstacles de taille:

• L'URL affichée pour la page falsifiée est différente à l'URL attendue par l'utilisateur. Bien que le pirate puisse forger une autre attaque contre le serveur DNS du client nommée DNS Spoofing afin de falsifier les enregistrements et parvenir ainsi à afficher la bonne URL pour la mauvaise page, mais cette pratique devient de plus en plus difficile à accomplir en raison de la sécurisation des transactions DNS notamment via DNSSec (Domain Name System Security Extensions).
• Si la page d’authentification utilise un certificat SSL (pour le HTTPS) alors le navigateur affichera aussitôt un avertissement mettant garde la potentielle victime de tentative de Phishing.

Le Clickjacking a la même finalité que le Phishing, c'est à dire, dérober les informations confidentielles de la victime, mais cette fois en utilisant la page légitime qui demande ces informations là.

L'idée consiste à ajouter une couche transparente au dessus de la page légitime (on parle d'intégrer une couche transparente entre l'application et le doigt de la victime, car cette attaque ciblait à la base les applications mobiles qui reposent sur des écrans tactiles). En effet, le pirate crée une sorte de formulaire HTML transparent qu'il place au dessus de la page légitime de telle sorte à superposer les champs du formulaire qu'il a créés aux champs figurant déjà dans la page. Quand la victime saisit du texte, elle croit que c'est dans le champ visible qu'elle est entrain de le faire, alors qu'en réalité c'est le formulaire transparent qui accueillit ses données. Par conséquent, une fois le formulaire posté au serveur, le pirate reçoit aussitôt les données à travers son formulaire masqué.

Mais comment le pirate arrive-t-il à ajouter cette couche transparente?

Il est évident que le pirate qui mène l'attaque Clickjacking n'ait pas accès au site légitime, donc il ne peut pas le modifier pour ajouter son formulaire transparent. Par contre, le pirate crée sa propre page Web dans laquelle il pourrait afficher la page légitime simplement à l'aide de la balise <iframe> comme ceci:
Au dessus de l'élément <iframe> le pirate intègre le formulaire qu'il masque à l'aide du CSS et il fait en sorte que les champs visibles sur la page légitime soient couverts pas les champs qu'il a inclut dans son faux formulaire. Il pourrait aussi ajouter un petit tour en Javascript afin que l'affichage paraisse normal pour qu'il n'éveille pas les soupçons de la victime.

Comme pour le Phishing, le pirate incite l'utilisateur à visiter sa page. Bien entendu, l'URL affichée ne correspond pas à celle attendue par l'utilisateur, par contre aucun message d'avertissement ne sera affiché par le navigateur à l'égard du certificat SSL, car la page légitime s'exécute conformément dans une <iframe>. Par conséquent, si la victime ne remarquait pas l'URL, alors elle pourrait bien mordre à l'hameçon et saisir ses données confidentielles.

Comment se protéger du Clickjacking?

Au niveau du code source

Dans le site légitime, on peut interdire l'inclusion de ses pages dans les <iframe> déclarés dans d'autres sites Web en spécifiant la balise <meta> suivante:
Dans ce cas, la page qui contient cette META ne sera pas incluse dans une quelconque IFRAME (même déclarée dans le site légitime). Sinon on peut remplacer "deny" par "sameorigin" pour autoriser l'inclusion sur le même domaine.

Cependant cette technique n'est pas recommandée et on préconise surtout d'envoyer un entête HTTP par le serveur interdisant cette inclusion conformément au mécanisme Content Security Policy (ou CSP).

Au niveau de la configuration du serveur (Mécanisme Content Security Policy - CSP)

Au moment de l'exécution de la page légitime, le navigateur vérifie les entêtes afin de décider comment s'y prendre. Donc, pour interdire (ou limiter) l'inclusion de la page dans une IFRAME on pourrait ajouter la directive suivante dans le fichier de configuration Apache (ou simplement dans un fichier .htaccess):
Sur un serveur Nginx la directive devient:
Les valeurs possibles en option sont:

• DENY: pour interdire l'inclusion dans n'importe quelle page (même celles appartenant au même site Web légitime).
• SAMEORIGIN: pour interdire l'inclusion dans toute page qui ne fait pas partie du site Web légitime (d'origine).
• allow-from https://site-autorisé-à-inclure-la-page.com: pour interdire l'inclusion dans toute page n'appartenant pas au site autorisé.

Sensibilisation des utilisateurs du risque du Clickjacking

De manière générale, il est recommandé de sensibiliser les utilisateurs d'une application mobile ou site Web qui requière des données confidentielles de telle sorte à les informer des risques de Phishing, de Clickjacking ou de toute autre attaque de type scam. Un simple message à afficher dans les pages critiques pourrait suffire de telles sorte à informer l'utilisateur de vérifier si l'URL correspond bien à ce qui est attendu ou de noter tout avertissement soulevé par le navigateur à propos du certificat SSL.