Un article récent de CNET annonce une faille dans le protocole OpenID Connect. Ce n’est pas vraiment une découverte et la mise en oeuvre reste confidentielle. Pourtant il existe bien une faiblesse qui pourrait être comblée en demandant aux applications clientes de fournir les méta données de leur service.
OpenID Connect = OpenID + OAuth
La nouvelle version du protocole OpenID validée en février de cette année, entérine ce que proposait déjà Yahoo! depuis quelques temps. C’est la fin de l’illusion qu’une identité sur le Net qui pouvait être simplement une URL. Il faut maintenant être affilié à un fournisseur. Les points clés du protocole sont:
- Une application demande pour vous l’autorisation de lire vos informations (OAuth)
- Le fournisseur qui détient vos informations demande votre authentification
- L’application transforme cette demande d’autorisation en demande d’accès (OAuth)
- Finalement les informations sont lues par l’application (OpenID) et une session est ouverte
HTTP 302 au coeur des protocoles de sécurité
Toutes les implémentations des protocoles de sécurité avec un client navigateur utilisent la redirection. Dans OpenID Connect elle intervient dans tous les échanges. Les serveurs se servent de votre butineur pour faire rebondir des informations, ou vous diriger vers des pages d’authentification. Pour OpenID Connect la faiblesse réside dans le fait que le serveur d’autorisation utilise une URL fournie par l’application cliente et ce lien peut vous rediriger n’importe où. La faille en question est bien documentée dans l’analyse de sécurité faite du protocole (voir RFC 6819) et Google par exemple traite déjà ce problème, ce qui n’était pas le cas pour LinkedIn !
vulnérable ou faillible
En premier il faut voler l’identifiant d’une application et son secret. Pour cela le site malveillant doit attaquer soit le serveur d’autorisation, soit l’application cliente.
En second la mise en oeuvre suppose de mettre en ligne un site qui va “piéger” des utilisateurs en leur présentant un leurre. Ce site va demander l’autorisation de lire des données personnelles de l’utilisateur, qui devra s’authentifier. Pour cela il utilisera les données volées (clienId, secretId).
En troisième, si le serveur d’autorisation ne vérifie pas l’URL de redirection à l’issue de l’authentification, la faiblesse est exploitable et va permettre à un site inconnu de poursuivre l’échange (demander l’autorisation d’accès). Ce site va finalement capter les informations.
En quatrième, pour rester discret, il devra rediriger l’utilisateur, vers le site initial, qui lui-même acceptera l’accès.
Ce cinquième point reposera sur une vulnérabilité de l’application cliente qu’il faudra découvrir, par exemple le fait de recevoir le jeton d’autorisation et relancer une demande d’échange du jeton d’accès.
Mais on peut faire plus simple, en proposant un site alléchant qui ne tiendra pas ses promesses. Vous serez déçu mais vos informations aurons été captées.
vérifier, encore vérifier
Si le serveur d’autorisation souhaite aller plus loin qu’une simple vérification de l’URL de retour au client, il pourrait aussi vérifier le certificat du serveur que cible ce lien. En effet il n’est pas évident que la machine qui a fait la demande d’authentification, soit la même que celle qui traitera la réponse. De plus la demande est sans doute tombée sur un reverse proxy qui a fait cette vérification.
Mais dans la phase de validation de l’URL nous sommes derrière le proxy et n’avons plus cette information. Comme nous allons faire une redirection au travers du navigateur, il serait élégant de vérifier pour l’utilisateur la cohérence de ce lien.
Mais force est de constater que personne n’a encore pensé à cette vérification, sinon on demanderait au développeur de déposer son certificat public en même temps que l’URL de redirection pendant la phase d’inscription de son application cliente.
En effet cette vérification devrait consister à faire un handshake avec le serveur de redirection mais aussi vérifier que le certificat déposé soit identique à celui présenté par le serveur.
les méta données de SAML
La base de la sécurité de SAML repose sur l’échange entre le fournisseur d’identité et le fournisseur de service des données de connexion et des clés publiques.
Finalement si le développeur fournit son certificat public au serveur d’autorisation (en plus de l’URL de redirection) c’est déjà la moitié des méta données de SAML.
Stéphane
Crédit photo : © Sergey Nivens - Fotolia.com
Architecte des systèmes d'identité et d'accès, je dispose d'une bonne culture de développement. Proche des utilisateurs je défends bec et ongle leurs intérêts dans les projets d'intégration.