Faille Salesloft : comment la PKI réduit le risque de détournement de jetons OAuth

Introduction

Les certificats, notamment les certificats mTLS (Mutual TLS), constituent un moyen efficace de limiter les risques liés au vol de jetons OAuth. Ils n’empêchent pas le vol du jeton, mais réduisent fortement son utilité pour un attaquant.

Le principe consiste à lier le jeton OAuth à un client précis au moyen d’une clé cryptographique, afin qu’un jeton volé ne puisse pas être utilisé depuis un autre client.

Problème central : le vol de jetons OAuth

1. Vol : un attaquant dérobe un jeton d’accès, par exemple par une attaque de l’intercepteur, une fuite de journaux, un cache de navigateur compromis ou une extension malveillante.
2. Réutilisation : il présente le jeton volé à un serveur de ressources (par exemple une API).
3. Accès accordé : le serveur vérifie la signature et l’expiration du jeton, mais ne peut pas savoir s’il provient du client légitime. L’attaquant obtient un accès non autorisé.

Solution : authentification client par certificat (mTLS)

Cette approche s’appuie sur les spécifications OAuth 2.0 Mutual-TLS Client Authentication et Certificate-Bound Access Tokens. Le processus comporte deux parties.

Partie 1 : authentifier le client avec un certificat

Lorsqu’il demande un jeton, le client prouve son identité au moyen d’un certificat TLS, plutôt qu’uniquement avec client_id et client_secret.

1. Provisionnement du client : l’application légitime reçoit un certificat X.509 unique et sa clé privée. Dans les environnements d’entreprise, ce provisionnement peut être dynamique.
2. Négociation TLS : lorsque le client se connecte au serveur d’autorisation pour demander un jeton, une négociation mTLS complète a lieu. Le serveur prouve son identité au client comme en TLS standard ; le client doit également prouver son identité en présentant son certificat et en signant des données avec sa clé privée.
3. Demande de jeton : le client effectue une demande standard (par exemple avec l’octroi client_credentials ou le code d’autorisation). Le serveur d’autorisation valide l’identité du client grâce à la négociation mTLS, et non à un secret partagé.

Partie 2 : lier le jeton au certificat (étape clé)

1. Calcul de l’empreinte : le serveur d’autorisation calcule l’empreinte du certificat présenté pendant la négociation mTLS. Une méthode courante consiste à appliquer le hachage SHA-256 à l’encodage DER du certificat.
2. Intégration au jeton : le serveur intègre cette empreinte (x5t#S256) directement au jeton d’accès, par exemple comme JWT claim.
3. Utilisation du jeton : lorsqu’il appelle l’API (serveur de ressources), le client effectue de nouveau une négociation mTLS et présente le même certificat que celui utilisé pour obtenir le jeton.
4. Validation du jeton : le serveur de ressources vérifie la signature et l’expiration du jeton, en extrait l’empreinte, calcule celle du certificat présenté lors de la négociation TLS et compare les deux. Si elles correspondent, la requête est autorisée ; sinon, elle est rejetée.

Comment cela limite les conséquences d’un vol

1. L’attaquant dérobe un jeton et tente de l’utiliser auprès du serveur de ressources depuis sa propre machine.
2. Le serveur exige une négociation mTLS, mais l’attaquant ne possède pas la clé privée associée au certificat du client légitime.
3. Il ne peut pas terminer la négociation mTLS ; la connexion est interrompue au niveau TLS avant l’envoi du jeton.
4. Même s’il parvenait à envoyer le jeton, le serveur constaterait l’absence de certificat client ou l’incompatibilité entre l’empreinte présentée et celle du jeton.
5. La requête est rejetée. Le jeton volé ne suffit pas sans le certificat et la clé privée correspondants.

Normes et profils

Ce mécanisme n’est pas propriétaire ; il est défini dans les normes de l’IETF :

• RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens : la spécification principale.
• FAPI 2.0 Security Profile : recommande et utilise l’authentification client mTLS et la liaison des jetons pour les scénarios à haute sécurité.

Avantages

1. Authentification forte : remplace le client_secret statique par une preuve cryptographique solide.
2. Réduction du rejeu de jetons : seul le client possédant le certificat auquel le jeton est lié peut l’utiliser.
3. Défense en profondeur : protège même lorsque d’autres mesures, comme le stockage des jetons, échouent.

Défis et points à considérer

1. Complexité : gérer l’émission, le renouvellement et la révocation des certificats clients est plus complexe que gérer des secrets. Une infrastructure à clé publique (PKI), avec une solution CLM comme PKI Trust Manager, peut simplifier la gestion des certificats mTLS.
2. Prise en charge par les clients : toutes les bibliothèques et applications OAuth ne prennent pas nativement en charge mTLS et la présentation de certificats.
3. Charge de déploiement : la configuration concerne le serveur d’autorisation, le serveur de ressources et tous les clients.

Résumé

En conclusion, l’utilisation de certificats mTLS pour authentifier les clients et lier les jetons constitue une stratégie efficace pour limiter le vol de jetons OAuth. Elle fait évoluer le modèle de sécurité : au lieu de s’appuyer sur la « possession du jeton », il exige la « possession du jeton et de la clé cryptographique correspondante », ce qui complique considérablement la tâche des attaquants. Cette approche est recommandée pour sécuriser les communications machine à machine (M2M) et les API à forte valeur, notamment celles utilisées par des agents d’IA.