Un bref récapitulatif de la sécurité OAuth

Introduction#

Il y a quelques jours à peine, un intéressant article sur une vulnérabilité OAuth nous a frappés. A-new-oauth-vulnerability-that-may-impact-hundreds-of-online-services par le laboratoire SALT. Cet article spécifique met en évidence une vulnérabilité découverte dans Expo, un cadre largement utilisé pour la mise en œuvre d'OAuth et d'autres fonctionnalités. Il s'adresse spécifiquement à une vulnérabilité dans la bibliothèque expo-auth-session, qui a été attribuée et correctement résolue.

Si vous êtes intéressé par OAuth ou travaillez sur un produit lié à CIAM comme nous, nous vous recommandons vivement de lire cet article. Il est assez inspirant et fournit des informations utiles. Ces rapports de chapeaux blancs servent de rappel sur la façon dont la fonctionnalité la plus simple peut causer des vulnérabilités. Lorsqu'il s'agit de la cybersécurité et de l'autorisation, nous ne pouvons jamais être trop prudents pour garantir la sécurité et la confidentialité des informations des utilisateurs. Si cet article retient votre attention, je crois que vous serez fortement d'accord avec nous.

Cela me rappelle le temps où nous avons commencé. Nous avons passé beaucoup de temps à apprendre et à rechercher les détails des protocoles OAuth et OIDC. C'était pénible et fastidieux, mais les bénéfices étaient immenses. Bien que peut-être pas chaque individu de notre équipe soit un expert en OAuth, tout le monde s'engage à faire un effort continu en matière de sécurité et de méticulosité. Grâce à ces efforts dédiés, le produit Logto a évolué pour devenir ce qu'il est aujourd'hui.

Grâce à cette formidable opportunité, nous aimerions rafraîchir notre mémoire sur certains des détails de sécurité d'OAuth ici.

Aperçu du flux d'autorisation OAuth#

OAuth 2.0 offre divers flux d'autorisation adaptés à différents types de clients et exigences. Ceux-ci incluent le Flux implicite, le Flux des informations d'identification du client, le Flux des informations d'identification du mot de passe du propriétaire de la ressource, et le Flux d'autorisation de l'appareil. Cependant, le Flux du Code d'autorisation se distingue comme le plus sûr et le plus largement utilisé. Contrairement aux autres flux, il sépare l'authentification de l'utilisateur de l'application client et implique l'échange d'un Code d'autorisation pour des jetons. Cette approche fournit une couche supplémentaire de sécurité, car les jetons sensibles ne sont jamais exposés au client. De plus, le Flux du Code d'autorisation prend en charge la gestion des jetons côté serveur, ce qui le rend adapté pour les applications Web qui nécessitent une sécurité robuste et un contrôle renforcé de l'accès des utilisateurs.

Voici un diagramme du Flux du Code d'autorisation le plus simple:

Examinons les deux demandes les plus cruciales faites dans le flux de subvention du Code d'autorisation et les fragments apparemment insignifiants qu'ils contiennent mais qui jouent un rôle crucial dans la protection contre la fraude.

Le point de terminaison de l'autorisation:

Le point de terminaison d'échange de jetons:

Informations d'identification du client#

Dans OAuth, les Informations d'identification du client désignent les informations d'identification utilisées par une application client pour s'authentifier et s'identifier auprès du serveur d'autorisation. Ces informations d'identification sont obtenues lors du processus d'enregistrement du client et sont utilisées pour valider l'identité du client lors de la réalisation de demandes au serveur d'autorisation. (Vous pouvez trouver votre identifiant de client dans la console d'administration de Logto lorsque vous avez enregistré votre application pour la première fois.)

Les informations d'identification du client sont généralement composées de deux composants :

1. ID Client : Un identifiant unique attribué à l'application client par le serveur d'autorisation. C'est une valeur publique qui n'est généralement pas considérée comme sensible.
2. Secret Client : Une valeur confidentielle et stockée en toute sécurité, connue uniquement du client et du serveur d'autorisation. Il sert de forme d'authentification pour l'application client et est utilisé pour vérifier l'identité du client lorsqu'il fait des demandes au serveur d'autorisation.

Comme vous pouvez le constater, la combinaison ID Client et Secret Client est utilisée lors de la demande de jeton pour authentifier le client et obtenir des jetons d'accès.

Les informations d'identification du client jouent un rôle vital dans la garantie de la sécurité du flux OAuth. Ils aident le serveur d'autorisation à vérifier l'authenticité des applications client et à contrôler l'accès aux ressources protégées. Il est important de manipuler les informations d'identification du client de manière sécurisée et de les protéger contre l'accès non autorisé. Logto catégorise les applications client en deux niveaux de sécurité différents :

