Un groupe de chercheurs de l’université de Trier (en Allemagne) a
effectué une analyse de sécurité de la norme OAuth 2.0. Ils ont
découvert que deux types d’attaques auraient pu être utilisés pour
briser les autorisations et authentifications dans OAuth.
En
guise d’introduction dans le document décrivant leur recherche, ils ont
rappelé que le protocole OAuth 2.0 permet aux utilisateurs d’accorder à
des parties de confiance un accès aux ressources de fournisseurs
d’identité. En plus d’être utilisé pour ce type d’autorisation, OAuth
est également souvent utilisé pour l’authentification dans les systèmes
SSO (single sign-on, système à authentification unique, une méthode
permettant à un utilisateur d'accéder à plusieurs applications ou sites
web sécurisés en ne procédant qu'à une seule authentification). Il faut
noter qu’OAuth 2.0 est l’un des protocoles les plus utilisés dans ces
desseins sur le web avec des entreprises comme Google (avec Google
Account), Yahoo (avec YahooID), Facebook (avec Facebook Login) ou
Microsoft (avec Live ID) qui jouent le rôle de fournisseurs d’identité
et des millions de sites web qui se connectent à ces services jouent le
rôle de parties de confiance.
Si OAuth 2.0 est au cœur de
nombreuses implémentations à l’instar de celles qui sont citées en sus,
l’étude note que la prochaine version du système SSO Open ID Connect va
également se baser dessus. Pour rappel, OpenID est un système
d’authentification décentralisé qui permet l’authentification unique,
ainsi que le partage d’attributs. Il permet à un utilisateur de
s’authentifier auprès de plusieurs sites (devant prendre en charge cette
technologie) sans avoir à retenir un identifiant pour chacun d’eux,
mais en utilisant à chaque fois un unique identifiant OpenID.
« Malgré
la popularité d’OAuth, jusqu’à présent les efforts d’analyse ont été
orientés pour trouver des bogues dans des implémentations spécifiques et
se basaient sur des modèles formels qui faisaient abstraction de
nombreuses fonctionnalités web ou ne fournissaient pas du tout un
traitement formel », précisent les chercheurs, avant de relever deux
vulnérabilités qui peuvent permettre d’exécuter deux attaques.
Les
chercheurs ont expliqué que dans la première attaque (aussi connue sous
le nom de HTTP 307 Temporary Redirect – redirection temporaire), les
fournisseurs d’identité font suivre par inadvertance des identifiants
(nom d’utilisateurs et mots de passe) aux parties de confiance ou à un
attaquant.
« Cette attaque sévère est causée par une erreur
logique dans le protocole OAuth 2.0 et est tributaire de la présence de
parties de confiance malveillantes », ont-ils commenté. « Dans cette
attaque, le pirate (qui se sert d’une partie de confiance malveillante)
glane des informations sur les identifiants de l’utilisateur lorsque
celui-ci se connecte à un fournisseur d’identité qui se sert du mauvais
code d’état de redirection HTTP ».
Voici le scénario d’attaque
qu’ils ont décrit : l'utilisateur se sert d’OAuth pour se connecter à
une partie de confiance malveillante gérée par l'attaquant, et est
redirigé vers le fournisseur d'identité où il est invité à entrer ses
informations d'identification. Les identifiants sont envoyés au
fournisseur d'identité via une requête POST, puis vérifiés et par la
suite l'utilisateur est redirigé vers l’extrémité de la redirection de
la partie utilisatrice. Si le fournisseur d'identité utilise le code
d'état de redirection 307 HTTP, la partie de confiance malveillante
(c’est-à-dire l'attaquant) recevra également une requête POST contenant
toutes les données issues du formulaire précédent, ce qui inclut les
informations d'identification de l'utilisateur.
Les chercheurs
estiment que, pour résoudre ce problème, seuls les codes HTTP 303
devraient être autorisés dans OAuth étant donné que « la redirection 300
est définie sans ambiguïté pour ne pas utiliser le corps d’une requête
HTTP POST ».
La seconde faille implique une attaque sur le site
de la partie de confiance : « l’attaquant sème la confusion chez la
partie de confiance concernant quel fournisseur d’identité l’utilisateur
a choisi au début du processus de connexion/autorisation dans
l’intention d’obtenir un code d’authentification ou un token d’accès qui
pourrait être utilisé pour usurper l’identité de l’utilisateur ou
accéder à ses données ».
Voici le scénario de l’attaque :
« l’attaquant manipule la première demande de l’utilisateur de telle
façon que la partie de confiance pense que l’utilisateur veut utiliser
une identité gérée par un fournisseur d’identité de l’attaquant alors
que l’utilisateur voudrait plutôt utiliser une identité gérée par un
fournisseur d’identité légal. Par conséquent, la partie de confiance
envoie le code d’autorisation ou le token d’accès (dépendant du mode de
l’OAuth) délivré par le fournisseur d’identité légal à l’attaquant, qui
peut par la suite utiliser ces valeurs pour se connecter à la partie de
confiance sous l’identité de l’utilisateur (gérée par le fournisseur
d’identité légal) ou accéder à ses ressources protégées ».
Pour
pouvoir effectuer cette attaque, les pirates doivent être en mesure de
manipuler les requêtes envoyées par les utilisateurs ainsi que les
réponses, ce qui signifie qu’ils doivent avoir une présence sur le
réseau (attaque Man-in-the-middle).
Les chercheurs ont expliqué
que pour résoudre ce problème, OAuth devrait inclure l’identité du
fournisseur d’identité dans la redirection d’une certaine façon. « Plus
précisément, nous suggérons que les parties de confiance fournissent une
extrémité de redirection unique pour chaque fournisseur d’identité.
Ainsi, l’information redirigée par le fournisseur d’identité sera
encodée dans la requête et la partie de confiance pourra détecter les
anomalies ».
Avec ces problèmes résolus, les chercheurs ont
estimé qu’OAuth 2.0 est suffisamment sécurisé pour fournir à la fois les
autorisations et les authentifications, si elles sont implémentées
correctement.
Ian Muscat, responsable de la communication produit
chez Acunetix (spécialiste de la sécurité des applications web), a
avancé que « lorsqu’il s’agit des processus d’authentification et
d’autorisation au sein d’une application web, à moins d’avoir une
compréhension profonde de la technologie ainsi qu’une raison spécifique,
justifiable et soigneusement réfléchie, ne déployez pas votre propre
système d’authentification. À la place, servez-vous d’une bibliothèque
ou d’un Framework qui a été examiné par le public et a une communauté
active qui traite la question de sécurité comme étant prioritaire ».
Pour
Liviu Itoafa, chercheur en sécurité chez Kaspersky Lab, parlant de
l’attaque qu’il est possible de lancer contre le site de la partie de
confiance, il a avancé que « ce problème implique qu’il doit y avoir un
souci du côté de la partie de confiance – par exemple elle pourrait ne
pas se servir de HTTPS pour la requête initiale de l’utilisateur ».
