OAuth mal tourné : quand "Se connecter avec Google" ouvre une boîte de Pandore 🔑

Nous avons tous cliqué sur ce bouton pratique “Se connecter avec Google” — c’est plus rapide que de créer un mot de passe supplémentaire, et cela semble plus sûr que de taper des identifiants sur un site inconnu. Mais derrière ce bouton inoffensif se cache une danse d’authentification complexe qui, si elle est mal orchestrée, devient un tapis rouge pour les attaquants pour s’introduire directement dans les comptes utilisateurs.

OAuth 2.0 est devenu la colonne vertébrale de l’authentification web moderne, alimentant des milliards de connexions à travers Internet. Pourtant, la popularité d’OAuth2 en fait une cible privilégiée pour les attaquants, et sa complexité peut conduire à des mauvaises configurations créant des failles de sécurité. L’adoption généralisée du protocole signifie que ces vulnérabilités ne touchent pas seulement des sites individuels — elles peuvent se propager à travers des écosystèmes entiers de services interconnectés.

La tempête parfaite : pourquoi les vulnérabilités OAuth comptent plus que jamais

Le paysage de la cybersécurité a connu un changement radical dans la façon dont les attaquants ciblent les systèmes basés sur OAuth. En 2024-2025, des groupes comme ShinyHunters ont exploité systématiquement des vulnérabilités dans la concession d’autorisation des appareils OAuth pour compromettre certaines des plus grandes entreprises mondiales, affectant des millions de données clients.

Ce qui rend ces attaques particulièrement insidieuses, c’est qu’elles ne nécessitent pas d’exploiter des vulnérabilités logicielles traditionnelles. Elles ciblent plutôt les relations de confiance et les processus de décision humaine sur lesquels OAuth repose. Les attaques OAuth réussissent en passant par la porte d’entrée avec des identifiants valides et un accès autorisé — pas de portes dérobées, pas de force brute, juste l’exploitation de défauts d’implémentation et d’ingénierie sociale.

Le paramètre d’état manquant : votre première ligne de défense (que personne n’utilise)

L’une des erreurs d’implémentation OAuth les plus courantes et dangereuses est l’omission ou la validation incorrecte du paramètre state. Ce paramètre apparemment anodin sert de première défense contre les attaques de type Cross-Site Request Forgery (CSRF) dans les flux OAuth.

Comment le paramètre d’état doit fonctionner

La principale raison d’utiliser le paramètre state est de réduire les risques d’attaques CSRF en utilisant une valeur unique et imprévisible associée à chaque demande d’authentification. Le mécanisme est simple : votre application génère une valeur aléatoire et imprévisible avant de rediriger les utilisateurs vers le fournisseur OAuth, la stocke en toute sécurité (dans une session ou un cookie), puis vérifie que la même valeur revient avec la réponse d’autorisation.

Lorsqu’il est correctement implémenté, le paramètre state garantit que la réponse OAuth que votre application reçoit correspond réellement à une demande que vous avez initiée. Sans cette protection, les attaquants peuvent initier leur propre flux OAuth, capturer le code ou le jeton d’autorisation, puis tromper la victime pour qu’elle complète le processus — liant ainsi le compte tiers de l’attaquant au compte de l’application de la victime.

Le scénario d’attaque

Un attaquant commence le flux OAuth avec un serveur d’autorisation cible pour obtenir un code d’autorisation, mais interrompt le processus après avoir obtenu le code, puis configure un site malveillant contenant une iframe pointant vers l’URL de rappel du client OAuth avec le code d’autorisation de l’attaquant. Lorsqu’une victime visite ce site malveillant, son navigateur effectue automatiquement une requête à l’URL de rappel du client OAuth avec le code de l’attaquant. Le client OAuth consomme alors à tort le code d’autorisation de l’attaquant, croyant qu’il provient d’un flux OAuth légitime initié par la victime.

