Redirections ouvertes : valider la cible vers laquelle un paramètre next peut rediriger la personne utilisatrice

Ce que c'est

Les pages de connexion, les gestionnaires de déconnexion, les sélecteurs de langue et les rappels OAuth (callbacks) acceptent couramment un paramètre next, returnUrl ou redirect et y envoient ensuite le navigateur. Utilisé sans vérification, https://example.org/login?next=https://evil.example/ est un lien situé sur le domaine légitime mais qui aboutit sur la page de l'attaquant ; l'aide-mémoire OWASP note que, le nom de serveur figurant dans le lien étant celui de confiance, la tentative de hameçonnage paraît plus crédible. L'aide-mémoire couvre également les « forwards » : une redirection interne côté serveur vers un chemin extrait de la requête peut contourner le contrôle d'accès.

Pourquoi c'est important

Les redirections ouvertes ont, seules, une utilité limitée, mais elles servent de brique de base : elles prêtent la réputation du domaine légitime à des courriers de hameçonnage, la RFC 9700 décrit comment un redirecteur ouvert présent chez un client peut servir à faire fuiter des codes d'autorisation et des jetons, et elles mettent en échec les règles « liens vers notre domaine uniquement » des filtres de messagerie et des politiques de contenu.

Comment l'appliquer

• Privilégier l'absence de destination fournie par la requête : conserver l'emplacement de retour prévu dans la session, ou associer côté serveur un court identifiant à une URL (premières recommandations de l'aide-mémoire), en restant attentif à l'énumération des identifiants.
• Si une URL doit être acceptée, utiliser une liste d'autorisation, que l'aide-mémoire préfère à une liste d'exclusion : n'accepter que les chemins relatifs commençant par un seul / (rejeter //host, /\host et tout ce qui contient un schéma), ou l'analyser et comparer le schéma et l'hôte à une liste explicite d'origines autorisées.
• Analyser avec l'analyseur d'URL de la plateforme, puis valider les composants obtenus. La documentation Python indique que urlsplit() et urlparse() ne valident pas leur entrée, peuvent renvoyer des composants vides plutôt que de lever une exception, et que tout code ayant des implications de sécurité doit vérifier que le schéma, l'hôte et le chemin ont un sens avant de leur faire confiance.
• Normaliser avant de comparer : décoder l'encodage pourcentage une seule fois, mettre l'hôte en minuscules, retirer les espaces et les caractères de contrôle, rejeter les formes avec userinfo (user@host).
• Dans les flux OAuth, comparer redirect_uri aux valeurs enregistrées par correspondance exacte, et non par préfixe ou par motif : la RFC 9700 recommande une correspondance exacte des URI de redirection et précise que les serveurs web hébergeant des URI de redirection ne doivent pas exposer de redirecteurs ouverts.
• Conserver une liste de test des formes de contournement (//evil.example, https:evil.example, /\evil.example, https://example.org.evil.example, https://example.org@evil.example) et vérifier que chacune est rejetée.

Pièges

Vérifier avec startswith("https://example.org"), qui correspond aussi à https://example.org.evil.example. Valider avant de décoder puis rediriger après. Autoriser n'importe quel sous-domaine alors qu'un sous-domaine héberge du contenu utilisateur. L'analyseur de la validation et celui du navigateur peuvent diverger : la documentation Python note que ses fonctions reprennent des aspects à la fois du WHATWG URL Standard et de la RFC 3986 sans être conformes à l'un ni à l'autre ; il faut donc tester ce que fait le navigateur avec la valeur acceptée, pas seulement ce que le serveur croit qu'elle signifie.