Last updated
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 wat vir meer besonderhede besoek kan word.
Google Workspace se Domeinwye delegasie maak dit moontlik vir 'n identiteitsobjek, of dit nou 'n eksterne toepassing van die Google Workspace-markplek is of 'n interne GCP-diensrekening, om data regoor die Workspace namens gebruikers te benader. Hierdie kenmerk, wat noodsaaklik is vir toepassings wat met Google-API's interaksieer of dienste benodig vir gebruikersverpersoonliking, verbeter doeltreffendheid en minimaliseer menslike foute deur take te outomatiseer. Deur gebruik te maak van OAuth 2.0 kan toepassingsontwikkelaars en administrateurs hierdie diensrekeninge toegang tot gebruikersdata gee sonder individuele gebruikersgoedkeuring. Google Workspace maak die skepping van twee hooftipes globale gedelegeerde objekidentiteite moontlik:
GWS-toepassings: Toepassings van die Workspace-markplek 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. Alhoewel dit nie die risiko van misbruik heeltemal uitskakel nie, verhoog dit die moeilikheid vir sulke voorvalle aansienlik.
GCP-diensrekening: Leer meer oor GCP-diensrekeninge hier.
So kan 'n GCP-diensrekening Google-API's namens ander identiteite in Google Workspace benader:
Identiteit skep 'n JWT: Die identiteit gebruik die privaatsleutel van die diensrekening (deel van die JSON-sleutelpaar-lêer) om 'n JWT te onderteken. Hierdie JWT bevat bewerings oor die diensrekening, die teikengebruiker om te verpersoonlik, en die OAuth-skopes van toegang tot die REST-API wat aangevra word.
Die Identiteit gebruik die JWT om 'n toegangsteken aan te vra: Die toepassing/gebruiker gebruik die JWT om 'n toegangsteken van Google se OAuth 2.0-diens aan te vra. Die versoek sluit ook die teikengebruiker om te verpersoonlik (die gebruiker se Workspace-e-pos) en die skopes waarvoor toegang aangevra word, in.
Google se OAuth 2.0-diens gee 'n toegangsteken terug: Die toegangsteken verteenwoordig die diensrekening se gesag om namens die gebruiker op te tree vir die gespesifiseerde skopes. Hierdie teken is tipies kortstondig en moet periodiek hernu word (volgens die toepassing se behoefte). Dit is noodsaaklik om te verstaan dat die OAuth-skopes wat in die JWT-teken gespesifiseer is, geldigheid het en 'n impak op die resulterende toegangsteken het. Byvoorbeeld, toegangstekens met verskeie skopes sal geldigheid hê vir verskeie REST-API-toepassings.
Die Identiteit gebruik die toegangsteken om Google-API's te roep: Nou, met 'n relevante toegangsteken, kan die diens die vereiste REST-API benader. Die toepassing gebruik hierdie toegangsteken in die "Authorization"-kop van sy HTTP-versoeke wat bestem is vir Google-API's. Hierdie API's gebruik die teken om die verpersoonlikte identiteit te verifieer en te bevestig dat dit die nodige magtiging het.
Google-API's gee die versoekte data terug: As die toegangsteken geldig is en die diensrekening die nodige magtiging het, gee die Google-API's die versoekte data terug. Byvoorbeeld, in die volgende prentjie het ons die users.messages.list metode gebruik om al die Gmail-boodskap-ID's wat met 'n teiken Workspace-gebruiker geassosieer word, te lys.
