Sadržaj

OAuth 2.0 protokol

OAuth 2.0 protokol

Sažetak

OAuth je vrlo raširen protokol za autorizaciju aplikacija. Često se može vidjeti u aplikacijama prijava preko nekog drugog servera, kao npr. „prijava preko google“, „prijava preko facebooka“. To omogućava raznim aplikacijama autorizaciju korisnika bez potrebe za registracijom.

OAuth je protokol koji autorizira korisnika pomoću poslužitelja koji nazivamo autorizacijski poslužitelj. Komunikacija s tim poslužiteljem treba biti sigurna kako bi korisnici uopće htjeli koristit protokol OAuth. OAuth pruža 6 načina autorizacije: način s autorizacijskim kodom, implicitni način, način s lozinkom, način s klijentskim akreditiv, kod uređaja i način s osvježavajućim tokenom. Svaki način ima svoje prednosti i mane, a OAuth dokumentacija preporučuje autorizacijski kod kao način koji je najbolji za autorizaciju.

Osim autorizacijskog poslužitelja OAuth poznaje ulogu klijenta koji je poslužitelj koji komunicira direktno s krajnjim korisnikom, resursni poslužitelj koji predstavlja poslužitelja koji sadrži povjerljive resurse i vlasnika servera koji je poslužitelj koji daje pristup resursnom poslužitelju.

OAuth dokumentacija navodi neke napade koji su mogući i mjere opreza kojima bi se mogli spriječiti. Napadi se događaju iskorištavanjem nedovoljno definiranim URI preusmjerivačem, krađom autorizacijskog koda, umetanjem istog u postupak autorizacije.

Ključne riječi: OAuth, koraci, protokol, napadi, sigurnost

Uvod

OAuth je protokol za autorizaciju koji omogućava mnogim aplikacijama prijavu u njih bez potreba registracije. Na tržištu postoje mnoge aplikacije koje koriste OAuth protokol za autorizaciju na google-ov, facebook-ov autorizacijski server. Zato se ovaj seminarski rad bavi proučavanjem tog protokola i proučavanjem njegove sigurnosti pregledom napada na koje nije imun. Prvo će biti uvod o OAuth, a potom će se obraditi napadi.

O OAuth-u protokolu

OAuth je protokol definiran kao industrijski standard koji služi za autorizaciju. OAuth je zamišljen kao jednostavna apstrakcija koja pruža autorizaciju za mnoge aplikacije. Primjeri takvih aplikacija su web, desktop, mobilne i mnoge druge aplikacije. OAuth može poslužiti i za Internet stvari.

OAuth autorizacijski okvir omogućava aplikacijama trećih strana (engl. Third-party) dobivanje ograničenog pristupa nekom servisu. Poslužitelj koji sadrži neke korisne podatke nazivat ćemo vlasnik resursa (engl. Resource owner) i on može upravljati ograničenjima između njegovih podataka i servisa.

OAuth uloge

OAuth poznaje 4 uloge. To su vlasnik resursa ( engl. Resource owner ), poslužitelj s resursima ( engl. Resource server ), klijent ( engl. client ) i autorizacijski poslužitelj ( engl. Authorization server).

Vlasnik resursa je poslužitelj koji daje pristup zaštićenom resursu.

Server s resursima je poslužitelj koji sadrži resurse.

Klijent je poslužitelj koji koristi uslugu.

Autorizacijski server je poslužitelj koji sadrži podatke o ljudima i identificira ih. Drugim riječima predaje tokene pomoću kojih klijenti mogu pristupiti nekom zaštićenom resursu.

Autorizacijski server i server s resursima mogu biti isti server.

4. Koraci protokola

Protokol OAuth sastoji se od 6 koraka. Prikaz protokola ilustriran je slikom 4.1.

Objašnjenje koraka:

Klijent traži autorizaciju od vlasnika resursa. Autorizacijski zahtjev može se poslati direktno vlasniku resursa kako je prikazano na slici 4.1 ili autorizacijskom serveru kao posredniku.
Klijent prima odobrenje za autorizaciju. Tu potvrdu je moguće dobiti na 4 načina, tj. U OAuth specifikaciji je dokumentirano 4 načina. Tip potpore za autentifikaciju ovisi o metodi koju klijent koristi u zahtjevu za autentifikaciju i naravno omogućenih tipova potpora koje su omogućene na autorizacijskom poslužitelju.
Klijent zahtjeva pristupni token autoriziran s autorizacijskog poslužitelja.
Autorizacijski poslužitelj autorizira klijenta i provjerava autorizacijski tip potpore. Ako je sve ispravno vraća pristupni token.
Klijent zahtjeva zaštićene resurse od resursnog poslužitelja i autorizira zahtjev dodavanjem pristupnog tokena.
Resursni poslužitelj provjerava pristupni token. Ako je token ispravan za resurse koji se traže, onda vraća te resurse.

