GCP - Understanding Domain-Wide Delegation
Ce post est l'introduction de https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover qui peut être consulté pour plus de détails.
Comprendre la délégation à l'échelle du domaine
La délégation à l'échelle du domaine de Google Workspace permet à un objet d'identité, soit une application externe du Google Workspace Marketplace, soit un compte de service GCP interne, d'accéder aux données à travers le Workspace au nom des utilisateurs. Cette fonctionnalité, qui est cruciale pour les applications interagissant avec les API Google ou les services nécessitant une usurpation d'identité utilisateur, améliore l'efficacité et minimise les erreurs humaines en automatisant les tâches. En utilisant OAuth 2.0, les développeurs d'applications et les administrateurs peuvent donner à ces comptes de service accès aux données des utilisateurs sans le consentement individuel des utilisateurs. Google Workspace permet la création de deux principaux types d'identités d'objet déléguées globales :
Applications GWS : Les applications du Marketplace Workspace peuvent être configurées comme une identité déléguée. Avant d'être mises à disposition dans le marketplace, chaque application Workspace subit un examen par Google pour minimiser les abus potentiels. Bien que cela n'élimine pas entièrement le risque d'abus, cela augmente considérablement la difficulté pour que de tels incidents se produisent.
Compte de service GCP : En savoir plus sur les comptes de service GCP ici.
Délégation à l'échelle du domaine : En coulisses
Voici comment un compte de service GCP peut accéder aux API Google au nom d'autres identités dans Google Workspace :
L'identité crée un JWT : L'identité utilise la clé privée du compte de service (partie du fichier de paire de clés JSON) pour signer un JWT. Ce JWT contient des revendications concernant le compte de service, l'utilisateur cible à usurper, et les portées OAuth d'accès à l'API REST demandée.
L'identité utilise le JWT pour demander un jeton d'accès : L'application/utilisateur utilise le JWT pour demander un jeton d'accès au service OAuth 2.0 de Google. La demande inclut également l'utilisateur cible à usurper (l'email Workspace de l'utilisateur), et les portées pour lesquelles l'accès est demandé.
Le service OAuth 2.0 de Google renvoie un jeton d'accès : Le jeton d'accès représente l'autorité du compte de service à agir au nom de l'utilisateur pour les portées spécifiées. Ce jeton est généralement de courte durée et doit être rafraîchi périodiquement (selon les besoins de l'application). Il est essentiel de comprendre que les portées OAuth spécifiées dans le jeton JWT ont une validité et un impact sur le jeton d'accès résultant. Par exemple, les jetons d'accès possédant plusieurs portées auront une validité pour de nombreuses applications API REST.
L'identité utilise le jeton d'accès pour appeler les API Google : Maintenant avec un jeton d'accès pertinent, le service peut accéder à l'API REST requise. L'application utilise ce jeton d'accès dans l'en-tête "Authorization" de ses requêtes HTTP destinées aux API Google. Ces API utilisent le jeton pour vérifier l'identité usurpée et confirmer qu'elle a l'autorisation nécessaire.
Les API Google renvoient les données demandées : Si le jeton d'accès est valide et que le compte de service a l'autorisation appropriée, les API Google renvoient les données demandées. Par exemple, dans l'image suivante, nous avons utilisé la méthode users.messages.list pour lister tous les identifiants de messages Gmail associés à un utilisateur Workspace cible.
Last updated
