Поделиться через

Переход от использования утверждений электронной почты для идентификации пользователя или авторизации

  • Статья

Эта статья предназначена для предоставления разработчикам рекомендаций, приложения которых в настоящее время используют небезопасный шаблон, в котором утверждение электронной почты используется для авторизации, что может привести к полному переходу на учетную запись другим пользователем. Продолжайте чтение, чтобы узнать больше о том, влияет ли ваше приложение, и шаги по исправлению.

Как я могу узнать, затронуто ли мое приложение?

Корпорация Майкрософт рекомендует просматривать исходный код приложения и определять наличие следующих шаблонов:

  • Изменяемое утверждение, например email, используется для уникальной идентификации пользователя.
  • Изменяемое утверждение, например email используется в целях авторизации доступа пользователя к ресурсам

Эти шаблоны считаются небезопасными, так как пользователи без подготовленного почтового ящика могут иметь любой адрес электронной почты для атрибута Mail (Primary SMTP). Этот атрибут не гарантируется, что он будет поступать с проверенного адреса электронной почты. Когда заявление электронной почты с непроверенным владельцем домена используется для авторизации, любой пользователь без предоставленного почтового ящика может получить несанкционированный доступ, изменив атрибут Mail, чтобы выдать себя за другого пользователя.

Электронное письмо считается проверенным владельцем домена, если:

  • Домен принадлежит клиенту, в котором находится учетная запись пользователя, и администратор клиента выполнил проверку домена.
  • Сообщение электронной почты из учетной записи Майкрософт (MSA)
  • Электронная почта из учетной записи Google
  • Электронная почта использовалась для проверки подлинности с помощью потока одноразового секретного кода (OTP)

Также следует отметить, что учетные записи Facebook и SAML/WS-Fed не имеют проверенных доменов.

Этот риск несанкционированного доступа найден только в мультитенантных приложениях, так как пользователь из одного клиента может повысить свои привилегии для доступа к ресурсам из другого клиента путем изменения атрибута Mail.

Как немедленно защитить мое приложение?

Чтобы защитить приложения от ошибок, связанных с непроверенными адресами электронной почты, с июня 2023 года все новые мультитенантные приложения автоматически подключаются к новому поведению по умолчанию, которое удаляет адреса электронной почты с непроверенными владельцами доменов из токенов. Это поведение не включено для приложений с одним клиентом и мультитенантных приложений с предыдущим действием входа с непроверенными адресами электронной почты владельца домена.

В зависимости от вашего сценария вы можете определить, что токены приложения должны продолжать получать непроверенные сообщения электронной почты. Хотя для большинства приложений не рекомендуется, можно отключить поведение по умолчанию, задав removeUnverifiedEmailClaim свойство в объекте authenticationBehaviors API приложений в Microsoft Graph.

Задав значение removeUnverifiedEmailClaimfalse, ваше приложение будет получать email утверждения, которые могут быть непроверенными и подвержены риску захвата учетных записей. Если вы отключаете это поведение, чтобы предотвратить сбои в процессах входа пользователей, настоятельно рекомендуется как можно скорее перейти на уникальное сопоставление утверждений токенов, как описано в руководстве ниже.

Определение небезопасных конфигураций и выполнение миграции базы данных

Вы никогда не должны использовать изменяемые утверждения (например email, preferred_usernameи т. д.) в качестве идентификаторов для выполнения проверок авторизации или индексирования пользователей в базе данных. Эти значения можно использовать повторно и может предоставить приложению возможность атак эскалации привилегий.

Следующий пример псевдокода помогает проиллюстрировать небезопасный шаблон идентификации пользователя или авторизации:

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

После определения того, что приложение полагается на этот небезопасный атрибут, необходимо обновить бизнес-логику, чтобы переиндексировать пользователей с глобально уникальным идентификатором (GUID).

Мультитенантные приложения должны индексировать сопоставление двух уникальных утверждений, tid + oid. Это сегментирует арендаторов по tid, а пользователей по их oid.

Использование дополнительного xms_edov утверждения для определения статуса проверки электронной почты и миграции пользователей

Чтобы помочь разработчикам в процессе миграции, мы ввели необязательное утверждение, xms_edov, логическое свойство, указывающее на то, был ли проверен владелец домена электронной почты.

xms_edov можно использовать для проверки электронной почты пользователя перед переносом первичного ключа на уникальные идентификаторы, например oid. В следующем примере псевдокода показано, как это утверждение может использоваться в рамках миграции.

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

Миграция на глобально уникальное сопоставление гарантирует, что каждый пользователь прежде всего индексируется со значением, которое нельзя использовать повторно или которое нельзя использовать для подделки личности другого пользователя. После индексирования пользователей по глобальному уникальному идентификатору вы готовы исправить любую потенциальную логику авторизации, использующую email утверждение.

Обновление логики авторизации с помощью правильной проверки утверждений

Если ваше приложение использует email (или любое другое изменяемое утверждение) для авторизации, вам следует прочитать статью Защита приложений и API через проверку утверждений и реализовать соответствующие проверки.

Следующие шаги