GCP - Razumevanje Delegacije na Nivou Domen

Reading time: 4 minutes

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 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.

Delegacija na Nivou Domen: Iza Scene

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

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.