• Clients confidentiels : Il s'agit notamment des applications web rendues côté serveur et des applications machine à machine (M2M). Dans le cas des clients confidentiels, toutes les informations d'identification liées à l'autorisation, y compris les informations d'identification du client, sont stockées en toute sécurité côté serveur. De plus, toutes les demandes d'échange intermédiaires sont cryptées pour garantir la confidentialité des données. Le risque de fuite des informations d'identification du client pour les clients confidentiels est très faible, ce qui les rend intrinsèquement plus sûrs. Par conséquent, les clients confidentiels sont traités avec un niveau de sécurité plus élevé par défaut. Dans le flux d'échange de jetons, la présentation du Secret du Client est obligatoire.
• Clients publics : Il s'agit notamment des applications web à une seule page (SPA) et des applications natives. Pour les clients publics, les informations d'identification du client sont généralement codées en dur côté client, comme dans un package JavaScript ou un package d'application sur une plateforme native. Le risque de fuite des informations d'identification est plus élevé par rapport aux clients confidentiels en raison de l'exposition inhérente des informations d'identification du client dans le code côté client. Dans le flux d'échange de jetons, la présentation du Secret du Client est FACULTATIVE. Logto ne fera pas confiance à ces informations d'identification provenant d'un client public par défaut.

État#

Dans le flux OAuth, le paramètre state est une valeur générée aléatoirement qui est incluse dans la demande d'autorisation envoyée par le client au serveur d'autorisation. Son but est de maintenir l'état ou le contexte de la demande du client tout au long du processus d'autorisation.

Le paramètre state sert de mesure de sécurité pour prévenir les attaques de type requête intersite falsifiée (CSRF). Lorsque le serveur d'autorisation redirige l'utilisateur vers l'application client après l'authentification et l'autorisation, il inclut la même valeur d'état dans la réponse. L'application client DOIT comparer cette valeur avec la valeur state originale qu'elle a envoyée dans la demande d'autorisation.

En vérifiant le paramètre d'état, le client peut s'assurer que la réponse reçue du serveur d'autorisation correspond à la demande initiale qu'il a faite. Cela aide à prévenir les attaques où un attaquant tente de tromper le client pour qu'il accepte une réponse destinée à un autre utilisateur ou à une autre application.

Prenons l'exemple suivant d'une attaque CSRF dans un cas d'utilisation fictif :

Attaque CSRF : Fraude pour lier un compte social - problème

Avec un mécanisme de validation d'état correct, le client peut détecter l'attaque et empêcher l'utilisateur d'être redirigé vers le site web de l'attaquant :

Attaque CSRF : Fraude pour lier un compte social - solution

PKCE#

Comme mentionné précédemment, les clients publics tels que les applications web SPA et les applications natives comportent un risque plus élevé de fuite des informations d'authentification, y compris le Code d'autorisation délivré par le serveur d'autorisation.

PKCE signifie Proof Key for Code Exchange. C'est une extension du Flux du Code d'autorisation d'OAuth 2.0 qui renforce la sécurité des clients publics.

PKCE a été introduit pour atténuer le risque qu'un attaquant intercepte le Code d'autorisation et l'échange contre un jeton d'accès sans que le client en ait connaissance. Ce type d'attaque, connu sous le nom d'attaque d'interception du Code d'autorisation, est plus courant dans les environnements où l'application client ne peut pas stocker en toute sécurité un secret de client.

Pour mettre en œuvre PKCE, l'application client génère un vérificateur de code aléatoire et en déduit un défi de code en utilisant un algorithme de hachage spécifique (généralement SHA-256). Le défi de code est inclus dans la demande d'autorisation initiale envoyée au serveur d'autorisation.

Lorsque le serveur d'autorisation délivre le Code d'autorisation, l'application client inclut le vérificateur de code original dans la demande de jeton. Le serveur vérifie que le vérificateur de code correspond au défi de code stocké et délivre alors le jeton d'accès.

En utilisant PKCE, l'application client s'assure que le Code d'autorisation seul n'est pas suffisant pour obtenir un jeton d'accès. Ce mécanisme ajoute une couche supplémentaire de sécurité au flux d'autorisation, en particulier pour les clients publics où le stockage des secrets de client représente un défi.

Logto utilise PKCE comme le seul flux d'autorisation pour toutes les applications du type client public. Cependant, PKCE et peut être omis pour ces clients confidentiels.

URI de redirection#

Une URI de redirection (Uniform Resource Identifier) est un point de terminaison ou une URL spécifique vers laquelle le serveur d'autorisation redirige l'utilisateur après le processus d'authentification et d'autorisation en OAuth.

Au cours du flux OAuth, l'application client inclut une URI de redirection dans la demande d'autorisation initiale. Cette URI sert d'URL de rappel où l'utilisateur sera redirigé après avoir donné avec succès des permissions au client.

Une fois que l'utilisateur a terminé le processus d'authentification, le serveur d'autorisation génère une réponse qui inclut un Code d'autorisation, et redirige l'utilisateur vers l'URI de redirection spécifiée.

