Abandonner l’utilisation des revendications d’e-mail pour l’identification de l’utilisation ou l’autorisation

  • Article

Cet article est destiné à fournir des conseils aux développeurs dont les applications utilisent actuellement un modèle non sécurisé avec revendication e-mail pour l’autorisation, pouvant entraîner une prise de contrôle de compte totale par un autre utilisateur. Poursuivez la lecture pour découvrir si votre application est concernée, ainsi que les mesures correctives.

Comment déterminer si mon application est concernée ?

Microsoft recommande d’examiner le code source de l’application à la recherche des modèles suivants :

  • Une revendication mutable, telle que email, est utilisée à des fins d’identification unique d’un utilisateur
  • Une revendication mutable, telle que email, est utilisée pour autoriser l’accès d’un utilisateur aux ressources

Ces modèles sont considérés comme non sécurisés, car les utilisateurs sans boîte aux lettres configurée peuvent définir n’importe quelle adresse e-mail pour leur attribut de messagerie (SMTP principal). Le fait que cet attribut provienne d’une adresse e-mail vérifiée n’est pas garanti. Lorsqu’une revendication d’e-mail avec un propriétaire de domaine non vérifié est utilisée pour l’autorisation, tout utilisateur sans boîte aux lettres approvisionnée peut obtenir un accès non autorisé en modifiant son attribut de messagerie pour emprunter l’identité d’un autre utilisateur.

Un e-mail est considéré comme vérifié par le propriétaire du domaine si :

  • Le domaine appartient au locataire où réside le compte d’utilisateur et l’administrateur du locataire a effectué la vérification du domaine.
  • L’e-mail provient d’un compte Microsoft (MSA)
  • L’e-mail provient d’un compte Google
  • L’e-mail a été utilisé pour l’authentification à l’aide du flux de code secret à usage unique (OTP)

Il convient également de noter que les comptes Facebook et SAML/WS-Fed n’ont pas de domaines vérifiés.

Ce risque d’accès non autorisé n’a été détecté que dans les applications multilocataires, où un utilisateur d’un locataire peut élever ses privilèges d’accès aux ressources d’un autre locataire via la modification de son attribut de messagerie.

Comment protéger mon application immédiatement ?

Pour sécuriser les applications contre les erreurs avec des adresses e-mail non vérifiées, toutes les nouvelles applications multilocataires sont automatiquement activées vers un nouveau comportement par défaut qui supprime les adresses e-mail avec des propriétaires de domaine non vérifiés des jetons à compter de juin 2023. Ce comportement n’est pas activé pour les applications monolocataires et les applications multilocataires avec une activité de connexion précédente avec des adresses e-mail non vérifiées du propriétaire du domaine.

Selon votre scénario, vous pouvez déterminer que les jetons de votre application doivent continuer à recevoir des e-mails non vérifiés. Bien que ce ne soit pas recommandé pour la plupart des applications, vous pouvez désactiver le comportement par défaut en définissant la propriété removeUnverifiedEmailClaim dans l’objet authenticationBehaviors de l’API d’applications dans Microsoft Graph.

En définissant removeUnverifiedEmailClaim sur false, votre application reçoit des revendications email potentiellement non vérifiées et soumet les utilisateurs à un risque de prise de contrôle du compte. Si vous désactivez ce comportement pour ne pas interrompre les flux de connexion utilisateur, il est vivement recommandé de migrer vers un mappage de revendications de jeton d’identification unique dès que possible, comme décrit dans les conseils ci-dessous.

Identification des configurations non sécurisées et exécution de la migration de base de données

Vous ne devez jamais utiliser de revendications mutables (telles que email, preferred_username, etc.) comme identificateurs pour effectuer des vérifications d’autorisation ou indexer des utilisateurs dans une base de données. Ces valeurs sont réutilisables et peuvent exposer votre application à des attaques par élévation des privilèges.

L’exemple de pseudo-code suivant permet d’illustrer le modèle non sécurisé d’identification/d’autorisation de l’utilisateur :

 // Your relying party (RP) using the insecure email claim for user identification (or authorization)
 MyRPUsesInsecurePattern()
 {
    // grab data for the user based on the email (or other mutable) attribute
    data = GetUserData(token.email)

    // Create new record if no data present (This is the anti-pattern!)
    if (data == null) 
    {
        data = WriteNewRecords(token.email)
    }

    insecureAccess = data.show // this is how an unverified user can escalate their privileges via an arbirarily set email
 }

Une fois que vous avez déterminé que votre application s’appuie sur cet attribut non sécurisé, vous devez mettre à jour la logique métier pour réindexer les utilisateurs sur un identificateur global unique (GUID).

Les applications multilocataires doivent s’indexer sur un mappage de deux revendications d’identification unique, tid + oid. Cela segmente les locataires par le tid, et segmente les utilisateurs par leur oid.

Utilisation de la revendication facultative xms_edov pour déterminer l’état de vérification d’e-mail et migrer les utilisateurs

Pour aider les développeurs dans le processus de migration, nous avons introduit une revendication facultative, xms_edov, une propriété booléenne qui indique si le propriétaire du domaine de courrier a été vérifié ou non.

xms_edov peut être utilisé pour aider à vérifier l’adresse e-mail d’un utilisateur avant de migrer sa clé primaire vers des identificateurs uniques, tels que oid. L’exemple de pseudocode suivant illustre comment cette revendication peut être utilisée dans le cadre de votre migration.

// Verify email and migrate users by performing lookups on tid+oid, email, and xms_edov claims
MyRPUsesSecurePattern()
{
    // grab the data for a user based on the secure tid + oid mapping
    data = GetUserData(token.tid + token.oid)

    // address case where users are still indexed by email
    if (data == null) 
    {
        data = GetUserData(token.email)

        // if still indexed by email, update user's key to GUID
        if (data != null) 
        {

            // check if email domain owner is verified 
            if (token.xms_edov == false) 
            {
                yourEmailVerificationLogic()
            }

            // migrate primary key to unique identifier mapping (tid + oid)
            data.UpdateKeyTo(token.tid + token.oid)
        }

        // new user, create new record with the correct (secure) key
        data = WriteNewRecord(token.sub)
    }

    secureAccess = data.show
}

La migration vers un mappage global unique garantit que chaque utilisateur est principalement indexé avec une valeur qui ne peut pas être réutilisée ou utilisée pour emprunter l’identité d’un autre utilisateur. Une fois que vos utilisateurs sont indexés sur un identificateur global unique, vous êtes prêt à corriger toute logique d’autorisation potentielle qui utilise la revendication email.

Mettre à jour la logique d’autorisation avec une validation appropriée des revendications

Si votre application utilise email (ou toute autre revendication mutable) à des fins d’autorisation, consultez Sécuriser des applications et des API par la validation des revendications et mettez en œuvre les vérifications appropriées.

Étapes suivantes