Korištenje autorizacijskog poslužitelja kao posrednika za dobivanje potpornog tipa (opisano u 1. i 2. koraku na slici 2.1) od vlasnika resursa je preferirana metoda.

Slika 4.1 Prikaz koraka protokola OAuth za autorizaciju [5]

5. Načini autorizacije

OAuth 2.0 okvir specificira nekoliko različitih tipova pristupa za različite slučajeve korištenja. To su: način s autorizacijskim kodom, implicitni način, način sa šifrom, način s klijentski akreditivima, način s kodom uređaja i pomoću osvježavajućeg Tokena.

5.1 Način s autorizacijskim kodom

Autorizacijski kod (engl. Authorization code) je tip potpore koji se koristi za povjerljive i javne klijente. Služi za razmjenu autorizacijskog koda za pristupni token (engl. access token). Stvara ga autorizacijski server.

Nakon što korisnički agent vrati klijenta na povratni URL, aplikacija će dobiti autorizacijski kod za URL i koristit će ga za dohvat pristupnog tokena.

Koraci prilikom ovog načina protokola su sljedeći, a prikazani su na slici 5.1.1:

Klijent počinje pristupati vlasniku resursa pomoću korisničkog agenta koji se spaja na autorizacijsku točku pristupa ( CKGE_TMP_i engl. endpoint CKGE_TMP_i ). Klijent predaje svoj identifikator, međukrug djelovanja, lokalno stanje i povratni link pomoću kojeg će se autorizacijski server vratiti na korisničkog agenta kada se odobri pristup (ili se odbije)
Autorizacijski server identificira vlasnika resursa (s korisničkim agentom) i utvrđuje je li vlasnik servera dopustio klijentske pristupne zahtjeve
Pretpostavljajući dopušten pristup od vlasnika servera, autorizacijski server preusmjerava korisničkog agenta natrag do klijenta koristeći povratni URI koji je predan ranije (u koraku 1.). Povratni odgovor sadržava autorizacijski kod i neko lokalno stanje dano od klijenta u koraku 1.
Klijent zahtjeva pristupni token s autorizacijskog serverskog tokena pristupne točke uključujući autorizacijski kod u zahtjevu. Prilikom izrade zahtjeva, klijent se autorizira s autorizacijskim serverom. Klijent javlja povratni uri kako bi dobio autorizacijski kod za verifikaciju.
Autorizacijski server autorizira klijenta, provjerava autorizacijskih kod i osigurava povratni URI primljen u 3 koraku. Ako je sve ispravno, onda vraća pristupni token i opcionalno osvježavajući token.

slika 5.1.1 način autorizacije autorizaciskim kodom [5]

5.2 Implicitni način

Implicitni način je pojednostavljeni slučaj koji se koristi kod javnih klijenata, gdje se pristupni token vraća odmah, bez dodatnog koraka zamjene autorizacijskog koda za pristupni token.

Generalno se ne preporučuje koristiti implicitni način. Neki serveri zabranjuju ovaj način prijave u potpunosti. U vrijeme od kada je specifikacija napisana, industrijska praksa se pokazala kako je najbolje koristiti autorizacijski kod za javne klijente.

OAuth 2.0 Security Best Current Practice dokumenti nikako ne preporučuju korištenje implicitnog načina. OAuth 2.0 za aplikacije nad preglednikom opisuju tehnike kako koristiti autorizacijski kod sa PKCE.

Slijed koraka implicitnog način dan je kroz iduće točke, a prikazuje ga slika 5.2.1

Klijent komunicira s korisničkim agentom kako bi pristupio autorizacijskoj točki pristupa. Prilikom komunikacije klijent šalje svoju identifikaciju, traženi djelokrug, lokalno stanje i povratni URI kako bi se autorizacijski server znao vratiti na početnu stranicu pristupa onda kada se potvrdi autorizacija.
Autorizacijski server autentificira vlasnika resursa (pomoću korisničkog agenta) i provjerava prihvaća li vlasnik resursa klijentski zahtjev.
Pretpostavkom da je vlasnik resursa odobrio pristup, autorizacijski server preusmjerava korisničkog agenta na URI koji je korisnik poslao prilikom slanja zahtjeva za autorizacijom. Prilikom povratka vraća se i pristupni token u URI fragmentu.
Korisnički agent prati upute za preusmjeravanje praveći zahtjev na web-hosted client resource. Korisnički agent zadržava fragmentske informacije lokalno
Web-host client resource vraća web stranicu sposobnu pristupiti punom povratnom URI uključujući i fragment koji sadrži korisnički agent i može izvući pristupni token koji se nalazi u fragmentu.
Korisnički agent izvršava skriptu koju pruža web-hosted client resource lokalno, koja izvlači pristupni token.
Korisnički agent vraća pristupni token klijentu.

