OAuth do preuzimanja naloga

Reading time: 16 minutes

Osnovne informacije

OAuth nudi različite verzije, sa osnovnim uvidima dostupnim na OAuth 2.0 dokumentacija. Ova diskusija se prvenstveno fokusira na široko korišćeni OAuth 2.0 tip granta za autorizaciju, pružajući okvir autorizacije koji omogućava aplikaciji da pristupi ili izvrši radnje na korisničkom nalogu u drugoj aplikaciji (server za autorizaciju).

Zamislite hipotetičku veb stranicu https://example.com, dizajniranu da prikaže sve vaše objave na društvenim mrežama, uključujući privatne. Da bi to postigla, koristi se OAuth 2.0. https://example.com će zatražiti vašu dozvolu da pristupi vašim objavama na društvenim mrežama. Kao rezultat toga, na https://socialmedia.com će se pojaviti ekran za saglasnost, koji će prikazati dozvole koje se traže i programera koji podnosi zahtev. Nakon vaše autorizacije, https://example.com dobija mogućnost da pristupi vašim objavama u vaše ime.

Važno je razumeti sledeće komponente unutar OAuth 2.0 okvira:

• vlasnik resursa: Vi, kao korisnik/entitet, autorizujete pristup vašem resursu, kao što su objave na vašem nalogu na društvenim mrežama.
• server resursa: server koji upravlja autentifikovanim zahtevima nakon što je aplikacija obezbedila access token u ime vlasnika resursa, npr. https://socialmedia.com.
• klijentska aplikacija: aplikacija koja traži autorizaciju od vlasnika resursa, kao što je https://example.com.
• server za autorizaciju: server koji izdaje access tokens klijentskoj aplikaciji nakon uspešne autentifikacije vlasnika resursa i obezbeđivanja autorizacije, npr. https://socialmedia.com.
• client_id: Javni, jedinstveni identifikator za aplikaciju.
• client_secret: Tajni ključ, poznat samo aplikaciji i serveru za autorizaciju, koji se koristi za generisanje access_tokens.
• response_type: Vrednost koja specificira tip tokena koji se traži, kao što je code.
• scope: nivo pristupa koji klijentska aplikacija traži od vlasnika resursa.
• redirect_uri: URL na koji se korisnik preusmerava nakon autorizacije. Ovo obično mora biti u skladu sa unapred registrovanim URL-om za preusmeravanje.
• state: Parametar za održavanje podataka tokom korisnikovog preusmeravanja ka i sa servera za autorizaciju. Njegova jedinstvenost je ključna za služenje kao mehanizam zaštite od CSRF.
• grant_type: Parametar koji označava tip granta i tip tokena koji treba da bude vraćen.
• code: Autorizacioni kod sa servera za autorizaciju, koji klijentska aplikacija koristi zajedno sa client_id i client_secret da bi dobila access_token.
• access_token: token koji klijentska aplikacija koristi za API zahteve u ime vlasnika resursa.
• refresh_token: Omogućava aplikaciji da dobije novi access_token bez ponovnog traženja od korisnika.

Tok

Aktuelni OAuth tok se odvija na sledeći način:

1. Idete na https://example.com i birate dugme “Integracija sa društvenim mrežama”.
2. Sajt zatim šalje zahtev na https://socialmedia.com tražeći vašu autorizaciju da aplikacija https://example.com pristupi vašim objavama. Zahtev je strukturiran kao:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. Zatim se prikazuje stranica za pristanak.
4. Nakon vašeg odobrenja, Social Media šalje odgovor na redirect_uri sa code i state parametrima:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com koristi ovaj code, zajedno sa svojim client_id i client_secret, da izvrši zahtev na serverskoj strani kako bi dobio access_token u vaše ime, omogućavajući pristup dozvolama na koje ste pristali:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. Na kraju, proces se završava kada https://example.com koristi vaš access_token da izvrši API poziv ka društvenim mrežama za pristup

