Qu'est-ce que le clickjacking et comment s'en protéger Imprimer

Le clickjacking (détournement de clic en français) est une attaque qui incite un utilisateur à cliquer sur un élément de page Web qui est invisible ou déguisé en un autre élément. Cela peut amener les utilisateurs à télécharger involontairement des logiciels malveillants, à visiter des pages Web malveillantes, à fournir des informations d'identification ou des informations sensibles, à transférer de l'argent ou à acheter des produits en ligne.

En règle générale, le détournement de clic est effectué en affichant une page invisible ou un élément HTML, à l'intérieur d'un iframe, en haut de la page que l'utilisateur voit. L'utilisateur croit cliquer sur la page visible mais en fait il clique sur un élément invisible de la page supplémentaire transposée par-dessus.

La page invisible peut être une page malveillante ou une page légitime que l'utilisateur n'a pas l'intention de visiter - par exemple, une page sur le site bancaire de l'utilisateur qui autorise le transfert d'argent.

Il existe également plusieurs variantes de l'attaque de détournement de clic, telles que:

• Likejacking  - une technique dans laquelle le bouton «J'aime» de Facebook est manipulé, amenant les utilisateurs à «aimer» une page qu'ils n'avaient en fait pas l'intention d'aimer.
• Cursorjacking  - une technique de correction de l'interface utilisateur qui change le curseur de la position perçue par l'utilisateur vers une autre position. Le détournement de curseur repose sur les vulnérabilités de Flash et du navigateur Firefox, qui ont maintenant été corrigées.

Voici un exemple concret de clickjacking (attaque de détournement de clic) :

1. L'attaquant crée une page attractive qui promet de donner à l'utilisateur un voyage gratuit à Tahiti.
2. En arrière-plan, l'attaquant vérifie si l'utilisateur est connecté à son site bancaire et si c'est le cas, charge l'écran qui permet le transfert de fonds, en utilisant des paramètres de requête pour insérer les coordonnées bancaires de l'attaquant dans le formulaire.
3. La page de virement bancaire est affichée dans une iframe invisible au-dessus de la page de cadeau gratuit, avec le bouton «Confirmer le transfert» aligné exactement sur le bouton «Recevoir un cadeau» visible par l'utilisateur.
4. L'utilisateur visite la page et clique sur le bouton «Réserver mon voyage gratuit».
5. En réalité, l'utilisateur clique sur l'iframe invisible et a cliqué sur le bouton «Confirmer le transfert». Les fonds sont transférés à l'attaquant.
6. L'utilisateur est redirigé vers une page contenant des informations sur le cadeau gratuit (ne sachant pas ce qui s'est passé en arrière-plan).

Cet exemple met en exergue que, dans une attaque de détournement de clic, l'action malveillante (sur le site Web de la banque, dans ce cas) ne peut pas être retracée jusqu'à l'attaquant car l'utilisateur l'a exécutée en étant légitimement connecté à son propre compte. vous pouvez donc être considéré comme responsable des gestes effectués.

Mitigation (Atténuation) du détournement de clic

Il existe deux moyens généraux de se défendre contre le détournement de clic:

• Méthodes côté client  - la plus courante est appelée Frame Busting. Les méthodes côté client peuvent être efficaces dans certains cas, mais ne sont pas considérées comme une bonne pratique, car elles peuvent être facilement contournées.
• Méthodes côté serveur  - la plus courante est X-Frame-Options. Les méthodes côté serveur sont recommandées par les experts en sécurité comme moyen efficace de se défendre contre le détournement de clics.

Atténuer le détournement de clic avec l'en-tête de réponse X-Frame-Options

L'en-tête de réponse X-Frame-Options est passé dans le cadre de la réponse HTTP d'une page Web, indiquant si un navigateur doit être autorisé ou non à afficher une page dans une balise <FRAME> ou <IFRAME>.

Trois valeurs sont autorisées pour l'en-tête X-Frame-Options:

• DENY - n'autorise aucun domaine à afficher cette page dans un cadre
• SAMEORIGIN - permet à la page actuelle d'être affichée dans un cadre sur une autre page, mais uniquement dans le domaine actuel
• ALLOW-FROM URI - permet à la page actuelle d'être affichée dans un cadre, mais uniquement dans un URI spécifique - par exemple  www.example.com/frame-page

Utiliser l'option SAMEORIGIN pour se défendre contre le détournement de clic

X-Frame-Options permet aux éditeurs de contenu d'empêcher que leur propre contenu ne soit utilisé dans un cadre invisible par des attaquants.

