Le dernière bug découvert par des chercheurs dans l’implémentation OAuth sur divers sites web permet aux utilisateurs de s'authentifier avec leurs identités à partir de services tiers comme Facebook ou Google. Or, certains sites ne parviennent pas à franchir une étape importante de la chaîne d'autorisation OAuth, qui consiste à valider l'application pour laquelle un jeton d'accès a été émis par le fournisseur d'identité. En exploitant cette faille, un attaquant pourrait collecter les jetons émis pour une app ou un site web leurre, créés de toute pièce, puis les utiliser pour accéder aux comptes des victimes sur des sites vulnérables à ce problème. Les chercheurs de l’entreprise de sécurité Salt Security en ont fait la démonstration sur trois sites web populaires : le service d'aide à la saisie Grammarly, le site de streaming vidéo indonésien Vidio et la plateforme de commerce électronique indonésienne Bukalapak.

Si ces entreprises ont été informées en privé et ont corrigé le problème, les chercheurs estiment que toutes les entreprises devraient vérifier leurs implémentations pour s'assurer qu'elles n'exposent pas leurs utilisateurs à des attaques similaires. « Ces trois sites nous suffisent pour prouver notre point de vue, et nous avons décidé de ne pas chercher d'autres cibles, mais nous pensons que des milliers d'autres sites web sont vulnérables à l'attaque que nous détaillons dans cet article et mettent en danger des milliards d'internautes supplémentaires chaque jour », ont déclaré les chercheurs de Salt Security dans leur rapport.

Les jetons d'accès liés aux apps émettrices de la requête

Très populaire sur le web, la norme d'autorisation et de pseudo-authentification OAuth sert pour un site web ou une application à demander à un fournisseur d'identité comme Google, Facebook, Apple ou Microsoft de vérifier qu'un utilisateur est bien celui qu'il prétend être. Cette méthode facilite le processus d'authentification pour les utilisateurs, car ils peuvent utiliser leurs identités Facebook, Google ou Microsoft, ce qui leur évite de créer et de retenir des mots de passe distincts pour différents sites. En réalité, OAuth ne se limite pas à l'authentification. Le mécanisme offre aux utilisateurs d'accorder à des sites web externes l'accès à diverses informations de profil associées à chaque fournisseur d'identité via l'API du fournisseur. Cependant, ce problème découvert par Salt Security s'applique à la partie authentification, c’est-à-dire quand un site demande au fournisseur d'identité de confirmer que l'utilisateur est bien le propriétaire de l'identité (adresse électronique) qu'il souhaite utiliser. Et si pour leur démonstration, les chercheurs ont utilisé « Login with Facebook », elle pourrait techniquement fonctionner avec n'importe quel fournisseur d'identité.

Le processus OAuth fonctionne de la manière suivante : un utilisateur souhaite créer un compte sur un site web et choisit l’option « Login with Facebook » en fournissant une adresse électronique. Le site web redirige le navigateur de l'utilisateur vers Facebook afin d'apporter la preuve que l'utilisateur dispose bien d'un compte sous cette adresse électronique auprès du fournisseur d'identité. La première fois, pour confirmer que le site web ou l'application de tierce partie sont autorisés à accéder aux informations relatives à son compte, comme l'adresse électronique, Facebook affiche une demande d'autorisation à l'utilisateur. Ensuite, il génère un jeton secret et redirige le navigateur de l'utilisateur vers le site web demandeur, le jeton étant joint à l'URL de la requête.

Des permissions mémorisées

Le site web prend le jeton et l'utilise pour accéder à l'API Facebook Graph au nom de l'utilisateur et demande au réseau social quelle est l'adresse électronique associée au jeton. Facebook répondra avec l'adresse électronique de l'utilisateur et le site web aura la confirmation que l'utilisateur est bien celui qu'il prétend être et l'autorisera à créer son compte. Pour toute connexion ultérieure, le processus se répète, sauf que Facebook ne demandera plus à l'utilisateur de fournir un accès puisqu'il lui a déjà été accordé. L'utilisateur cliquera simplement sur « Login with Facebook », le site redirigera son navigateur vers Facebook pour obtenir un jeton, Facebook redirigera le navigateur de l'utilisateur vers le site avec le jeton attaché dans l'URL et le site utilisera le jeton pour confirmer le courriel de l'utilisateur via l'API de Facebook et le laisser entrer. Cependant, la sécurité de ce processus comporte un élément très important : Facebook, et tout fournisseur d'identité OAuth, lie le jeton à l'app ID du site web qui a demandé le jeton via le navigateur de l'utilisateur. Chaque site web ou application qui souhaite proposer la fonctionnalité « Login with Facebook » doit d'abord s'enregistrer auprès de Facebook et recevra son propre identifiant d'application unique dans la base de données de Facebook.

