Udostępnij za pośrednictwem

Migrowanie z dala od używania oświadczeń poczty e-mail na potrzeby identyfikacji lub autoryzacji użytkownika

  • Artykuł

Ten artykuł zawiera wskazówki dla deweloperów, których aplikacje używają obecnie niezabezpieczonego wzorca, w którym oświadczenie e-mail jest używane do autoryzacji, co może prowadzić do pełnego przejęcia konta przez innego użytkownika. Kontynuuj czytanie, aby dowiedzieć się więcej na temat wpływu aplikacji i kroków korygowania.

Jak mogę wiedzieć, czy moja aplikacja ma wpływ?

Firma Microsoft zaleca przejrzenie kodu źródłowego aplikacji i określenie, czy istnieją następujące wzorce:

  • Oświadczenie modyfikowalne, takie jak email, jest używane do celów unikatowego identyfikowania użytkownika
  • Oświadczenie modyfikowalne, takie jak email jest używane do celów autoryzowania dostępu użytkownika do zasobów

Te wzorce są uznawane za niezabezpieczone, ponieważ użytkownicy bez aprowizowanej skrzynki pocztowej mogą mieć dowolny adres e-mail ustawiony dla atrybutu Poczta podstawowa SMTP. Ten atrybut nie ma gwarancji, że pochodzi z zweryfikowanego adresu e-mail. Gdy oświadczenie e-mail z niezweryfikowanym właścicielem domeny jest używane do autoryzacji, każdy użytkownik bez aprowizowanej skrzynki pocztowej może uzyskać nieautoryzowany dostęp, zmieniając atrybut poczty na personifikację innego użytkownika.

Wiadomość e-mail jest uważana za zweryfikowaną przez właściciela domeny, jeśli:

  • Domena należy do dzierżawy, w której znajduje się konto użytkownika, a administrator dzierżawy dokonał weryfikacji domeny
  • Wiadomość e-mail pochodzi z konta Microsoft (MSA)
  • Adres e-mail pochodzi z konta Google
  • Wiadomość e-mail została użyta do uwierzytelniania przy użyciu przepływu jednorazowego kodu dostępu (OTP)

Należy również zauważyć, że konta Facebook i SAML/WS-Fed nie mają zweryfikowanych domen.

To ryzyko nieautoryzowanego dostępu zostało znalezione tylko w aplikacjach wielodostępnych, ponieważ użytkownik z jednej dzierżawy może eskalować swoje uprawnienia dostępu do zasobów z innej dzierżawy poprzez modyfikację atrybutu poczty.

Jak mogę natychmiast chronić moją aplikację?

Aby zabezpieczyć aplikacje przed błędami z niezweryfikowanymi adresami e-mail, wszystkie nowe aplikacje wielodostępne są automatycznie włączane do nowego domyślnego zachowania, które usuwa adresy e-mail z niezweryfikowanymi właścicielami domeny z tokenów od czerwca 2023 r. To zachowanie nie jest włączone dla aplikacji z jedną dzierżawą i aplikacji wielodostępnych z poprzednimi działaniami logowania z niezweryfikowanymi adresami e-mail właściciela domeny.

W zależności od scenariusza możesz określić, że tokeny aplikacji powinny nadal otrzymywać niezweryfikowane wiadomości e-mail. Chociaż nie jest to zalecane w przypadku większości aplikacji, można wyłączyć domyślne zachowanie, ustawiając removeUnverifiedEmailClaim właściwość w obiekcie authenticationBehaviors interfejsu API aplikacji w programie Microsoft Graph.

Po ustawieniu wartości removeUnverifiedEmailClaimfalseaplikacja będzie otrzymywać email oświadczenia, które są potencjalnie niezweryfikowane i podlegają użytkownikom ryzyko przejęcia. Jeśli to zachowanie jest wyłączane, aby nie przerywać przepływów logowania użytkowników, zdecydowanie zaleca się przeprowadzenie migracji do unikatowego mapowania oświadczeń tokenu tak szybko, jak to możliwe, zgodnie z poniższymi wskazówkami.

Identyfikowanie niezabezpieczonych konfiguracji i przeprowadzanie migracji bazy danych

Nigdy nie należy używać oświadczeń modyfikowalnych (takich jak email, preferred_usernameitd.) jako identyfikatorów do przeprowadzania kontroli autoryzacji lub indeksowania użytkowników w bazie danych. Te wartości są wielokrotnego użytku i mogą uwidaczniać aplikację w przypadku ataków eskalacji uprawnień.

Poniższy przykład pseudokodu pomaga zilustrować niezabezpieczony wzorzec identyfikacji/autoryzacji użytkownika:

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

Po ustaleniu, że aplikacja opiera się na tym niezabezpieczonym atrybucie, należy zaktualizować logikę biznesową, aby ponownie indeksować użytkowników na globalnie unikatowy identyfikator (GUID).

Aplikacje Mutli-tenant powinny indeksować mapowanie dwóch unikatowych oświadczeń: tid + oid. Spowoduje to segmentowanie dzierżaw według tidużytkowników , i segmentów według ich oidwartości .

Korzystanie z opcjonalnego xms_edov oświadczenia w celu określenia stanu weryfikacji wiadomości e-mail i migrowania użytkowników

Aby pomóc deweloperom w procesie migracji, wprowadziliśmy opcjonalne oświadczenie , właściwość logiczną wskazującą, xms_edovczy właściciel domeny poczty e-mail został zweryfikowany.

xms_edov może służyć do weryfikowania wiadomości e-mail użytkownika przed migracją klucza podstawowego do unikatowych identyfikatorów, takich jak oid. Poniższy przykład pseudokodu ilustruje sposób użycia tego oświadczenia w ramach migracji.

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

Migracja do globalnie unikatowego mapowania gwarantuje, że każdy użytkownik jest przede wszystkim indeksowany wartością, która nie może być ponownie użyta lub nadużywana do personifikacji innego użytkownika. Gdy użytkownicy będą indeksowani na unikatowym identyfikatorze globalnym, możesz naprawić dowolną potencjalną logikę autoryzacji korzystającą email z oświadczenia.

Aktualizowanie logiki autoryzacji przy użyciu prawidłowej weryfikacji oświadczeń

Jeśli aplikacja używa email (lub innego oświadczenia modyfikowalnego) do celów autoryzacji, należy zapoznać się z bezpiecznymi aplikacjami i interfejsami API, sprawdzając oświadczenia i implementując odpowiednie kontrole.

Następne kroki