# GCP - Verstaan van Domein-Wye Delegasie

{{#include ../../../banners/hacktricks-training.md}}

Hierdie pos is die inleiding van [https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover](https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover) wat toegang bied tot meer besonderhede.

## **Verstaan van Domein-Wye Delegasie**

Google Workspace se Domein-Wye delegasie laat 'n identiteitsobjek, hetsy 'n **eksterne app** van Google Workspace Marketplace of 'n interne **GCP-diensrekening**, toe om **data oor die Workspace namens gebruikers te verkry**. Hierdie funksie, wat van kardinale belang is vir toepassings wat met Google API's of dienste wat gebruikersverpersoonliking benodig, interaksie het, verbeter doeltreffendheid en minimaliseer menslike foute deur take te outomatiseer. Deur gebruik te maak van OAuth 2.0, kan app-ontwikkelaars en administrateurs hierdie diensrekeninge toegang tot gebruikersdata gee sonder individuele gebruikers se toestemming.\
\
Google Workspace laat die skepping van twee hoofsoorte globale gedelegeerde objek identiteite toe:

- **GWS Toepassings:** Toepassings van die Workspace Marketplace kan as 'n gedelegeerde identiteit opgestel word. Voordat dit in die markplek beskikbaar gestel word, ondergaan elke Workspace-toepassing 'n hersiening deur Google om potensiële misbruik te minimaliseer. Terwyl dit nie die risiko van misbruik heeltemal uitskakel nie, verhoog dit aansienlik die moeilikheidsgraad vir sulke voorvalle om voor te kom.
- **GCP-diensrekening:** Leer meer oor [**GCP-diensrekeninge hier**](../gcp-basic-information/#service-accounts).

### **Domein-Wye Delegasie: Onder die Motorkap**

So kan 'n GCP-diensrekening Google API's namens ander identiteite in Google Workspace benader:

<figure><img src="../../../images/image (58).png" alt=""><figcaption></figcaption></figure>

1. **Identiteit skep 'n JWT:** Die Identiteit gebruik die diensrekening se privaat sleutel (deel van die JSON-sleutel paar lêer) om 'n JWT te teken. Hierdie JWT bevat aansprake oor die diensrekening, die te verpersoonlikte teiken gebruiker, en die OAuth skope van toegang tot die REST API wat aangevra word.
2. **Die Identiteit gebruik die JWT om 'n toegangstoken aan te vra:** Die toepassing/gebruiker gebruik die JWT om 'n toegangstoken van Google se OAuth 2.0 diens aan te vra. Die aanvraag sluit ook die teiken gebruiker in om te verpersoonlik (die gebruiker se Workspace e-pos), en die skope waarvoor toegang aangevra word.
3. **Google se OAuth 2.0 diens keer 'n toegangstoken terug:** Die toegangstoken verteenwoordig die diensrekening se gesag om namens die gebruiker vir die gespesifiseerde skope op te tree. Hierdie token is tipies kortstondig en moet periodiek verfris word (volgens die toepassing se behoefte). Dit is noodsaaklik om te verstaan dat die OAuth skope wat in die JWT-token gespesifiseer is, geldigheid het en 'n impak op die resulterende toegangstoken het. Byvoorbeeld, toegangstokens wat verskeie skope besit, sal geldigheid hou vir verskeie REST API-toepassings.
4. **Die Identiteit gebruik die toegangstoken om Google API's aan te roep**: Nou met 'n relevante toegangstoken, kan die diens die vereiste REST API benader. Die toepassing gebruik hierdie toegangstoken in die "Authorization" kop van sy HTTP-aanvra vir Google API's. Hierdie API's gebruik die token om die verpersoonlikte identiteit te verifieer en te bevestig dat dit die nodige magtiging het.
5. **Google API's keer die aangevraagde data terug**: As die toegangstoken geldig is en die diensrekening die toepaslike magtiging het, keer die Google API's die aangevraagde data terug. Byvoorbeeld, in die volgende prent, het ons die _users.messages.list_ metode benut om al die Gmail boodskap-ID's wat met 'n teiken Workspace-gebruiker geassosieer is, te lys.

{{#include ../../../banners/hacktricks-training.md}}
