Condividi tramite

Impedire l'uso di attestazioni di posta elettronica per l'identificazione o l'autorizzazione dell'utente

  • Articolo

Questo articolo intende fornire indicazioni agli sviluppatori di applicazioni attualmente basate su un modello non sicuro in cui l'attestazione di posta elettronica viene usata per l'autorizzazione, con possibile acquisizione totale dell'account da parte di un altro utente. Continuare a leggere per altre informazioni sulle possibili ripercussioni per l'applicazione e sui passaggi per porvi rimedio.

Come stabilire se il problema riguarda l'applicazione?

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

  • Un'attestazione modificabile, ad esempio email, viene usata per identificare in modo univoco un utente
  • Un'attestazione modificabile, ad esempio email, viene usata per autorizzare l'accesso alle risorse da parte dell'utente

Questi modelli sono considerati non sicuri, poiché gli utenti senza una cassetta postale di cui è stato effettuato il provisioning possono impostare qualsiasi indirizzo e-mail come attributo di posta elettronica (SMTP primario). Non c'è alcuna garanzia che questo attributo provenga da un indirizzo e-mail verificato. Quando un'attestazione di posta elettronica con un proprietario di dominio non verificato viene usata per l'autorizzazione, qualsiasi utente senza una cassetta postale di cui è stato effettuato il provisioning può ottenere l'accesso non autorizzato modificando l'attributo di posta elettronica per rappresentare un altro utente.

Si considera che un messaggio di posta elettronica ha un proprietario di dominio verificato se:

  • Il dominio appartiene al tenant in cui risiede l'account utente e l'amministratore tenant ha completato 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 tramite il flusso di passcode monouso (OTP)

Si noti inoltre 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 eseguire l'escalation dei propri privilegi per accedere alle risorse da un altro tenant modificando l'attributo di posta elettronica.

Come proteggere immediatamente l'applicazione?

Per prevenire il rischio di errori nelle applicazioni con indirizzi e-mail non verificati, a partire da giugno 2023 tutte le nuove applicazioni multi-tenant vengono configurate automaticamente con un nuovo comportamento predefinito che rimuove dai token gli indirizzi e-mail con proprietari di dominio non verificati. Questo comportamento non è abilitato per le applicazioni a tenant singolo e le applicazioni multi-tenant con precedenti attività di accesso tramite indirizzi e-mail con proprietario di dominio non verificato.

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

Impostando removeUnverifiedEmailClaim su false, l'applicazione riceverà attestazioni email potenzialmente non verificate e soggette al rischio di acquisizione dell'account da parte degli utenti. Se si disabilita questo comportamento per evitare di interrompere i flussi di accesso degli utenti, è vivamente consigliato migrare a una mappatura delle attestazioni dei token di identificazione univoca il prima possibile, come indicato di seguito.

Identificazione di configurazioni non sicure ed esecuzione della migrazione del database

Non usare mai attestazioni modificabili (ad esempio email, preferred_username e così via) come identificatori per eseguire controlli delle autorizzazioni o indicizzare gli utenti in un database. Questi valori possono essere riutilizzati e potrebbero esporre la tua applicazione a attacchi di escalation dei privilegi.

Il p-code di esempio riportato di seguito aiuta a illustrare 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 arbitrarily set email
 }

Dopo aver stabilito 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 multitenant devono indicizzare basandosi su una mappa di due rivendicazioni identificative univoche tid + oid. I tenant saranno segmentati in base al tid e gli utenti in base al oid.

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

Per supportare 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 usata per verificare la posta elettronica di un utente prima di eseguire la migrazione della chiave primaria a identificatori univoci, come oid. Il pseudocodice di esempio riportato di seguito illustra come questa asserzione possa essere utilizzata come parte della tua 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 non riutilizzabile o usato in modo improprio per rappresentare un altro utente. Dopo aver indicizzato gli utenti in un identificatore univoco globale, è possibile correggere qualsiasi logica di autorizzazione potenziale che usi l'attestazione email.

Aggiornare la logica di autorizzazione con la convalida delle attestazioni corretta

Se l'applicazione utilizza email (o qualsiasi altra attestazione modificabile) per scopi di autorizzazione, dovresti leggere Proteggere applicazioni e API convalidando le attestazioni e implementare i controlli appropriati.

Passaggi successivi