Slika 5.2.1 implicitni način autorizacije [5]

5.3 Način s lozinkom

Način autorizacije s lozinkom ( engl. Password ) koristi se samo za prvi pristup vlasnika resursa gdje se korisničko ime i lozinka traže za pristupni token.

Kako se traži korisničko ime i lozinka, ovaj način nije siguran, pa se ne preporuča koristiti drugim korisnicima.

Koraci autorizacije dani su kroz iduće korake koji su pokazani na slici 5.3.1:

Vlasnik resursa predaje klijentu njegovu korisničko ime i lozinku.
Klijent šalje zahtjev za pristupnim tokenom prema autorizacijskom serveru, a šalje korisničko ime i lozinku primljenih od vlasnika resursa.
Autorizacijski server provjerava podatke od klijenta i vlasnika resursa i ako je sve ispravno onda mu vraća pristupni token.

Slika 5.3.1 Način autorizacije lozinkom [4]

5.4 Način s klijentski akreditivom

Klijentski akreditiv (engl. Client Credentials) je potporni tip koji se koristi za klijente koji dobivaju pristupni token izvan konteksta korisnika.

Tipično se koristi od strane klijenata za pristup nekim resursima o sebi bolje nego da pristupaju korisničkim resursima.

Koraci autorizacije dani su kroz iduće korake koji su opisani na slici 5.4.1

Klijent se autentificira s autorizacijskim serverom i zahtjeva pristupni token od točke s tokenima (engl. token end-point).
Autorizacijski server autentificira klijenta, i ako je sve ispravno, vraća mu pristupni token.

Slika 5.4.1 Način autorizacije sa klijentskim akreditivom[3]

5.5 Kod uređaja

Kod uređaja (engl. Device Code) je potporni tip koji se koristi od strane više-manje preglednika ili ulazno ograničenih uređaja. Temelji se na razmjeni koda uređaja za pristupni kod.

5.6 Način sa osvježavajućim tokenom

Osvježavajući token (engl. Refresh Token) je potporni tip koji se koristi od strane klijenata za zamjenu osvježavajućeg tokena za pristupni token kada pristupni token istekne.

Pomoću ovog potpornog tipa klijent se ne mora stalno prijavljivati, u ovisnosti koliko traje neki pristupni token. Nakon isteka pristupnog tokena lako se dobije novi.

Autorizacija s osvježavajućim tokenom dana je kroz sljedeće korake koji su prikazani na slici 5.6.1.

Slika 5.6.1 Način autorizacije sa osvježavajućim tokenom [2]

6. Napadi

6.1 Nedovoljna provjera preusmjerivača

Nedovoljna provjera URI preusmjerivača (engl. Insufficient Redirect URI Validation) opisuje napad u kojem je na autorizacijskom serveru registriran URI kojeg na više načina provjera može valjano proći. Višeznačni uzorak koji dopušta valjanost povratnog URI-ja na više načina se može zloupotrijebiti, te natjerati autorizacijski server da pošalje pristupni token na neku drugu stranicu.

Zloupotrebljavanje provjere je moguće na 2 načina. Prvi način je navođenje preusmjerivača direktno na napadačevu stranicu. Drugi način zloupotrebe je preko otvorenih preusmjerivača.

Primjer prvog načina napada, odnosno napada kojim se direktno preusmjerava na napadačevu stranicu se sastoji od toga da se registrira sljedeća putanja za preusmjeravanje:

