Aller au contenu
TortueTech
RubriquesIdentités, accès & habilitations

Découverte et enregistrement dynamique de client

Découverte et enregistrement dynamique de client

Section intitulée « Découverte et enregistrement dynamique de client »

Brancher une application sur un fournisseur d’identité suppose, en principe, un échange administratif : on déclare l’application, on obtient un identifiant, on configure des adresses, on échange des clés. Deux spécifications d’OpenID Connect suppriment cette étape. La découverte permet au client de trouver seul toutes les adresses et toutes les clés du fournisseur ; l’enregistrement dynamique lui permet de s’inscrire tout seul. C’est commode, c’est devenu indispensable aux outils qui se connectent à des services qu’ils ne connaissaient pas à leur compilation, et cela déplace la confiance vers un endroit qu’il faut regarder de près.

→ Lire l’explication complète de la marmotte

La découverte : un document de métadonnées à une adresse connue

Section intitulée « La découverte : un document de métadonnées à une adresse connue »

Le principe tient en une concaténation. Un fournisseur qui prend en charge la découverte « DOIT rendre disponible un document JSON au chemin formé en concaténant la chaîne /.well-known/openid-configuration à l’émetteur ». Pour un émetteur https://example.com, le client interroge donc https://example.com/.well-known/openid-configuration ; si l’émetteur comporte un composant de chemin, la barre oblique finale est retirée avant la concaténation, de sorte que https://example.com/issuer1 donne https://example.com/issuer1/.well-known/openid-configuration. La spécification précise la raison de cette subtilité : « l’usage de composants de chemin permet de prendre en charge plusieurs émetteurs par hôte, ce qui est requis dans certaines configurations d’hébergement multi-locataires ». Et elle ajoute une mise au point utile : ce recours à .well-known sert à cela, et, contrairement à son usage habituel, « il ne fournit pas d’information générale sur l’hôte ».

La réponse est « un ensemble de déclarations sur la configuration du fournisseur, incluant toutes les adresses nécessaires et l’information de localisation des clés publiques ». Autrement dit, un seul document détermine où le client ira demander une autorisation, où il échangera son code contre un jeton, et avec quelles clés il vérifiera les signatures. La spécification recommande de prendre en charge le partage de ressources entre origines sur cette adresse, pour que des clients vivant dans un navigateur puissent la lire, mécanisme dont les règles sont exposées dans la politique de même origine.

Il faut bien voir ce que ce document concentre. Qui le contrôle contrôle les clés de vérification, donc la capacité à forger des jetons d’identité que le client acceptera. Ce n’est pas un fichier de configuration, c’est une ancre de confiance servie par le réseau.

L’usurpation d’émetteur, et la seule parade qui marche

Section intitulée « L’usurpation d’émetteur, et la seule parade qui marche »

La spécification consacre une section à cette attaque, et sa lecture dispense de la plupart des commentaires sur le sujet. Deux variantes y figurent.

La première est l’interception classique : le client « DOIT effectuer la vérification du certificat du serveur TLS lorsqu’il fait une requête de configuration ». Et la justification est précise : « vérifier que le certificat du serveur est valide pour l’adresse de l’émetteur empêche les attaques de l’intercepteur et les attaques fondées sur le DNS. Ces attaques pourraient amener un client à être trompé pour qu’il utilise les clés et les adresses d’un attaquant, ce qui permettrait l’usurpation de l’émetteur légitime. Si un attaquant y parvient, il peut accéder aux comptes de tous les utilisateurs existants du client qui peuvent s’y connecter avec le fournisseur qu’il usurpe. » La dépendance au système de noms de domaine est donc structurelle, et les moyens de le corrompre sont l’objet de l’empoisonnement de cache DNS.

