Chapitre 8.3 — Clickjacking & open redirect

⏱️ TL;DR — Deux attaques qui n’injectent pas de code mais détournent l’interface et la navigation. Le clickjacking charge ton site dans une iframe invisible posée sur un leurre : la victime croit cliquer sur le leurre, mais son clic atteint ton interface (valider un paiement, changer un réglage). Parade : interdire la mise en iframe de ton site par d’autres origines — X-Frame-Options: DENY et/ou CSP frame-ancestors 'none'. L’open redirect exploite une redirection dont la destination vient de l’utilisateur (/go?url=...) sans validation : l’attaquant fabrique un lien vers ton domaine (de confiance) qui rebondit vers un site de phishing. Parade : valider la cible (allow-list, redirections internes uniquement).

🎯 Objectifs

• Comprendre le clickjacking (iframe superposée) et son impact.
• Interdire la mise en iframe de son site (X-Frame-Options, frame-ancestors).
• Comprendre l’open redirect et pourquoi il sert le phishing.
• Valider les cibles de redirection (allow-list, chemins internes).

Clickjacking : le clic détourné

Le clickjacking (détournement de clic) consiste à superposer ton site — chargé dans une iframe transparente — par-dessus une page leurre attirante (« Cliquez pour gagner ! », un faux bouton de jeu). L’iframe est rendue invisible (opacité nulle) et positionnée pour que le bouton réel et sensible de ton site (valider un virement, supprimer un compte, accorder une permission) se trouve pile sous le curseur au moment où la victime clique le leurre.

Couche visible (leurre) :   [  Cliquez ici pour continuer  ]
Couche invisible (iframe) : [  Valider le virement de 500€  ]   <- le vrai clic va ici

La victime, authentifiée sur ton site (l’iframe charge ta page avec sa session), clique « en confiance » sur le leurre — mais son clic actionne l’action sensible de ton interface. C’est une forme d’abus de confiance visuelle : rien n’est « piraté » techniquement, on trompe l’œil de l’utilisateur.

La parade : interdire l’encadrement

Puisque l’attaque exige de charger ton site dans une iframe, la parade est de l’interdire (sauf, éventuellement, depuis ta propre origine). Deux en-têtes (vus en Partie 2), à poser sur les pages sensibles (voire partout) :

X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'

• X-Frame-Options: DENY (ou SAMEORIGIN) : l’ancien en-tête, largement supporté.
• frame-ancestors 'none' (ou 'self') : la directive CSP moderne, plus flexible (permet de lister des origines autorisées si besoin). Elle prime sur X-Frame-Options là où les deux sont présents.

Le réflexe : par défaut, ton appli n’a aucune raison d’être mise en iframe par un tiers → frame-ancestors 'none'. Si un cas légitime existe (widget embarqué), n’autoriser que les origines précises.

⚠️ Piège — Ne pas confondre clickjacking et CSRF : le clickjacking n’envoie pas de requête forgée, il fait cliquer la victime sur ta vraie interface. Un jeton anti-CSRF ne protège donc pas du clickjacking (le clic légitime porte le bon jeton !). La parade est spécifique : empêcher la mise en iframe (frame-ancestors/X-Frame-Options). Les deux attaques sont complémentaires ; il faut les deux défenses.

Open redirect : la redirection détournée

Beaucoup d’applis ont une redirection paramétrable : après login, on renvoie l’utilisateur vers la page qu’il voulait (/login?redirect=/mon-espace) ; ou un « lien de sortie » (/go?url=...). Si la destination vient de l’utilisateur et n’est pas validée, c’est un open redirect : l’attaquant peut faire pointer la redirection vers n’importe quel site.

# Lien envoye a la victime (le domaine est CELUI DE CONFIANCE) :
https://app.formacampus.fr/go?url=https://evil.example/faux-login
# -> l'appli redirige la victime vers le site de phishing

Le danger n’est pas une prise de contrôle directe, mais l’abus de confiance : le lien commence par ton domaine (que la victime reconnaît et à qui elle fait confiance), ce qui rend le phishing bien plus crédible. L’open redirect sert aussi à contourner des filtres (une allow-list de domaines qui autorise le tien, lequel rebondit ailleurs) et peut aggraver d’autres failles (vol de token OAuth via une redirect_uri laxiste — Partie 4).

La parade : valider la cible

• Rediriger uniquement vers des chemins internes : n’accepter que des destinations relatives à ton site (/mon-espace), jamais une URL absolue fournie par l’utilisateur. C’est la solution la plus simple et la plus sûre.
• Allow-list si des destinations externes sont vraiment nécessaires : n’autoriser qu’un ensemble fini de domaines connus.
• Rejeter les URL absolues et les schémas dangereux ; se méfier des contournements (//evil.example — une URL « protocol-relative » qui ressemble à un chemin mais part ailleurs, /\evil.example, encodages).

// ✅ N'autoriser que des chemins internes (relatifs a l'origine)
function cibleSure(dest) {
  // refuse les URL absolues, les "//host", les schemas
  if (!dest || !dest.startsWith('/') || dest.startsWith('//')) return '/'
  return dest
}
res.redirect(cibleSure(req.query.redirect))

💡 Réflexe — Devant tout paramètre de redirection (?redirect=, ?url=, ?next=, returnTo), demande-toi : « peut-il pointer ailleurs que chez moi ? ». Par défaut, n’autorise que des chemins internes (commençant par / mais pas //). C’est suffisant dans l’immense majorité des cas et ferme l’open redirect. Ne redirige jamais vers une URL absolue brute venant de l’utilisateur.

🎯 Côté attaquant — L’open redirect est un multiplicateur pour le phishing et le vol de jetons : un lien qui commence par le domaine légitime (app.formacampus.fr) endort la méfiance, avant de rebondir vers une page piégée. L’attaquant l’utilise aussi pour contourner des protections qui « font confiance » aux redirections internes, ou pour détourner un flux OAuth. Pour le clickjacking, il cible les actions à un clic (valider, autoriser, supprimer) et compte sur l’absence de frame-ancestors. Les deux exploitent la confiance — dans ton domaine, dans ce que l’œil voit.

🧭 Sur FormaCampus — FormaCampus pose X-Frame-Options: DENY et frame-ancestors 'none' sur toutes ses pages (aucun besoin d’être mis en iframe), fermant le clickjacking. Ses redirections post-login n’acceptent que des chemins internes (validés : commencent par /, pas //, pas de schéma), et le « lien sortant » vers des ressources partenaires passe par une allow-list de domaines. Le flux OAuth (chapitre 4.4) verrouille strictement ses redirect_uri. Résultat : impossible de faire de app.formacampus.fr un tremplin de phishing ou une interface piégée en iframe.

✏️ Exercices

Exercice 1 — CSRF ou clickjacking ? Une action sensible est protégée par un jeton anti-CSRF. Un attaquant charge quand même la page dans une iframe invisible et fait cliquer la victime sur le bouton d’action. L’attaque marche-t-elle ? Que faut-il ajouter ?

Exercice 2 — Ferme l’open redirect. Ce code redirige après connexion : res.redirect(req.query.next). Montre l’abus et corrige.

🧠 Quiz de révision

Chapitre suivant : CORS bien configuré — comprendre CORS (un assouplissement de la SOP, pas une protection) et le configurer sans se percer un trou.