Clickjacking : comprendre et se protéger
Auteur : Rédaction Domeny.ForSale Publié le
En bref : Le clickjacking, aussi appelé UI redress attack, consiste à pousser l’utilisateur à cliquer sur un autre élément que celui qu’il voit. Un attaquant peut, par exemple, superposer une page invisible contenant un bouton à un bouton de jeu apparemment anodin. Pour limiter ces attaques, le propriétaire du site doit avant tout contrôler qui peut intégrer ses pages, tandis que l’utilisateur doit se méfier des interactions suspectes.
Comment fonctionne le détournement de clics
Un navigateur peut afficher une page à l’intérieur d’une autre à l’aide de l’élément iframe, qui constitue un cadre intégré. Cette fonctionnalité courante sert notamment à afficher des vidéos ou des cartes. Dans une attaque par clickjacking, le malfaiteur l’utilise pour dissimuler la véritable cible du clic sous une interface préparée à cet effet, ou par-dessus celle-ci.
Voici un scénario typique : l’utilisateur ouvre une page contrôlée par l’attaquant, qui charge un autre site dans un cadre. Ce cadre est transparent ou recadré et positionné de manière à placer son bouton exactement à l’endroit où l’utilisateur s’apprête à cliquer. L’utilisateur voit une commande, mais le navigateur enregistre une interaction avec un autre élément.
L’attaquant n’a pas besoin de lire le contenu du site tiers. Les restrictions d’accès entre sites imposées par le navigateur n’empêchent pas, à elles seules, l’intégration d’une page et le détournement des clics. Empêcher la lecture des données et empêcher l’intégration de l’interface sont donc deux tâches distinctes.
Exemple : une récompense qui déclenche une autre action
Imaginez une page proposant un jeu simple et un bouton « Récupérer la récompense ». Un cadre invisible contenant l’interface d’un autre service est superposé à ce bouton. Si ce service autorise son intégration et que la session de l’utilisateur fonctionne dans ce cadre, le clic peut atteindre un bouton qui effectue une opération sur son compte.
Cela ne signifie pas que toute visite sur une page malveillante entraîne immédiatement la prise de contrôle du compte. La réussite de l’attaque dépend notamment des protections du site ciblé, de la disponibilité de la session authentifiée dans le cadre et de l’éventuelle nécessité de confirmer l’opération. Les paramètres des cookies et les restrictions du navigateur peuvent compliquer ce scénario, mais ils ne remplacent pas la protection contre l’intégration dans un cadre.
Les conséquences possibles comprennent une modification involontaire des paramètres, l’exécution d’une action sur le service ou la validation d’une opération. Une confirmation supplémentaire exigeant une action délibérée de l’utilisateur réduit le risque. Toutefois, l’ajout d’un simple bouton ne garantit pas la protection : l’attaque peut tenter de guider la victime à travers plusieurs clics.
Ce qui distingue le clickjacking du phishing et de CSRF
Dans une attaque de phishing, l’escroc se fait généralement passer pour une entité de confiance afin de soutirer des données ou d’inciter à une action précise. Avec le clickjacking, l’utilisateur peut au contraire cliquer sur un élément du véritable service, mais dissimulé dans un environnement trompeur. Les deux techniques peuvent être combinées, mais le mécanisme de tromperie diffère.
Une attaque CSRF consiste à provoquer l’envoi d’une requête non souhaitée à un service en exploitant les droits de l’utilisateur connecté, sans son consentement éclairé. Le clickjacking vise, lui, à détourner l’interaction avec l’interface. Un jeton de protection contre CSRF ne suffit pas à protéger contre le clickjacking, car le clic peut déclencher l’envoi d’un formulaire légitime accompagné de son jeton valide.
HTTPS ne résout pas non plus ce problème. Il chiffre la connexion avec le site, mais ne garantit ni l’honnêteté de son interface ni les intentions de son propriétaire.
Comment protéger son site
La protection principale repose sur l’en-tête de réponse HTTP Content-Security-Policy, associé à la directive frame-ancestors. Un en-tête HTTP est une information envoyée par le serveur au navigateur avec la page. Cette directive définit les origines autorisées à intégrer la page dans des cadres.
Si le site ne doit jamais être intégré dans un cadre, vous pouvez utiliser :
Content-Security-Policy: frame-ancestors 'none'
Si l’intégration doit être autorisée uniquement au sein de la même origine — c’est-à-dire la même combinaison de protocole, d’hôte et de port — la valeur appropriée est :
Content-Security-Policy: frame-ancestors 'self'
Un mécanisme plus ancien est X-Frame-Options, avec la valeur DENY ou SAMEORIGIN. Il peut servir de protection complémentaire compatible avec les clients plus anciens. La directive frame-ancestors offre un contrôle plus souple, en permettant par exemple d’autoriser une origine précise appartenant à un partenaire. Elle doit être envoyée dans un en-tête de réponse : la placer dans une balise meta n’assure pas cette protection.
La mise en œuvre pratique comporte trois étapes :
- Déterminez quelles pages doivent réellement fonctionner dans des cadres, par exemple dans le cadre d’une intégration avec un partenaire.
- Configurez la politique appropriée sur le serveur, dans l’application ou dans le service intermédiaire, puis vérifiez les en-têtes dans les outils de développement du navigateur.
- Testez à la fois le blocage des intégrations indésirables et le bon fonctionnement des intégrations légitimes.
Ne comptez pas uniquement sur des scripts JavaScript qui tentent de faire sortir la page de son cadre. Ces solutions ont des limites et peuvent être contournées. Pour les opérations sensibles, exigez également une nouvelle authentification ou une confirmation décrivant clairement l’action effectuée.
Ce que peut faire l’utilisateur
Évitez les pages qui exigent une série de clics incompréhensibles, notamment sous prétexte de récupérer une récompense, de débloquer une vidéo ou de passer une prétendue vérification. Gardez votre navigateur à jour, mais n’oubliez pas qu’une version récente ne remplace pas les protections du service visité.
Si vous soupçonnez qu’un clic a déclenché une action indésirable, ouvrez vous-même le service concerné plutôt que de suivre un lien sur la page suspecte. Consultez l’historique d’activité et les paramètres modifiés, puis signalez toute opération non autorisée à l’assistance. Le propriétaire du site devrait commencer par vérifier l’en-tête frame-ancestors sur les pages du compte et de l’interface d’administration.
Voir aussi : Qu’est-ce que le Mass Assignment ?
À lire aussi
