Dela via

Migrera bort från att använda e-post som metod för användaridentifiering eller autentisering

  • Artikel

Den här artikeln är avsedd att ge vägledning till utvecklare vars program för närvarande använder ett osäkert mönster där e-postanspråket används för auktorisering, vilket kan leda till fullständigt kontoövertagande av en annan användare. Fortsätt läsa om du vill veta mer om ditt program påverkas och steg för reparation.

Hur gör jag för att veta om mitt program påverkas?

Microsoft rekommenderar att du granskar programmets källkod och avgör om följande mönster finns:

  • Ett föränderligt anspråk, till exempel email, används för att unikt identifiera en användare
  • Ett föränderligt anspråk, till exempel email används för att auktorisera en användares åtkomst till resurser

Dessa mönster anses vara osäkra, eftersom användare utan en etablerad postlåda kan ha valfri e-postadress inställd för sitt e-postattribut (primär SMTP). Det här attributet garanteras inte komma från en verifierad e-postadress. När ett e-postanspråk med en overifierad domänägare används för auktorisering har alla användare utan en etablerad postlåda potential att få obehörig åtkomst genom att ändra sitt Mail-attribut för att utge sig för att vara en annan användare.

Ett e-postmeddelande anses vara domänägare verifierat om:

  • Domänen tillhör den klientorganisation där användarkontot finns och klientadministratören har verifierat domänen
  • E-postmeddelandet kommer från ett Microsoft-konto (MSA)
  • E-postmeddelandet kommer från ett Google-konto
  • E-postmeddelandet användes för autentisering med hjälp av engångslösenordflödet (OTP)

Det bör också noteras att Facebook- och SAML/WS-Fed-konton inte har verifierade domäner.

Den här risken för obehörig åtkomst har bara påträffats i appar med flera klientorganisationer, eftersom en användare från en klientorganisation kan eskalera sina behörigheter för att få åtkomst till resurser från en annan klientorganisation genom att ändra sitt e-postattribut.

Hur gör jag för att skydda mitt program omedelbart?

För att skydda applikationer från misstag med ostyrkta e-postadresser får alla nya flertenantapplikationer automatiskt ett nytt standardbeteende som tar bort e-postadresser med ostyrkta domänägare från tokenarna från och med juni 2023. Det här beteendet är inte aktiverat för program med en enda klientorganisation och program med flera klientorganisationer med tidigare inloggningsaktivitet med domänägares overifierade e-postadresser.

Beroende på ditt scenario kan du bestämma att programmets token ska fortsätta att ta emot overifierade e-postmeddelanden. Även om det inte rekommenderas för de flesta program kan du inaktivera standardbeteendet genom att ange removeUnverifiedEmailClaim egenskapen i objektet authenticationBehaviors för program-API:et i Microsoft Graph.

Genom att ange removeUnverifiedEmailClaim till false så får email ditt program anspråk som potentiellt är overifierade och utsätter användare för risken för kontoövertagande. Om du inaktiverar det här beteendet för att inte bryta användarinloggningsflöden rekommenderar vi starkt att du migrerar till en unikt identifierande tokenanspråksmappning så snart som möjligt, enligt beskrivningen i vägledningen nedan.

Identifiera osäkra konfigurationer och utföra databasmigrering

Du bör aldrig använda föränderliga anspråk (till exempel email, preferred_usernameoch så vidare) som identifierare för att utföra auktoriseringskontroller eller indexanvändare i en databas. Dessa värden kan återanvändas och kan utsätta programmet för privilegierade eskaleringsattacker.

Följande pseudokodexempel illustrerar det osäkra mönstret för användaridentifiering/auktorisering:

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

När du har fastställt att ditt program förlitar sig på det här osäkra attributet måste du uppdatera affärslogik för att indexera om användare på en globalt unik identifierare (GUID).

Program med flera klienter bör indexeras på en mappning av två unikt identifierande anspråk, tid + oid. Detta segmenterar hyresgäster efter tid, och segmenterar användare efter deras oid.

Använda det valfria påståendet xms_edov för att fastställa e-postverifieringsstatus och migrera användare

För att hjälpa utvecklare i migreringsprocessen har vi infört ett valfritt anspråk, xms_edov, en boolesk egenskap som anger om e-postdomänägaren har verifierats eller inte.

xms_edov kan användas för att verifiera en användares e-post innan de migrerar sin primära nyckel till unika identifierare, till exempel oid. Följande pseudokodexempel illustrerar hur det här anspråket kan användas som en del av migreringen.

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

Om du migrerar till en globalt unik mappning ser du till att varje användare främst indexeras med ett värde som inte kan återanvändas eller missbrukas för att personifiera en annan användare. När dina användare har indexerats på en globalt unik identifierare är du redo att åtgärda eventuell auktoriseringslogik som använder anspråket email .

Uppdatera auktoriseringslogik med korrekt anspråksverifiering

Om ditt program använder email (eller något annat föränderligt anspråk) för auktoriseringsändamål bör du läsa igenom säkra program och API:er genom att verifiera anspråk och implementera lämpliga kontroller.

Nästa steg