La seconde variante est plus retorse et vise un client qui ferait pourtant tout bien côté TLS : « un attaquant peut aussi tenter d’usurper un fournisseur en publiant un document de découverte qui contient une déclaration d’émetteur reprenant l’adresse du fournisseur usurpé, mais avec ses propres adresses et ses propres clés de signature. Cela lui permettrait d’émettre des jetons d’identité au nom de ce fournisseur, si le client les accepte. » L’attaquant publie donc un document de découverte sur son propre domaine, en y inscrivant comme émetteur le nom de sa victime.

La parade est une égalité stricte, exigée en trois points : « les clients DOIVENT s’assurer que l’adresse d’émetteur qu’ils utilisent pour la requête de configuration correspond exactement à la valeur de la déclaration d’émetteur dans le document de métadonnées reçu, et que celle-ci correspond également exactement à la valeur de la déclaration iss dans les jetons d’identité censés provenir de cet émetteur ». Trois valeurs, une seule chaîne de caractères, comparées sans normalisation indulgente. C’est un contrôle de deux lignes, et son absence est la vulnérabilité la plus répandue des intégrations faites à la main. La mécanique générale de rattachement d’une clé à une identité est exposée dans relier une clé à une identité, et la mise en œuvre concrète d’une intégration dans la configuration d’OIDC entre un fournisseur et une application interne.

L’enregistrement dynamique : le client se décrit lui-même

Section intitulée « L’enregistrement dynamique : le client se décrit lui-même »

La seconde spécification complète la première. Le client envoie un POST en JSON au point d’enregistrement, « avec n’importe quels paramètres de métadonnées de client qu’il choisit de spécifier pour lui-même », et le serveur d’autorisation « assigne à ce client un identifiant unique, optionnellement assigne un secret, et associe les métadonnées fournies dans la requête à l’identifiant délivré ».

Les métadonnées déclarées sont nombreuses et déterminantes : le type d’application, les adresses de redirection, le nom affiché, l’adresse d’un logo, l’adresse d’une politique de confidentialité, la méthode d’authentification du client, l’adresse de publication de ses clés publiques, les algorithmes qu’il accepte, des adresses de contact. Le serveur garde une marge de manœuvre, et une phrase de la spécification mérite d’être retenue : il « PEUT rejeter ou remplacer n’importe laquelle des valeurs de champ demandées par le client, à l’exception de la valeur des adresses de redirection », et doit alors les renvoyer dans sa réponse. Les adresses de redirection sont donc le seul champ que le client impose, ce qui est exactement le champ qui détermine où partiront les codes d’autorisation. Les conséquences d’une redirection mal maîtrisée sont l’objet de les pièges OAuth 2.1.

La réponse peut comporter un jeton d’accès d’enregistrement et une adresse de configuration du client, permettant au client de relire et de mettre à jour son inscription. Sur ce point, la spécification est catégorique d’une manière qui en dit long : le serveur « DOIT fournir au client l’adresse pleinement qualifiée », il « NE DOIT PAS attendre du client qu’il construise ou découvre cette adresse par lui-même », et le client « DOIT utiliser l’adresse telle que donnée par le serveur et NE DOIT PAS la construire à partir de composants ». Une adresse devinable et construite côté client serait une invitation à lire ou à modifier l’enregistrement d’un autre.

Les risques de l’enregistrement ouvert

Section intitulée « Les risques de l’enregistrement ouvert »

La spécification consacre ses considérations de sécurité à deux familles de problèmes, et la première est inattendue.

L’usurpation par l’apparence. « Un client malveillant pourrait utiliser le logo du client légitime qu’il essaie d’usurper. Un fournisseur doit prendre des mesures pour atténuer ce risque d’hameçonnage, puisque le logo pourrait amener les utilisateurs à croire qu’ils se connectent au client légitime. » La contre-mesure suggérée est simple et rarement implémentée : « un fournisseur pourrait alerter si le domaine du logo ne correspond pas au domaine des adresses de redirection enregistrées », et « peut aussi afficher des avertissements contre les clients non fiables dans tous les cas, en particulier s’ils sont enregistrés dynamiquement, n’ont jamais été approuvés par aucun utilisateur auparavant, et veulent utiliser la fonction de logo ». Un écran de consentement qui affiche un nom et un logo choisis par le demandeur, sans aucune vérification, est un support d’hameçonnage financé par le fournisseur d’identité.