Le problème est qu'il incombe au site web de vérifier le jeton avant de l'accepter et de l'utiliser. Cette validation implique de vérifier que le jeton a été généré pour son propre app ID et non pour une autre application. Pour ce faire, une requête est adressée à un point de terminaison spécial de l'API de Facebook avant d'utiliser le jeton pour demander à Facebook de valider l'identité de l'utilisateur et de lui permettre d'accéder à son compte. Si cette étape est omise - et il s'avère que de nombreux sites web l'omettent - il est possible d'usurper l'identité de l'utilisateur et de s'emparer de son compte. Par exemple, un pirate peut créer un site web ou une application légitime qui fournit un service, l'enregistrer auprès de Facebook pour fournir la fonction « Login with Facebook », puis l'utiliser subrepticement pour générer et collecter des jetons OAuth auprès d'utilisateurs qui souhaitent légitimement utiliser le service. Les jetons que Facebook générera pour que les utilisateurs valident leur identité sur le site web de l'attaquant seront valides, même s'ils seront émis pour l'app ID du site web. Mais, si un autre site web ne vérifie pas l'identifiant d'application des jetons qu'il reçoit et se contente de les utiliser, l'attaquant pourrait prendre un jeton généré par un utilisateur pour son site web et l'utiliser sur un site web vulnérable pour accéder au compte de l'utilisateur sur ce site web. Si ce site est une plateforme de commerce électronique comme Bukalapak, l'utilisateur a peut-être stocké dans son profil des informations de facturation et de paiement. S'il s'agit d'un service comme Grammarly, l'utilisateur peut avoir des documents sensibles, etc.

Autres variantes et défauts d’implementation

OAuth est une norme complexe qui offre plusieurs variantes de mise en œuvre. Par exemple, au lieu d'utiliser des URL de redirection entre le site et le fournisseur d'identité, le site peut choisir d'utiliser la fonction PostMessage, mais l'attaque est toujours possible dans une telle implémentation si le jeton n'est pas validé. Le passage de jetons via des URL est potentiellement vulnérable aux attaques de type « man-in-the-middle » si un attaquant a la capacité de surveiller passivement le trafic et d'extraire le jeton OAuth de l'URL qu'il observe. Pour cette raison, OAuth propose également une approche plus sûre dans laquelle le fournisseur d'identité émet un code unique au lieu d'un jeton d'accès, puis le site web prend ce code avec un secret d'application que seuls lui-même et Facebook connaissent et échange le code en jeton à l'aide de l'API de Facebook. Grammarly a effectivement utilisé cette méthode plus sûre basée sur le code quand l'équipe de Salt Security a testé sa mise en œuvre d'OAuth. Cependant, les chercheurs ont constaté que le script OAuth de Grammarly prenait des requêtes avec le code d'entrée dans la requête et se sont demandés s'il pouvait inclure une fonction qui prendrait aussi des jetons. Ils ont donc essayé de faire des demandes en remplaçant le code par différents mots comme token, facebookToken, FBtoken et d'autres variations, jusqu'à ce qu'ils trouvent que access_token fonctionnait et était accepté.

En d'autres termes, ils ont réussi à faire passer l'implémentation de Grammarly à la variante la plus sécurisée parce que le code permettant de gérer les jetons directement à la place du code était encore laissé en option dans le script. Et il s'est avéré qu'il n'y avait pas d'étape de validation du jeton pour vérifier l’app ID. Par le passé, les chercheurs de Salt Security ont trouvé d'autres failles dans l'implémentation d'OAuth sur des sites web importants, dont certaines auraient pu permettre à des attaquants d'accéder à des comptes Booking.com. « Il est extrêmement important de s'assurer que l'implémentation d'OAuth est sécurisée », ont déclaré les chercheurs. « Le correctif se résume à une simple ligne de code. Quand OAuth sert pour fournir une authentification de service, toute faille de sécurité peut conduire au vol d'identité, à la fraude financière et à l'accès à diverses informations personnelles, y compris les numéros de cartes de crédit, les messages privés, les dossiers médicaux, et plus encore, en fonction du service spécifique attaqué », ont encore déclaré les chercheurs.