# GCP - Razumevanje Delegacije na Nivou Domen

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

Ovaj post je uvod u [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) koji se može pristupiti za više detalja.

## **Razumevanje Delegacije na Nivou Domen**

Delegacija na nivou domena Google Workspace omogućava identitetskom objektu, bilo **spoljnoj aplikaciji** iz Google Workspace Marketplace-a ili internom **GCP servisnom nalogu**, da **pristupi podacima širom Workspace-a u ime korisnika**. Ova funkcija, koja je ključna za aplikacije koje komuniciraju sa Google API-ima ili uslugama koje zahtevaju impersonaciju korisnika, poboljšava efikasnost i minimizira ljudske greške automatizacijom zadataka. Korišćenjem OAuth 2.0, programeri aplikacija i administratori mogu dati ovim servisnim nalozima pristup korisničkim podacima bez pojedinačne saglasnosti korisnika.\
\
Google Workspace omogućava kreiranje dva glavna tipa globalnih delegiranih identiteta:

- **GWS Aplikacije:** Aplikacije iz Workspace Marketplace-a mogu biti postavljene kao delegirani identitet. Pre nego što postanu dostupne na tržištu, svaka Workspace aplikacija prolazi reviziju od strane Google-a kako bi se minimizirala potencijalna zloupotreba. Iako to ne eliminiše potpuno rizik od zloupotrebe, značajno povećava težinu za takve incidente da se dogode.
- **GCP Servisni Nalog:** Saznajte više o [**GCP Servisnim Nalozima ovde**](../gcp-basic-information/#service-accounts).

### **Delegacija na Nivou Domen: Iza Scene**

Ovako GCP Servisni Nalog može pristupiti Google API-ima u ime drugih identiteta u Google Workspace-u:

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

1. **Identitet kreira JWT:** Identitet koristi privatni ključ servisnog naloga (deo JSON datoteke sa ključem) da potpiše JWT. Ovaj JWT sadrži tvrdnje o servisnom nalogu, ciljanom korisniku koga treba impersonirati, i OAuth opsezima pristupa REST API-ju koji se zahteva.
2. **Identitet koristi JWT da zatraži pristupni token:** Aplikacija/korisnik koristi JWT da zatraži pristupni token od Google-ove OAuth 2.0 usluge. Zahtev takođe uključuje ciljanog korisnika koga treba impersonirati (korisnički Workspace email), i opsege za koje se traži pristup.
3. **Google-ova OAuth 2.0 usluga vraća pristupni token:** Pristupni token predstavlja ovlašćenje servisnog naloga da deluje u ime korisnika za određene opsege. Ovaj token je obično kratkotrajan i mora se periodično osvežavati (prema potrebama aplikacije). Važno je razumeti da opsezi OAuth navedeni u JWT tokenu imaju validnost i uticaj na rezultantni pristupni token. Na primer, pristupni tokeni koji poseduju više opsega će imati validnost za brojne REST API aplikacije.
4. **Identitet koristi pristupni token da pozove Google API-e**: Sada sa relevantnim pristupnim tokenom, servis može pristupiti potrebnom REST API-ju. Aplikacija koristi ovaj pristupni token u "Authorization" header-u svojih HTTP zahteva upućenih Google API-ima. Ovi API-ji koriste token da verifikuju impersonirani identitet i potvrde da ima potrebna ovlašćenja.
5. **Google API-e vraćaju tražene podatke**: Ako je pristupni token validan i servisni nalog ima odgovarajuće ovlašćenje, Google API-e vraćaju tražene podatke. Na primer, na sledećoj slici, iskoristili smo metodu _users.messages.list_ da bismo naveli sve Gmail ID-ove poruka povezane sa ciljnim Workspace korisnikom.

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