Le résultat ? La victime lie à son insu son compte aux identifiants tiers de l’attaquant. Selon l’application, cela peut signifier que des données sensibles — informations bancaires, dossiers médicaux ou communications personnelles — sont enregistrées dans des ressources contrôlées par l’attaquant.

Pourquoi les développeurs l’ignorent

Puisque le paramètre state n’est pas requis pour un flux OAuth2 réussi, il est très fréquent que ce paramètre soit omis ou ignoré lors de l’implémentation OAuth2. Les développeurs testant les flux OAuth constatent souvent que tout “fonctionne” sans le paramètre state, ce qui les conduit à déployer un code de production avec cette vulnérabilité critique. La surface d’attaque n’est pas immédiatement évidente lors du développement, et l’absence du paramètre state ne génère pas d’erreurs ou d’avertissements.

Validation de l’URI de redirection : la boîte de Pandore d’OAuth

Le paramètre redirect_uri indique au fournisseur OAuth où envoyer les utilisateurs après l’authentification, avec le code d’autorisation ou le jeton d’accès précieux. Lorsque ce paramètre n’est pas correctement validé, il devient une voie pour voler des jetons et prendre le contrôle de comptes.

Techniques de contournement courantes

Certaines implémentations permettent une gamme de sous-répertoires en vérifiant uniquement que la chaîne commence par la séquence correcte de caractères — un domaine approuvé. Les attaquants exploitent cela en testant diverses modifications : suppression ou ajout de chemins arbitraires, ajout de paramètres de requête ou manipulation de fragments pour contourner la validation tout en redirigeant vers des domaines contrôlés par l’attaquant.

L’utilisation d’un redirecteur comme une page de déconnexion d’un domaine légitime contenant un paramètre continue peut permettre aux attaquants de diriger le flux OAuth vers leurs propres serveurs. Ces vulnérabilités de redirection ouverte sur des domaines de confiance deviennent des points de lancement pour le vol de jetons OAuth.

Conséquences réelles

Des chercheurs de Salt Labs ont découvert des failles critiques dans l’implémentation OAuth de Booking.com, centrées sur une gestion incorrecte de l’URI de redirection, permettant à des acteurs malveillants d’envoyer des utilisateurs vers des domaines contrôlés par eux. La vulnérabilité fonctionnait à travers une chaîne de défaillances interconnectées, montrant comment un seul maillon faible dans la validation de redirection peut compromettre tout un système d’authentification.

Le cas du vol de jetons OAuth via redirect_uri est typique, où le serveur d’autorisation effectue une validation insuffisante et les attaquants contournent la validation avec des liens malveillants qu’ils contrôlent. Une fois qu’un attaquant capture le code d’autorisation, il peut l’échanger contre un jeton d’accès au point de rappel légitime et obtenir un accès complet au compte de la victime.

La vulnérabilité OAuth de Google : quand les domaines changent de mains

Peut-être aucune vulnérabilité OAuth récente n’illustre mieux les risques inhérents au protocole que la faille de propriété de domaine découverte dans la fonction “Se connecter avec Google”. Cette vulnérabilité montre comment même les géants de la tech peuvent avoir du mal avec les subtilités d’OAuth.

Le vecteur d’attaque

La connexion OAuth de Google ne protège pas contre l’achat d’un domaine d’une startup en faillite et son utilisation pour recréer des comptes email pour d’anciens employés. L’attaque est simple mais dévastatrice : lorsqu’une startup échoue et laisse expirer son domaine, n’importe qui peut l’acheter et créer de nouveaux comptes email correspondant à d’anciens employés. Parce qu’OAuth de Google utilise des adresses email et des domaines hébergés pour identifier les utilisateurs, ces comptes recréés peuvent se connecter à tout service où l’ancien employé utilisait “Se connecter avec Google”.

Les comptes les plus sensibles incluent des systèmes RH contenant des documents fiscaux, des fiches de paie, des informations d’assurance et des numéros de sécurité sociale. Les plateformes d’entretien contenaient également des informations sensibles sur les retours de candidats, les offres et les rejets.

