Vulnérabilités OAuth et schémas d’attaque

Les serveurs d'autorisation OAuth doivent valider strictement le paramètre redirect_uri. Si le serveur autorise la correspondance par préfixe ou par caractère générique (par exemple, en acceptant toute URL commençant par "https://app.example.com"), un attaquant peut créer une requête d'autorisation redirigeant vers "https://app.example.com.attacker.com/steal" ou vers une redirection ouverte sur le domaine légitime, et ainsi voler le code d'autorisation.

Sans protection contre la CSRF, un attaquant peut lancer un flux OAuth et tromper le navigateur d'une victime pour qu'il termine l'autorisation. La victime autorise ainsi involontairement le client de l'attaquant. Le paramètre "state" (RFC 6749) empêche cela : le client génère un état aléatoire, l'inclut dans la requête et vérifie qu'il correspond dans la réponse de rappel. En cas de discordance, le flux est interrompu.

Sur les plateformes mobiles, des applications malveillantes peuvent enregistrer le même schéma d'URI personnalisé qu'un client OAuth légitime et intercepter les codes d'autorisation redirigés après l'authentification de l'utilisateur. PKCE constitue une défense complète : le code intercepté est inutilisable sans le vérificateur de code que seule l'application légitime a généré au début du flux.

Lorsqu'un jeton d'identité ou un jeton d'accès est inclus dans un fragment ou un paramètre de requête d'URL, les navigations ultérieures depuis cette page incluent l'URL dans l'en-tête Referer, ce qui peut faire fuir le jeton vers des scripts d'analyse tiers ou des fournisseurs de CDN. Utilisez toujours le flux de code d'autorisation avec transmission des jetons via le canal secondaire afin d'éviter que les jetons apparaissent dans les URL.

Lorsqu'un client prend en charge plusieurs fournisseurs OAuth, les attaques par confusion trompent le client pour qu'il envoie à l'endpoint de jetons du fournisseur B un code d'autorisation obtenu auprès du fournisseur A. Le client doit valider la revendication "iss" dans les jetons d'identité et lier la réponse de rappel au fournisseur précis qui a lancé le flux, au moyen du paramètre state ou de JARM (mode de réponse d'autorisation sécurisé par JWT).

Les attaques par falsification de requête côté serveur (SSRF) ciblent les implémentations OAuth qui effectuent des requêtes HTTP côté serveur vers redirect_uri. Si le serveur d'autorisation récupère redirect_uri pour le vérifier, un attaquant fournit une adresse IP interne (par exemple, http://169.254.169.254/latest/meta-data/) afin d'accéder aux métadonnées d'une instance cloud ou à des services internes. Une validation de redirect_uri fondée sur une liste d'autorisation stricte empêche cette attaque.

De nombreuses applications utilisent la revendication d'adresse e-mail d'un jeton d'identité OIDC pour associer des comptes entre plusieurs fournisseurs. Si un attaquant contrôle une adresse e-mail correspondant au compte d'une victime chez un autre fournisseur, il peut s'inscrire auprès d'un fournisseur différent avec cette adresse et accéder au compte de la victime. Défense : associez les comptes uniquement à l'aide de la paire (iss, sub), jamais de l'adresse e-mail seule.

Les attaques par confusion d'algorithme JWT exploitent les implémentations qui font confiance à l'en-tête "alg" pour sélectionner l'algorithme de vérification. Attaque : remplacez "alg" par "HS256" au lieu de "RS256" et signez le jeton avec la clé publique du serveur comme secret HMAC (puisque la clé publique est publique). Défense : spécifiez toujours explicitement l'algorithme attendu dans le code de vérification ; ne faites jamais confiance à la revendication alg de l'en-tête du jeton.

Les attaquants enregistrent des clients OAuth malveillants avec des noms et des logos d'apparence légitime, puis envoient des liens d'hameçonnage à leurs cibles. La victime voit un véritable écran de consentement OAuth (hébergé par Google, Microsoft, etc.) pour une application malveillante et lui accorde l'accès. Défense : vérifiez que client_id correspond à l'application attendue ; Google et Microsoft proposent des programmes de vérification des clients pour les applications légitimes.

Une élévation de portée se produit lorsqu'un client obtient des jetons dotés d'autorisations plus étendues que celles autorisées par l'utilisateur. Des défauts d'implémentation qui ignorent la validation de la portée sur le point de terminaison de jetons, mettent en cache des jetons dont les portées fusionnent celles de requêtes différentes ou ne vérifient pas que la portée du jeton émis ne dépasse pas la portée autorisée peuvent tous entraîner une élévation de privilèges via OAuth.

Défendez les implémentations OAuth en : utilisant une validation de redirect_uri par correspondance exacte, exigeant PKCE pour tous les clients publics, validant le paramètre state pour la protection contre la CSRF, liant les jetons d'identité à l'aide de (iss, sub) et non de l'adresse e-mail, spécifiant explicitement les algorithmes JWT attendus, demandant des portées minimales, utilisant des jetons d'accès à courte durée de vie avec rotation des jetons d'actualisation et vérifiant l'apparence de l'écran de consentement pour détecter les risques d'usurpation de marque.

Un serveur d'autorisation OAuth accepte tout redirect_uri qui commence par "https://app.example.com". Quelle attaque cela permet-il ?

Principales attaques OAuth : redirection ouverte due à une validation laxiste de redirect_uri (utilisez une correspondance exacte), CSRF due à l'absence du paramètre state, interception de code sur mobile (atténuée par PKCE), fuite de jetons dans les URL, confusion dans les configurations multi-fournisseurs (validez iss), SSRF via un redirect_uri récupéré par le serveur, collision de revendications d'adresse e-mail (utilisez iss+sub), confusion d'algorithme JWT (fixez l'algorithme attendu) et hameçonnage via de faux écrans de consentement.