Le callback de connexion SSO comporte une redirection ouverte (il redirige vers toute URL passée en paramètre). Quel est le risque ?
Réponse courte
Une redirection ouverte sur un flux d'authentification permet à un attaquant de forger un lien de connexion d'apparence fiable qui, après authentification, envoie l'utilisateur — et potentiellement un code d'autorisation ou un jeton — vers un domaine contrôlé par l'attaquant, permettant le détournement de compte et un phishing convaincant. Corrigez-le en allow-listant strictement les redirect URI exacts côté serveur et en rejetant tout le reste. Ce n'est ni cosmétique ni un problème de performance, et HTTPS n'aide pas car la destination de l'attaquant peut aussi être un site HTTPS valide.
Une redirection ouverte est souvent écartée comme de faible gravité — jusqu'à ce qu'elle se trouve sur un callback d'authentification. Là, elle cesse d'être une nuisance de phishing pour devenir une voie vers le détournement de compte, car ce qui est redirigé peut transporter des identifiants, un code d'autorisation ou un jeton.
Pourquoi le risque est élevé
Dans un flux SSO/OAuth, l'utilisateur s'authentifie et le fournisseur le renvoie vers votre callback, qui le redirige ensuite plus loin. Si cette cible de redirection est contrôlée par l'attaquant (parce que le paramètre de redirection n'est pas validé), deux choses néfastes se produisent :
- Phishing avec un domaine réel et de confiance. Le lien malveillant part de votre URL de connexion légitime, il passe donc le contrôle « est-ce le vrai site ? » de l'utilisateur, puis le renvoie vers la page de l'attaquant pour récolter identifiants ou consentement.
- Vol de jeton/code. Si le code d'autorisation ou le jeton transite par la redirection (dans l'URL ou via une fuite par Referer/fragment), le domaine de l'attaquant le reçoit et peut l'échanger ou le rejouer pour détourner le compte.
La bonne correction
Allow-listez strictement les redirect URI côté serveur, en comparant à un ensemble exact et préenregistré de valeurs — pas un préfixe, une sous-chaîne ni un contrôle « même domaine », que les attaquants contournent tous (https://votresite.com.evil.com, //evil.com, astuces de chemin). Rejetez tout ce qui n'est pas dans la liste. Combinez ceci avec le paramètre OAuth state (protection CSRF) et PKCE pour durcir le flux de bout en bout.
Pourquoi les autres réponses sont fausses
- « Purement cosmétique » et « connexions légèrement plus lentes » sous-estiment gravement la gravité — la faille peut divulguer le jeton même qui est la session de l'utilisateur.
- « Aucun risque tant que le site utilise HTTPS » méprend la menace : HTTPS protège la connexion, mais l'attaquant héberge simplement sa page d'atterrissage sur son propre site HTTPS valide. Le chiffrement du transport ne fait rien pour empêcher une redirection vers une destination malveillante.
L'examinateur cherche à voir si vous reconnaissez qu'une redirection ouverte sur un chemin d'authentification est une primitive de vol d'identifiants, et si vous optez pour une allow-list à correspondance exacte plutôt qu'un filtre astucieux mais contournable.
Questions de suivi probables
- Comment une redirection ouverte sur un redirect_uri OAuth se transforme-t-elle en vol de code d'autorisation ?
- Pourquoi une allow-list à correspondance exacte est-elle plus sûre qu'une correspondance par préfixe ou par domaine ?
- Quel rôle jouent le paramètre state et PKCE aux côtés de la validation du redirect_uri ?