Les adresses fournies par le client et affichées à l’utilisateur. Le passage est net : « dans une situation où le serveur d’autorisation prend en charge l’enregistrement ouvert de clients, il doit être extrêmement prudent avec toute adresse fournie par le client et qui sera affichée à l’utilisateur final, par exemple l’adresse du logo et celle de la politique. Un client malveillant pourrait spécifier une requête d’enregistrement avec une référence vers un téléchargement à la dérobée dans l’adresse de politique. » La recommandation est de vérifier que ces adresses « ont le même hôte que ceux définis dans le tableau des adresses de redirection ». Il faut ajouter, car la spécification ne le dit pas explicitement, que toute adresse fournie par le client et récupérée par le serveur est un vecteur de requête côté serveur, famille de problèmes traitée dans les requêtes côté serveur et la désérialisation : chercher un logo à une adresse choisie par l’inscrit, c’est offrir un client HTTP dans le réseau interne.

La fuite par schéma d’adresse personnalisé. La spécification signale enfin un problème de plateforme : sur certains systèmes mobiles, l’information revient aux applications natives par des schémas d’adresse personnalisés, « mais plusieurs applications peuvent enregistrer le même schéma. Dans ce cas, il est non déterministe quelle application reçoit l’information », ce qui « peut entraîner la fuite d’un code d’autorisation vers la mauvaise application ». Le remède est venu depuis par d’autres moyens, mais le principe reste : une adresse de redirection n’est une frontière de sécurité que si le système d’exploitation garantit son unicité.

Cadrer l’enregistrement dynamique plutôt que l’interdire

Section intitulée « Cadrer l’enregistrement dynamique plutôt que l’interdire »

L’enregistrement dynamique a changé de statut. Longtemps curiosité des grandes fédérations, il est devenu le mécanisme par lequel un outil ou un agent se connecte à un service qu’il ne connaissait pas à sa compilation : c’est la voie retenue par les protocoles d’outillage des agents, qui s’appuient sur la découverte des métadonnées du serveur d’autorisation puis sur l’enregistrement dynamique du client pour obtenir un identifiant sans intervention humaine. Le problème est connu et il n’est pas théorique : un client qui s’enregistre lui-même est, par construction, un client dont personne n’a vérifié l’identité, et qui obtient néanmoins une place dans l’écran de consentement de l’utilisateur. Le portefeuille européen d’identité a pris le parti inverse en inscrivant chaque vérificateur dans un registre national avant sa première demande, ce qui est moins souple et nettement moins naïf. Les précautions à prendre du côté de l’agent relèvent de la gouvernance des identités des agents logiciels autonomes et de la sécurisation de leurs actions irréversibles.

Six contrôles rendent le mécanisme tenable, et aucun n’est coûteux. Exiger un jeton d’accès initial pour pouvoir s’enregistrer, ce qui transforme l’enregistrement ouvert en enregistrement contrôlé sans rien changer au protocole. Vérifier l’égalité stricte des trois valeurs d’émetteur, côté client, comme la spécification de découverte l’exige. Refuser les adresses de redirection qui ne respectent pas une politique écrite, le seul champ que le client impose étant aussi le plus dangereux. Ne jamais récupérer une adresse fournie par l’inscrit depuis le réseau du serveur d’autorisation, ou le faire depuis un contexte isolé sans accès interne. Marquer les clients enregistrés dynamiquement dans l’écran de consentement, et ne pas leur accorder les attributs d’apparence, nom et logo, d’un client vérifié. Et distinguer les usages : un client auto-enregistré peut convenir pour un accès de faible portée, et ne devrait pas pouvoir demander des portées sensibles. C’est précisément la position du NIST, qui admet l’établissement dynamique des identifiants et des clés à ses deux premiers niveaux d’assurance de fédération et l’exclut au troisième, où ils « DOIVENT être établis manuellement » : voir l’assertion fédérée injectée et les niveaux de fédération. La souplesse et la confiance sont deux grandeurs qui s’échangent, et il vaut mieux décider du taux de change que le découvrir.

