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

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

  • Статья

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

Разделы справки знать, влияет ли мое приложение?

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

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

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

Сообщение электронной почты считается владельцем домена, проверяемое, если:

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

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

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

Разделы справки немедленно защитить приложение?

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

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

Задав значение removeUnverifiedEmailClaim false, приложение получит 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 arbirarily set email
 }

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

Приложения mutli-tenant должны индексировать сопоставление двух уникальных утверждений. 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, проверяя утверждения и реализуя соответствующие проверки.

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