Freigeben über

Migrieren von der Verwendung von E-Mail-Ansprüchen zur Benutzererkennung oder -autorisierung

  • Artikel

Dieser Artikel enthält Anleitungen für Entwickler, deren Anwendungen derzeit ein unsicheres Muster verwenden, bei dem der E-Mail-Anspruch zum Autorisieren verwendet wird, was zu einer vollständigen Kontoübernahme durch andere Benutzer führen kann. Lesen Sie weiter, um mehr darüber zu erfahren, ob Ihre Anwendung betroffen ist und welche Schritte Sie zur Wartung ausführen können.

Woran erkenne ich, ob meine Anwendung betroffen ist?

Microsoft empfiehlt, den Anwendungsquellcode zu überprüfen und zu ermitteln, ob die folgenden Muster vorhanden sind:

  • Ein veränderbarer Anspruch, z. B email, wird verwendet, um Benutzer*innen eindeutig zu identifizieren
  • Ein veränderlicher Anspruch wie email wird zum Autorisieren des Benutzerzugriffs auf Ressourcen verwendet.

Diese Muster gelten als unsicher, da Benutzer*innen ohne bereitgestelltes Postfach eine beliebige E-Mail-Adresse für ihr E-Mail-Attribut (Primäre SMTP-Adresse) festlegen können. Es ist nicht garantiert, dass dieses Attribut von einer überprüften E-Mail-Adresse stammt. Wenn ein E-Mail-Anspruch mit einem nicht überprüften Domänenbesitzer für die Autorisierung verwendet wird, können alle Benutzer ohne bereitgestelltes Postfach potenziell unbefugten Zugriff erhalten, indem sie ihr E-Mail-Attribut ändern und sich als ein anderer Benutzer ausgeben.

Eine E-Mail gilt unter folgenden Umständen als vom Domänenbesitzer überprüft:

  • Die Domäne gehört zu dem Mandanten, in dem sich das Benutzerkonto befindet, und der Mandantenadministrator hat die Domäne überprüft
  • Die E-Mail stammt von einem Microsoft-Konto (MSA)
  • Die E-Mail stammt von einem Google-Konto
  • Die E-Mail wurde für die Authentifizierung mit dem Einmal-Passcode (One-Time-Passcode, OTP) verwendet

Beachten Sie auch, dass Facebook- und SAML/WS-Fed-Konten keine verifizierten Domains aufweisen.

Dieses Risiko eines nicht autorisierten Zugriffs wurde nur in mehrinstanzenfähigen Apps festgestellt, da ein/e Benutzer*in von einem Mandanten ihre/seine Berechtigungen zum Zugriff auf Ressourcen aus einem anderen Mandanten durch Änderung des E-Mail-Attributs ausweiten könnte.

Gewusst wie ich meine Anwendung sofort schützen kann?

Um Anwendungen vor Fehlern mit nicht überprüften E-Mail-Adressen zu schützen, werden ab Juni 2023 alle neuen mehrinstanzenfähigen Anwendungen automatisch für ein neues Standardverhalten aktiviert, das E-Mail-Adressen mit nicht überprüften Domänenbesitzern aus Token entfernt. Dieses Verhalten ist für einzelinstanzenfähige und mehrinstanzenfähige Anwendungen mit vorheriger Anmeldeaktivität mit nicht überprüften E-Mail-Adressen des Domänenbesitzers nicht aktiviert.

In Abhängigkeit von Ihrem Szenario können Sie bestimmen, dass die Token Ihrer Anwendung weiterhin nicht überprüfte E-Mails erhalten sollen. Obwohl dies für die meisten Anwendungen nicht empfohlen wird, können Sie das Standardverhalten deaktivieren, indem Sie die removeUnverifiedEmailClaim-Eigenschaft im authenticationBehaviors-Objekt der Anwendungs-API in Microsoft Graph festlegen.

Wenn Sie removeUnverifiedEmailClaim auf false festlegen, erhält Ihre Anwendung email-Ansprüche, die potenziell nicht überprüft sind und Benutzer dem Risiko der Kontoübernahme aussetzen. Wenn Sie dieses Verhalten deaktivieren, um Benutzeranmeldungsflows nicht zu unterbrechen, wird dringend empfohlen, so bald wie möglich zu einer eindeutig identifizierenden Tokenanspruchszuordnung zu migrieren, wie in der folgenden Anleitung beschrieben.

Identifizieren unsicherer Konfigurationen und Durchführen der Datenbankmigration

Sie sollten niemals veränderbare Ansprüche (z. B. email, preferred_username usw.) als Bezeichner verwenden, um Autorisierungsprüfungen durchzuführen oder Benutzer*innen in einer Datenbank zu indizieren. Diese Werte sind wiederverwendbar und können Ihre Anwendung für Rechteerweiterungsangriffe anfällig machen.

Das folgende Pseudocodebeispiel veranschaulicht das unsichere Muster der Benutzererkennung/-autorisierung:

 // 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
 }

Nachdem Sie festgestellt haben, dass Ihre Anwendung auf dieses unsichere Attribut angewiesen ist, müssen Sie die Geschäftslogik aktualisieren, um Benutzer mit einem globalen eindeutigen Bezeichner (Global Unique Identifier, GUID) neu zu indizieren.

Mehrinstanzenfähige Anwendungen sollten für eine Zuordnung von zwei eindeutig identifizierenden Ansprüchen indiziert werden, tid + oid. Dadurch werden Mandanten nach der tid und Benutzer nach ihrer oid segmentiert.

Verwenden des optionalen Anspruchs xms_edov zum Ermitteln des E-Mail-Überprüfungsstatus und Migrieren von Benutzern

Um Entwickler beim Migrationsprozess zu unterstützen, haben wir einen optionalen Anspruch eingeführt, xms_edov, eine boolesche Eigenschaft, die angibt, ob der Besitzer der E-Mail-Domäne überprüft wurde oder nicht.

xms_edov kann verwendet werden, um die E-Mails eines Benutzers vor der Migration seines Primärschlüssels zu eindeutigen Bezeichnern wie oid zu überprüfen. Im folgenden Pseudocodebeispiel wird veranschaulicht, wie dieser Anspruch im Rahmen Ihrer Migration verwendet werden kann.

// 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
}

Durch die Migration zu einer global eindeutigen Zuordnung wird sichergestellt, dass jeder Benutzer primär mit einem Wert indiziert wird, der nicht wiederverwendet oder zum Annehmen der Identität eines anderen Benutzers missbraucht werden kann. Sobald Ihre Benutzer mit einem global eindeutigen Bezeichner indiziert wurden, können Sie jede potenzielle Autorisierungslogik beheben, die den email-Anspruch verwendet.

Aktualisieren der Autorisierungslogik mit ordnungsgemäßer Anspruchsüberprüfung

Wenn Ihre Anwendung email (oder einen anderen veränderbaren Anspruch) zu Autorisierungszwecken verwendet, sollten Sie den Artikel Sichern von Anwendungen und APIs durch Überprüfen von Ansprüchen lesen und die entsprechenden Überprüfungen implementieren.

Nächste Schritte