Razlike

Slijede razlike između dviju inačica stranice.

--- racfor_wiki:mrezna_forenzika:oauth_2_0_protokol [2020/01/10 06:14]
abijelic [5.6 Način sa osvježavajućim tokenom]
+++ racfor_wiki:mrezna_forenzika:oauth_2_0_protokol [2024/12/05 12:24] (trenutno)
@@ Redak 19: / Redak 19: @@
 ===== 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.
@@ Redak 49: / Redak 51: @@
 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 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, 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 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. Zahtjev sadrži i autorizacijski tip potpore.
+  - 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.
+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.
 {{  https://assets.digitalocean.com/articles/oauth/abstract_flow.png?direct&561x372  }}
-Slika 4.1 Prikaz koraka protokola OAuth za autorizaciju
+Slika 4.1 Prikaz koraka protokola OAuth za autorizaciju [5]
@@ Redak 81: / Redak 84: @@
   - <font 12.0pt/Calibri,sans-serif;;inherit;;inherit>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.</font>
-{{https://assets.digitalocean.com/articles/oauth/abstract_flow.png?nolink&561x372}}
+{{https://assets.digitalocean.com/articles/oauth/auth_code_flow.png?nolink&600x347}}
-<font 12.0pt/Calibri,sans-serif;;inherit;;inherit>slika 5.1.1 način autorizacije autorizaciskim kodom</font>
+<font 12.0pt/Calibri,sans-serif;;inherit;;inherit>slika 5.1.1 način autorizacije autorizaciskim kodom [5]</font>
@@ Redak 106: / Redak 109: @@
 {{https://assets.digitalocean.com/articles/oauth/implicit_flow.png?nolink&715x414}}
-<font 12.0pt/Calibri,sans-serif;;inherit;;inherit>Slika 5.2.1 implicitni način autorizacije</font>
+<font 12.0pt/Calibri,sans-serif;;inherit;;inherit>Slika 5.2.1 implicitni način autorizacije [5]</font>
@@ Redak 123: / Redak 126: @@
 {{https://docs.wso2.com/download/attachments/61670242/OAuth grant types - password.png?nolink&500x358}}
-<font 12.0pt/Calibri,sans-serif;;inherit;;inherit>Slika 5.3.1 Način autorizacije lozinkom.</font>
+<font 12.0pt/Calibri,sans-serif;;inherit;;inherit>Slika 5.3.1 Način autorizacije lozinkom [4]</font>
@@ Redak 139: / Redak 142: @@
 {{https://docs.wso2.com/download/attachments/92523222/OAuth grant types - client-credential.png?nolink&500x183}}
-<font 12.0pt/Calibri,sans-serif;;inherit;;inherit>Slika 5.4.1 Način autorizacije sa klijentskim akreditivom</font>
+<font 12.0pt/Calibri,sans-serif;;inherit;;inherit>Slika 5.4.1 Način autorizacije sa klijentskim akreditivom[3]</font>
@@ Redak 155: / Redak 158: @@
 <font 12pt/Arial,sans-serif;;inherit;;inherit>Autorizacija s osvježavajućim tokenom dana je kroz sljedeće korake koji su prikazani na slici 5.6.1.</font>
-<font 12pt/Arial,sans-serif;;inherit;;inherit></font>
+{{https://docs.wso2.com/download/attachments/87705099/OAuth grant types - refresh-token.png?nolink&600x406}}
 <font 12pt/Arial,sans-serif;;inherit;;inherit>Slika 5.6.1 Način autorizacije sa osvježavajućim tokenom [2]</font>
@@ Redak 230: / Redak 233: @@
 . 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|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 ====
+===== Zaključak =====
-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.
+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.
-Napad se sastoji od toga da napadač pokrene OAuth protokol i na kraju ubaci taj ukradeni token, te tako pristupi podacima od korisnika.
+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.
-Nemoguće je uočiti ovu vrstu napada. Ali za zaštitu potrebno je napraviti mjere opreza kao i u poglavlju 5.2.4.
+===== Literatura =====
-==== 6.6 Napad curenja podataka u preporučenom zaglavlju ====
+[1] OAuth 2.0, [[https://oauth.net/2/|https://oauth.net/2/]], 06.01.2020
-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.
+<font 12.0pt/inherit;;inherit;;inherit>[2] Refresh Token Grant</font> , [[https://docs.wso2.com/display/IS560/Refresh+Token+Grant|https://docs.wso2.com/display/IS560/Refresh+Token+Grant]], 09.01.2020
-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.
+[3] Client Credentials Grant, [[https://docs.wso2.com/display/IS570/Client+Credentials+Grant|https://docs.wso2.com/display/IS570/Client+Credentials+Grant]], 09.01.2020
-Č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.
+[4] Resource owner password credentials grant, [[https://docs.wso2.com/display/IS540/Resource+Owner+Password+Credentials+Grant|https://docs.wso2.com/display/IS540/Resource+Owner+Password+Credentials+Grant]], 09.01.2020
-===== Sources =====
+[5] Mitchell Anicas, An intorduction of OAuth 2, [[https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2|https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2]], 09.01.2020

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