Migrálás az e-mail-jogcímek felhasználóazonosításhoz vagy engedélyezéshez való használatáról

Ez a cikk útmutatást nyújt azoknak a fejlesztőknek, akiknek az alkalmazásai jelenleg nem biztonságos mintát használnak, ahol az e-mail-jogcímet az engedélyezéshez használják, ami egy másik felhasználó általi teljes fiókátvételhez vezethet. További információ az alkalmazás hatásáról és a szervizelés lépéseiről.

Hogyan tudja, hogy érintett-e az alkalmazásom?

A Microsoft azt javasolja, hogy tekintse át az alkalmazás forráskódját, és állapítsa meg, hogy a következő minták vannak-e jelen:

• A rendszer egy mutable jogcímet használ, például emailegy felhasználó egyedi azonosítására
• A felhasználó erőforrásokhoz való hozzáférésének engedélyezése céljából használt, nem módosítható jogcím email

Ezek a minták nem biztonságosak, mivel a kiépített postaládával nem rendelkező felhasználók bármilyen e-mail-címmel rendelkezhetnek a Levelezés (elsődleges SMTP) attribútumhoz. Ez az attribútum nem garantáltan ellenőrzött e-mail-címről származik. Ha egy nem ellenőrzött tartománytulajdonossal rendelkező e-mail-jogcímet használnak engedélyezésre, a kiépített postaládával nem rendelkező felhasználók jogosulatlan hozzáférést kaphatnak a Levelezés attribútumuk módosításával egy másik felhasználó megszemélyesítésére.

Az e-mailek akkor tekinthetők tartománytulajdonosnak, ha:

• A tartomány ahhoz a bérlőhöz tartozik, amelyben a felhasználói fiók található, és a bérlő rendszergazdája elvégezte a tartomány ellenőrzését
• Az e-mail egy Microsoft-fiókból (MSA) származik
• Az e-mail egy Google-fiókból származik
• Az e-mailt az egyszeri pin-kód (OTP) folyamattal történő hitelesítéshez használták

Azt is meg kell jegyezni, hogy a Facebook és az SAML/WS-Fed fiókok nem rendelkeznek ellenőrzött tartományokkal.

Ez a jogosulatlan hozzáférés kockázata csak a több-bérlős alkalmazásokban található, mivel az egyik bérlő felhasználója eszkalálhatja a jogosultságait, hogy a Levelezés attribútum módosításával hozzáférjenek egy másik bérlő erőforrásaihoz.

Hogyan azonnal védeni az alkalmazást?

A nem ellenőrzött e-mail-címekkel rendelkező hibáktól való védelem érdekében az összes új több-bérlős alkalmazás automatikusan be van jelentkezve egy új alapértelmezett viselkedésbe, amely 2023 júniusától eltávolítja a nem ellenőrzött tartománytulajdonosokkal rendelkező e-mail-címeket a jogkivonatokból. Ez a viselkedés nem engedélyezett az egybérlős alkalmazások és a több-bérlős alkalmazások esetében, amelyek korábbi bejelentkezési tevékenységet végeznek a tartománytulajdonos nem ellenőrzött e-mail-címeivel.

A forgatókönyvtől függően megállapíthatja, hogy az alkalmazás jogkivonatainak továbbra is ellenőrizetlen e-maileket kell kapniuk. Bár a legtöbb alkalmazás esetében nem ajánlott, letilthatja az alapértelmezett viselkedést úgy, hogy beállítja a tulajdonságot az removeUnverifiedEmailClaimapplication API authenticationBehaviors objektumában a Microsoft Graphban.

A beállítással removeUnverifiedEmailClaimfalseaz alkalmazás olyan jogcímeket kap email , amelyek esetleg nem ellenőrzöttek, és a felhasználókat felelősségre vonják az átvétel kockázatára. Ha letiltja ezt a viselkedést annak érdekében, hogy ne törje meg a felhasználói bejelentkezési folyamatokat, javasoljuk, hogy a lehető leghamarabb migráljon egy egyedi azonosító jogkivonat-jogcímleképezésre az alábbi útmutatóban leírtak szerint.

A nem biztonságos konfigurációk azonosítása és az adatbázis migrálása

Soha ne használjon mutable jogcímeket (például email, preferred_usernamestb.) azonosítóként az engedélyezési ellenőrzések végrehajtásához vagy a felhasználók indexeléséhez az adatbázisban. Ezek az értékek újrafelhasználhatók, és elérhetővé tehetik az alkalmazást a jogosultság-eszkalációs támadásoknak.

Az alábbi pszeudokódminta a felhasználóazonosítás /engedélyezés nem biztonságos mintáját mutatja be:

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

Miután megállapította, hogy az alkalmazás erre a nem biztonságos attribútumra támaszkodik, frissítenie kell az üzleti logikát, hogy újraindexelje a felhasználókat egy globálisan egyedi azonosítón (GUID).

A Mutli-bérlői alkalmazásoknak indexelnie kell két egyedileg azonosító jogcím leképezését. tid + oid Ez a bérlőket a bérlők szerint, a felhasználókat pedig a tidsajátjuk szerint szegmenteli oid.

Az opcionális jogcím használata az xms_edov e-mail-ellenőrzés állapotának meghatározásához és a felhasználók áttelepítéséhez

Az áttelepítési folyamat fejlesztőinek segítéséhez bevezettünk egy opcionális jogcímet, egy logikai tulajdonságot, amely azt jelzi, xms_edovhogy az e-mail-tartomány tulajdonosa ellenőrizve lett-e.

xms_edov segítségével ellenőrizheti a felhasználó e-mail-címét, mielőtt az elsődleges kulcsát egyedi azonosítókra, például oid. Az alábbi pszeudokód-példa bemutatja, hogyan használható ez a jogcím a migrálás részeként.

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

A globálisan egyedi leképezésre való migrálás biztosítja, hogy minden felhasználó elsődlegesen olyan értékkel legyen indexelve, amelyet nem lehet újra felhasználni, vagy visszaélni egy másik felhasználó megszemélyesítéséhez. Miután a felhasználókat egy globálisan egyedi azonosítóra indexelték, készen áll a jogcímet használó email esetleges engedélyezési logika kijavítására.

Engedélyezési logika frissítése megfelelő jogcímérvényesítéssel

Ha az alkalmazás engedélyezési célokra használ email (vagy bármilyen más jogcímet), olvassa át a biztonságos alkalmazásokat és API-kat a jogcímek érvényesítésével és a megfelelő ellenőrzések végrehajtásával.

Következő lépések

• A jogcímalapú engedélyezés biztonságos használatával kapcsolatos további információkért lásd : Biztonságos alkalmazások és API-k a jogcímek érvényesítésével
• Az opcionális jogcímekkel kapcsolatos további információkért tekintse meg a választható jogcímek hivatkozását