Oauth en débat
Un rapport récent de la société Salt Security a pointé l’importance de la sécurisation de l’implémentation Oauth afin de se protéger contre l’usurpation d’identité, la fraude financière et l’accès aux informations personnelles. Nous allons tenter de voir dans cet article ce qu’il en est.
Le dernier bug découvert par des chercheurs en sécurité de Salt Security dans l’implémentation Oauth est assez inquiétant. Il permet aux utilisateurs de s’authentifier sur différents sites web à partir de services tiers tels que Google, Facebook… Le problème qui se pose est que certains sites ne parviennent pas à franchir une étape très importante de la chaîne d’autorisation consistant à valider l’application pour laquelle un jeton d’accès a été émis par le fournisseur d’identité. L’exploitation de cette faille par un attaquant peut lui permettre de collecter les jetons émis pour une application ou un site web spoofé ( imité), créés de toute pièce, et de les utiliser ensuite pour accéder aux comptes des victimes sur des sites vulnérables à cette faille. Les grey hats de Salt Security en ont fait la démonstration sur trois sites web populaires : le service d’aide à la saisie Grammarly, la plateforme de commerce électronique indonésienne Bukalapak, ainsi que le site de streaming vidéo indonésien Vidio. Certes, ces entreprises ont été informées en privé par les chercheurs et ont corrigé le problème. Néanmoins, toutes les sociétés employant ce système devraient très rapidement vérifier leurs implémentations afin de s’assurer qu’elles n’exposent pas leurs utilisateurs à des attaques de ce genre. « Ces trois sites nous suffisent amplement pour prouver la véracité de notre théorie et nous avons décidé de ne pas chercher plus avant en testant d’autres cibles, mais nous pensons que des milliers d’autres sites web sont vulnérables à ce type d’attaque, mettant en danger des milliards d’internautes » , ont déclaré de manière collégiale les dits chercheurs dans leur rapport.
Les jetons d’accès liés aux applications émettrices de la requête
La norme d’autorisation et de pseudo- authentification Oauth, très populaire sur le web, sert tout simplement aux sites web et aux applications à demander à un fournisseur d’identité tel qu’apple, Facebook, Google ou Microsoft de vérifier qu’un utilisateur est bien celui qu’il prétend être et non un vilain intrus. Cette méthode facilite grandement le processus d’authentification pour les utilisateurs qui peuvent ainsi utiliser leur identification auprès
d’un fournisseur pour éviter de créer encore et encore de nouveaux mots de passe. Oauth ne se limite pas à l’authentification. Ce mécanisme permet également aux utilisateurs d’accorder à des sites web externes l’accès à diverses informations de profil associées à chaque fournisseur d’identité via son API. Néanmoins, le problème cité s’applique à la partie authentification, c’est- à- dire lorsqu’un site demande au fournisseur d’identité de confirmer que l’utilisateur est bien le propriétaire de l’identité ( représentée par son adresse électronique) qu’il souhaite utiliser. Au passage si, pour leur démonstration, les chercheurs ont utilisé « Login with Facebook » , ils auraient pu faire le test avec n’importe quel autre fournisseur d’identité ( comme, encore eux, Google, Microsoft et consorts). Voici comment fonctionne le processus Oauth : un utilisateur qui souhaite créer un compte sur un site web va choisir l’option « Login with Facebook » ( ou « Login with Google » , si l’option est disponible) en fournissant une adresse électronique en correspondance avec le fournisseur choisi. Le site web va rediriger le navigateur de l’utilisateur vers l’adresse du fournisseur d’identité concerné afin d’apporter la preuve que l’utilisateur dispose bien d’un compte avec cette adresse électronique auprès dudit fournisseur. Ce fournisseur va, la première fois que l’accès est demandé, afficher une demande d’autorisation à l’utilisateur en vue de confirmer que le site web ou l’application de tierce partie sont autorisés à accéder aux informations relatives à son
compte. Il va ensuite générer un « secret token » , un jeton secret si vous préférez, et rediriger le navigateur de l'utilisateur vers le site web demandeur. Le jeton créé précédemment va alors être joint à L'URL de la requête.
Mémorisation des permissions
Le site web prend alors le jeton et s'en sert cette fois pour accéder à L'API d'identification du fournisseur d'identité ( Graph dans le cas de Facebook) au nom de l'utilisateur et demande au fournisseur quelle est l'adresse électronique associée au jeton transmis. Le fournisseur répond avec l'adresse électronique de l'utilisateur et le site web reçoit la confirmation que l'utilisateur est bien celui qu'il prétend être et l'autorise à créer son compte. Le processus se répétera lors des connexions ultérieures. Une exception : le fournisseur d'identité ne demandera plus à l'utilisateur de fournir un accès puisque celui- ci lui a déjà été accordé. L'utilisateur n'aura simplement qu'à cliquer sur « Login with Facebook » , si bien entendu c'est Facebook le fournisseur employé, et le site redirigera le navigateur de l'utilisateur vers le site du fournisseur pour obtenir un jeton. Enfin, le fournisseur en question redirigera le navigateur de l'utilisateur vers le site cible, toujours avec le jeton secret attaché à L'URL, qui l'utilisera afin de confirmer l'adresse mail de l'utilisateur via L'API du fournisseur et le laisser entrer. La sécurité liée à ce processus comporte un élément très important : tout fournisseur d'identité Oauth lie le jeton à l'app ID du site web qui a demandé ce jeton via le navigateur de l'utilisateur. Du coup, tout site web ou application souhaitant proposer la fonctionnalité de connexion via le fournisseur d'identité ( « Login with Google » , par exemple) doit d'abord s'enregistrer auprès du fournisseur en vue de recevoir son propre identifiant d'application unique dans sa base de données. Le problème crucial qui se pose alors 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 bien été généré pour son propre app ID et non pour une autre application. À cette fin, une requête est adressée à un point de terminaison spécial de L'API du fournisseur avant de pouvoir utiliser le jeton en demandant au fournisseur de valider l'identité de l'utilisateur pour lui permettre d'accéder à son compte. Si jamais cette étape est omise — et il s'avère malheureusement que de nombreux sites web le fassent — il devient possible d'usurper l'identité de l'utilisateur et de « s'emparer » de son compte. Un pirate peut, par exemple, créer un site web spoofé, voire une application légitime fournissant un service, et l'enregistrer auprès du fournisseur afin de fournir la fonction de connexion précitée puis l'utiliser subrepticement en vue de générer et de collecter des jetons Oauth auprès d'utilisateurs qui, eux, souhaitent utiliser le service de façon légitime. Les jetons générés par le fournisseur d'identité pour que ces utilisateurs valident leur identité sur le site web du vilain cracker seront valides, quand bien même ils auront été émis pour l'app ID du site web fallacieux ou de l'application. Mais si jamais un autre site web ne vérifie pas l'identifiant d'application des jetons qu'il reçoit et se contente simplement d'essayer de les utiliser, le pirate pourra alors récupérer un jeton généré par un utilisateur pour son site web et l'utiliser sur un autre site vulnérable afin d'accéder au compte de l'utilisateur. Si ce site est, par exemple, une plateforme de ecommerce comme Bukalapak, Amazon ou autre Alibaba, il est tout à fait possible que l'utilisateur ait stocké dans son profil des données bancaires. Avec un service comme Grammarly, ce seront plutôt des documents sensibles. Quelle que soit la nature de ces données, elles pourront alors être compromises.