Partilhar via

Deixe de usar declarações de e-mail para identificação ou autorização do usuário

  • Artigo

Este artigo destina-se a fornecer orientação aos desenvolvedores cujos aplicativos estão atualmente usando um padrão inseguro em que a declaração de e-mail é usada para autorização, o que pode levar à tomada total da conta por outro usuário. Continue lendo para saber mais sobre se seu aplicativo foi afetado e as etapas para correção.

Como posso saber se a minha candidatura foi afetada?

A Microsoft recomenda revisar o código-fonte do aplicativo e determinar se os seguintes padrões estão presentes:

  • Uma declaração mutável, como email, é usada com a finalidade de identificar exclusivamente um usuário
  • Uma declaração mutável, como email a que é usada para autorizar o acesso de um usuário aos recursos

Esses padrões são considerados inseguros, pois os usuários sem uma caixa de correio provisionada podem ter qualquer endereço de email definido para seu atributo Mail (SMTP primário). Não é garantido que este atributo venha de um endereço de e-mail verificado. Quando uma declaração de e-mail com um proprietário de domínio não verificado é usada para autorização, qualquer usuário sem uma caixa de correio provisionada tem o potencial de obter acesso não autorizado alterando seu atributo Mail para se passar por outro usuário.

Um e-mail é considerado verificado pelo proprietário do domínio se:

  • O domínio pertence ao locatário onde a conta de usuário reside e o administrador do locatário fez a verificação do domínio
  • O email é de uma Conta da Microsoft (MSA)
  • O e-mail é de uma Conta do Google
  • O e-mail foi usado para autenticação usando o fluxo de senha única (OTP)

Também deve ser notado que as contas do Facebook e SAML/WS-Fed não têm domínios verificados.

Esse risco de acesso não autorizado só foi encontrado em aplicativos multilocatário, pois um usuário de um locatário pode escalar seus privilégios para acessar recursos de outro locatário por meio da modificação de seu atributo Mail.

Como posso proteger a minha aplicação imediatamente?

Para proteger os aplicativos contra erros com endereços de e-mail não verificados, todos os novos aplicativos multilocatários são automaticamente aceitos em um novo comportamento padrão que remove endereços de e-mail com proprietários de domínio não verificados de tokens a partir de junho de 2023. Esse comportamento não está habilitado para aplicativos de locatário único e aplicativos multilocatários com atividade de entrada anterior com endereços de email não verificados do proprietário do domínio.

Dependendo do cenário, você pode determinar que os tokens do seu aplicativo devem continuar recebendo e-mails não verificados. Embora não seja recomendado para a maioria dos aplicativos, você pode desabilitar o comportamento padrão definindo a removeUnverifiedEmailClaimpropriedade no objeto authenticationBehaviors da API de aplicativos no Microsoft Graph.

Ao definir removeUnverifiedEmailClaim como false, seu aplicativo receberá email declarações que são potencialmente não verificadas e sujeitam os usuários ao risco de aquisição de conta. Se você estiver desabilitando esse comportamento para não interromper os fluxos de login do usuário, é altamente recomendável migrar para um mapeamento de declaração de token de identificação exclusiva o mais rápido possível, conforme descrito nas orientações abaixo.

Identificando configurações inseguras e executando a migração do banco de dados

Você nunca deve usar declarações mutáveis (como email, preferred_usernamee assim por diante) como identificadores para executar verificações de autorização ou indexar usuários em um banco de dados. Esses valores são reutilizáveis e podem expor seu aplicativo a ataques de escalonamento de privilégios.

O exemplo de pseudocódigo a seguir ajuda a ilustrar o padrão inseguro de identificação/autorização do usuário:

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

Depois de determinar que seu aplicativo está confiando nesse atributo inseguro, você precisa atualizar a lógica de negócios para reindexar os usuários em um GUID (identificador global exclusivo).

Os aplicativos mutli-tenant devem indexar em um mapeamento de duas declarações de identificação exclusiva, tid + oid. Isso segmentará os locatários pelo tid, e segmentará os usuários pelo .oid

Usando a declaração opcional para determinar o status de verificação de xms_edov e-mail e migrar usuários

Para ajudar os desenvolvedores no processo de migração, introduzimos uma declaração opcional, xms_edov, uma propriedade booleana que indica se o proprietário do domínio de e-mail foi verificado ou não.

xms_edov pode ser usado para ajudar a verificar o e-mail de um usuário antes de migrar sua chave primária para identificadores exclusivos, como oid. O exemplo de pseudocódigo a seguir ilustra como essa declaração pode ser usada como parte da migração.

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

A migração para um mapeamento globalmente exclusivo garante que cada usuário seja indexado principalmente com um valor que não pode ser reutilizado ou abusado para representar outro usuário. Depois que os usuários forem indexados em um identificador global exclusivo, você estará pronto para corrigir qualquer lógica de autorização potencial que use a email declaração.

Atualize a lógica de autorização com a validação adequada de declarações

Se seu aplicativo usa email (ou qualquer outra declaração mutável) para fins de autorização, você deve ler os aplicativos e APIs seguros validando as declarações e implementando as verificações apropriadas.

Próximos passos