Pourquoi cela reste un problème

Google a initialement répondu que ce comportement était “conforme à ce qui était prévu” et a fermé le rapport de vulnérabilité, mais trois mois plus tard, ils ont rouvert le dossier, payé une prime de 1 337 $, et indiqué qu’ils travaillaient à une correction. Cependant, selon les derniers rapports, aucune correction n’a été mise en œuvre.

Bien que le jeton d’identification OAuth de Google inclue un identifiant utilisateur unique — la revendication sub — qui pourrait théoriquement prévenir ce problème, il a été jugé peu fiable. La question fondamentale est que sans identifiants immuables pour les utilisateurs et les espaces de travail, la propriété du domaine continuera à compromettre les comptes.

Validation des jetons : le raccourci qui coûte cher

Même lorsque les flux OAuth sont correctement implémentés, les jetons qu’ils produisent peuvent devenir des vecteurs d’attaque s’ils ne sont pas correctement validés. La validation des jetons d’accès est l’endroit où de nombreux développeurs prennent des raccourcis dangereux.

L’attaque de rétrogradation du flux implicite

Si l’application utilise les jetons d’accès comme cookies de session ou en-têtes d’autorisation, elle pourrait être vulnérable à des attaques où des attaquants fournissent des jetons d’accès victimes générés pour un autre Client ID et prennent le contrôle des comptes.

Le scénario d’attaque est simple : un attaquant crée un site public permettant aux utilisateurs de se connecter avec le flux implicite OAuth de Google. Lors de la connexion, l’attaquant collecte leurs jetons d’accès OAuth générés pour son application. Si certains de ces utilisateurs ont des comptes sur un site vulnérable qui ne vérifie pas l’ID client du jeton d’accès, l’attaquant peut fournir le jeton de la victime et prendre le contrôle de son compte.

Même si le Client utilise un flux plus sécurisé comme le Flux de Code d’Autorisation, il pourrait accepter des jetons d’accès — permettant en pratique une rétrogradation vers le flux implicite. Cela signifie que la mise en œuvre du “bon” flux OAuth ne garantit pas la sécurité si la validation des jetons est faible.

Les étapes de vérification manquantes

Une validation correcte des jetons nécessite de vérifier plusieurs revendications : l’audience du jeton (pour quelle application il a été émis), son émetteur (le fournisseur OAuth qui l’a créé), sa date d’expiration, et sa signature cryptographique. En pratique, s’assurer que les jetons d’accès ne sont jamais acceptés à partir de paramètres contrôlés par l’utilisateur évite de briser la chaîne d’exploitation dès le départ.

De nombreux développeurs supposent qu’un jeton valide reçu d’un fournisseur OAuth est sûr à utiliser. Cette supposition ignore la possibilité que le jeton ait été émis pour une autre application, qu’il soit expiré ou qu’il ait été volé dans un autre contexte.

La vulnérabilité de la plateforme d’intégration OAuth

Une nouvelle catégorie de vulnérabilités OAuth a émergé des plateformes d’intégration API unifiées — des services qui simplifient la connexion de plusieurs applications via une interface unique. Ces plateformes, tout en étant précieuses pour accélérer le développement, introduisent de nouvelles surfaces d’attaque.

CSRF dans les plateformes d’intégration

Une faille importante dans la mise en œuvre OAuth 2.0 sur plusieurs plateformes d’intégration API unifiées permet aux acteurs malveillants d’usurper ces applications OAuth vérifiées, leur permettant de mener des attaques de phishing de consentement OAuth. Le risque provient d’une protection CSRF inadéquate dans ces plateformes.

En plus d’une plateforme de démonstration, trois autres plateformes d’intégration API unifiées ont été trouvées vulnérables à la même faille, soulignant à quel point ces vulnérabilités d’intégration CSRF sont courantes et souvent négligées. Lorsqu’elles manquent d’une mise en œuvre correcte du paramètre state, les attaquants peuvent tromper les utilisateurs pour qu’ils autorisent l’accès à leurs comptes sans leur consentement.

