Razlike

Slijede razlike između dviju inačica stranice.

--- racfor_wiki:mrezna_forenzika:oauth_2_0_protokol [2020/01/10 06:22]
abijelic [6.8 Napad na osvježavajući token]
+++ 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 231: / Redak 234: @@
-==== 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“.
-====   ====

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