Dirottamento dell'URI di reindirizzamento Entra ID: URL wildcard e flusso implicito

Cos'è il dirottamento dell'URI di reindirizzamento Entra ID

Un URI di reindirizzamento di Entra ID — la documentazione Microsoft lo chiama anche reply URL — è l'endpoint a cui la piattaforma di identità Microsoft invia un utente, insieme a un token o a un codice di autorizzazione, una volta che si è autenticato e ha dato il consenso. Ogni app registration che utilizza il flusso authorization code di OAuth 2.0, il flusso implicit grant, o OpenID Connect deve elencare in anticipo i propri URI di reindirizzamento esatti; Entra ID rifiuta di reindirizzare altrove e restituisce AADSTS50011 se il valore nella richiesta di accesso non corrisponde a nessuno di quelli registrati.

Questo passaggio di corrispondenza è, da solo, l'intero confine di sicurezza. Tre scelte di configurazione su una singola app registration bastano a indebolirlo abbastanza da permettere a un attaccante di ottenere un token valido al posto dell'app legittima:

• Reply URL con wildcard (APP_REPLY_URL_WILDCARD) — un pattern come https://*.contoso.com invece di un URL esatto.
• Reply URL in HTTP (APP_REPLY_URL_HTTP) — un URI di reindirizzamento non limitato a https.
• Implicit grant abilitato (APP_IMPLICIT_GRANT_ENABLED) — l'app registration lascia ancora che Entra ID restituisca direttamente un access token o un ID token nel browser, invece di passare per uno scambio di token lato server.

Ognuno di questi punti ha severità Alta da solo nel catalogo EtcSec. Combinati sulla stessa app, trasformano un semplice link di phishing in un percorso di esfiltrazione di token funzionante — e si aggiungono ad altri rischi delle app registration monitorati da EtcSec, come le app registration con permessi eccessivi, le credenziali obsolete, e i permessi Graph API pericolosi.

Come funziona

La corrispondenza esatta è il punto, i wildcard lo vanificano

Entra ID richiede che gli URI di reindirizzamento inizino con https, con un'eccezione ristretta per localhost in sviluppo locale — http://localhost/myapp è valido, http://contoso.com/callback non lo è. I wildcard sono un allentamento separato e opzionale della regola di corrispondenza, non della regola di schema: un'app registration limitata agli account aziendali o scolastici può, tramite l'editor del manifest dell'applicazione, registrare https://*.contoso.com e far sì che Entra ID tratti come autorizzato qualsiasi sottodominio corrispondente. La guida ufficiale Microsoft su best practice e limitazioni degli URI di reindirizzamento è esplicita: questo va evitato; secondo la RFC 6749 sezione 3.1.2, un endpoint di reindirizzamento deve essere un URI assoluto, e quando una voce wildcard corrisponde, Entra rimuove la query string e il frammento dal reindirizzamento — che è esattamente dove viaggerebbe un token del flusso implicito.

La RFC 9700, le attuali best practice di sicurezza IETF per OAuth 2.0, va oltre il semplice "evitare": richiede che i server di autorizzazione usino la corrispondenza esatta della stringa per gli URI di reindirizzamento, con la sola eccezione del numero di porta sugli URI localhost dei client nativi. La motivazione è concreta — implementazioni ingenue dei wildcard hanno permesso ad attaccanti di registrare qualcosa come attaccante.esempio/.sitovittima.esempio e far passare una corrispondenza di sottostringa, e persino una gestione corretta dei wildcard lascia aperto il subdomain takeover come percorso reale: qualsiasi sottodominio che un attaccante possa attivare (un CNAME abbandonato, un host di sviluppo dimenticato) diventa un target di reindirizzamento valido non appena corrisponde al pattern.

L'implicit grant consegna il token a chiunque detenga l'URL

Il flusso authorization code mantiene lo scambio del token su un canale separato: il browser vede solo un codice di breve durata, che l'app scambia poi con un token da server a server. L'implicit grant salta questo passaggio — Entra ID restituisce direttamente l'access token o l'ID token nella risposta /authorize, aggiunto al frammento dell'URI di reindirizzamento. Questo comportamento è controllato per singola app registration tramite due proprietà di Microsoft Graph sulla risorsa web dell'applicazione: implicitGrantSettings.enableIdTokenIssuance e implicitGrantSettings.enableAccessTokenIssuance. Se una delle due è true, l'app può richiedere un response type token o id_token e ottenere un token senza alcuno scambio lato server.

La RFC 9700 sezione 2.1.2 è diretta sulla conseguenza: i client "NON DOVREBBERO usare l'implicit grant … a meno che l'iniezione di access token nella risposta di autorizzazione non sia impedita e i vettori di fuga di token menzionati non siano mitigati". I vettori di fuga elencati sono poco appariscenti ma reali — un token che risiede in un frammento di URL può finire nella cronologia del browser, essere ripropagato dallo user agent attraverso i redirect, o trapelare tramite un header Referer verso un sito terzo a cui la pagina che porta il token si trova a linkare. In aggiunta, un token del flusso implicito non ha alcun sender-constraining: nulla lo lega al client per cui è stato emesso, quindi una copia vale quanto l'originale. Anche la documentazione Microsoft sul flusso implicit grant è arrivata alla stessa conclusione da un'angolazione diversa — l'abbandono dei cookie di terze parti da parte dei browser ha rotto il passaggio di rinnovo silenzioso del flusso — e ora dice esplicitamente agli sviluppatori di non usarlo, rimandando alla RFC 9700 sezione 2.1.2 e raccomandando la migrazione al flusso authorization code.