L’avantage de l’application vérifiée

Ce qui rend cette vulnérabilité particulièrement dangereuse, c’est que ces plateformes d’intégration ont souvent des applications OAuth vérifiées avec la confiance des utilisateurs existante. En utilisant ces applications OAuth vérifiées, les attaquants peuvent gagner la confiance des utilisateurs finaux, augmentant le taux de réussite des tentatives de phishing. La coche bleue ou le badge “vérifié” censé signaler la sécurité devient une arme dans l’arsenal de l’attaquant.

La vulnérabilité du type de réponse ouvert

En juillet 2024, des chercheurs en sécurité ont découvert une nouvelle classe de vulnérabilités OAuth exploitant la gestion des différents types de réponse OAuth combinée à des vulnérabilités de type cross-site scripting (XSS).

Le mécanisme d’attaque

La vulnérabilité du type de réponse ouvert permet à un attaquant de tromper le site web pour obtenir des codes d’autorisation via l’URL plutôt que par une transmission sécurisée. Le danger se manifeste lorsque le site possède également une vulnérabilité XSS permettant à l’attaquant d’injecter du JavaScript malveillant dans la page web pour lire l’URL, y compris le code secret utilisé pour créer des jetons d’accès.

Si l’application ne traite pas le code depuis le fragment et le laisse dans l’URL, l’attaquant dispose d’un moyen fiable de l’extraire via une attaque XSS et de l’utiliser pour demander un jeton d’accès. Cette vulnérabilité montre à quel point la sécurité OAuth dépend souvent d’une chaîne d’implémentations correctes — briser un maillon, et tout le système s’effondre.

La vague d’attaques du flux device

Le flux d’autorisation de dispositif OAuth, conçu pour les appareils sans navigateur (comme les téléviseurs intelligents ou les appareils IoT), est devenu une cible privilégiée tout au long de 2024-2025. Des groupes comme ShinyHunters ont mené des campagnes systématiques ciblant des industries spécifiques et des organisations à haute valeur, en se concentrant sur des entreprises disposant de bases de données clients précieuses.

Ingénierie sociale à grande échelle

Le groupe a rapidement adapté ses applications OAuth pour imiter des outils commerciaux légitimes, en utilisant des titres comme “Data Loader”, “My Ticket Portal” et “Security Compliance Tool” pour augmenter leur crédibilité lors des appels d’ingénierie sociale. Cette sophistication opérationnelle leur a permis de maintenir un accès persistant à des environnements compromis pendant des mois, en extrayant soigneusement des données avant de commencer des activités d’extorsion.

Les attaques par flux device ont réussi non par exploitation technique, mais par manipulation de l’élément humain de l’autorisation. Les employés du support technique, formés pour aider les utilisateurs avec des problèmes d’accès, sont devenus involontairement complices en accordant aux attaquants les jetons nécessaires pour compromettre des organisations entières.

Stratégies de prévention : construire OAuth correctement

Comprendre ces vulnérabilités n’a de sens que si l’on sait comment les prévenir. Voici les mesures défensives essentielles pour chaque implémentation OAuth :

Toujours implémenter les paramètres state

Générez une valeur state aléatoire cryptographiquement pour chaque flux OAuth, stockez-la en toute sécurité dans la session de l’utilisateur, et vérifiez qu’elle correspond à la valeur renvoyée. Le paramètre state doit être unique et opaque pour servir de défense contre CSRF et le phishing. Ne sautez jamais cette étape, même en développement.

Validation stricte de l’URI de redirection

Implémentez une validation robuste de redirect_uri en faisant correspondre client_id et redirect_uri, et utilisez une liste blanche si le nombre d’applications clientes est gérable. La correspondance exacte est préférable à la correspondance par motif — évitez les jokers et ne faites jamais confiance à une validation “commence par” pour la sécurité.