Sources

Section intitulée « Sources »

🐝 Ce qui arrive si on s’en passe

Section intitulée « 🐝 Ce qui arrive si on s’en passe »

Sans vérification du certificat du serveur pour l’adresse de l’émetteur, un détournement de résolution de noms suffit à faire adopter par le client les adresses et les clés d’un attaquant, qui accède alors à tous les comptes utilisables avec ce fournisseur. Sans égalité stricte entre l’adresse interrogée, la déclaration d’émetteur du document de métadonnées et la déclaration d’émetteur des jetons, un attaquant publie sur son propre domaine un document qui se présente comme celui du fournisseur visé, et signe des jetons d’identité avec ses propres clés. Sans jeton d’accès initial sur le point d’enregistrement, n’importe qui obtient un identifiant de client et une place dans l’écran de consentement des utilisateurs. Sans contrôle des adresses de logo et de politique fournies par l’inscrit, l’écran de consentement affiche l’apparence d’un service légitime et peut même pointer vers un téléchargement hostile. Sans politique sur les adresses de redirection, le seul champ que le client impose est aussi celui qui décide où partent les codes d’autorisation. Et sans distinction entre clients vérifiés et clients auto-enregistrés, un inconnu obtient les mêmes portées qu’un partenaire contractuel.

🦫 Explication de la marmotte 🍫

Section intitulée « 🦫 Explication de la marmotte 🍫 »

Pour qu’une application permette de se connecter avec un compte tiers, il faut qu’elle sache où s’adresser et que le service tiers la connaisse. Deux mécanismes automatisent ces deux étapes.

Le premier est la découverte. Le service tiers publie, à une adresse standardisée obtenue en ajoutant un suffixe connu à son nom, un petit fichier qui donne toutes ses adresses et toutes ses clés de vérification. L’application le télécharge et se configure toute seule.

Le danger est immédiat : qui contrôle ce fichier contrôle les clés, donc peut fabriquer de fausses preuves d’identité que l’application croira. Deux précautions sont obligatoires. Vérifier que le certificat du serveur correspond bien au nom attendu, ce qui bloque les détournements de réseau. Et surtout vérifier que le nom inscrit dans le fichier est exactement le nom auquel on s’est adressé, et exactement celui qui figurera dans les attestations reçues ensuite. Sans cette comparaison, un attaquant peut publier sur son propre site un fichier qui prétend appartenir au service visé.

Le second mécanisme est l’enregistrement automatique. L’application s’inscrit elle-même auprès du service tiers en déclarant son nom, son logo, ses adresses de retour, et reçoit un identifiant. Rien ne vérifie que ce qu’elle déclare est vrai. Le document de référence met d’ailleurs en garde : une application malveillante peut reprendre le nom et le logo d’une application connue, de sorte que l’écran de consentement présente à l’utilisateur l’apparence d’un service de confiance. Elle peut aussi fournir une adresse de politique de confidentialité qui pointe vers un téléchargement hostile.

Ce mécanisme est devenu courant, parce que les outils et les assistants automatiques se connectent à des services qu’ils ne connaissaient pas à l’avance. Il ne faut pas l’interdire, mais le cadrer : exiger un jeton d’accès pour pouvoir s’inscrire, contrôler les adresses déclarées, signaler clairement dans l’écran de consentement qu’une application s’est inscrite seule, et ne pas lui accorder les mêmes permissions qu’à un partenaire vérifié.

À lire aussi

Pages voisines

Découverte et enregistrement dynamique de client

Elle cite

: les deux pages se citent l’une l’autre.