<summary><strong>Naučite AWS hakovanje od početnika do eksperta sa</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Ako želite da vidite svoju **kompaniju reklamiranu na HackTricks** ili **preuzmete HackTricks u PDF formatu** Pogledajte [**PRETPLATNIČKE PLANOVE**](https://github.com/sponsors/carlospolop)!
* **Pridružite se** 💬 [**Discord grupi**](https://discord.gg/hRep4RUj7f) ili [**telegram grupi**](https://t.me/peass) ili **pratite** nas na **Twitteru** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podelite svoje hakovanje trikove podnošenjem PR-ova na** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repozitorijume.
OAuth nudi različite verzije, sa osnovnim uvidima dostupnim na [OAuth 2.0 dokumentaciji](https://oauth.net/2/). Ova diskusija se prvenstveno fokusira na široko korišćeni [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/), pružajući **okvir za autorizaciju koji omogućava aplikaciji da pristupi ili izvrši radnje na korisničkom nalogu u drugoj aplikaciji** (server za autorizaciju).
Razmotrite hipotetički sajt _**https://example.com**_, dizajniran da **prikaže sve vaše objave na društvenim mrežama**, uključujući privatne. Da bi to postigao, 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, pojaviće se ekran za saglasnost na _https://socialmedia.com_, navodeći **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**.
* **resource owner**: Vi, kao **korisnik/entitet**, dajete dozvolu za pristup vašem resursu, kao što su vaše objave na društvenim mrežama.
* **resource server**: **Server koji upravlja autentifikovanim zahtevima** nakon što aplikacija dobije `access token` u ime `resource owner`, npr. **https://socialmedia.com**.
* **client application**: **Aplikacija koja traži autorizaciju** od `resource owner`, kao što je **https://example.com**.
* **authorization server**: **Server koji izdaje `access tokens`**`client application` nakon uspešne autentifikacije `resource owner` i dobijanja autorizacije, npr. **https://socialmedia.com**.
* **client\_id**: Javni, jedinstveni identifikator za aplikaciju.
* **client\_secret:** Tajni ključ, poznat samo aplikaciji i serveru za autorizaciju, korišćen za generisanje `access_tokens`.
* **response\_type**: Vrednost koja specificira **tip tokena koji se traži**, kao što je `code`.
* **scope**: **Nivo pristupa** koji `client application` traži od `resource owner`.
* **redirect\_uri**: **URL na koji se korisnik preusmerava nakon autorizacije**. Ovo obično mora da se poklapa sa unapred registrovanim URL-om za preusmeravanje.
* **state**: Parametar za **održavanje podataka tokom preusmeravanja korisnika na i sa servera za autorizaciju**. Njegova jedinstvenost je ključna za služenje kao **CSRF zaštitni mehanizam**.
* **grant\_type**: Parametar koji označava **tip granta i tip tokena koji će biti vraćen**.
* **code**: Autorizacioni kod sa `authorization server`, korišćen zajedno sa `client_id` i `client_secret` od strane client application za dobijanje `access_token`.
* **access\_token**: **Token koji client application koristi za API zahteve** u ime `resource owner`.
* **refresh\_token**: Omogućava aplikaciji da **dobije novi `access_token` bez ponovnog traženja od korisnika**.
1. Vi posećujete [https://example.com](https://example.com) i birate dugme “Integrate with Social Media”.
2. Sajt zatim šalje zahtev na [https://socialmedia.com](https://socialmedia.com) tražeći vašu autorizaciju da aplikacija https://example.com pristupi vašim objavama. Zahtev je strukturiran kao:
5. https://example.com koristi ovaj `code`, zajedno sa `client_id` i `client_secret`, da napravi server-side zahtev kako bi dobio `access_token` u vaše ime, omogućavajući pristup dozvolama na koje ste pristali:
`redirect_uri` je ključan za sigurnost u OAuth i OpenID implementacijama, jer usmerava gde se šalju osetljivi podaci, kao što su autorizacioni kodovi, nakon autorizacije. Ako je pogrešno konfigurisan, može omogućiti napadačima da preusmere ove zahteve ka zlonamernim serverima, omogućavajući preuzimanje naloga.
Tehnike eksploatacije variraju u zavisnosti od logike validacije autorizacionog servera. Mogu se kretati od striktnih podudaranja putanja do prihvatanja bilo kog URL-a unutar specificiranog domena ili poddirektorijuma. Uobičajene metode eksploatacije uključuju otvorene preusmeravanja, putanje zaobilaska, eksploataciju 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, discovery endpoint (`**.well-known/openid-configuration**`) često navodi vredne detalje konfiguracije kao što su `registration_endpoint`, `request_uri_parameter_supported` i "`require_request_uri_registration`. Ovi detalji mogu pomoći u identifikaciji registration endpoint-a i drugih specifičnosti konfiguracije servera.
Kao što je pomenuto u ovom bug bounty izveštaju [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) moguće je da se preusmeravanje **URL-a reflektuje u odgovoru** servera nakon što se korisnik autentifikuje, što je **ranjivo na XSS**. Mogući payload za testiranje:
U OAuth implementacijama, zloupotreba ili izostavljanje **`state` parametra** može značajno povećati rizik od **Cross-Site Request Forgery (CSRF)** napada. Ova ranjivost se javlja kada se `state` parametar **ne koristi, koristi kao statička vrednost ili se ne validira pravilno**, omogućavajući napadačima da zaobiđu CSRF zaštite.
Napadači mogu iskoristiti ovo presretanjem autorizacionog procesa kako bi povezali svoj nalog sa nalogom žrtve, što može dovesti do potencijalnog **preuzimanja naloga**. Ovo je posebno kritično u aplikacijama gde se OAuth koristi za **autentifikaciju**.
Primeri ove ranjivosti u stvarnom svetu dokumentovani su u raznim **CTF izazovima** i **hakerskim platformama**, ističući njene praktične implikacije. Problem se takođe proteže 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.
1.**Bez verifikacije emaila 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 unapred kreiranim nalogom napadača, što dovodi do neovlašćenog pristupa.
2.**Iskorišćavanje slabe verifikacije emaila u OAuth-u**: Napadači mogu iskoristiti OAuth usluge koje ne verifikuju emailove tako što će se registrovati sa svojom uslugom, a zatim promeniti email naloga na email žrtve. Ova metoda slična je prvoj situaciji, ali kroz drugačiji vektor napada.
Identifikacija i zaštita tajnih OAuth parametara je ključna. Dok se **`client_id`** može bezbedno otkriti, otkrivanje **`client_secret`** predstavlja značajan rizik. 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 se javlja 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 maskom aplikacije. Štaviše, kroz socijalni inženjering, napadači mogu eskalirati privilegije dodavanjem dodatnih opsega OAuth autorizaciji, dodatno eksploatišući poverenje aplikacije.
[**Pogledajte ovaj post**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)
U ovom bug bounty izveštaju: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](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**. Dakle, ako možete **promeniti korisnički email na drugi korisnički email**, možda ćete moći **preuzeti** druge naloge.
Kao što je [**pomenuto u ovom članku**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), OAuth tokovi koji očekuju da prime **token** (a ne kod) mogu biti ranjivi ako ne proveravaju da li token pripada aplikaciji.
To je zato što **napadač** može kreirati **aplikaciju koja podržava OAuth i prijaviti se sa Facebook-om** (na primer) u svojoj aplikaciji. Zatim, kada se žrtva prijavi sa Facebook-om u **napadačevoj aplikaciji**, napadač može dobiti **OAuth token korisnika dodeljen njegovoj aplikaciji i koristiti ga za prijavu u OAuth aplikaciju žrtve koristeći token korisnika žrtve**.
Dakle, ako napadač uspe da korisnik pristupi njegovoj OAuth aplikaciji, moći će da preuzme nalog žrtve u aplikacijama koje očekuju token i ne proveravaju da li je token dodeljen njihovom ID-u aplikacije.
### Dva linka i kolačić <a href="#bda5" id="bda5"></a>
Prema [**ovom članku**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), bilo je moguće naterati žrtvu da otvori stranicu sa **returnUrl** koji pokazuje na napadačev host. Ova informacija bi bila **sačuvana u kolačiću (RU)** i 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 da se pokrene **Oauth tok** 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. Zatim, **prompt neće informisati o napadačevom hostu**, ali će kolačić biti postavljen na njega, tako da će **token biti poslat na napadačev host** u preusmeravanju.
Kao što je objašnjeno u [**ovom videu**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), neke OAuth implementacije omogućavaju da se navede **`prompt`** GET parametar kao None (**`&prompt=none`**) da **spreče korisnike da budu pitani za potvrdu** datog pristupa u promptu na webu ako su već prijavljeni na platformu.
Kao što je [**objašnjeno u ovom videu**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), moguće je navesti parametar **`response_mode`** da se naznači gde želite da kod bude dostavljen u finalnom URL-u:
*`response_mode=query` -> Kod je dostavljen unutar GET parametra: `?code=2397rf3gu93f`
*`response_mode=fragment` -> Kod je dostavljen unutar fragment parametra URL-a `#code=2397rf3gu93f`
*`response_mode=form_post` -> Kod je dostavljen unutar POST forme sa inputom nazvanim `code` i vrednošću
*`response_mode=web_message` -> Kod je poslat u post poruci: `window.opener.postMessage({"code": "asdasdasd...`
### SSRF parametri <a href="#bda5" id="bda5"></a>
[**Pogledajte ovo istraživanje**](https://portswigger.net/research/hidden-oauth-attack-vectors) **za dodatne detalje o ovoj tehnici.**
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. Ovaj endpoint omogućava OAuth serverima da prime detalje o klijentskim aplikacijama, uključujući osetljive URL-ove koji mogu biti zloupotrebljeni.
* **Dinamička registracija klijenata** je često mapirana 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 potencijalno ranjive na SSRF.
* Proces registracije može nenamerno izložiti servere SSRF-u na nekoliko načina:
* **`logo_uri`**: URL za logotip klijentske aplikacije koji server može preuzeti, pokrećući SSRF ili dovodeći do XSS ako se URL neadekvatno 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`**: Referiše se na JSON niz `redirect_uris`, koji server može preuzeti, stvarajući SSRF priliku.
* **`request_uris`**: Navodi dozvoljene URI zahteve za klijenta, koji mogu biti zloupotrebljeni ako server preuzima ove URI-je na početku autorizacionog procesa.
* SSRF može biti pokrenut registracijom novog klijenta sa zlonamernim URL-ovima u parametrima kao što su `logo_uri`, `jwks_uri`, ili `sector_identifier_uri`.
* Dok direktna eksploatacija putem `request_uris` može biti ublažena kontrolama bele liste, snabdevanje unapred registrovanim, napadačem kontrolisanim `request_uri` može olakšati SSRF tokom faze autorizacije.
<summary><strong>Naučite AWS hakovanje od početnika do eksperta sa</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Ako želite da vidite vašu **kompaniju reklamiranu u HackTricks** ili **preuzmete HackTricks u PDF formatu** Pogledajte [**PRETPLATNE PLANOVE**](https://github.com/sponsors/carlospolop)!
* **Pridružite se** 💬 [**Discord grupi**](https://discord.gg/hRep4RUj7f) ili [**telegram grupi**](https://t.me/peass) ili **pratite** nas na **Twitter-u** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