Ranljivosti

Otvoreni redirect_uri

redirect_uri je ključan za bezbednost u OAuth i OpenID implementacijama, jer usmerava gde se osetljivi podaci, poput autorizacionih kodova, šalju nakon autorizacije. Ako je pogrešno konfigurisano, može omogućiti napadačima da preusmere ove zahteve na zlonamerne servere, omogućavajući preuzimanje naloga.

Tehnike eksploatacije variraju u zavisnosti od logike validacije autorizacionog servera. Mogu se kretati od stroge provere putanje do prihvatanja bilo kog URL-a unutar specificirane domene ili poddirektorijuma. Uobičajene metode eksploatacije uključuju otvorene redirekcije, prelazak putanje, iskorišćavanje slabih regex-a i HTML injekciju za krađu tokena.

Pored redirect_uri, drugi OAuth i OpenID parametri kao što su client_uri, policy_uri, tos_uri i initiate_login_uri su takođe podložni napadima preusmeravanja. Ovi parametri su opcioni i njihova podrška varira među serverima.

Za one koji ciljaju OpenID server, krajnja tačka otkrivanja (**.well-known/openid-configuration**) često navodi vredne detalje o konfiguraciji kao što su registration_endpoint, request_uri_parameter_supported i "require_request_uri_registration. Ovi detalji mogu pomoći u identifikaciji krajnje tačke registracije i drugih specifičnosti konfiguracije servera.

XSS u implementaciji preusmeravanja

Kao što je pomenuto u ovom izveštaju o bug bounty https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, može biti moguće da se URL preusmeravanja odražava u odgovoru servera nakon što se korisnik autentifikuje, što ga čini ranjivim na XSS. Mogući payload za testiranje:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Nepravilno rukovanje parametrom stanja

U OAuth implementacijama, zloupotreba ili izostavljanje state parametra može značajno povećati rizik od napada Cross-Site Request Forgery (CSRF). Ova ranjivost nastaje kada se state parametar ili ne koristi, koristi kao statička vrednost, ili se nevalidira ili ne povezuje pravilno sa korisničkom sesijom prilikom prijavljivanja, omogućavajući napadačima da zaobiđu CSRF zaštite.

Napadači mogu iskoristiti ovo presrećući proces autorizacije kako bi povezali svoj nalog sa nalogom žrtve, što može dovesti do potencijalnih preuzimanja naloga tako što će korisnik da se prijavi sa gotovo završenim oauth tokom koji pripada napadaču. Ovo je posebno kritično u aplikacijama gde se OAuth koristi u svrhe autentifikacije.

Primeri iz stvarnog sveta ove ranjivosti dokumentovani su u raznim CTF izazovima i hacking platformama, ističući njene praktične implikacije. Problem se takođe proširuje na integracije sa uslugama trećih strana kao što su Slack, Stripe, i PayPal, gde napadači mogu preusmeriti obaveštenja ili uplate na svoje naloge.

Pravilno rukovanje i validacija state parametra su ključni za zaštitu od CSRF i osiguranje OAuth toka.

Preuzimanje naloga

1. Bez verifikacije email-a prilikom kreiranja naloga: Napadači mogu unapred kreirati nalog koristeći email žrtve. Ako žrtva kasnije koristi uslugu treće strane za prijavu, aplikacija može nenamerno povezati ovaj nalog treće strane sa napadačevim unapred kreiranim nalogom, što dovodi do neovlašćenog pristupa.
2. Iskorišćavanje labave verifikacije email-a u OAuth-u: Napadači mogu iskoristiti OAuth usluge koje ne verifikuju email adrese tako što će se registrovati sa svojom uslugom, a zatim promeniti email naloga na onaj žrtve. Ova metoda takođe nosi rizik od neovlašćenog pristupa nalogu, slično prvom scenariju, ali kroz drugačiji napadački vektor.

Otkriće tajni

