Faille Facebook : non le SSO n’est pas un problème !

Ces dernières semaines, pléthore d’articles ont fourni des détails sur la nature de la faille Facebook dévoilée le 28 septembre dernier. On y comprend que les « jetons », « tokens », ou « clés d’accès », etc. -selon comment les différents articles les nomment – de 50 à 100 millions d’utilisateurs ont été piratés, mais que Facebook les a invalidés quasi immédiatement.

Certains articles mettent plus particulièrement en doute la fonction de SSO (Single Sign-On, ou Authentification unique) apportée par Facebook, car elle permet à divers sites d’utiliser le jeton Facebook de ses utilisateurs pour les authentifier de manière transparente. Si ces jetons ont été invalidés sur le monde Facebook, le sont-ils pour autant sur les sites qui les utilisent ?

Techniquement, de quoi parle-t-on ?

La notion de « Token » est assez large. Techniquement elle peut correspondre aux mécanismes utilisés dans les protocoles de fédération d’identités (on parle d’« Assertion », « Access Token », « ID Token », « Refresh Token ») que l’on détaillera ci-dessous, aux cookies des applications (par exemple le « JSESSIONID » du serveur d’applications Tomcat) ou aux jetons des solutions de SSO, qu’on appelle également « Token » ou « Cookie » selon les solutions.

Sans rentrer dans les détails de ce que représente le Token Facebook exactement, le fait est qu’il ait été volé, et que toute application, site ou système de SSO qui lui fait confiance s’expose notamment à des usurpations d’identités et à toutes les conséquences associées, quelle que soit l’implémentation technique choisie. Pour parer à cela, il faudrait appliquer quelques bonnes pratiques, comme par exemple permettre de révoquer les jetons utilisateurs, et disposer ainsi de mécanisme antivol de type CSRF (cross-site request forgery) dans le jeton principal pour qu’il ne soit utilisable qu’une seule fois par exemple.

Dans le cas présent, le jeton Facebook ayant été invalidé par la firme californienne, en est-il pour autant de même pour les sites ou les solutions de SSO qui le consomment ? Encore une fois, tout dépend de ce qui est implémenté dans les sites ou applications en question.

D’un point de vue technique, Facebook s’appuie sur les protocoles de fédération d’identités Oauth2/OpenIDConnect, avec quelques adaptations. Ces protocoles définissent les 4 « jetons » suivants

• Authorization code : c’est un OTP (One Time Password) utilisé dans l’échange OAuth2/OpenIDConnect pour obtenir ensuite les autres jetons. Son caractère OTP le rend peu sensible au type d’attaque vécu par Facebook.
• Access Token : il dure plusieurs heures, voire plus, et représente les droits de l’utilisateur. Pour l’exploiter il faut normalement appeler des composants liés à un « Authorization Server », ou fournisseur d’Identité : « token end point », « user end point », « resource server ». Ces services sont notamment en mesure de « bloquer » un token qui aurait été invalidé.
• Refresh Token : il dure plusieurs jours, et permet à l’application de redemander des Access Token même si l’utilisateur n’est pas connecté. Il est de fait de plus en plus décrié en termes de sécurité. Le fait de devoir appeler l’Authorization Server pour obtenir un Access token depuis le Refresh token permet à l’Authorization Server de bloquer un Refresh Token piraté.
• ID Token : il dure en moyenne quelques heures, ou plus, et représente l’identité de l’utilisateur. Il est stocké sous un format « ouvert » nommé JWT, et permet aux applications de le vérifier sans avoir à appeler l’Authorization Server, ce qui a pour effet que ce dernier ne peut pas forcément toujours bloquer un ID Token donné à une application. On est donc dépendant dans ce cas de l’application, et de la manière dont elle est codée.

De manière plus générale, lorsqu’un Authorization Server fournit un jeton, il ne contrôle pas ce qu’en font les applications une fois l’authentification réalisée sur la base de ce jeton. Après la phase d’authentification, l’application ouvre sa propre session utilisateur et la gère de façon autonome. Ainsi elle peut faire le choix de ne plus jamais appeler l’Authorization Server et garder ses utilisateurs connectés très longtemps.

C’est bien là le cœur de la critique actuelle contre le mécanisme de SSO, mis en avant par la faille Facebook. 

Plus que la fonction de SSO, c’est en réalité la fonction « rester connecté » qui pose problème

Il faut avoir conscience que les solutions de SSO ne fonctionnent pas tout à fait de la même façon dans le monde B2C et dans le monde B2B. Sans parler de généralisation du concept de « security by design », le monde professionnel – de par ses obligations légales ou business – a sûrement une approche un peu plus stricte en matière de sécurité des applications que le monde grand public, qui est la plupart du temps gouverné par des approches time-to-market.

Dans le monde professionnel par exemple, la durée de vie des jetons SSO est valable en général au maximum quelques heures. Cela rend ainsi l’exposition aux risques restreinte à un temps beaucoup plus court que dans le cas du monde grand public, où il est commun de laisser des jetons valides plusieurs mois, par volonté de ne pas trop contraindre le parcours utilisateurs.

En cas de vol du jeton principal du SSO, on peut peut-être propager l’attaque dans certains cas, mais le « rester connecté » permet en plus de prolonger la fenêtre d’exploitation de l’attaque une fois le jeton principal récupéré.

Quelle confiance accorder à un jeton Facebook ?

Certaines applications ont une confiance trop aveugle en l’identité externe fournie par des grands fournisseurs d’identités tels que Facebook ou Google. Ce dernier a par ailleurs annoncé dans la foulée de la découverte de la faille Facebook, l’arrêt pur et simple de son réseau social Google+ d’ici à août 2019, suite à la révélation par la presse d’une vulnérabilité exposant les données personnelles de ses utilisateurs. Si le problème n’est pas le même que celui de la faille Facebook, il met également en évidence ce problème de confiance.

Pourtant il existe des solutions pour sécuriser l’exploitation de ces mécanismes.

En effet, l’une des bonnes pratiques est de gérer plusieurs niveaux d’authentification, et d’y associer le bon contenu en tenant compte du niveau de sensibilité de ce dernier. Prenons l’exemple d’un site qui offrirait du contenu vidéo (films, retransmissions de compétitions sportives) à ses utilisateurs et qui s’appuierait – entre autre – sur la consommation d’un jeton Facebook.
On commence par définir des niveaux d’authentification : 

• Niveau 0 : anonyme
• Niveau 1 : le « rester connecté » demandé par l’utilisateur, ou l’authentification depuis un compte fédéré avec un réseau social (Facebook…)
• Niveau 2 : authentification login/password du site ou – bien mieux – authentification multi-facteur (MFA pour « Multi-Factor Authentication)

Ensuite, on peut y associer des niveaux de sécurité :

• Niveau 0 : pages publiques
•  Niveau 1 : contenu non lié aux droits (ex : noter un film ou un match, faire un commentaire sur un article…) ou lié à des droits simples de consommation de contenu (ex : regarder un film ou un match…)
•  Niveau 2 : gestion du compte (ex : changer de mot de passe, accéder à Mon compte…)

Avec un tel système, et dans cet exemple, on ne pourra modifier les informations du compte que si on est connecté explicitement avec son compte client. Dans ce cas, une attaque comme celle de Facebook ne permet pas de récupérer les informations du compte utilisateur, mais seulement de l’utiliser pour visualiser un film ou un match. Si c’est une perte – assumée dans ce cas – pour le site, l’identité de ses clients ne sera pas compromise ou un risque pour autant. A noter dans le cas du niveau 2 que les technologies d’authentification multi-facteurs, pour peu qu’elles soient bien pensées, s’avèrent être de plus en plus le meilleur compromis entre sécurité et expérience utilisateur.

Security by design, l’affaire de tous !

L’intégration de la sécurité dès la conception ne doit plus être un slogan, mais une réalité.

Quand les applications « codent » leur connexion à des sources externes, sans réelles compétences sur le sujet sécurité, ou à moindre coût, elles s’exposent très probablement à des risques. Facebook a précisé que pour tous ceux qui ont utilisé leur SDK (Software Development Kit) officiel, la propagation de l’invalidation des jetons compromis serait effective. Quid des autres ? Evidemment non.

Une bonne pratique en entreprise est de déléguer la réalisation des fonctions liées à la sécurité des applications aux équipes sécurité, et non pas aux équipes de développement web par exemple. Ces dernières doivent uniquement, sur ce point, se limiter à appeler ou configurer les fonctions, framework et solutions industrielles et professionnelles mis à disposition par les équipes sécurité.