GCP - Understanding Domain-Wide Delegation
Esta publicación es la introducción de https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover que se puede consultar para más detalles.
Comprendiendo la Delegación de Dominio Amplio
La delegación de dominio amplio de Google Workspace permite que un objeto de identidad, ya sea una aplicación externa del Marketplace de Google Workspace o una Cuenta de Servicio de GCP interna, acceda a datos en todo el Workspace en nombre de los usuarios. Esta función, que es crucial para aplicaciones que interactúan con APIs de Google o servicios que necesitan suplantación de usuarios, mejora la eficiencia y minimiza el error humano al automatizar tareas. Usando OAuth 2.0, los desarrolladores de aplicaciones y administradores pueden otorgar a estas cuentas de servicio acceso a los datos de los usuarios sin el consentimiento individual de los usuarios. Google Workspace permite la creación de dos tipos principales de identidades de objeto delegadas globales:
Aplicaciones GWS: Las aplicaciones del Marketplace de Workspace pueden configurarse como una identidad delegada. Antes de estar disponibles en el marketplace, cada aplicación de Workspace pasa por una revisión por parte de Google para minimizar el posible uso indebido. Si bien esto no elimina por completo el riesgo de abuso, aumenta significativamente la dificultad para que tales incidentes ocurran.
Cuenta de Servicio de GCP: Aprende más sobre Cuentas de Servicio de GCP aquí.
Delegación de Dominio Amplio: Detrás de Escena
Así es como una Cuenta de Servicio de GCP puede acceder a las APIs de Google en nombre de otras identidades en Google Workspace:
La identidad crea un JWT: La identidad utiliza la clave privada de la cuenta de servicio (parte del archivo de clave JSON) para firmar un JWT. Este JWT contiene afirmaciones sobre la cuenta de servicio, el usuario objetivo a suplantar y los ámbitos de OAuth de acceso a la API REST que se está solicitando.
La identidad utiliza el JWT para solicitar un token de acceso: La aplicación/usuario utiliza el JWT para solicitar un token de acceso del servicio OAuth 2.0 de Google. La solicitud también incluye el usuario objetivo a suplantar (el correo electrónico del usuario de Workspace) y los ámbitos para los cuales se solicita acceso.
El servicio OAuth 2.0 de Google devuelve un token de acceso: El token de acceso representa la autoridad de la cuenta de servicio para actuar en nombre del usuario para los ámbitos especificados. Este token es típicamente de corta duración y debe ser renovado periódicamente (según la necesidad de la aplicación). Es esencial entender que los ámbitos de OAuth especificados en el token JWT tienen validez e impacto en el token de acceso resultante. Por ejemplo, los tokens de acceso que poseen múltiples ámbitos tendrán validez para numerosas aplicaciones de API REST.
La identidad utiliza el token de acceso para llamar a las APIs de Google: Ahora, con un token de acceso relevante, el servicio puede acceder a la API REST requerida. La aplicación utiliza este token de acceso en el encabezado "Authorization" de sus solicitudes HTTP destinadas a las APIs de Google. Estas APIs utilizan el token para verificar la identidad suplantada y confirmar que tiene la autorización necesaria.
Las APIs de Google devuelven los datos solicitados: Si el token de acceso es válido y la cuenta de servicio tiene la autorización adecuada, las APIs de Google devuelven los datos solicitados. Por ejemplo, en la siguiente imagen, hemos aprovechado el método users.messages.list para listar todos los IDs de mensajes de Gmail asociados con un usuario objetivo de Workspace.
Last updated
