Compartir a través de

Dejar de usar notificaciones de correo electrónico para la identificación o autorización de usuarios

  • Artículo

Este artículo está diseñado para proporcionar instrucciones a los desarrolladores cuyas aplicaciones usan actualmente un patrón no seguro en el que se usa la notificación de correo electrónico para la autorización, lo que puede llevar a que otro usuario asuma el control total de la cuenta. Siga leyendo para obtener más información sobre si su aplicación se ve afectada y los pasos para la corrección.

¿Cómo sé si mi aplicación se ve afectada?

Microsoft recomienda revisar el código fuente de la aplicación y determinar si están presentes los siguientes patrones:

  • Una notificación mutable, como email, se usa para identificar de forma única a un usuario
  • Una notificación mutable, como email, se usa para autorizar el acceso del usuario a los recursos

Estos patrones se consideran inseguros, ya que los usuarios sin un buzón aprovisionado pueden tener cualquier dirección de correo electrónico establecida para su atributo Mail (SMTP principal). No se garantiza que este atributo proceda de una dirección de correo electrónico verificada. Cuando se usa una notificación de correo electrónico con un propietario de dominio no comprobado para la autorización, cualquier usuario sin un buzón aprovisionado tiene la posibilidad de obtener acceso no autorizado al cambiar su atributo Correo para suplantar a otro usuario.

Se considera que un correo electrónico fue comprobado por el propietario del dominio si:

  • El dominio pertenece al inquilino donde reside la cuenta de usuario y el administrador del inquilino ha realizado la comprobación del dominio
  • El correo electrónico procede de una cuenta de Microsoft (MSA)
  • El correo electrónico procede de una cuenta de Google
  • El correo electrónico se ha usado para la autenticación mediante el flujo de código de acceso de un solo uso (OTP)

También debe tenerse en cuenta que las cuentas de Facebook y SAML/WS-Fed no tienen dominios comprobados.

Este riesgo de acceso no autorizado solo se ha encontrado en aplicaciones multiinquilino, ya que un usuario de un inquilino podría escalar sus privilegios para acceder a los recursos desde otro inquilino mediante la modificación de su atributo Mail.

¿Cómo puedo proteger mi aplicación inmediatamente?

Para proteger las aplicaciones frente a problemas con direcciones de correo electrónico no comprobadas, todas las nuevas aplicaciones multiinquilino se adoptan automáticamente un nuevo comportamiento predeterminado que elimina de los tókenes las direcciones de correo electrónico con propietarios de dominio no verificados a partir de junio de 2023. Este comportamiento no está habilitado para las aplicaciones de inquilino único ni para las aplicaciones multiinquilino con una fecha de actividad de inicio de sesión anterior, que tengan direcciones de correo electrónico no comprobadas del propietario del dominio.

Según su escenario, puede determinar si los tókenes de la aplicación deben seguir recibiendo correos electrónicos no comprobados. Aunque no se recomienda para la mayoría de las aplicaciones, puede deshabilitar el comportamiento predeterminado al establecer la propiedad removeUnverifiedEmailClaim en el objeto authenticationBehaviors de la API de aplicaciones en Microsoft Graph.

Al establecer removeUnverifiedEmailClaim en false, la aplicación recibirá notificaciones de email que puede que no se comprueben y someten a los usuarios al riesgo de robo de cuentas. Si deshabilita este comportamiento para no interrumpir los flujos de inicio de sesión de usuarios, se recomienda encarecidamente migrar a una asignación de notificaciones de token de identificación única lo antes posible, como se describe en las instrucciones siguientes.

Identificación de configuraciones no seguras y migración de bases de datos

Nunca debe usar notificaciones mutables (como email, preferred_username, etc.) como identificadores para realizar comprobaciones de autorización o indexar usuarios de una base de datos. Estos valores se pueden volver a usar y podrían exponer la aplicación a ataques de elevación de privilegios.

El ejemplo de pseudocódigo siguiente ayuda a ilustrar el patrón inseguro de identificación y autorización del usuario:

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

Una vez que haya determinado que la aplicación depende de este atributo no seguro, debe actualizar la lógica de negocios para volver a indexar a los usuarios en un identificador único global (GUID).

Las aplicaciones multiinquilino deben indizarse en una asignación de dos notificaciones de identificación única, tid + oid. Esto segmentará los inquilinos por tid y segmentará a los usuarios por su oid.

Uso de la notificación opcional xms_edov para determinar el estado de comprobación de correo electrónico y migrar usuarios

Para ayudar a los desarrolladores en el proceso de migración, hemos introducido una notificación opcional, xms_edov, una propiedad booleana que indica si se ha comprobado o no el propietario del dominio de correo electrónico.

xms_edov se puede usar para ayudar a comprobar el correo electrónico de un usuario antes de migrar su clave principal a identificadores únicos, como oid. En el ejemplo de pseudocódigo siguiente, se muestra cómo se puede usar esta notificación como parte de la migración.

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

La migración a una asignación única global garantiza que cada usuario se indice principalmente con un valor que no se puede reutilizar ni usar para suplantar a otro usuario. Una vez que los usuarios se indexan en un identificador único global, está listo para corregir cualquier lógica de autorización potencial que use la notificación email.

Actualización de la lógica de autorización con validación de notificaciones adecuada

Si la aplicación usa email (o cualquier otra notificación mutable) con fines de autorización, consulte Protección de aplicaciones y API mediante la validación de notificaciones e implemente las comprobaciones adecuadas.

Pasos siguientes