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#
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