Share via

Eseguire la migrazione dall'uso di attestazioni di posta elettronica per l'identificazione o l'autorizzazione dell'utente

  • Articolo

Questo articolo è progettato per fornire indicazioni agli sviluppatori le cui applicazioni usano attualmente un modello non sicuro in cui l'attestazione di posta elettronica viene usata per l'autorizzazione, che può portare alla acquisizione completa dell'account da un altro utente. Continuare a leggere per altre informazioni su se l'applicazione è interessata e sui passaggi per la correzione.

Ricerca per categorie sapere se l'applicazione è interessata?

Microsoft consiglia di esaminare il codice sorgente dell'applicazione e determinare se sono presenti i modelli seguenti:

  • Un'attestazione modificabile, ad esempio email, viene usata ai fini dell'identificazione univoca di un utente
  • Un'attestazione modificabile, ad esempio email viene usata ai fini dell'autorizzazione dell'accesso di un utente alle risorse

Questi modelli sono considerati non sicuri, poiché gli utenti senza una cassetta postale di cui è stato effettuato il provisioning possono avere qualsiasi indirizzo di posta elettronica impostato per l'attributo Mail (SMTP primario). Questo attributo non è garantito che provengano da un indirizzo di posta elettronica verificato. Quando viene usata un'attestazione di posta elettronica con un proprietario di dominio non verificato per l'autorizzazione, qualsiasi utente senza una cassetta postale di cui è stato effettuato il provisioning può ottenere l'accesso non autorizzato modificando l'attributo Mail per rappresentare un altro utente.

Un messaggio di posta elettronica viene considerato proprietario del dominio verificato se:

  • Il dominio appartiene al tenant in cui risiede l'account utente e l'amministratore del tenant ha eseguito la verifica del dominio
  • Il messaggio di posta elettronica proviene da un account Microsoft (MSA)
  • Il messaggio di posta elettronica proviene da un account Google
  • Il messaggio di posta elettronica è stato usato per l'autenticazione usando il flusso di passcode monouso (OTP)

Si noti anche che gli account Facebook e SAML/WS-Fed non hanno domini verificati.

Questo rischio di accesso non autorizzato è stato rilevato solo nelle app multi-tenant, poiché un utente di un tenant potrebbe inoltrare i propri privilegi per accedere alle risorse da un altro tenant tramite la modifica dell'attributo Mail.

Ricerca per categorie proteggere immediatamente l'applicazione?

Per proteggere le applicazioni da errori con indirizzi di posta elettronica non verificati, tutte le nuove applicazioni multi-tenant vengono automaticamente acconsentite a un nuovo comportamento predefinito che rimuove gli indirizzi di posta elettronica con proprietari di dominio non verificati dai token a partire da giugno 2023. Questo comportamento non è abilitato per le applicazioni a tenant singolo e le applicazioni multi-tenant con attività di accesso precedente con indirizzi di posta elettronica non verificati del proprietario del dominio.

A seconda dello scenario, è possibile determinare che i token dell'applicazione devono continuare a ricevere messaggi di posta elettronica non verificati. Sebbene non sia consigliato per la maggior parte delle applicazioni, è possibile disabilitare il comportamento predefinito impostando la removeUnverifiedEmailClaim proprietà nell'oggetto authenticationBehaviors dell'API delle applicazioni in Microsoft Graph.

Impostando su removeUnverifiedEmailClaimfalse, l'applicazione riceverà email attestazioni potenzialmente non verificate e soggette a rischi di acquisizione da parte degli utenti. Se si disabilita questo comportamento per non interrompere i flussi di accesso utente, è consigliabile eseguire la migrazione a un mapping di attestazione token di identificazione univoco il prima possibile, come descritto nelle indicazioni seguenti.

Identificazione di configurazioni non sicure ed esecuzione della migrazione del database

È consigliabile non usare mai attestazioni modificabili , ad emailesempio , preferred_usernamee così via, come identificatori per eseguire controlli di autorizzazione o indicizzare gli utenti in un database. Questi valori sono riutilizzabili e possono esporre l'applicazione agli attacchi di escalation dei privilegi.

L'esempio di pseudocodice seguente illustra il modello non sicuro di identificazione/autorizzazione dell'utente:

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

Dopo aver determinato che l'applicazione si basa su questo attributo non sicuro, è necessario aggiornare la logica di business per reindicizzare gli utenti in un identificatore univoco globale (GUID).

Le applicazioni Mutli-tenant devono indicizzare in un mapping di due attestazioni che identificano in modo univoco, tid + oid. Questo segmenterà i tenant in base agli tidutenti e segmenterà gli utenti in base al relativo oidoggetto .

Uso dell'attestazione xms_edov facoltativa per determinare lo stato di verifica della posta elettronica ed eseguire la migrazione degli utenti

Per aiutare gli sviluppatori nel processo di migrazione, è stata introdotta un'attestazione facoltativa, xms_edov, una proprietà booleana che indica se il proprietario del dominio di posta elettronica è stato verificato o meno.

xms_edov può essere usato per verificare la posta elettronica di un utente prima di eseguire la migrazione della chiave primaria a identificatori univoci, ad esempio oid. Nell'esempio di pseudocodice seguente viene illustrato come usare questa attestazione come parte della migrazione.

// 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 migrazione a un mapping univoco globale garantisce che ogni utente venga indicizzato principalmente con un valore che non può essere riutilizzato o usato in modo improprio per rappresentare un altro utente. Dopo che gli utenti sono indicizzati in un identificatore univoco globale, è possibile correggere qualsiasi logica di autorizzazione potenziale che usa l'attestazione email .

Aggiornare la logica di autorizzazione con la convalida corretta delle attestazioni

Se l'applicazione usa email (o qualsiasi altra attestazione modificabile) a scopo di autorizzazione, è necessario leggere le API e le applicazioni sicure convalidando le attestazioni e implementando i controlli appropriati.

Passaggi successivi