La validation de l'URI de redirection est une étape essentielle pour assurer la sécurité et l'intégrité du flux OAuth. Elle consiste à vérifier que l'URI de redirection utilisée dans la demande d'autorisation et les redirections subséquentes est valide et de confiance.

Revenons en arrière et regardons le rapport de vulnérabilité OAuth original. (La section suivante est référencée à partir du post original)

Quand l'utilisateur clique sur "login with facebook" en utilisant l'APP mobile dans Expo Go, il redirige l'utilisateur vers le lien suivant :

https://auth.expo.io/@moreisless3/me321/start?authUrl=https://www.facebook.com/v6.0/dialog/oauth?code_challenge=...&display=popup&auth_nonce=...&code_challenge_method=S256&redirect_uri=https://auth.expo.io/@moreisless3/me321&client_id=3287341734837076&response_type=code,token&state=gBpzi0quEg&scope=public_profile,email&returnUrl=exp://192.168.14.41:19000/--/expo-auth-session

En réponse, auth.expo.io a défini le cookie suivant : ru=exp://192.168.14.41:19000/--/expo-auth-session. La valeur RU sera utilisée plus tard comme Return Url à l'étape 5. Il montre ensuite à l'utilisateur un message de confirmation, et si l'utilisateur approuve - il le redirige vers le login Facebook pour poursuivre le flux d'authentification

…

Cette page lit le paramètre de requête "returnUrl" et règle le cookie en conséquence.

Changeons le returnUrl en hTTps://attacker.com (https n'est pas autorisé, alors j'ai essayé d'insérer des lettres majuscules et ça a marché), ce qui règle le RU (Return Url) dans le cookie à https://attacker.com.

…

Dans le cas ci-dessus, malgré les paramètres d'origine redirect_uri, Expo a introduit un nouveau paramètre appelé returnUrl sans validation appropriée. Ce manque de surveillance a donné l'occasion aux attaquants d'accéder au Code d'autorisation retourné par Facebook. Pour plus de détails, veuillez vous référer au post original.

La validation de l'URI de redirection sert plusieurs objectifs importants:

1. Prévenir les attaques de hameçonnage : En validant l'URI de redirection, le serveur d'autorisation s'assure que l'utilisateur est redirigé vers un point de terminaison autorisé et de confiance. Cela aide à prévenir les attaques où les attaquants redirigent les utilisateurs vers des lieux malveillants ou non autorisés.
2. Protéger contre les redirections ouvertes : Les redirections ouvertes sont des vulnérabilités qui peuvent être exploitées pour rediriger les utilisateurs vers des sites web malveillants. En validant l'URI de redirection, le serveur d'autorisation peut s'assurer que la redirection reste dans les limites du domaine autorisé ou de l'ensemble des domaines de confiance.
3. Assurer le routage correct des réponses d'autorisation : La validation de l'URI de redirection aide à garantir que le serveur d'autorisation redirige l'utilisateur vers l'application client prévue. Elle assure que la réponse, comme un Code d'autorisation ou un jeton d'accès, est livrée à la bonne destination.

Dans Logto, l'enregistrement de redirect_uri est obligatoire pour tous les types d'applications. Nous comparons et vérifions la valeur reçue par rapport à celles enregistrées sur le serveur Logto. Cela inclut tous les paramètres de recherche personnalisés. Si une demande d'autorisation échoue à la validation en raison d'une valeur redirect_uri manquante, invalide ou discordante, une erreur d'URI de redirection invalide sera renvoyée à l'redirect_urienregistrée en fichier.

Résumé#

Du fait de leur nature complexe et nuancée, il est compréhensible que ces détails soient souvent négligés. Certains sont juste une chaîne aléatoire comme state.

Cependant, il est important de noter que ces mesures de sécurité ajoutent des couches de protection à l'autorisation de l'utilisateur, atténuant les risques tels que les attaques CSRF, l'interception du Code d'autorisation, et les redirections non autorisées.

Ce ne sont qu'une petite partie des fonctionnalités de sécurité complètes offertes par le protocole OAuth. OAuth fournit un cadre robuste pour l'authentification et l'autorisation sécurisées. Il propose également des terminaisons flexibles et ouvertes pour répondre à diverses exigences dans les applications de produits du monde réel.

En tant que développeurs et fournisseurs de services, il est impératif de prioriser continuellement la sécurité du flux d'autorisation de l'utilisateur. Rester vigilant, respecter les meilleures pratiques et se tenir au courant des derniers développements dans l'écosystème OAuth sont essentiels pour garantir l'intégrité et la protection des identités des utilisateurs et des données sensibles. Nous resterons engagés à respecter les normes les plus élevées de sécurité dans la mise en œuvre d'OAuth et à protéger la vie privée et la confiance de nos utilisateurs.