Validation complète des jetons

Ne jamais accepter les jetons tels quels. Vérifiez que la revendication d’audience (aud) correspond à l’ID client de votre application, confirmez que l’émetteur (iss) est le fournisseur OAuth attendu, vérifiez les dates d’expiration, et validez la signature cryptographique. Stockez les jetons en toute sécurité côté serveur et client, et préparez des processus pour réagir si les jetons sont compromis.

Utiliser des identifiants immuables

Utilisez des identifiants immuables comme la revendication sub au lieu des adresses email, vérifiez la propriété de l’email avant de fusionner des comptes, et implémentez une vérification correcte des domaines. Les adresses email et domaines peuvent changer de propriété, mais les identifiants uniques correctement implémentés ne peuvent pas.

Défense en profondeur

Aucune mesure de sécurité unique ne suffit. Implémentez plusieurs couches : paramètres state ET validation de redirect_uri ET vérification des jetons ET gestion correcte des sessions. Filtrez et validez les entrées utilisateur en supprimant ou échappant les balises HTML et caractères spéciaux, et utilisez une politique de sécurité du contenu pour prévenir les scripts en ligne.

Audits de sécurité réguliers

Les implémentations OAuth nécessitent une surveillance continue. De nombreuses vulnérabilités OAuth concernent la logique et la sécurité web, comme les redirections ouvertes, une mauvaise utilisation du paramètre state, une validation incorrecte des redirect_uri, et une gestion non sécurisée des jetons. Des audits réguliers par des équipes familiarisées avec les vecteurs d’attaque spécifiques à OAuth peuvent identifier les problèmes avant qu’ils ne soient exploités.

L’avenir de la sécurité OAuth

L’avenir de la sécurité d’entreprise ne consiste pas à construire des murs plus hauts, mais à créer des relations de confiance plus intelligentes — des systèmes capables de distinguer entre demandes d’autorisation légitimes et malveillantes, qui peuvent s’adapter aux nouveaux modèles d’attaque, tout en maintenant l’efficacité opérationnelle et en protégeant contre l’ingénierie sociale sophistiquée.

Les organisations doivent reconnaître que la sécurité de l’identité n’est pas seulement une préoccupation informatique, mais une capacité commerciale essentielle. Les attaques OAuth de 2024-2025 nous ont montré que des adversaires sophistiqués continueront à trouver des moyens innovants d’exploiter la confiance. Nos défenses doivent évoluer en conséquence.

Conclusion : la commodité ne doit pas coûter la sécurité

Le bouton “Se connecter avec Google” représente une promesse magnifique : une authentification sans friction, à la fois pratique pour les utilisateurs et sécurisée pour les applications. Mais comme nous l’avons vu, l’écart entre cette promesse et la réalité est rempli de pièges d’implémentation qui peuvent transformer la commodité en catastrophe.

OAuth n’est pas intrinsèquement dangereux — mais il est intrinsèquement complexe. Cette complexité crée d’innombrables opportunités d’erreurs, et en sécurité, les erreurs se mesurent en comptes compromis, données volées, et confiance brisée. Chaque paramètre state manquant, chaque URI de redirection faiblement validé, et chaque jeton non vérifié est une porte d’entrée potentielle pour une prise de contrôle de compte.

La question n’est pas de savoir si OAuth est dangereux — mais si votre implémentation respecte la complexité du protocole et prend les précautions nécessaires. Ce bouton social pratique pourrait être votre fonctionnalité d’authentification la plus précieuse ou votre plus grande faille de sécurité. La différence dépend entièrement de la rigueur avec laquelle vous l’avez implémenté.

Dans un monde où des millions de comptes peuvent être compromis à cause d’un seul paramètre OAuth oublié, il n’y a pas de place pour les raccourcis. Le prix de la commodité, c’est une vigilance éternelle — et une mise en œuvre méticuleuse de chaque mesure de sécurité qu’OAuth offre.