Identifikacija i zaštita tajnih OAuth parametara je ključna. Dok se client_id može bezbedno otkriti, otkrivanje client_secret predstavlja značajne rizike. Ako je client_secret kompromitovan, napadači mogu iskoristiti identitet i poverenje aplikacije da ukradu korisničke access_tokens i privatne informacije.

Uobičajena ranjivost nastaje kada aplikacije greškom rukovode razmenom autorizacionog code za access_token na klijentskoj strani umesto na serverskoj strani. Ova greška dovodi do izlaganja client_secret, omogućavajući napadačima da generišu access_tokens pod krinkom aplikacije. Štaviše, kroz socijalno inženjerstvo, napadači bi mogli da eskaliraju privilegije dodavanjem dodatnih opsega u OAuth autorizaciju, dodatno iskorišćavajući povereni status aplikacije.

Bruteforce klijent tajne

Možete pokušati da bruteforce-ujete client_secret provajdera usluga sa identitetskim provajderom kako biste pokušali da ukradete naloge.
Zahtev za BF može izgledati slično:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header leaking Code + State

Kada klijent ima code i state, ako se reflektuje unutar Referer header-a kada pređe na drugu stranicu, onda je ranjiv.

Access Token Stored in Browser History

Idite na istoriju pretraživača i proverite da li je access token sačuvan tamo.

Everlasting Authorization Code

Authorization code bi trebao da živi samo neko vreme kako bi se ograničio vremenski prozor u kojem napadač može da ga ukrade i iskoristi.

Authorization/Refresh Token not bound to client

Ako možete da dobijete authorization code i iskoristite ga sa različitim klijentom, onda možete preuzeti druge naloge.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Check this post

AWS Cognito

U ovom izveštaju o bug bounty: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ možete videti da token koji AWS Cognito vraća korisniku može imati dovoljno dozvola da prepiše korisničke podatke. Stoga, ako možete promeniti korisnički email za drugi korisnički email, možda ćete moći da preuzmete druge naloge.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Za detaljnije informacije o tome kako zloupotrebiti AWS cognito, proverite:

AWS - Cognito Unauthenticated Enum - HackTricks Cloud

Zloupotreba tokena drugih aplikacija

Kao što je spomenuto u ovom izveštaju, OAuth tokovi koji očekuju da prime token (a ne kod) mogli bi biti ranjivi ako ne provere da li token pripada aplikaciji.

To je zato što bi napadač mogao da kreira aplikaciju koja podržava OAuth i prijavi se putem Facebook-a (na primer) u svojoj aplikaciji. Zatim, kada žrtva prijavi putem Facebook-a u napadačevoj aplikaciji, napadač bi mogao da dobije OAuth token korisnika dodeljen njegovoj aplikaciji i iskoristi ga za prijavu u žrtvinu OAuth aplikaciju koristeći žrtvin korisnički token.

Dva linka & kolačić

Prema ovom izveštaju, bilo je moguće naterati žrtvu da otvori stranicu sa returnUrl koja pokazuje na napadačev host. Ove informacije bi bile smeštene u kolačiću (RU), a u kasnijem koraku prompt će pitati korisnika da li želi da da pristup tom napadačevom hostu.

Da bi se zaobišao ovaj prompt, bilo je moguće otvoriti tab za iniciranje Oauth toka koji bi postavio ovaj RU kolačić koristeći returnUrl, zatvoriti tab pre nego što se prompt prikaže, i otvoriti novi tab bez te vrednosti. Tada prompt neće obavestiti o napadačevom hostu, ali bi kolačić bio postavljen na njega, tako da će token biti poslat na napadačev host u redirekciji.

Zaobilaženje interakcije sa promptom

Kao što je objašnjeno u ovom videu, neke OAuth implementacije omogućavaju da se GET parametar prompt označi kao None (&prompt=none) kako bi se sprečilo da se korisnicima postavlja pitanje da potvrde dodeljeni pristup u promptu na vebu ako su već prijavljeni na platformu.

