GCP - Understanding Domain-Wide Delegation
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 a cui si può accedere per ulteriori dettagli.
Comprensione della Delega a Livello di Dominio
La delega a livello di dominio di Google Workspace consente a un oggetto di identità, sia un applicazione esterna dal Google Workspace Marketplace o un Account di Servizio GCP interno, di accedere ai dati in tutto il Workspace per conto degli utenti. Questa funzionalità, fondamentale per le applicazioni che interagiscono con le API di Google o i servizi che necessitano dell'impersonificazione dell'utente, migliora l'efficienza e riduce gli errori umani automatizzando compiti. Utilizzando OAuth 2.0, gli sviluppatori di app e gli amministratori possono concedere a questi account di servizio l'accesso ai dati degli utenti senza il consenso individuale dell'utente. Google Workspace consente la creazione di due tipi principali di identità oggetto delegate globali:
Applicazioni GWS: Le applicazioni dal Workspace Marketplace possono essere configurate come identità delegate. Prima di essere rese disponibili nel marketplace, ogni applicazione Workspace viene sottoposta a una revisione da parte di Google per ridurre al minimo possibili abusi. Anche se questo non elimina del tutto il rischio di abusi, aumenta significativamente la difficoltà che tali incidenti si verifichino.
Account di Servizio GCP: Per saperne di più sugli Account di Servizio GCP qui.
Delega a Livello di Dominio: Dietro le Quinte
Ecco come un Account di Servizio GCP può accedere alle API di Google per conto di altre identità in Google Workspace:
L'Identità crea un JWT: L'Identità utilizza la chiave privata dell'account di servizio (parte del file di coppia di chiavi JSON) per firmare un JWT. Questo JWT contiene informazioni sull'account di servizio, sull'utente di destinazione da impersonare e sugli ambiti OAuth di accesso all'API REST richiesta.
L'Identità utilizza il JWT per richiedere un token di accesso: L'applicazione/l'utente utilizza il JWT per richiedere un token di accesso dal servizio OAuth 2.0 di Google. La richiesta include anche l'utente di destinazione da impersonare (l'email dell'utente di Workspace) e gli ambiti per i quali viene richiesto l'accesso.
Il servizio OAuth 2.0 di Google restituisce un token di accesso: Il token di accesso rappresenta l'autorità dell'account di servizio di agire per conto dell'utente per gli ambiti specificati. Questo token è tipicamente a breve termine e deve essere aggiornato periodicamente (secondo le esigenze 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 avranno validità per numerose applicazioni API REST.
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 "Autorizzazione" delle sue richieste HTTP destinate alle API di Google. Queste API utilizzano il token per verificare l'identità impersonata e confermare che abbia l'autorizzazione necessaria.
Le API di Google restituiscono i dati richiesti: Se il token di accesso è valido e l'account di servizio ha l'autorizzazione appropriata, le API di Google restituiscono i dati richiesti. Ad esempio, nella seguente immagine, abbiamo sfruttato il metodo users.messages.list per elencare tutti gli ID dei messaggi Gmail associati a un utente di Workspace di destinazione.
Last updated
