Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Open Redirect

hacking

Définition

Une vulnérabilité de redirection ouverte (Open Redirect) se produit quand une application web utilise des paramètres URL contrôlables par l'utilisateur pour effectuer une redirection vers une URL externe, sans valider que la destination est une URL sûre ou appartenant au domaine autorisé. Cette vulnérabilité est souvent utilisée comme composant dans des attaques de phishing, d'OAuth abuse, ou de bypass de contrôles de sécurité. Les redirections ouvertes sont fréquentes dans les fonctionnalités de 'returnUrl', 'redirect', 'next', 'goto', 'redir' dans les applications web — par exemple, après un login : /login?returnUrl=/dashboard redirige vers /dashboard après authentification. Si l'application redirige vers n'importe quelle URL (pas seulement des chemins relatifs du même domaine), un attaquant peut utiliser /login?returnUrl=https://evil.com pour rediriger les victimes vers un site de phishing après avoir cliqué sur un lien depuis le domaine légitime. Les techniques de bypass de validation incluent : utiliser des variantes d'encodage URL (%2F%2Fevil.com peut être traité comme //evil.com — une URL relative de protocole), des protocoles alternatifs (data:, javascript: pour XSS via open redirect), des techniques de parsing confuses (/login?url=https://legitimate.com@evil.com — certains parseurs considèrent legitimate.com comme le username), et l'utilisation de caractères spéciaux contournant des filtres basiques. Dans des chaînes d'attaque, les open redirects facilitent : le bypass de filtres OAuth (forcer une redirection OAuth vers evil.com pour voler le code d'autorisation si le paramètre redirect_uri est basé sur un open redirect), la crédibilisation du phishing (envoyer un lien depuis le domaine légitime qui redirige vers le phishing), et dans certains cas, le bypass de contrôles de sécurité basés sur le domaine référent.

Fonctionnement

Test basique : curl -I 'https://target.com/login?returnUrl=https://evil.com' — si la réponse est 302 avec Location: https://evil.com, c'est un open redirect. Bypass de filtres : ?redirect=//evil.com, ?next=/%09/evil.com, ?url=https://target.com.evil.com, ?redir=https://evil%E3%80%82com (point Unicode). OAuth abuse : https://provider.com/oauth/authorize?client_id=APP&redirect_uri=https://target.com/login%3FreturnUrl%3Dhttps%3A%2F%2Fevil.com — si target.com/login redirige vers evil.com et que l'état OAuth est dans l'URL, le token OAuth peut être volé.

Exploitation offensive

Les open redirects sont classés 'Low' ou 'Informational' dans les bug bounties quand utilisés seuls, mais leur valeur augmente en chaînage : un open redirect + SSRF = SSRF depuis le domaine légitime ; un open redirect + OAuth = token theft ; un open redirect dans un email de phishing = clic sur un domaine légitime qui redirige vers le phishing.

Détection et mitigation

Valider les URLs de redirection en whitelist (uniquement des chemins relatifs du domaine courant, ou une liste fixe de domaines autorisés). Utiliser des identifiants de redirection (stocker l'URL en serveur et passer uniquement un token numérique dans l'URL cliente). Les WAFs avec règles open redirect détectent les patterns les plus courants mais pas les bypass avancés.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis