Aperçu
< 9.0.0 ou la bibliothèque Lock dans une version < 11.0.0 pour l’authentification interdomaines par nom d’utilisateur et mot de passe — aussi appelée connexion intégrée. De plus, toute utilisation interdomaines du point de terminaison de l’Authentication API /usernamepassword/login en dehors de ces bibliothèques peut aussi être touchée.
Après la vérification des identifiants de l’utilisateur sur /usernamepassword/login, un formulaire HTML est généré dans le navigateur de l’utilisateur et exécuté automatiquement. Il envoie par POST un (JWT) vers le point de terminaison /login/callback. Ce jeton authentifié conserve l’état lié à l’identité de l’utilisateur; cela ne peut pas être fait directement en raison des restrictions de gestion de session interdomaines imposées par la plupart des navigateurs modernes. En raison de l’absence d’association de session, cet envoi de formulaire est vulnérable aux attaques CSRF. Un attaquant disposant d’identifiants utilisateur valides dans un locataire Auth0 peut les utiliser pour obtenir un tel formulaire, puis recourir à des techniques comme l’ingénierie sociale ou le détournement de clics pour amener le navigateur d’une victime à l’exécuter. La victime aura alors une session de connexion dans le locataire Auth0 sous le compte de l’attaquant — et sera donc reconnue comme l’attaquant par toute application en aval dans sa fédération. Si l’utilisateur effectue des actions pendant qu’il est connecté de cette façon malveillante, ces actions et toute information connexe seront visibles pour l’attaquant.
L’attaque ne permet aucune élévation de privilèges de la part de l’attaquant, et les actions de la victime visibles pour l’attaquant sont limitées aux autorisations qui ont été accordées à cet attaquant dans le système. La victime sera également entièrement reconnue comme l’attaquant dans la fédération et pourrait donc voir des renseignements sur le compte ou d’autres indices contextuels révélant qu’elle n’agit pas dans le cadre de son propre compte.
Suis-je concerné?
Comment corriger cela ?
/usernamepassword/login continuera de fonctionner pour les connexions à partir de la page hébergée sur /login; toutefois, puisqu’il s’agit de connexions sur le même domaine, elles seront protégées contre les attaques CSRF. Autrement, la désactivation de l’indicateur désactivera l’authentification inter-domaine sur ce point de terminaison.
Pour les applications qui utilisent auth0.js version < 9.0.0 ou Lock version < 11.0.0, cela peut empêcher les utilisateurs de se connecter. La mise à niveau vers auth0.js version > 9.0.0 ou Lock version > 11.0.0 rétablira l’authentification intégrée par nom d’utilisateur et mot de passe à l’aide de l’authentification inter-origine (notez les limites). Il est également recommandé de migrer vers Universal Login.
Les Private SaaS Appliances exécutant des versions > 14591 avec l’indicateur de l’API Lock ancien désactivé ne sont pas touchés par cette vulnérabilité.