L'option DENY est la plus sécurisée, empêchant toute utilisation de la page en cours dans un cadre. Plus couramment, SAMEORIGIN est utilisé, car il permet l'utilisation de cadres, mais les limite au domaine actuel.

Limitations des options X-Frame

• Pour activer l'option SAMEORIGIN sur un site Web, l'en-tête X-Frame-Options doit être renvoyé dans le cadre de la réponse HTTP pour chaque page individuelle (ne peut pas être appliqué intersite).
• X-Frame-Options ne prend pas en charge une liste blanche de domaines autorisés, il ne fonctionne donc pas avec les sites multi-domaines qui doivent afficher du contenu encadré entre eux.
• Une seule option peut être utilisée sur une seule page, ainsi, par exemple, il n'est pas possible que la même page soit affichée sous forme de cadre à la fois sur le site Web actuel et sur un site externe.
• L'option ALLOW-FROM n'est pas prise en charge par tous les navigateurs.
• X-Frame-Options est une option obsolète dans la plupart des navigateurs.

Test de détournement de clics - Votre site est-il vulnérable?

Un moyen de base pour tester si votre site est vulnérable au détournement de clics est de créer une page HTML et d'essayer d'inclure une page sensible de votre site Web dans un iframe. Il est important d'exécuter le code de test sur un autre serveur Web, car c'est le comportement typique dans une attaque de détournement de clic.

Utilisez un code comme celui-ci, fourni dans le cadre du  guide de test OWASP :

<html>
<head>
<title> Page de test Clickjack </title>
</head>
<body>
<p> Le site Web est vulnérable au détournement de clics! </p>
<iframe src = "http://www.votresite.com/sensitive-page" width = "500" height = "500"> </iframe>
</body>
</html>

Affichez la page HTML dans un navigateur et évaluez la page comme suit:

• Si le texte «Le site Web est vulnérable au détournement de clic» apparaît et en dessous vous voyez le contenu de votre page sensible,  la page est vulnérable au détournement de clic .
• Si seul le texte «Le site Web est vulnérable au détournement de clic» apparaît et que vous ne voyez pas le contenu de votre page sensible, la page n'est pas vulnérable à la forme la plus simple de détournement de clic.

Cependant, des tests supplémentaires sont nécessaires pour voir quelles méthodes anti-clickjacking sont utilisées sur la page et si elles peuvent être contournées par des attaquants.

Comment nous vous aidons à atténuer les attaques de détournement de clic ?

Pour arriver au point de détourner un site, le site devra être compromis, ce que notre mod_security s'efforce d'empêcher. Nous nous assurons également que les ressources de votre site envoient les en-têtes HTTP X-Frame-Options appropriés grâce à l'option SAMEORIGIN, ce qui empêchera certaines parties de votre site d'être encadrées dans d'autres pages ou en dehors de votre domaine.

Un article pouvant vous intéresser ? Focus sur le mod_security et notamment le déploiement du "Comodo ModSecurity Rule Set" : https://clients.offshore-cloud.com/knowledgebase/47/WHM---Deployer-Comodo-ModSecurity-Rule-Set-dans-cPanel.html

X-Frame-Options étant obsolète ou en fin de vie pour de nombreux navigateurs, l'en-tête appelé CSP (pour Content-Security-Policy) possède une directive frame-ancestors qui supplante cet en-tête pour les navigateurs compatibles.

Un article à ce sujet juste ici : https://clients.offshore-cloud.com/knowledgebase/139/CSP---Implementer-les-frame-ancestors-en-remplacement-des-X-Frame-Options.html

Exemple de configuration :

• similaire à X-Frame-Options DENY.
  • Header set Content-Security-Policy "frame-ancestors none;"
• similaire à SAMEORIGIN + un autre site, comme votre CDN, en exemple
  • Header set Content-Security-Policy "frame-ancestors 'self' cloudflare.com;"

A ce jour (T1 2021), nous considérons que les options X-frame fonctionnent bien et que c'est un en-tête facile à utiliser notamment dans notre cas de règle générale appliqué à l'ensemble du cluster mutualisé. Pas besoin de supprimer encore X-Frame; spécifiquement car beaucoup de gens n'utilisent toujours pas CSP (non supporté sur les anciens navigateurs). Sachez tout de même qu'en définissant une règle CSP , celle-ci remplacera et prendra le dessus sur l'option X-Frame similaire. A noter également que le CSP permet l'option Report-only et donc de tester votre configuration (rendue visible) sans l'appliquer afin d'anticiper tout blocage.