La redirection à moitié vérifiée : voler un code OAuth
Le défi
Loomhaus vous authentifie via OAuth. Lorsqu'il construit le lien de connexion, il vérifie que le redirect_uri demandé appartient bien à l'application, et cette vérification consiste à contrôler que la valeur commence par l'adresse enregistrée https://app.loomhaus.example. Le serveur d'autorisation enverra le code à usage unique vers n'importe quel redirect_uri qui passe cette vérification. Une victime a déjà cliqué sur un lien que vous aviez préparé, et le endpoint de journalisation de l'attaquant a enregistré ce qui est arrivé. Forgez le redirect_uri qui passe la vérification mais livre le code à l'attaquant, puis lisez le code capturé.
Ce que tu vas apprendre
- Expliquer pourquoi les noms d'hôte se lisent de droite à gauche et pourquoi une correspondance de préfixe ne vérifie pas l'origine
- Construire un redirect_uri qui passe startsWith tout en pointant vers un hôte de l'attaquant
- Décrire comment un code d'autorisation divulgué mène à une prise de contrôle de compte
- Expliquer pourquoi les listes d'autorisation à correspondance exacte sont la seule validation sûre de redirect_uri
- Expliquer comment PKCE rend un code volé inutilisable
Compétences testées
Prérequis
- L'étape du code d'autorisation OAuth dans les grandes lignes
- La structure d'une URL
Comment ça marche
Dans le flux authorization-code, le serveur envoie un code à usage unique au redirect_uri demandé par le client. Valider cette URI fait donc toute la sécurité de l'étape. Si un attaquant parvient à faire livrer le code à un hôte qu'il contrôle, il peut terminer la connexion à la place de la victime.
Un contrôle du type commence-t-elle par notre adresse paraît raisonnable, et ne l'est pas. https://app.loomhaus.example est le préfixe littéral de https://app.loomhaus.example.evil-capture.example, où le vrai nom de l'application est devenu les libellés les plus à gauche d'un domaine enregistré par l'attaquant. Les noms d'hôte se comparent de droite à gauche : un test de chaîne ancré à gauche ignore totalement cela.
La seule validation fiable est une correspondance exacte avec des URI de redirection complètes, enregistrées à l'avance. startsWith, endsWith et contains échouent chacun face à un hôte de forme différente.
Erreurs fréquentes
- Utiliser un hôte d'attaquant nu.
https://evil-capture.example/cbne commence pas par l'adresse enregistrée, donc le contrôle le rejette. - Retirer le cookie de la victime. L'endpoint authorize n'émet un code que pour une session connectée, et la requête en porte déjà une.
- Répondre avec l'URL de redirection. Ce qu'il faut trouver, c'est la valeur de
codedans le journal de l'attaquant, pas l'emplacement. - Croire que le code est inoffensif. Sans liaison PKCE, celui qui détient le code peut l'échanger.
Comment s'en protéger
Validez exactement la cible de redirection, et liez le code au client.
- Comparez
redirect_urià une liste d'autorisation d'URI exactes et complètes, enregistrées pour le client. N'utilisez jamaisstartsWith,endsWithni de tests de sous-chaîne. - Exigez PKCE : le code ne peut être échangé que par la partie qui détient le verifier d'origine, donc un code volé est inutile.
- Limitez le périmètre et la durée de vie des codes, et déclenchez une alerte sur les requêtes authorize dont l'hôte de redirection n'est pas celui qui est enregistré.