Aracılığıyla paylaş

Kullanıcı belirleme veya yetkilendirme için e-posta taleplerini kullanmaktan uzağa geçiş

  • Makale

Bu makale, uygulamaları şu anda yetkilendirme için e-posta talebi kullanılan ve başka bir kullanıcı tarafından tam hesap devralmaya yol açabilecek güvenli olmayan bir desen kullanan geliştiricilere rehberlik sağlamak için tasarlanmıştır. Uygulamanızın etkilenip etkilenmediğini ve düzeltme adımlarını öğrenmek için okumaya devam edin.

Uygulamamın etkilenip etkilenmediğini Nasıl yaparım? biliyor musunuz?

Microsoft, uygulama kaynak kodunun gözden geçirilmesini ve aşağıdaki desenlerin mevcut olup olmadığının belirlenmesini önerir:

  • gibi emaildeğiştirilebilir bir talep, bir kullanıcıyı benzersiz olarak tanımlamak amacıyla kullanılır
  • Örneğin, email kullanıcının kaynaklara erişimine yetki vermek amacıyla kullanılan değiştirilebilir talep

Sağlanan posta kutusu olmayan kullanıcıların Posta (Birincil SMTP) öznitelikleri için ayarlanmış herhangi bir e-posta adresi olabileceği için bu desenler güvenli değildir. Bu özniteliğin doğrulanmış bir e-posta adresinden geldiği garanti değildir. Yetkilendirme için, onaylanmamış etki alanı sahibine sahip bir e-posta talebi kullanıldığında, sağlanan posta kutusu olmayan herhangi bir kullanıcının Posta özniteliğini başka bir kullanıcının kimliğine bürünecek şekilde değiştirerek yetkisiz erişim elde etme olasılığı vardır.

E-postanın etki alanı sahibi olduğu kabul edilir ve şu durumda doğrulanır:

  • Etki alanı, kullanıcı hesabının bulunduğu kiracıya aittir ve kiracı yöneticisi etki alanı doğrulamasını yapmıştır
  • E-posta bir Microsoft Hesabından (MSA)
  • E-posta bir Google hesabından
  • E-posta, tek seferlik geçiş kodu (OTP) akışı kullanılarak kimlik doğrulaması için kullanıldı

Facebook ve SAML/WS-Fed hesaplarında doğrulanmış etki alanları olmadığı da belirtilmelidir.

Bu yetkisiz erişim riski yalnızca çok kiracılı uygulamalarda bulunmuştur çünkü bir kiracıdaki bir kullanıcı, Posta özniteliğini değiştirme yoluyla başka bir kiracıdaki kaynaklara erişim ayrıcalıklarını yükseltebilir.

Uygulamamı hemen koruma Nasıl yaparım??

Doğrulanmamış e-posta adresleriyle uygulamaların hatalardan güvenliğini sağlamak için tüm yeni çok kiracılı uygulamalar, Doğrulanmamış etki alanı sahiplerine sahip e-posta adreslerini Haziran 2023'ten itibaren belirteçlerden kaldıran yeni bir varsayılan davranışa otomatik olarak kabul edilir. Bu davranış, etki alanı sahibi doğrulamasız e-posta adresleriyle önceki oturum açma etkinliğine sahip tek kiracılı uygulamalar ve çok kiracılı uygulamalar için etkinleştirilmez.

Senaryonuza bağlı olarak, uygulamanızın belirteçlerinin doğrulanmamış e-postaları almaya devam etmesi gerektiğini belirleyebilirsiniz. Çoğu uygulama için önerilmiyor olsa da, Microsoft Graph'taki uygulama API'sinin authenticationBehaviors nesnesinde özelliğini ayarlayarak removeUnverifiedEmailClaim varsayılan davranışı devre dışı bırakabilirsiniz.

olarak ayarlayarak removeUnverifiedEmailClaimfalse, uygulamanız doğrulanmamış olabilecek ve kullanıcıların devralma riskini hesaba aktarmasına neden olabilecek talepler alır email . Kullanıcı oturum açma akışlarını bozmamak için bu davranışı devre dışı bırakırsanız, aşağıdaki kılavuzda açıklandığı gibi en kısa sürede benzersiz olarak tanımlayıcı bir belirteç talep eşlemesine geçmeniz kesinlikle önerilir.

Güvenli olmayan yapılandırmaları belirleme ve veritabanı geçişi gerçekleştirme

Veritabanında yetkilendirme denetimleri yapmak veya kullanıcıları dizine almak için tanımlayıcı olarak hiçbir zaman değiştirilebilir talepler (, emailpreferred_usernamevb.) kullanmamalısınız. Bu değerler yeniden kullanılabilir ve uygulamanızı ayrıcalık yükseltme saldırılarına maruz bırakabilir.

Aşağıdaki sahte kod örneği, kullanıcı belirleme/ yetkilendirmenin güvenli olmayan desenini göstermeye yardımcı olur:

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

Uygulamanızın bu güvenli olmayan özniteliğe dayandığını belirledikten sonra, kullanıcıları genel olarak benzersiz bir tanımlayıcıda (GUID) yeniden dizine almak için iş mantığını güncelleştirmeniz gerekir.

Mutli kiracısı uygulamaları benzersiz olarak tanımlayan iki talebin eşlemesinde dizin oluşturmalıdır: tid + oid. Bu, kiracıları öğesine göre segmentlere tidayırır ve kullanıcıları kendilerine göre segmentlere oidayırır.

xms_edov E-posta doğrulama durumunu belirlemek ve kullanıcıları geçirmek için isteğe bağlı talebi kullanma

Geçiş işleminde geliştiricilere yardımcı olmak için, e-posta etki alanı sahibinin doğrulanıp doğrulanmadığını gösteren isteğe bağlı bir boole özelliği olan bir talep xms_edovkullanıma sunulmuştur.

xms_edov , birincil anahtarını gibi oidbenzersiz tanımlayıcılara geçirmeden önce kullanıcının e-postasını doğrulamaya yardımcı olmak için kullanılabilir. Aşağıdaki sahte kod örneği, bu talebin geçişinizin bir parçası olarak nasıl kullanılabileceğini göstermektedir.

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

Genel olarak benzersiz bir eşlemeye geçiş, her kullanıcının öncelikle yeniden kullanılamayabilen veya başka bir kullanıcının kimliğine bürünmek için kötüye kullanılan bir değerle dizine alınmasına yardımcı olur. Kullanıcılarınız genel olarak benzersiz bir tanımlayıcıda dizine eklendikten sonra, talebi kullanan olası yetkilendirme mantığını düzeltmeye email hazır olursunuz.

Yetkilendirme mantığını doğru talep doğrulama ile güncelleştirme

Uygulamanız yetkilendirme amacıyla kullanıyorsa (veya başka bir değiştirilebilir talep) kullanıyorsa email , talepleri doğrulayarak Güvenli uygulamalar ve API'leri okumalı ve uygun denetimleri uygulamalısınız.

Sonraki adımlar