RISQUE UI
CLICKJACKING
PROTECTION HTTP
clickjacking.php
Cette page explique en détail la technique de clickjacking,
son fonctionnement, ses variantes, ses dangers et les protections recommandées.
Le point clé : empêcher l'intégration de tes pages dans des iframes externes.
Conseil pratique : pour une page sensible, la configuration la plus simple et la plus sûre est souvent :
X-Frame-Options: DENY +
Content-Security-Policy: frame-ancestors 'none';
Défense n°1
CSP frame-ancestors
Défense n°2
X-Frame-Options
Défense n°3
Confirmations fortes + cookies bien réglés
1. Définition
Le clickjacking, aussi appelé UI redressing, est une technique d'attaque
qui consiste à faire cliquer un utilisateur sur un élément différent de celui qu'il croit voir.
En général, une page légitime est chargée dans un iframe, puis masquée, décalée,
rendue transparente, recouverte d'un faux bouton ou intégrée dans une interface trompeuse.
L'utilisateur pense cliquer sur « voir une vidéo », « fermer », « jouer », « télécharger », « suivant »,
mais son clic déclenche en réalité une action sensible sur la page cachée :
autoriser une permission, supprimer un contenu, valider un achat, changer un paramètre,
ou lancer une opération administrative.
2. Idée générale de l'attaque
Le schéma classique :
- L'attaquant crée une page piégée visuellement crédible.
- Il charge en arrière-plan une vraie page cible dans un
iframe.
- Il rend l'iframe invisible ou presque invisible.
- Il aligne un faux bouton au-dessus d'un vrai bouton sensible.
- L'utilisateur clique en pensant agir sur le faux bouton.
- Le clic est en fait reçu par la page légitime chargée en dessous.
Le danger augmente si l'utilisateur est déjà connecté au site cible, car son navigateur
envoie souvent automatiquement ses cookies de session au site légitime.
3. Exemples concrets
- Cliquer sur « Lancer la vidéo » alors que le clic active un bouton « Autoriser ».
- Cliquer sur un faux jeu alors que le clic suit une page ou valide un abonnement.
- Cliquer sur « Télécharger » alors que le clic modifie des réglages d'un compte.
- Cliquer sur un faux bouton graphique placé sur un bouton bancaire réel.
- Cliquer sur une zone décorative alors que le clic déclenche une action admin.
4. Pourquoi cela marche
- L'utilisateur voit une interface trompeuse mais ne voit pas la vraie cible.
- Le navigateur autorise parfois l'intégration d'une page dans un
iframe.
- Le site cible n'envoie pas d'en-têtes anti-framing.
- La session utilisateur est active.
- L'action sensible ne demande pas de confirmation forte.
5. Cibles fréquentes
- Panneaux d'administration
- Interfaces bancaires
- Pages de paiement
- Pages de changement de mot de passe
- Interfaces de modération
- Réseaux sociaux
- Autorisations caméra / micro / notifications
- Portails internes d'entreprise
6. Variantes de clickjacking
- Invisible iframe clickjacking : iframe cachée ou presque transparente.
- Cursorjacking : position réelle du curseur trompée.
- Likejacking : pousser à aimer / suivre / partager sans le vouloir.
- Touchjacking : variante mobile avec zones tactiles piégées.
- Drag-and-drop hijacking : l'utilisateur déplace un objet vers une zone cachée.
- Multi-step clickjacking : plusieurs clics successifs guident vers une action finale.
7. Signes de vulnérabilité
- La page peut être ouverte dans un
iframe externe.
- Aucun
Content-Security-Policy: frame-ancestors.
- Aucun
X-Frame-Options.
- Des actions critiques sont déclenchées par un simple clic sans confirmation.
- Le site suppose à tort que « on ne voit pas mon bouton donc il est protégé ».
8. Défense principale : empêcher l'intégration en iframe
La meilleure défense consiste à empêcher ton site d'être chargé dans un
frame ou iframe par un autre site.
Option moderne recommandée : CSP frame-ancestors
Content-Security-Policy: frame-ancestors 'none';
Bloque totalement l'intégration de la page dans un iframe.
Content-Security-Policy: frame-ancestors 'self';
Autorise seulement l'intégration par le même site/origine.
Content-Security-Policy: frame-ancestors 'self' https://exemple.com;
Autorise le même site et un domaine précis.
Compatibilité supplémentaire : X-Frame-Options
X-Frame-Options: DENY
Bloque totalement l'affichage dans un frame.
X-Frame-Options: SAMEORIGIN
Autorise seulement le même site à intégrer la page.
Ne pas utiliser ALLOW-FROM dans les nouveaux développements :
ce n'est pas une stratégie moderne fiable.
9. Défenses complémentaires
- Demander une revalidation du mot de passe pour les actions très sensibles.
- Demander une confirmation explicite avant suppression, paiement, transfert, etc.
- Utiliser un second facteur pour les opérations critiques.
- Limiter les permissions navigateur et les valider côté serveur.
- Utiliser des cookies de session avec
SameSite=Lax ou SameSite=Strict selon le besoin.
- Journaliser les actions critiques.
- Réduire les interfaces dangereuses déclenchées par un simple clic unique.
10. SameSite et clickjacking
Le paramètre SameSite des cookies n'est pas une solution unique au clickjacking,
mais il peut réduire certains scénarios où la session ou certaines requêtes inter-sites
seraient sinon envoyées automatiquement.
Cela ne remplace pas frame-ancestors ni X-Frame-Options.
C'est une couche complémentaire, pas la défense principale.
11. Frame busting JavaScript : utile ou pas ?
Les anciens scripts du type :
if (top !== self) {
top.location = self.location;
}
Étaient contournables facilement via l'attribut sandbox sur l'iframe,
ou par d'autres techniques. Ils ne sont pas fiables comme défense principale.
Ils peuvent servir comme couche supplémentaire, mais ne doivent jamais remplacer
les en-têtes HTTP frame-ancestors et X-Frame-Options.