“*.somesite.example/*”

Kao što se vidi, može se preusmjeriti na bilo koju domenu tipa samosite.example/ gdje se može nadodati prefiks ili postaviti neki parametri u sufiksu. Napadač može posjedovati domenu tipa evil.somesite.example i ta će mu domena dati pristup pristupnim tokenima. Napad se može izvršiti upravo ovom naredbom:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=9ad67f13&redirect_uri=https%3A%2F%2Fevil.somesite.example%2Fcb HTTP/1.1

Ovakav napad će biti otežan u slučaju dobro zaštićenih klijenata i načina razmjene autorizacijskog koda. Teško će napadač znati tajni kod koji se predaje uz autorizacijski kod. Napadač tako treba napasti preko nekog postojećeg klijenta, što daje manje mogućnosti. Kod implicitnog načina autorizacije problem napada je malo lakši. Ako napadač može utjecati na autorizacijski odgovor, onda može vrlo lako pristupiti pristupnom tokenu. Napadač inače može utjecati na argumente tako da pošalje korisničkom agentu fragment u kojem se navodi parametar kao otvoreni preusmjerivač. Taj otvoreni preusmjerivač preusmjerava klijenta na napadačevu stranicu uslijed čega napadač uzima pristupni token, a klijenta vraća na očekivanu stranicu. Pretpostavimo da je za klijenta registriran povratni URI “client.somesite.example/cb?*”. Kao što se vidi svi parametri su omogućeni, pa tako i parametar redirect_to. Kada pretraživač uoči taj parametar šalje http zahtjev 303 na stranicu danu u paramatru. Primjer jednog takvog napada je s komandnom linijom:

GET /authorize?response_type=token&state=9ad67f13 &client_id=s6BhdRkqt3&redirect_uri=https%3A%2F%2Fclient.somesite.example %2Fcb%26redirect_to%253Dhttps%253A%252F %252Fclient.evil.example%252Fcb HTTP/1.1

Ako taj URI prolazi provjeru, onda će pretraživač napraviti HTTP 303 zahtjev na stranicu

“client.somesite.example/cb?redirect_to%3Dhttps%3A%2F%2Fclient.evil.example%2Fcb#access_token=2YotnFZFEjr1zCsicMWpAA&…”

Kao što se vidi, pristupni token će biti prisutan napadaču, ali i svima onima koji prisluškuju promet. Postoji više mjera opreza kod ovog napada, a koji su navedeni u nastavku. Server koji treba preusmjeravati ne bi trebao dozvoljavati otvorena preusmjeravanja. Osim toga, klijent bi trebao odbacivati sve „popravljajuće fragmente“ kako bi se zaštitio od bilo kojih zlonamjernih fragmenata. I na kraju klijent bi trebao koristiti način autorizacije temeljen na zamjeni autorizacijskog koda.

6.2 Umetanje autorizacijskog koda

Umetanje autorizacijskog koda (engl. Authorization Code Injection) je napad u kojem napadač preko nekog postojećeg klijenta krade pristupne tokene. To postiže umetanjem autorizacijskog koda nekom klijentu koji mu potom vraća pristupne tokene.

Postoje 3 mogućnosti zašto napadač napada preko klijenta koji nije njegov. Prva mogućnost je da zapravo on želi biti žrtva. Druga mogućnost je posjedovanje autorizacijskog koda koji je vezan uz točno određenog klijenta. A zadnja mogućnost je da su resursni ili autorizacijski server na privatnim mrežama za koje napadač nema pristup.

Postupak napada je sljedeći:

1. Napadač dobiva autorizacijski kod obavljajući neki napad.

2. Napadač obavlja redoviti postupak autorizacije OAuth s legitimnim klijentom na svom uređaju.

3. Napadač ubrizga ukradeni autorizacijski kod u odgovoru poslužitelja autorizacije legitimnom klijentu.

4. Klijent šalje kôd krajnjoj točki tokena poslužitelja autorizacije, s ID-om klijenta, tajnom klijenta i stvarnim “redirect_uri”.

5. Poslužitelj autorizacije provjerava tajnu klijenta, je li kôd izdan određenom klijentu i odgovara li stvarni URI preusmjeravanja parametru “redirect_uri”.

6. Ako sve provjere uspiju, poslužitelj autorizacije klijentu izdaje pristupne i druge tokene, tako da napadač može lažno predstavljati legitimnog korisnika.

Mjera opreza protiv ovakvog napada je korištenje „nonce“ parametara. „nonce“ je parametar kojeg generira klijent i koji se koristi samo jednom. Ako je napadač u odgovoru na autorizaciju ubacio autorizacijski kôd, vrijednost nonce u sesiji klijenta i vrijednost nonce u ID tokenu neće se podudarati i napad je otkriven.

Kao „nonce“ može se koristiti i parametar „state“ koji je vezan uz kod (engl. Code-bound state). Parametar se koristi isto kao „nonce“ parametar.

Osim ta dva parametra postoje i PKCE „code chalange“ i „code verifer“ parametri koji su uvedeni kao mjera opreza. Za ispravnost se trebaju razlikovati. Ovo je po OAuth specifikaciji zadani način protiv ovakvog napada, ali u praksi se ne koristi često.

6.3 Mix-up napad

Mix-up napad se koristi kada više autorizacijskih servera komunicira. Cilj napada je da neki autorizacijski server pošalje autorizacijski kod napadaču umjesto nekom drugom serveru.

Kako bi napad uspio potrebno je da serveri koriste implicitni način ili način s razmjenom autorizacijskog koda. Uvjet je i da barem jedan poslužitelj bude pošten (tj. Onaj od kojeg će se ukrasti autorizacijski kod), a barem jedan lažan, odnosno napadačev. Uz to na klijentu se treba bilježiti u korisničkoj sesiji koji je server odabrao korisnik. A kao završno napadač mora moći manipulirati prvim parom zahtjeva/odgovora.

U nastavku slijedi primjer napada u kojem je H-AS (URI: “honest.as.example”, ID klijenta: “7ZGZldHQ”) pošten server i A-AS (URI: “napadac.primjer ”, ID klijenta:“ 666RVZJTA ”) napadačev server.

Napad na autorizacijsku kod:

1. Korisnik odabire pokrenuti autorizaciju s H-AS (npr. Klikom na gumb na web mjestu klijenta).

2. Napadač presreće ovaj zahtjev i promijeni korisnikov izbor u “A-AS”.

3. Klijent u korisničkoj sesiji pohranjuje da je korisnik odabrao “A-AS” i preusmjerava korisnika do krajnje točke autorizacije A-AS-a slanjem koda odgovora “303 See Other” sa zaglavljem lokacije s URL-om “napadac.primjeri/authorize?response_type=code&client_id=666RVZJTA”. 4. Sada napadač presreće ovaj odgovor i promijeni preusmjeravanje tako da se korisnik preusmjeri na H-AS. Napadač također zamjenjuje klijentov ID klijenta u A-AS-u s klijentovim ID-om u H-AS-u. Stoga preglednik prima preusmjeravanje (“303 See other'') sa zaglavljem lokacije prema kojemu je usmjere”honest.as.example/authorize?response_type=code&client_id=7ZGZldHQ“ 5. Sada korisnik ovlašćuje klijenta da pristupi njegovim resursima u H-AS. H-AS izdaje kod i šalje ga (putem preglednika) natrag klijentu. 6. Budući da klijent još uvijek pretpostavlja da je kod od A-AS, pokušat će ga poslati na pristupnu točku tokena A-AS-ovog poslužitelja. 7. Napadač, dakle, dobiva kod i može zamijeniti kod za pristupni token (za javne klijente) ili izvršiti napad ubrizgavanja koda koji je obrađen u poglavlju 5.2.2. Postoje još neke varijante ovog napada. Npr. Kada se koristi implicitni način autorizacije, onda je razlika u tome što se ne dobiva autorizacijski kod, već se dobije pristupni token. Za mjeru opreza se može konfigurirati autorizacijski server tako da se omogući zahtjev za njegovim id-jem kako bi ga klijent mogao pitati i usporediti sa svojim podacima. Osim toga dobro je imati točno specificirani URI kao povratni URI nakon autorizacije. I uz to dobro je provjeriti URI na koji je poslan zahtjev.

Zaključak

Kroz seminarski rad prošlo je se kroz protokol OAuth. OAuth u svojoj dokumentaciji ima 6 načina autorizacije. Neki načini nisu sigurni, kao npr. Implicitni i način s lozinkom. Ostali načini, kao npr. Način s autorizacijskim kodom, način s klijentskim akreditivom, kodom uređaja i osvježavajućim su sigurniji. Naravno postoje tehnike kojima se može i te načine učiniti nesigurnima.

OAuth dokumentacija predstavlja 10 napada koji su najčešće vezani uz način autorizacije s autorizacijskim kodom i nesigurnog implicitnog načina. OAuth je sigurniji što se više parametara koristi u komunikaciji poslužitelja. Ali postoje načini kada napadač ipak može zlonamjerno iskoristiti aplikaciju. U slučaju krađe pristupnog tokena OAuth protokol ne pruža neku mjeru zaštite, već samo preventivno kako se takav slučaj ne bi dogodio.

Literatura

[1] OAuth 2.0, https://oauth.net/2/, 06.01.2020

[2] Refresh Token Grant , https://docs.wso2.com/display/IS560/Refresh+Token+Grant, 09.01.2020

[3] Client Credentials Grant, https://docs.wso2.com/display/IS570/Client+Credentials+Grant, 09.01.2020

[4] Resource owner password credentials grant, https://docs.wso2.com/display/IS540/Resource+Owner+Password+Credentials+Grant, 09.01.2020

[5] Mitchell Anicas, An intorduction of OAuth 2, https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2, 09.01.2020

racfor_wiki/mrezna_forenzika/oauth_2_0_protokol.txt · Zadnja izmjena: 2023/06/19 18:17 (vanjsko uređivanje)