Sdílet prostřednictvím

Upustit od používání e-mailových tvrzení pro identifikaci nebo autorizaci uživatele

  • Článek

Cílem tohoto článku je poskytnout vývojářům, jejichž aplikace aktuálně používají nezabezpečený vzor, kde se e-mailová deklarace používá k autorizaci, což může vést k úplnému převzetí účtu jiným uživatelem. Pokračujte ve čtení a získejte další informace o tom, jestli se vaše aplikace týká, a kroky pro nápravu.

Jak zjistím, zda je moje aplikace ovlivněna?

Microsoft doporučuje zkontrolovat zdrojový kód aplikace a určit, jestli existují následující vzory:

  • Proměnlivá deklarace identity, například email, se používá pro účely jedinečné identifikace uživatele.
  • Proměnlivý přístupový požadavek, jako je například email, se používá pro účely autorizace přístupu uživatele k prostředkům.

Tyto vzory jsou považovány za nezabezpečené, protože uživatelé bez zřízené poštovní schránky můžou mít pro atribut Mail (Primary SMTP) nastavenou libovolnou e-mailovou adresu. U tohoto atributu není zaručeno, že pochází z ověřené e-mailové adresy. Když se k autorizaci použije e-mailový požadavek s neověřeným vlastníkem domény, může každý uživatel bez zřízené poštovní schránky změnou atributu E-mail získat neoprávněný přístup tím, že se vydává za jiného uživatele.

E-mail se považuje za ověřený vlastníkem domény, pokud:

  • Doména patří do tenanta, ve kterém se nachází uživatelský účet, a správce tenanta provedl ověření domény.
  • E-mail pochází z účtu Microsoft (MSA)
  • E-mail je z účtu Google.
  • E-mail byl použit k ověření pomocí toku jednorázového hesla (OTP).

Je také třeba poznamenat, že účty Facebook a SAML/WS-Fed nemají ověřené domény.

Toto riziko neoprávněného přístupu bylo nalezeno pouze v aplikacích s více tenanty, protože uživatel z jednoho tenanta může eskalovat svá oprávnění pro přístup k prostředkům z jiného tenanta prostřednictvím změny atributu Pošta.

Jak mohu okamžitě chránit svou aplikaci?

Pokud chcete zabezpečit aplikace před chybami s neověřenými e-mailovými adresami, všechny nové aplikace s více tenanty se automaticky přihlásí k novému výchozímu chování, které odebere e-mailové adresy s neověřenými vlastníky domény z tokenů od června 2023. Toto chování není povolené pro aplikace s jedním tenantem a aplikace s více tenanty s předchozí přihlašovací aktivitou s neověřenými e-mailovými adresami vlastníka domény.

V závislosti na vašem scénáři můžete zjistit, že tokeny vaší aplikace by měly dál přijímat neověřené e-maily. I když se pro většinu aplikací nedoporučuje, můžete výchozí chování zakázat nastavením removeUnverifiedEmailClaim vlastnosti v objektu authenticationBehaviors rozhraní API aplikací v Microsoft Graphu.

Nastavením removeUnverifiedEmailClaim na false vaše aplikace obdrží email prohlášení, která jsou potenciálně neověřená a vystavují uživatele riziku převzetí účtu. Pokud toto chování zakážete, abyste neporušili procesy přihlašování uživatelů, důrazně doporučujeme migrovat na mapování tokenů s unikátní identifikací nároku, jak je popsáno v následujících pokynech.

Identifikace nezabezpečených konfigurací a provádění migrace databází

K provádění kontrol autorizace nebo indexování uživatelů v databázi byste nikdy neměli používat proměnlivé deklarace identity (například emailpreferred_username, atd.). Tyto hodnoty jsou opakovaně použitelné a můžou vaši aplikaci vystavit útokům eskalace oprávnění.

Následující ukázka pseudokódu pomáhá znázornit nezabezpečený vzor identifikace a autorizace uživatele:

 // 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 arbitrarily set email
 }

Jakmile zjistíte, že se vaše aplikace spoléhá na tento nezabezpečený atribut, musíte aktualizovat obchodní logiku, aby se uživatelé přeindexovali na globálně jedinečný identifikátor (GUID).

Víceklientské aplikace by měly být indexovány na mapování dvou jednoznačně identifikujících nároků, tid + oid. Tím se nájemníci segmentují podle tid a uživatelé segmentují podle jejich oid.

xms_edov Použití volitelné deklarace identity k určení stavu ověření e-mailu a migraci uživatelů

Abychom vývojářům pomohli s procesem migrace, zavedli jsme volitelnou deklaraci identity, xms_edovlogickou vlastnost, která označuje, jestli byl vlastník e-mailové domény ověřený nebo ne.

xms_edov lze použít k ověření e-mailu uživatele před migrací primárního klíče na jedinečné identifikátory, například oid. Následující příklad pseudokódu ukazuje, jak se tato deklarace identity může použít jako součást migrace.

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

Migrace na globálně jedinečné mapování zajišťuje, že každý uživatel je primárně indexovaný s hodnotou, kterou nelze znovu použít nebo zneužít k zosobnění jiného uživatele. Jakmile budou vaši uživatelé indexovaní globálně jedinečným identifikátorem, můžete opravit případnou autorizační logiku email , která tuto deklaraci identity používá.

Aktualizace logiky autorizace pomocí správného ověřování deklarací identity

Pokud vaše aplikace využívá email (nebo jakýkoli jiný proměnlivý nárok) pro účely autorizace, měli byste si přečíst dokument Zabezpečení aplikací a rozhraní API ověřováním nároků a implementovat příslušné kontroly.

Další kroky