La catena di attacco

Passo 1 — Trovare o dirottare un target di reindirizzamento che corrisponde

Se l'app registration target porta APP_REPLY_URL_WILDCARD — diciamo https://*.contoso.com/auth — l'attaccante non deve compromettere il dominio principale. Qualsiasi sottodominio che si risolve, incluso uno di un ambiente di sviluppo abbandonato o un record DNS orfano lasciato da un servizio dismesso, corrisponde al pattern e diventa un target di reindirizzamento dall'aspetto legittimo per Entra ID.

Passo 2 — Richiedere un token invece di un codice

Con APP_IMPLICIT_GRANT_ENABLED impostato sull'app, l'attaccante costruisce un URL di accesso contro il vero client_id con response_type=token (o id_token token) e redirect_uri impostato sul proprio endpoint corrispondente, poi lo distribuisce come link di phishing. La vittima si autentica sulla pagina di accesso genuina di Entra ID — non c'è nessun falso modulo di login da individuare — ed Entra ID reindirizza il browser all'endpoint dell'attaccante con il token allegato.

Passo 3 — Catturare il token in chiaro

Dove APP_REPLY_URL_HTTP è presente anche qui, o dove l'endpoint controllato dall'attaccante si limita a registrare ciò che riceve, il token che viaggia nell'URL può essere catturato direttamente, loggato da un proxy, o esposto tramite i vettori di fuga documentati dalla RFC 9700 — cronologia del browser, header Referer sui link in uscita dalla pagina di atterraggio, o ripropagazione durante un ulteriore redirect.

Passo 4 — Riutilizzare il token senza alcun client secret richiesto

Poiché l'implicit grant emette un bearer token senza sender-constraining, l'attaccante lo usa direttamente contro Microsoft Graph o qualunque risorsa per cui era scopato, fingendosi la vittima, finché resta valido. Questo flusso non prevede un refresh token, quindi la finestra è delimitata dalla durata dell'access token — ma nient'altro si frappone tra la cattura e il riutilizzo. Questo è un meccanismo diverso dal phishing da consenso OAuth, che induce un utente ad autorizzare un'app malevola invece di intercettare un token destinato a una legittima — ma entrambi finiscono con un attaccante in possesso di una credenziale valida verso il vostro tenant.

Rilevamento

La configurazione degli URI di reindirizzamento e le impostazioni dell'implicit grant risiedono sull'oggetto applicazione, non nei log di attività di accesso, quindi si tratta di un controllo di inventario su Microsoft Graph piuttosto che di una query SIEM:

Nell'admin center di Microsoft Entra, la stessa informazione è visibile per app sotto App registrations → [app] → Authentication: la lista degli URI di reindirizzamento della piattaforma Web, e le caselle Implicit grant and hybrid flows per ID token e access token.

Correzione (Remediation)

1. Sostituire gli URI di reindirizzamento wildcard con URI esatti e assoluti. Elenca ogni endpoint di callback reale individualmente invece di un pattern. Se il numero di sottodomini rende la cosa ingestibile, Microsoft documenta un'alternativa con parametro state: un singolo URI di reindirizzamento condiviso, protetto da CSRF, più un valore state specifico per app, invece di una corrispondenza wildcard.
2. Rimuovere qualsiasi URI di reindirizzamento http:// non-localhost. Entra ID rifiuta già le nuove voci senza https al di fuori di localhost, ma le app registration legacy possono averne una risalente a prima che questa restrizione fosse applicata; verifica direttamente web.redirectUris invece di assumere che l'admin center l'avrebbe bloccata alla creazione.
3. Disabilitare l'implicit grant. Imposta sia implicitGrantSettings.enableIdTokenIssuance sia enableAccessTokenIssuance su false (o deseleziona le due caselle nel portale), a meno che un'integrazione legacy non ne dipenda esplicitamente.
4. Migrare al flusso authorization code con PKCE. La RFC 9700 sezione 2.1.1 richiede PKCE per i client pubblici e lo raccomanda per i client confidenziali; le librerie MSAL di Microsoft implementano lo scambio del codice e la challenge PKCE al posto vostro, quindi di solito è una sostituzione di libreria e non un progetto di reimplementazione del protocollo.
5. Ricontrollare la piattaforma dopo la migrazione. Una single-page app che necessita ancora di un flusso limitato al browser deve migrare al flusso authorization code con PKCE sulla piattaforma SPA, e non restare su Web con l'implicit grant abilitato.

Come EtcSec rileva questo

L'audit Azure di EtcSec legge web.redirectUris e web.implicitGrantSettings di ogni app registration tramite Microsoft Graph, e solleva APP_REPLY_URL_WILDCARD per qualsiasi voce wildcard, APP_REPLY_URL_HTTP per qualsiasi voce http:// non-localhost, e APP_IMPLICIT_GRANT_ENABLED quando uno dei due flag di emissione dell'implicit grant è true — tutti e tre limitati alla piattaforma Web, come indicato sopra. Questo cluster è solo una parte di una revisione più ampia; vedi la nostra guida pratica per verificare la sicurezza di Microsoft Entra ID per la checklist completa oltre alle app registration.