Delen via

Migreren van het gebruik van e-mailclaims voor gebruikersidentificatie of -autorisatie

  • Artikel

Dit artikel is bedoeld voor ontwikkelaars van wie toepassingen momenteel gebruikmaken van een onveilig patroon waarbij de e-mailclaim wordt gebruikt voor autorisatie, wat kan leiden tot volledige accountovername door een andere gebruiker. Lees verder voor meer informatie over of uw toepassing wordt beïnvloed en de stappen voor herstel.

Hoe kan ik weten of mijn toepassing wordt beïnvloed?

Microsoft raadt aan om de broncode van de toepassing te controleren en te bepalen of de volgende patronen aanwezig zijn:

  • Een onveranderbare claim, zoals email, wordt gebruikt voor het uniek identificeren van een gebruiker
  • Een veranderlijke claim, zoals email wordt gebruikt voor het autoriseren van de toegang van een gebruiker tot resources

Deze patronen worden als onveilig beschouwd, omdat gebruikers zonder een ingericht postvak elk e-mailadres kunnen hebben ingesteld voor het kenmerk E-mail (Primair SMTP). Dit kenmerk is niet gegarandeerd afkomstig van een geverifieerd e-mailadres. Wanneer een e-mailclaim met een niet-geverifieerde domeineigenaar wordt gebruikt voor autorisatie, heeft elke gebruiker zonder ingericht postvak de mogelijkheid om onbevoegde toegang te krijgen door het kenmerk Mail te wijzigen om een andere gebruiker te imiteren.

Een e-mailbericht wordt beschouwd als domeineigenaar geverifieerd als:

  • Het domein behoort tot de tenant waar het gebruikersaccount zich bevindt en de tenantbeheerder heeft verificatie van het domein uitgevoerd
  • Het e-mailbericht is afkomstig van een Microsoft-account (MSA)
  • De e-mail is afkomstig van een Google-account
  • Het e-mailbericht is gebruikt voor verificatie met behulp van de eenmalige wachtwoordcodestroom (OTP)

Er moet ook worden opgemerkt dat Facebook- en SAML-/WS-Fed-accounts geen geverifieerde domeinen hebben.

Dit risico op onbevoegde toegang is alleen gevonden in apps met meerdere tenants, omdat een gebruiker van de ene tenant zijn bevoegdheden kan escaleren om toegang te krijgen tot resources van een andere tenant door het kenmerk Mail te wijzigen.

Hoe kan ik mijn toepassing onmiddellijk beveiligen?

Als u toepassingen wilt beveiligen tegen fouten met niet-geverifieerde e-mailadressen, worden alle nieuwe toepassingen met meerdere tenants automatisch aangemeld bij een nieuw standaardgedrag waarmee e-mailadressen worden verwijderd met niet-geverifieerde domeineigenaren van tokens vanaf juni 2023. Dit gedrag is niet ingeschakeld voor toepassingen met één tenant en toepassingen met meerdere tenants met eerdere aanmeldingsactiviteiten met niet-geverifieerde e-mailadressen van domeineigenaar.

Afhankelijk van uw scenario kunt u bepalen dat de tokens van uw toepassing niet-geverifieerde e-mailberichten blijven ontvangen. Hoewel dit niet wordt aanbevolen voor de meeste toepassingen, kunt u het standaardgedrag uitschakelen door de removeUnverifiedEmailClaim eigenschap in te stellen in het object authenticationBehaviors van de api voor toepassingen in Microsoft Graph.

Door deze instelling in te falsestellenremoveUnverifiedEmailClaim, ontvangt email uw toepassing claims die mogelijk niet-geverifieerd zijn en gebruikers onderworpen zijn aan accountovernamerisico's. Als u dit gedrag uitschakelt om aanmeldingsstromen van gebruikers niet te verbreken, wordt het ten zeerste aanbevolen om zo snel mogelijk te migreren naar een uniek identificerende tokenclaimtoewijzing, zoals beschreven in de onderstaande richtlijnen.

Onveilige configuraties identificeren en databasemigratie uitvoeren

U moet nooit onveranderbare claims (zoals email, preferred_usernameenzovoort) gebruiken als id's om autorisatiecontroles uit te voeren of gebruikers te indexeren in een database. Deze waarden zijn herbruikbaar en kunnen uw toepassing blootstellen aan escalatieaanvallen met bevoegdheden.

Het volgende pseudocodevoorbeeld illustreert het onveilige patroon van gebruikersidentificatie/autorisatie:

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

Nadat u hebt vastgesteld dat uw toepassing afhankelijk is van dit onveilige kenmerk, moet u bedrijfslogica bijwerken om gebruikers opnieuw te indexeren op een GUID (Globally Unique Identifier).

Mutli-tenanttoepassingen moeten indexeren op een toewijzing van twee unieke identificatieclaims. tid + oid Hiermee worden tenants gesegmenteerd op basis van het tiden segmenteren van gebruikers op hun oid.

De optionele claim gebruiken om de xms_edov e-mailverificatiestatus te bepalen en gebruikers te migreren

Om ontwikkelaars te helpen bij het migratieproces, hebben we een optionele claim geïntroduceerd, xms_edoveen Booleaanse eigenschap die aangeeft of de eigenaar van het e-maildomein al dan niet is geverifieerd.

xms_edov kan worden gebruikt om het e-mailadres van een gebruiker te verifiëren voordat de primaire sleutel wordt gemigreerd naar unieke id's, zoals oid. In het volgende pseudocodevoorbeeld ziet u hoe deze claim kan worden gebruikt als onderdeel van uw migratie.

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

Als u migreert naar een globaal unieke toewijzing, zorgt u ervoor dat elke gebruiker voornamelijk wordt geïndexeerd met een waarde die niet opnieuw kan worden gebruikt of misbruikt om een andere gebruiker te imiteren. Zodra uw gebruikers zijn geïndexeerd op een wereldwijd unieke id, bent u klaar om mogelijke autorisatielogica op te lossen die gebruikmaakt van de email claim.

Autorisatielogica bijwerken met de juiste claimvalidatie

Als uw toepassing gebruikmaakt email van (of een andere veranderlijke claim) voor autorisatiedoeleinden, moet u de beveiligde toepassingen en API's lezen door claims te valideren en de juiste controles te implementeren.

Volgende stappen