Bagikan melalui

Bermigrasi jauh dari menggunakan klaim email untuk identifikasi atau otorisasi pengguna

  • Artikel

Artikel ini dimaksudkan untuk memberikan panduan kepada pengembang yang aplikasinya saat ini menggunakan pola yang tidak aman di mana klaim email digunakan untuk otorisasi, yang dapat menyebabkan pengambilalihan akun penuh oleh pengguna lain. Lanjutkan membaca untuk mempelajari selengkapnya tentang apakah aplikasi Anda terpengaruh, dan langkah-langkah untuk remediasi.

Bagaimana cara mengetahui apakah aplikasi saya terpengaruh?

Microsoft merekomendasikan untuk meninjau kode sumber aplikasi dan menentukan apakah pola berikut ada:

  • Klaim yang dapat diubah, seperti email, digunakan untuk tujuan mengidentifikasi pengguna secara unik
  • Klaim yang dapat diubah, seperti email digunakan untuk tujuan mengotorisasi akses pengguna ke sumber daya

Pola-pola ini dianggap tidak aman, karena pengguna tanpa kotak surat yang disediakan dapat memiliki alamat email apa pun yang ditetapkan untuk atribut Mail (SMTP Utama) mereka. Atribut ini tidak dijamin berasal dari alamat email terverifikasi. Ketika klaim email dengan pemilik domain yang belum diverifikasi digunakan untuk otorisasi, setiap pengguna tanpa kotak surat yang disediakan berpotensi mendapatkan akses yang tidak sah dengan mengubah atribut Mail mereka untuk meniru pengguna lain.

Email dianggap sebagai pemilik domain yang diverifikasi jika:

  • Domain milik penyewa tempat akun pengguna berada, dan admin penyewa telah melakukan verifikasi domain
  • Email berasal dari Akun Microsoft (MSA)
  • Email tersebut berasal dari akun Google
  • Email digunakan untuk autentikasi menggunakan alur kode akses satu kali (OTP)

Perlu dicatat juga bahwa akun Facebook dan SAML/WS-Fed tidak memiliki domain terverifikasi.

Risiko akses tidak sah ini hanya ditemukan di aplikasi multi-penyewa, karena pengguna dari satu penyewa dapat meningkatkan hak istimewa mereka untuk mengakses sumber daya dari penyewa lain melalui modifikasi atribut Mail mereka.

Bagaimana cara melindungi aplikasi saya segera?

Untuk mengamankan aplikasi dari kesalahan dengan alamat email yang belum diverifikasi, semua aplikasi multi-penyewa baru secara otomatis ikut serta dalam perilaku default baru yang menghapus alamat email dengan pemilik domain yang tidak diverifikasi dari token per Juni 2023. Perilaku ini tidak diaktifkan untuk aplikasi penyewa tunggal dan aplikasi multi-penyewa dengan aktivitas masuk sebelumnya dengan alamat email yang tidak diverifikasi pemilik domain.

Bergantung pada skenario Anda, Anda dapat menentukan bahwa token aplikasi Anda harus terus menerima email yang belum diverifikasi. Meskipun tidak direkomendasikan untuk sebagian besar aplikasi, Anda dapat menonaktifkan perilaku default dengan mengatur removeUnverifiedEmailClaim properti di objek authenticationBehaviors api aplikasi di Microsoft Graph.

Dengan mengatur removeUnverifiedEmailClaim ke false, aplikasi Anda akan menerima email klaim yang berpotensi tidak terverifikasi dan tunduk pada pengguna terhadap risiko pengamanan akun. Jika Anda menonaktifkan perilaku ini agar tidak merusak alur masuk pengguna, sangat disarankan untuk bermigrasi ke pemetaan klaim token yang mengidentifikasi secara unik sesegera mungkin, seperti yang dijelaskan dalam panduan di bawah ini.

Mengidentifikasi konfigurasi yang tidak aman dan melakukan migrasi database

Anda tidak boleh menggunakan klaim yang dapat diubah (seperti email, , preferred_usernamedan sebagainya) sebagai pengidentifikasi untuk melakukan pemeriksaan otorisasi atau pengguna indeks dalam database. Nilai-nilai ini dapat digunakan kembali dan dapat mengekspos aplikasi Anda ke serangan eskalasi hak istimewa.

Sampel pseudocode berikut membantu mengilustrasikan pola identifikasi/otorisasi pengguna yang tidak aman:

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

Setelah menentukan bahwa aplikasi Anda mengandalkan atribut yang tidak aman ini, Anda perlu memperbarui logika bisnis untuk mengindeks ulang pengguna pada pengidentifikasi unik global (GUID).

Aplikasi penyewa Mutli harus mengindeks pada pemetaan dua klaim yang mengidentifikasi secara unik, tid + oid. Ini akan segmentasi penyewa oleh tid, dan segmen pengguna oleh mereka oid.

xms_edov Menggunakan klaim opsional untuk menentukan status verifikasi email dan memigrasikan pengguna

Untuk membantu pengembang dalam proses migrasi, kami telah memperkenalkan klaim opsional, xms_edov, properti Boolean yang menunjukkan apakah pemilik domain email telah diverifikasi atau tidak.

xms_edov dapat digunakan untuk membantu memverifikasi email pengguna sebelum memigrasikan kunci utama mereka ke pengidentifikasi unik, seperti oid. Contoh pseudocode berikut menggambarkan bagaimana klaim ini dapat digunakan sebagai bagian dari migrasi Anda.

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

Migrasi ke pemetaan unik global memastikan bahwa setiap pengguna terutama diindeks dengan nilai yang tidak dapat digunakan kembali, atau disalahgunakan untuk meniru pengguna lain. Setelah pengguna Anda diindeks pada pengidentifikasi unik global, Anda siap untuk memperbaiki logika otorisasi potensial yang menggunakan email klaim.

Memperbarui logika otorisasi dengan validasi klaim yang tepat

Jika aplikasi Anda menggunakan email (atau klaim yang dapat diubah lainnya) untuk tujuan otorisasi, Anda harus membaca aplikasi dan API Aman dengan memvalidasi klaim dan menerapkan pemeriksaan yang sesuai.

Langkah berikutnya