Ovo je stara izmjena dokumenta!

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

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 ponajprije indirektno autorizacijskom serveru kao posredniku.
Klijent prima odobrenje za autorizaciju, koje je prikazano kao uvjerenje od vlasnika resursa. To uvjerenje 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. Zahtjev sadrži i autorizacijski tip potpore.
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. 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.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.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.

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

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.

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.

6.4 Napad preko povijesti pretraživača

Napad preko povijesti pretraživača (engl. Attacks through the Browser History) se može iskoristiti onda kada se pristupni token javlja u parametru GET zahtjeva. Primjer takve putanje je: “provider.com/get_user_profile?access_token=abcdef”. To ostaje u povijesti pretraživača i napadač vrlo lako može pristupiti tom tokenu.

Mjera opreza je da se token ne stavlja u parametar get zahtjeva već da se stavlja u parametar post zahtjeva. Ili jednostavno koristiti način autorizacije preko autorizacijskog koda.

6.5 Napad umetanja pristupnog tokena

Napad u kojem napadač pokušava iskoristiti ukradeni token od nekog korisnika na uređaju kojeg napadač koristi. S tokenom potom se prijaviti na glavni klijent.

Napad se sastoji od toga da napadač pokrene OAuth protokol i na kraju ubaci taj ukradeni token, te tako pristupi podacima od korisnika.

Nemoguće je uočiti ovu vrstu napada. Ali za zaštitu potrebno je napraviti mjere opreza kao i u poglavlju 5.2.4.

6.6 Napad curenja podataka u preporučenom zaglavlju

Curenje podataka u preporučenom zaglavlju može se dogoditi ne namjerno kako na klijentu tako i na autorizacijskom serveru. Uzročnik može biti i loša implementacija pretraživača.

Kako bi propustio klijent potrebno je da stranica nakon registracije sadrži vezu do neke druge stranice koju kontrolira napadač, a da korisnik kline na tu vezu ili da stranica nakon prijave sadrži sadržaj neke treće strane.

Čim preglednik prijeđe na stranicu napadača ili učita sadržaj treće strane, napadač može dobit odgovor autorizacije iz čega može izvući token.

Na sličan način napadač može iskoristiti i autorizacijski server. Na autorizacijskom serveru može dobiti pristupni token, autorizacijski kod, ali i stanje autorizacijskog servera.

Dobivanjem tokena napadač ima pristup kao legitimni korisnik. Ako napadač izvuče i stanje autorizacijskog servera, njegov napad će probiti CSRF zaštitu.

Za zaštitu je najbolje izbjegavati korištenje stranica nakon autorizacije koje sadrže neke linkove ili sadržaje trećih strana.

Prva moguća mjera je korištenje povjerljivog klijenta, tj. Klijenta koji za dobivanje pristupni token, osim koda treba predati i tajni niz znakova.

Druga mjera opreza je da se s istim kodom ne može 2 puta dobitni pristupni token. Ako se dogodi takva situacija onda se treba odbiti drugi zahtjev. Naravno, odbijanje ne ublažava posljedice ako je napadačev zahtjev prvi stigao. Ali server bi se trebao držati pravila u tom slučaju da drugi zahtjev povuče sve pristupne tokene koji su nastali posljedicom tog autorizacijskog koda.

Treća mjera je korištenje parametra „state“. Problem je ako taj parametar procuri napadaču.

Način autorizacije preko autorizacijskog koda je puno sigurnija od ostalih načina, pa je i samo korištenje tog načina jedna mjera opreza za ovakav napad.

6.7 Krivotvorenje zahtjeva na neku drugu stranicu

Napadač može pokušati napraviti preusmjeravanje klijenta na žrtvinom uređaju, tako da žrtvin uređaj pristupi vlastitim resursima, naravno pod kontrolom napadača.

Kako bi se izbjegao ovakav napad dobro je koristiti CSRF token koji je na korisničkom agentu i koji sadrži parametar „state“. Inače PKCE pruža CSRF zaštitu.

Ali klijent treba biti siguran pruža li autorizacijski server PKCE kako bi ga koristio. Ako ne pruža, bitno je koristiti parametar „state“.

6.8 Napad na osvježavajući token

Osvježivanje tokena prikladan je i neugodan način za dobivanje novih pristupnih tokena nakon isteka starih pristupnih tokena. Osvježeni tokeni također povećavaju sigurnost OAuth-a jer dopuštaju autoru autorizacije da kratkim vijekom trajanja i smanjenim opsegom izdaje pristupne tokene i tako smanjuje potencijalni utjecaj curenja pristupnog tokena.

Tokeni za osvježavanje atraktivna su meta napadača jer daju svu ovlast vlasnika osvježavajućeg tokena napadaču. Ako napadač uspije ukrasti i uspješno upotrijebiti token za osvježavanje, napadač će moći umanjiti pristupne tokene i koristiti ih za pristup poslužiteljima resursa u ime vlasnika osvježavajućeg tokena.

OAuth već pruža snažnu osnovnu zaštitu. To postiže zahtjevom povjerljivosti osvježavajućih tokena u prijenosu i skladištenju. Kod prijenosa se može koristiti TLS zaštićena veza između autorizacijskog poslužitelja i klijenta. Kod skladištenja autorizacijski poslužitelj je zadužen za održavanje i provjeru vezanja s klijentom, a klijent je zadužen za skladištenje osvježavajućeg tokena. Osim TLS-a autorizacijski poslužitelj bi trebao i identificirati klijenta. A ključna stvar kod izrade osvježavajućih tokena je ne mogućnost generiranja, mijenjanja ili nagađanja od strane napadača.

OAuth također postavlja temelje za daljnje (specifične za implementaciju) sigurnosne mjere, kao što je stvaranje i opoziv osvježavajućeg tokena. Osim toga i obnavljanje rotacije tokena definiranjem odgovarajućih kodova pogreške i ponašanja odgovora.

Poslužitelji autorizacije moraju odrediti na temelju njihove procjene rizika da li za određeni klijent izdati osvježavajući token. Ako poslužitelj autorizacije odluči ne izdati osvježavajući token, klijent može osvježiti pristupne tokene pomoću drugih način autorizacije, poput načina pomoću autorizacijskog koda. U takvom slučaju poslužitelj autorizacije može koristiti kolačiće i trajne donacije za optimizaciju korisničkog iskustva.

Ako su osvježavajući tokeni izdani, oni se moraju vezati za poslužitelje resursa jer ih je odobrio vlasnik resursa. Na ovaj se način sprečava eskalacija privilegija od strane zakonitog klijenta i umanjuje utjecaj opoziva osvježavajućih tokena.

Poslužitelji autorizacije trebaju automatski opozvati osvježavajuće tokene u slučaju nekih sigurnosnog događaja. Npr. Promjena lozinke ili odjava na autorizacijskom poslužitelju su takvi događaji.

Tokeni za osvježavanje trebali bi isteći ako klijent nije aktivan neko vrijeme, tj. Token za osvježavanje ima neko vrijeme valjanosti za dobivanje novih pristupnih tokena. Vrijeme isteka ovisi o autoru autorizacije. To može biti globalna vrijednost ili određeno na temelju klijentske politike ili odobrenja povezanog s tokenom za osvježavanje (i njegovom osjetljivošću).

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.

Sources

racfor_wiki/mrezna_forenzika/oauth_2_0_protokol.1578636758.txt.gz · Zadnja izmjena: 2024/12/05 12:23 (vanjsko uređivanje)

Sadržaj