Une redirection ouverte est une vulnérabilité où une application web prend une URL de destination à partir d'une entrée utilisateur non validée - généralement un paramètre de requête comme ?next= ou ?url= - et y transmet le navigateur sans la vérifier. Le lien part d'un domaine auquel la victime fait confiance, donc il passe l'inspection, puis l'emmène discrètement ailleurs. Le correctif n'est pas d'arrêter de rediriger. C'est d'arrêter de laisser la requête décider où va la redirection.
Cette distinction compte parce que les redirections sont partout et la plupart sont parfaitement correctes. Se connecter et rebondir vers la page que vous vouliez, passer la main à un fournisseur de paiement, un rappel OAuth - tout cela est normal, tout cela est des redirections. La faille, cataloguée sous CWE-601 et regroupée sous le contrôle d'accès défaillant dans le Top 10 de l'OWASP, est spécifiquement le cas où la cible provient d'une entrée contrôlée par l'utilisateur et que rien ne la valide d'abord. Un attaquant fournit sa propre URL, le site de confiance y transmet, et la confiance se transfère avec le clic.
Je passe mes journées sur le chemin de redirection, donc c'est un sujet sur lequel j'ai des opinions. Les liens courts sont des redirections par définition, ce qui fait de "un raccourcisseur n'est-il qu'une redirection ouverte ?" une question juste - et la réponse, bien faite, est un non net. Nous y arrivons plus bas. Si les mécanismes de redirection sont nouveaux pour vous, les types de redirections sont l'introduction, et comment fonctionnent les raccourcisseurs d'URL couvre les bases du niveau redirection.
Ce qu'est réellement une redirection ouverte
Réduisez-la au mécanisme. Une page accepte un paramètre nommant où aller ensuite, et l'utilise dans une redirection HTTP sans confirmer qu'il pointe vers un endroit autorisé.
https://trusted.example/login?next=https://evil.example/fake-login
La victime voit trusted.example en tête et clique. Après la connexion, l'application lit next et émet une redirection vers evil.example. Le navigateur obéit, car une redirection n'est qu'un en-tête Location et un statut 3xx - la spécification HTTP définit ce comportement clairement et le navigateur n'a aucun moyen de savoir que cette cible particulière est hostile. L'utilisateur, regardant la barre d'adresse changer après avoir déjà fait confiance au lien, ne le remarque souvent pas.
L'OWASP décrit le danger central sans détour : le nom de serveur dans le lien modifié est identique au site original, ce qui prête de la crédibilité à une redirection malveillante. La vulnérabilité n'est pas que le site redirige. C'est qu'une personne extérieure a choisi la destination.
Pourquoi une redirection "inoffensive" est une menace réelle
Le réflexe est de hausser les épaules : alors elle envoie quelqu'un vers un autre site web, où est le mal. Le mal est la confiance empruntée, et elle passe à l'échelle.
Le phishing est l'usage phare. Un lien qui commence par une banque, une connexion SaaS ou un portail gouvernemental passe le rapide contrôle visuel que font la plupart des gens, et passe un nombre surprenant de filtres automatisés qui n'inspectent que le domaine de tête. La victime arrive sur une fausse page de connexion au pixel près de celle qu'elle attendait, sur un domaine qui semblait correct un saut plus tôt, et tape son mot de passe. Pas de logiciel malveillant, pas de charge utile exotique - juste une redirection et un clone.
Cela empire quand les redirections se trouvent près de l'authentification. Une redirection ouverte dans un flux OAuth peut divulguer un code d'autorisation ou un jeton vers un redirect_uri contrôlé par l'attaquant, ce qui fait passer une faille "mineure" à une prise de contrôle complète du compte. C'est pourquoi les redirections ouvertes sont un classique des rapports de bug bounty plutôt qu'une note de bas de page. La même astuce blanchit aussi la réputation : les spammeurs et les opérateurs de logiciels malveillants adorent rebondir à travers un domaine de confiance car cela fait passer leur vrai lien au-delà des listes de blocage. Nous couvrons la catégorie plus large dans la checklist de sécurité des raccourcisseurs d'URL, et l'angle de la confiance du côté du visiteur dans les raccourcisseurs d'URL sont-ils sûrs.
Comment prévenir les redirections ouvertes
Il existe une hiérarchie de correctifs, et le sommet est celui qui met réellement fin au problème. L'antisèche de l'OWASP les classe, et l'ordre vaut la peine d'être suivi.
- Ne prenez pas d'URL de la requête du tout. Faites en sorte que le client envoie un nom court, un ID ou un jeton, et résolvez-le en destination complète côté serveur. L'OWASP appelle cela le plus haut degré de protection, car la requête entrante ne peut plus nommer une cible arbitraire. Si ce schéma vous semble familier, c'est normal : c'est ainsi que fonctionne un raccourcisseur d'URL.
- Liste d'autorisation, pas de liste de blocage. Quand vous devez accepter une destination, vérifiez-la contre une liste d'hôtes de confiance ou une regex stricte. La liste d'autorisation échoue en mode fermé - tout ce qui n'est pas explicitement permis est rejeté. La liste de blocage échoue en mode ouvert, et les attaquants sont payés pour trouver les entrées que vous avez oubliées.
- Analysez strictement. Rejetez les URL relatives au protocole (
//evil.example), normalisez les barres obliques inversées, décodez avant de valider, et traitez l'hôte - pas seulement le préfixe de la chaîne - comme l'élément à vérifier. La plupart des contournements de filtre vivent dans une analyse paresseuse. - Affichez une page intermédiaire comme filet de sécurité. Si une redirection vers un site externe est inévitable, faites-la passer par une page qui nomme la destination et demande à l'utilisateur de confirmer. C'est de la friction, mais cela convertit une redirection silencieuse en une redirection éclairée.
Le thème récurrent est que les redirections sûres sont décidées par le serveur, à partir de données auxquelles le serveur fait déjà confiance - jamais par la chaîne arrivée dans la requête.
Si vous intégrez des redirections dans un produit et préféreriez ne pas posséder ce mode de défaillance, la plateforme développeur d'Elido fait correspondre les codes aux destinations côté serveur par conception - commencez avec le démarrage rapide de l'API et ne codez plus jamais un paramètre ?url= à la main.
Pourquoi les liens courts sont la défense, pas la faille
Voici la partie qui surprend les gens. Un raccourcisseur d'URL correctement construit est l'implémentation manuelle du correctif numéro un de l'OWASP contre les redirections ouvertes.
Quand un lien court est créé, sa destination est validée et stockée côté serveur, liée à un code court. Quand quelqu'un le visite, le niveau de redirection recherche ce code et transmet vers la cible stockée. La destination ne provient jamais de la requête entrante - le visiteur ne peut pas ajouter un ?url= et détourner le lien ailleurs, car il n'existe aucun paramètre de ce genre à détourner. C'est exactement la correspondance jeton-vers-URL que l'OWASP recommande, fonctionnant en production des millions de fois par jour. Architecturalement, cela vit dans notre niveau de redirection edge, et le budget de latence que cela paie fait l'objet de atteindre un p95 sous 15 ms pour les redirections.
La mise en garde honnête : un raccourcisseur peut quand même être abusé, simplement pas via une redirection ouverte. Si une plateforme laisse n'importe qui créer des liens vers n'importe quoi sans analyse ni modération, les attaquants utiliseront sa réputation de domaine pour masquer leurs propres destinations malveillantes - c'est pourquoi les raccourcisseurs responsables analysent les cibles et appliquent des politiques anti-abus. C'est un problème de modération de contenu, distinct de la faille de validation d'entrée dont parle cet article, et qu'il vaut mieux ne pas confondre. La pratique connexe consistant à cacher délibérément une destination est couverte dans le link cloaking et le masquage d'URL expliqués, et le cousin de tout ceci en ingénierie sociale - les QR codes hostiles - dans les QR codes sont-ils sûrs.
La conclusion en une ligne
Si votre code lit une destination dans la requête et y redirige, vous avez une redirection ouverte qui n'attend que d'être trouvée. Faites plutôt correspondre un ID à une cible côté serveur, mettez en liste d'autorisation tout ce que vous ne pouvez éviter de prendre de l'entrée, et analysez comme si vous vous attendiez à être attaqué. Les redirections ne sont pas le risque. Laisser la requête choisir où elles vont l'est. La différence entre un 301 et un 302 dans 301 ou 302 redirections est une note de bas de page à côté de cette seule règle.
À lire aussi sur le blog
Questions fréquentes
Qu'est-ce qu'une vulnérabilité de redirection ouverte ?
Une redirection ouverte est une faille où une application web envoie les utilisateurs vers une URL de destination tirée d'une entrée non validée, généralement un paramètre de requête comme ?next= ou ?url=. Comme le lien part d'un domaine de confiance, le navigateur de la victime et tout filtre d'analyse de liens le traitent comme sûr, mais l'application les transmet ensuite vers le site que le paramètre nomme - y compris celui d'un attaquant. Elle est classée CWE-601 et relève du contrôle d'accès défaillant dans le Top 10 de l'OWASP. La faille est le contrôle manquant, pas la redirection elle-même.
Pourquoi les redirections ouvertes sont-elles dangereuses si elles vous envoient seulement vers un autre site ?
Parce que le danger est la confiance que prête le domaine de départ. Un lien de phishing qui se lit https://trusted-bank.example/login?next=evil.example passe le test visuel, survit à de nombreux filtres d'e-mail et amène la victime sur une fausse page de connexion convaincante - tout en semblant provenir de la vraie banque. Les redirections ouvertes s'enchaînent aussi dans des attaques plus importantes : elles peuvent divulguer des codes d'autorisation OAuth ou des jetons quand la cible de redirection est contrôlée par l'attaquant, transformant une faille de faible gravité en prise de contrôle de compte. La redirection est le mécanisme de livraison, pas l'exploit entier.
Les raccourcisseurs d'URL sont-ils une vulnérabilité de redirection ouverte ?
Non, pas quand ils sont bien construits - et la distinction est tout l'enjeu. Une redirection ouverte prend une destination arbitraire d'une entrée utilisateur au moment de la requête et y transmet sans validation. Un lien court fait correspondre un code fixe à une destination qui a été définie et stockée côté serveur lors de la création du lien ; la cible de redirection ne provient jamais de la requête entrante. Cette correspondance côté serveur est exactement la défense que l'OWASP recommande contre les redirections ouvertes. Un raccourcisseur ne devient un problème que s'il permet à des utilisateurs non audités de créer des liens vers n'importe quoi et leur prête une réputation de domaine qu'ils peuvent abuser - ce qui est un problème d'abus et de modération, pas une faille de redirection ouverte.
Comment prévenir les vulnérabilités de redirection ouverte ?
Le correctif le plus solide consiste à ne jamais accepter d'URL de destination provenant de la requête. Faites en sorte que le client envoie un nom court, un ID ou un jeton, et faites-le correspondre à la cible complète côté serveur - le même modèle qu'utilise un raccourcisseur d'URL. Quand vous devez véritablement accepter une URL, validez-la contre une liste d'autorisation d'hôtes de confiance plutôt qu'une liste de blocage de mauvais hôtes, rejetez tout ce qui n'est pas un chemin relatif ou un domaine approuvé, et soyez strict sur l'analyse pour que des astuces comme //evil.example ou les barres obliques inversées ne passent pas. En dernier recours, faites passer la redirection par une page intermédiaire qui affiche la destination avant d'envoyer l'utilisateur plus loin.
Comment les attaquants exploitent-ils une redirection ouverte ?
Ils trouvent un point de terminaison qui reflète un paramètre d'URL dans une redirection, puis fabriquent un lien sur le domaine de confiance avec leur propre site dans ce paramètre et le distribuent par e-mail, publicité ou message. Les variations incluent l'encodage URL de la charge utile pour contourner les filtres faibles, l'utilisation d'URL relatives au protocole comme //attacker.example, l'exploitation de la seule partie hôte tout en gardant un chemin d'apparence légitime, et l'abus du traitement du redirect_uri OAuth pour capturer des jetons. Le fil conducteur est que la victime voit et fait confiance au premier domaine et ne voit jamais le second avant qu'il ne soit trop tard.
Une redirection ouverte est-elle une vulnérabilité de gravité élevée ou faible ?
À elle seule, une redirection ouverte est souvent classée de faible à moyenne, car elle ne compromet pas directement le serveur - elle envoie les utilisateurs ailleurs. Mais la gravité dépend de ce dans quoi elle s'enchaîne. Près d'un flux d'authentification, elle peut divulguer des jetons OAuth et mener à une prise de contrôle de compte, ce qui est de gravité élevée ; en tant qu'aide au phishing, elle peut provoquer une perte d'identifiants réelle qu'un score CVSS ne capture pas. Traitez-la par son impact dans son contexte, pas par l'étiquette de base, et corrigez-la quoi qu'il arrive : la remédiation est peu coûteuse et le potentiel d'abus ne l'est pas.
Essayer Elido
Collez une URL, obtenez un lien court
Sans inscription. Lien actif 30 jours. Inscrivez-vous pour le garder pour toujours.
Gratuit, sans inscription · 2 par jour