response_mode

Kao što je objašnjeno u ovom videu, može biti moguće označiti parametar response_mode da se naznači gde želite da se kod dostavi u konačnom URL-u:

• response_mode=query -> Kod se dostavlja unutar GET parametra: ?code=2397rf3gu93f
• response_mode=fragment -> Kod se dostavlja unutar fragmenta URL-a #code=2397rf3gu93f
• response_mode=form_post -> Kod se dostavlja unutar POST forme sa inputom pod nazivom code i vrednošću
• response_mode=web_message -> Kod se šalje u post poruci: window.opener.postMessage({"code": "asdasdasd...

OAuth ROPC tok - zaobilaženje 2 FA

Prema ovom blog postu, ovo je OAuth tok koji omogućava prijavu u OAuth putem korisničkog imena i lozinke. Ako tokom ovog jednostavnog toka bude vraćen token sa pristupom svim radnjama koje korisnik može da izvrši, tada je moguće zaobići 2FA koristeći taj token.

ATO na veb stranici koja preusmerava na osnovu otvorenog preusmeravanja na referent

Ovaj blog post komentariše kako je bilo moguće zloupotrebiti otvoreno preusmeravanje na vrednost iz referenta da bi se zloupotrebio OAuth za ATO. Napad je bio:

1. Žrtva pristupa napadačevoj veb stranici
2. Žrtva otvara zlonamerni link i otvarač pokreće Google OAuth tok sa response_type=id_token,code&prompt=none kao dodatnim parametrima koristeći kao referent napadačevu veb stranicu.
3. U otvaraču, nakon što provajder odobri žrtvu, vraća ih nazad na vrednost parametra redirect_uri (žrtvina veb) sa 30X kodom koji i dalje drži napadačevu veb stranicu u referentu.
4. Žrtvina veb stranica pokreće otvoreno preusmeravanje na osnovu referenta preusmeravajući žrtvinog korisnika na napadačevu veb stranicu, pošto je respose_type bio id_token,code, kod će biti vraćen napadaču u fragmentu URL-a omogućavajući mu da preuzme račun korisnika putem Google-a na žrtvinom sajtu.

SSRFs parametri

Proverite ovo istraživanje Za dalja objašnjenja ove tehnike.

Dinamička registracija klijenata u OAuth služi kao manje očigledan, ali kritičan vektor za sigurnosne ranjivosti, posebno za Server-Side Request Forgery (SSRF) napade. Ova tačka omogućava OAuth serverima da prime detalje o klijentskim aplikacijama, uključujući osetljive URL-ove koji bi mogli biti zloupotrebljeni.

Ključne tačke:

• Dinamička registracija klijenata se često mapira na /register i prihvata detalje kao što su client_name, client_secret, redirect_uris, i URL-ove za logotipe ili JSON Web Key Sets (JWKs) putem POST zahteva.
• Ova funkcija se pridržava specifikacija navedenih u RFC7591 i OpenID Connect Registration 1.0, koje uključuju parametre koji su potencijalno ranjivi na SSRF.
• Proces registracije može nenamerno izložiti servere SSRF na nekoliko načina:
• logo_uri: URL za logotip klijentske aplikacije koji bi server mogao da preuzme, pokrećući SSRF ili dovodeći do XSS ako se URL nepravilno obradi.
• jwks_uri: URL do JWK dokumenta klijenta, koji, ako je zlonamerno kreiran, može uzrokovati da server izvrši izlazne zahteve ka serveru pod kontrolom napadača.
• sector_identifier_uri: Upućuje na JSON niz redirect_uris, koji server može preuzeti, stvarajući priliku za SSRF.
• request_uris: Navodi dozvoljene URI zahteve za klijenta, koji se mogu zloupotrebiti ako server preuzima ove URI na početku procesa autorizacije.

Strategija eksploatacije:

• SSRF se može pokrenuti registracijom novog klijenta sa zlonamernim URL-ovima u parametrima kao što su logo_uri, jwks_uri, ili sector_identifier_uri.
• Iako direktna eksploatacija putem request_uris može biti ublažena kontrolama na beloj listi, pružanje unapred registrovanog, napadačem kontrolisanog request_uri može olakšati SSRF tokom faze autorizacije.

OAuth provajderi trke

Ako je platforma koju testirate OAuth provajder, pročitajte ovo da biste testirali moguće trke.

Napad na promenljive tvrdnje

U OAuth-u, sub polje jedinstveno identifikuje korisnika, ali njegov format varira u zavisnosti od servera za autorizaciju. Da bi se standardizovala identifikacija korisnika, neki klijenti koriste e-mail adrese ili korisničke oznake. Međutim, ovo je rizično jer:

• Neki serveri za autorizaciju ne osiguravaju da ove osobine (kao što je e-mail) ostanu nepromenljive.
• U određenim implementacijama—kao što je "Prijava putem Microsoft-a"—klijent se oslanja na polje e-maila, koje je pod kontrolom korisnika u Entra ID i nije verifikovano.
• Napadač može iskoristiti ovo tako što će kreirati svoju Azure AD organizaciju (npr. doyensectestorg) i koristiti je za izvršenje prijave putem Microsoft-a.
• Iako je Object ID (smešten u sub) nepromenljiv i siguran, oslanjanje na promenljivo polje e-maila može omogućiti preuzimanje računa (na primer, otmicu računa kao što je victim@gmail.com).

Napad na konfuziju klijenata

U napadu na konfuziju klijenata, aplikacija koja koristi OAuth Implicit Flow ne uspeva da verifikuje da je konačni pristupni token posebno generisan za njen vlastiti Client ID. Napadač postavlja javnu veb stranicu koja koristi Google-ov OAuth Implicit Flow, obmanjujući hiljade korisnika da se prijave i tako prikupljajući pristupne tokene namenjene napadačevoj stranici. Ako ovi korisnici takođe imaju račune na drugoj ranjivoj veb stranici koja ne verifikuje Client ID tokena, napadač može ponovo koristiti prikupljene tokene da se pretvara da su žrtve i preuzme njihove račune.

Napad na nadogradnju opsega

Tip Authorization Code Grant uključuje sigurnu komunikaciju servera do servera za prenos korisničkih podataka. Međutim, ako Authorization Server implicitno veruje parametru opsega u zahtevu za pristupni token (parametar koji nije definisan u RFC-u), zlonamerna aplikacija bi mogla da nadogradi privilegije autorizacionog koda tražeći viši opseg. Nakon što je Access Token generisan, Resource Server mora da ga verifikuje: za JWT tokene, to uključuje proveru JWT potpisa i vađenje podataka kao što su client_id i opseg, dok za tokene nasumičnih stringova server mora da upita Authorization Server da bi dobio detalje o tokenu.

Otimanje sheme preusmeravanja

U mobilnim OAuth implementacijama, aplikacije koriste prilagođene URI sheme za primanje preusmeravanja sa autorizacionim kodovima. Međutim, pošto više aplikacija može registrovati istu shemu na uređaju, pretpostavka da samo legitimni klijent kontroliše URI preusmeravanja je prekršena. Na Android-u, na primer, Intent URI kao što je com.example.app:// oauth se hvata na osnovu sheme i opcionalnih filtera definisanih u aplikaciji. Pošto Android-ovo rešavanje intencija može biti široko—posebno ako je samo shema specificirana—napadač može registrovati zlonamernu aplikaciju sa pažljivo izrađenim intent filterom da bi otimao autorizacioni kod. Ovo može omogućiti preuzimanje računa ili kroz interakciju korisnika (kada više aplikacija može da obradi intenciju) ili putem tehnika zaobilaženja koje koriste previše specifične filtere, kao što je detaljno opisano u Ostorlabovom dijagramu toka procene.

Reference

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors
• https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html