GCP - Comprendere la Delegazione a Livello di Dominio

Reading time: 4 minutes

Questo post è l'introduzione di https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover che può essere consultato per ulteriori dettagli.

Comprendere la Delegazione a Livello di Dominio

La delegazione a livello di dominio di Google Workspace consente a un oggetto identità, sia un app esterna dal Google Workspace Marketplace che un GCP Service Account interno, di accedere ai dati attraverso il Workspace per conto degli utenti. Questa funzionalità, cruciale per le app che interagiscono con le API di Google o servizi che necessitano di impersonificazione dell'utente, migliora l'efficienza e riduce l'errore umano automatizzando i compiti. Utilizzando OAuth 2.0, gli sviluppatori di app e gli amministratori possono dare a questi service account accesso ai dati degli utenti senza il consenso individuale degli utenti.

Google Workspace consente la creazione di due principali tipi di identità di oggetti delegati globali:

• Applicazioni GWS: Le applicazioni del Marketplace di Workspace possono essere configurate come un'identità delegata. Prima di essere rese disponibili nel marketplace, ogni applicazione di Workspace viene sottoposta a una revisione da parte di Google per ridurre al minimo il potenziale abuso. Anche se questo non elimina completamente il rischio di abuso, aumenta significativamente la difficoltà affinché tali incidenti si verifichino.
• GCP Service Account: Scopri di più su GCP Service Accounts qui.

Delegazione a Livello di Dominio: Dietro le Quinte

Ecco come un GCP Service Account può accedere alle API di Google per conto di altre identità in Google Workspace:

1. L'identità crea un JWT: L'identità utilizza la chiave privata del service account (parte del file della coppia di chiavi JSON) per firmare un JWT. Questo JWT contiene dichiarazioni sul service account, l'utente target da impersonare e gli ambiti OAuth di accesso all'API REST richiesta.
2. L'identità utilizza il JWT per richiedere un token di accesso: L'applicazione/utente utilizza il JWT per richiedere un token di accesso dal servizio OAuth 2.0 di Google. La richiesta include anche l'utente target da impersonare (l'email dell'utente di Workspace) e gli ambiti per i quali viene richiesto l'accesso.
3. Il servizio OAuth 2.0 di Google restituisce un token di accesso: Il token di accesso rappresenta l'autorità del service account di agire per conto dell'utente per gli ambiti specificati. Questo token è tipicamente a breve termine e deve essere rinnovato periodicamente (in base alle necessità dell'applicazione). È essenziale comprendere che gli ambiti OAuth specificati nel token JWT hanno validità e impatto sul token di accesso risultante. Ad esempio, i token di accesso che possiedono più ambiti manterranno validità per numerose applicazioni API REST.
4. L'identità utilizza il token di accesso per chiamare le API di Google: Ora con un token di accesso pertinente, il servizio può accedere all'API REST richiesta. L'applicazione utilizza questo token di accesso nell'intestazione "Authorization" delle sue richieste HTTP destinate alle API di Google. Queste API utilizzano il token per verificare l'identità impersonata e confermare che ha l'autorizzazione necessaria.
5. Le API di Google restituiscono i dati richiesti: Se il token di accesso è valido e il service account ha l'autorizzazione appropriata, le API di Google restituiscono i dati richiesti. Ad esempio, nell'immagine seguente, abbiamo utilizzato il metodo users.messages.list per elencare tutti gli ID dei messaggi Gmail associati a un utente target di Workspace.