OAuth protokol

Ivan Budiselic

Seminarski rad za poslijediplomski predmetSigurnost racunalnih sustava

12. kolovoza 2011.

Sazetak

OAuth protokol omogucuje sigurno dijeljenje podataka i funkcionalnosti medurazlicitim web-aplikacijama, sto na modernom Webu postaje sve vaznije. Useminarskom radu je preciznije opisan problem koji se rjesava protokolom idan je pregled sigurnosnih znacajki OAuth 1.0a protokola. Nadalje, ukratkoje opisan i novi OAuth 2.0 protokol cija specifikacija se priblizava zavrsetku.Novi protokol nije kompatibilan s inacicom 1.0a, ali zasniva se na istoj ideji.Ipak, kao sto je opisano u radu, cini se da nudi losija sigurnosna svojstva.

Sadrzaj

Uvod 2

1 Osnove OAuth protokola 5

1.1 Problem pristupa zasticenom sredstvu iz strane web-aplikacije 6

1.2 Osnovni scenarij primjene OAuth protokola . . . . . . . . . . 8

2 Sigurnost OAuth protokola 10

2.1 Dohvacanje privremenog akreditiva . . . . . . . . . . . . . . . 10

2.2 Autorizacija klijenta za pristup zasticenom sredstvu . . . . . . 12

2.3 Zamjena privremenog akreditiva za pristupnu znacku . . . . . 13

2.4 Pristupanje zasticenom sredstvu . . . . . . . . . . . . . . . . . 14

2.5 Potpisivanje zahtjeva . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 OAuth 1.0a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 OAuth 2.0 18

3.1 Pregled OAuth 2.0 protokola . . . . . . . . . . . . . . . . . . . 18

3.2 Razvoj OAuth 2.0 specifikacije . . . . . . . . . . . . . . . . . . 19

Zakljucak 21

Literatura 22

1

Uvod

Razvojem Weba od 90-ih godina proslog stoljeca do danas, sigurnost racunalapostaje sve vaznija, a sigurnosni problemi koji se pojavljuju sve slozeniji. Zapovecanu vaznost sigurnosti racunala, moze se pronaci barem tri razloga.Prvi razlog je promjena paradigme koristenja Weba iz pregledavanja jed-nostavnih staticnih stranica u primjenu slozenih web-aplikacija. Te slozeneaplikacije obavljaju funkcije koje su prethodno bile iskljucivo u domeni lo-kalnih aplikacija instaliranih na racunalu korisnika, kao sto su upravljanjeelektronickom postom i uredivanje dokumenata. Dodatno, moderne web-aplikacije nude korisnicima prije potpuno nedostupne usluge kao sto su web-bankarstvo i rezervacija avionskih karata.

Drugo, dok su korisnici nekada bili anonimni citatelji web-stranica, da-nas vecina stranica omogucuje ili trazi registraciju i kasnije autentikacijukorisnika. Korisnici razlicitim posluziteljima povjeravaju podatke razlicitevaznosti, od osobnog imena, adrese elektronicke poste i fotografija, do bro-jeva kreditnih kartica. U ovoj interakciji korisnici ocjenjuju relativnu vaznostpodataka i razinu povjerenja prema odredenoj web-aplikaciji. Na primjer,vecini korisnika je prihvatljivije povjeriti broj svoje kreditne kartice Ama-zonu nego nekom nepoznatom web-ducanu, u uvjerenju da broj kartice necebiti zlorabljen niti ukraden.1

Konacno, treci razlog, vazan za razumijevanje namjene OAuth protokola,su povezane web-aplikacije (engl. mashups) koje za svoj rad koriste podatkei funkcionalnosti drugih web-aplikacija, tipicno koristeci programska suceljakoja te aplikacije izlazu. Ako se u radu povezane aplikacije koriste korisnickipodaci iz neke druge aplikacije, javlja se sigurnosni problem—kako korisnikmoze povezanoj aplikaciji omoguciti ogranicen pristup nekim svojim poda-cima u drugoj aplikaciji? Na primjer, web-stranica tvrtke za profesionalno

1Cak i uz visoku razinu povjerenja, u svjetlu brojnih slucajeva krade korisnickih osob-nih podataka od uglednih kompanija, mnogi strucnjaci za racunalnu sigurnost predlazukoristenje posebnog racuna za sva web-placanja.

2

otiskivanje fotografija mogla bi korisniku omoguciti da umjesto prijenosafotografije preko mreze, fotografiju odabere iz osobnog Facebook albuma.Vazno je uociti da ovaj scenarij podrazumijeva da podaci kojima treba pris-tupiti nisu javno dostupni, nego im je pristup na neki nacin ogranicen. Naprimjer, posluzitelj isporucuje podatke samo autenticiranom korisniku koji jevlasnik podataka i nekoj grupi korisnika koje je vlasnik podataka autoriziraoza pristup.

Neke povezane aplikacije ovaj problem rjesavaju koristeci protuuzorak lo-zinke (engl. password anti-pattern)—od korisnika traze korisnicko ime i lo-zinku za pristup drugoj web-aplikaciji [1]. Ovakvo rjesenje ima nekolikoznacajnih nedostataka. Prvo, korisnicko ime i lozinka omogucuju poveza-noj aplikaciji neogranicen pristup korisnickom racunu u drugoj aplikaciji. Uopisanom primjeru, aplikacija foto-studija mogla bi osim dohvacanja oda-brane fotografije za otiskivanje, na korisnikov Facebook zid objaviti reklamuza svoju uslugu ili nesto mnogo gore. Drugo, pristup korisnickom racunu udrugoj aplikaciji nije niti vremenski ogranicen—dok god korisnik ne promi-jeni lozinku, povezana aplikacija moze nesmetano pristupati drugoj aplikaciji.Trece, i uz pretpostavku da sama povezana aplikacija ne namjerava zlorabitidobiveno korisnicko ime i lozinku, sama sigurnost korisnickog imena i lozinkeugrozenija je nego prije. Na primjer, ako povezana aplikacija iz bilo kojeg raz-loga pohrani korisnicko ime i lozinku u svoju bazu podataka u nekriptiranomobliku, napad na povezanu aplikaciju moze napadacu omoguciti laksi pris-tup drugim aplikacijama koje mozda znatno bolje cuvaju podatke. Stovise,priroda problema cesto upravo zahtijeva da povezana aplikacija pohrani ko-risnicko ime i lozinku kako bi mogla vise puta pristupiti nekim podacima.

OAuth protokol predstavlja mnogo sigurnije rjesenje predstavljenog pro-blema. Slikovito se rjesenje moze shvatiti kroz primjer servisnog kljuca zaautomobil.2 Vlasnik automobila serviseru uz automobil ostavlja servisni kljuckoji serviseru omogucuje ispitivanje vozila, ali, na primjer, ogranicava maksi-malnu udaljenost koju automobil moze prijeci na nekoliko kilometara kako bisprijecio koristenje automobila za osobne potrebe ili kradu. OAuth protokolomogucuje predavanje vremenski ogranicenog pristupa nekom podskupu ko-risnikovih sredstava u jednoj web-aplikaciji drugoj web-aplikaciji. Sredstvoje u opcenitom smislu sve sto ima URL pa tako moze biti podatak, ali i nekaslozenija operacija nad programskim suceljem aplikacije. Dodatno, moguceje ograniciti i nacin pristupa; na primjer, pristup se moze ograniciti samo nacitanje.

2U SAD-u se slican kljuc koristi za parkiranje automobila ispred luksuznih hotela ilirestorana (engl. valet key).

3

Ostatak rada organiziran je na sljedeci nacin: u poglavlju 1 je detaljnijeopisan problem koji se rjesava OAuth protokolom i osnovni nacin koristenjaOAuth 1.0a protokola; sigurnosne znacajke protokola opisane su u poglavlju2; konacno, u poglavlju 3 je ukratko opisan OAuth 2.0 protokol cija speci-fikacija se priblizava zavrsetku i koji bi trebao kroz neko vrijeme zamijenitiOAuth 1.0a protokol.

4

Poglavlje 1

Osnove OAuth protokola

OAuth je otvoreni protokol ciji razvoj je poceo krajem 2006. godine, uz sudje-lovanje dijela OpenID zajednice i inzinjera iz Twittera, Magnolije, Googleai drugih web-kompanija. Prva gruba inacica specifikacije objavljena je usrpnju 2007. godine. Konacna inacica specifikacije, pod sluzbenim nazivomOAuth Core 1.0, objavljena je u prosincu iste godine. Sredinom 2008. godine,poceo je postupak standardizacije protokola pri IETF-u. Konacno, IETF jespecifikaciju objavio kao RFC 5849 u travnju 2010. godine.

U meduvremenu je zbog sigurnosnog propusta 2009. godine objavljenarevizija protokola pod nazivom OAuth Core 1.0a. Iako se cinilo da ce OAuthprotokol rijesiti vazan prakticni problem, protokol nije dozivio siroku pri-mjenu ubrzo nakon zavrsetka specifikacije, prvenstveno zbog slozenosti im-plementacije i losih svojstava razmjernog rasta. Dodatno, protokol je gotovonemoguce iskoristiti iz lokalnih i mobilnih aplikacija [2]. Zbog navedenihogranicenja, umjesto daljnjeg rada na OAuth 1.0 protokolu, u tijeku je ra-zvoj specifikacije OAuth 2.0 protokola. Novi protokol trebao bi ispravitiuocene nedostatke, ali nece biti kompatibilan s postojecim protokolom.

U nastavku poglavlja opisan je problem za koji je OAuth protokol osmisljeni osnovni scenarij primjene OAuth protokola. Protokol je prikazan na visokojrazini kroz osnovne korake, a detaljniji opis koraka dan je u poglavlju 2.

5

1.1 Problem pristupa zasticenom sredstvu iz

strane web-aplikacije

Vecina web-aplikacija autentikaciju korisnika provodi kroz jednostavnu ko-munikaciju izmedu klijenta i posluzitelja. Klijent je tipicno web-preglednik,a autentikacija se provodi razmjenom korisnickog imena i lozinke. Korisnikse autenticira kako bi mogao pristupiti zasticenim sredstvima unutar web-aplikacije. Najopcenitije receno, sredstvo je jedinstveno odredeno svojimURL-om, a pristup sredstvu obavlja se HTTP protokolom.

klijent poslužitelj

korisničko ime + lozinka (1)

identifikator sjednice (2)

Slika 1.1: Konceptualni prikaz autentikacije u klasicnom scenariju koristenjaweb-aplikacije.

Moguca interakcija izmedu klijenta i posluzitelja u postupku autentikacijeprikazana je na slici 1.1. Klijent zapocinje komunikaciju slanjem zahtjeva zaautentikaciju uz korisnicko ime i lozinku prema posluzitelju (1). Posluziteljprovjerava ispravnost primljenih podataka i, u slucaju da podaci ispravnoidentificiraju nekog korisnika aplikacije, otvara korisnicku sjednicu i klijentusalje identifikator sjednice (2).1 Klijent uz preostale zahtjeve posluziteljusalje i dobiveni identifikator sjednice.

Vazna pretpostavka na slici 1.1 je da vlasnik korisnickog racuna upravljaklijentom. Kada je klijent web-preglednik instaliran na korisnicko racunalo,ova pretpostavka je zadovoljena—korisnik korisnicko ime i lozinku predajeklijentu kroz web-obrazac ili ih predaje web-pregledniku na trajno cuvanjekao ih nebi morao unositi mnogo puta kroz veci broj pristupa istoj aplikaciji.

Slozeniji scenarij je prikazan na slici 1.2. Komunikacija izmedu klijenta,racunala A, i posluzitelja, racunala B, jednaka je kao u prethodnom scenariju:

1Dakako, cijela interakcija se tipicno odvija koristeci SSL/TLS kako bi se zastitilokorisnicko ime i lozinku. Nacin na koji se sjednica stiti od krade ovisi o implementaciji,ali nije vazan za ovaj primjer.

6

korisničko računalo

korisničko ime + lozinka (2)

identifikator sjednice (3)

A

korisničko ime+ lozinka (1)

B

Slika 1.2: Konceptualni prikaz protuuzorka autentikacije jedne web-aplikacijedrugoj.

posluzitelj od klijenta dobiva korisnicko ime i lozinku (2) i odgovara identi-fikatorom sjednice (3). Medutim, znacajna razlika u odnosu na prethodniscenarij je priroda klijenta—dok je klijent u prethodnom scenariju korisnickoracunalo koje izravno komunicira s posluziteljom web-aplikacije B, u ovomscenariju je klijent posluzitelj web-aplikacije A, a na korisnickom racunalu seizvodi prezentacijski sloj aplikacije A. Zbog jednostavnosti slike, pretpostav-lja se da je korisnik prethodno vec autenticiran prema web-aplikaciji A kojukoristi. Interakcija prikazana na slici trebala bi omoguciti aplikaciji A do-hvacanje nekog korisnikovog resursa iz aplikacije B, na primjer fotografije. Unajjednostavnijem rjesenju problema, korisnik jednostavno predaje aplikacijiA korisnicko ime i lozinku za autentikaciju prema aplikaciji B (1).

Dok korisnik u pravilu moze povjeriti svoje korisnicko ime i lozinku web-pregledniku na vlastitom racunalu, predaja tih podataka nekoj drugoj web-aplikaciji ima brojne nedostatke. Web-aplikacija A dobiva potpuno neo-

7

granicen pristup korisnickom racunu u aplikaciji B i moze ili zlonamjernoili greskom uciniti mnogo vise nego sto korisnik zeli. Dodatno, aplikacijaA moze pristupati korisnickom racunu u aplikaciji B sve dok korisnik nepromijeni lozinku.

1.2 Osnovni scenarij primjene OAuth proto-

kola

Kroz interakciju prikazanu na slici 1.2, korisnik omogucuje aplikaciji A da seautenticira kod aplikacije B kao sam korisnik. Umjesto toga, ako aplikacije Ai B podrzavaju OAuth protokol, korisnik aplikaciju A moze samo autoriziratiza pristup nekom zasticenom sredstvu u aplikaciji B, u odredenom vremen-skom intervalu. Granulacija prava pristupa ovisi o konkretnoj implementacijii nije u domeni OAuth protokola.

U postupku autorizacije aplikacije za pristup zasticenom sredstvu putemOAuth protokola sudjeluju posluzitelj na kojem se sredstvo nalazi, klijent kojisredstvu treba pristupiti i vlasnik sredstva (engl. resource owner), drugimrijecima korisnik. Umjesto koristenja korisnickog imena i lozinke vlasnikasredstva, klijent u okviru implementacije OAuth protokola od posluziteljadobiva vlastiti akreditiv (engl. credentials) koji se sastoji od identifikatora idijeljene tajne (engl. shared secret).2

U OAuth protokolu se autorizacija klijenta za pristup dijeljenom sred-stvu provodi kroz tri koraka [3]. Prvo, klijent dohvaca privremeni akreditiv.Drugo, vlasnik sredstva na posluzitelju autorizira klijenta za pristup sredstvu.Konacno, klijent zamjenjuje privremeni akreditiv za pristupnu znacku (engl.token credentials) koja se sastoji od identifikatora i dijeljene tajne. Klijentpristupa zasticenom sredstvu koristeci dobivenu pristupnu znacku. Ovisno oimplementaciji, vlasnik sredstva moze u bilo kojem trenutku klijentu oduzetipravo pristupa sredstvu cime znacka postaje bezvrijedna.

U slucaju da vlasnik sredstva klijentu i posluzitelju pristupa kroz web-preglednik, sto je tipicna primjena OAuth protokola, napredak kroz nave-dene korake moze se ostvariti koristenjem HTTP preusmjeravanja, kao stoje prikazano na slici 1.3. Vlasnik sredstva zapocinje komunikaciju zahtjevomprema klijentu da pristupi zasticenom sredstvu na posluzitelju (1). Klijent od

2Specifikacija protokola ne predvida tocan nacin na koji ce klijent od posluzitelja dobitiakreditiv. Dijeljena tajna koristi se samo ako se za potpisivanje zahtjeva koristi HMAC-SHA1, kao sto je objasnjeno u odjeljku 2.5.

8

korisničko računalo

poslužitelj

dohvat privremenog akreditiva (2)

dohvat pristupne značke (6)

klijent

zahtjev zakorištenjesredstva (1)

preusmjerenjena poslužitelj (3)

autorizacijaklijenta (4) preusmjerenje

na klijenta (5)

Slika 1.3: Osnovni scenarij primjene OAuth protokola.

posluzitelja dohvaca privremeni akreditiv (2) i preusmjerava web-preglednikvlasnika sredstva na odgovarajucu stranicu na posluzitelju (3). Vlasnik sred-stva autorizira klijenta za koristenje zasticenog resursa na posluzitelju (4),a posluzitelj preusmjerava web-preglednik vlasnika sredstva nazad na kli-jentsku aplikaciju (5). Konacno, klijent zamjenjuje privremeni akreditiv zapristupnu znacku (6).

Za ostvarenje prikazanog scenarija, posluzitelj treba izloziti URL-ove zadohvacanje privremenog akreditiva, za zamjenu privremenog akreditiva zapristupnu znacku i za stranicu na kojoj vlasnik sredstva moze autoriziratiklijenta za pristup zasticenom sredstvu.

9

Poglavlje 2

Sigurnost OAuth protokola

U ovom poglavlju su opisana pravila OAuth protokola za oblikovanje zah-tjeva sa slike 1.3 i kasnijih zahtjeva klijenta za pristup zasticenom sredstvukoristeci pristupnu znacku. Uz opis pravila navedeni su i primjeri HTTPporuka koje sudionici razmjenjuju.1 URL klijenta i posluzitelja u primjerusu redom klijent.example.com i posluzitelj.example.net. Akreditivklijenta za pristupanje posluzitelju sastoji se od identifikatora klijent123 idijeljene tajne klijent tajna123. Posluzitelj za potrebe OAuth protokolana relativnim HTTPS URL-ovima /privremeni, /autoriziraj i /znackaredom omogucuje dohvat privremenog akreditiva, autorizaciju klijenta zapristup zasticenom sredstvu i zamjenu privremenog akreditiva za pristupnuznacku.

2.1 Dohvacanje privremenog akreditiva

Klijent dohvaca privremeni akreditiv HTTPS POST zahtjevom prema posluzitelju.Za autorizaciju zahtjeva klijent koristi vlastiti akreditiv, prethodno dobivenod posluzitelja u okviru implementacije OAuth protokola.

1 POST /privremeni HTTP/1.1

2 Host: posluzitelj.example.net:443

3 Authorization: OAuth realm="domena",

4 oauth_consumer_key="klijent123",

5 oauth_signature_method="HMAC-SHA1",

1Primjeri poruka izgradeni su koristeci alat http://hueniverse.com/oauth/guide/

authentication/ i jednostavnu Python skriptu za racunanje HMAC-SHA1.

10

6 oauth_timestamp="1312201920",

7 oauth_nonce="nonce1",

8 oauth_callback="http%3A%2F%2Fklijent.example.com%2Fspreman"

,

9 oauth_signature="ETUe9pAAgWgFUyoKUAbpM08Q5Bk%3D"

Ispis 2.1: Primjer HTTP zahtjeva za dohvat privremenog akreditiva.

Primjer zahtjeva prikazan je u ispisu 2.1. Kljucan element prikazaneporuke je zaglavlje Authorization koje ima vrijednost OAuth i niz para-metara. Parametar realm je standardni HTTP autentikacijski parametarkoji OAuth posluzitelj opcionalno moze koristiti za definiranje zastitne do-mene, ali njegova semantika nije odredena specifikacijom [4]. Parametaroauth consumer key sadrzi vrijednost identifikatora iz klijentskog akreditiva.Kako se autentikacija svih poruka u OAuth protokolu moze opisati opcenito,znacenje parametara oauth signature method i oauth signature opisanisu u odjeljku 2.5.

Parametar oauth nonce sadrzi slucajno generirani niz znakova koji sluziza prevenciju napada ponavljanjem zahtjeva (engl. replay attack). Posluziteljza svaki par vremenske oznake i akreditiva, zahtjev s odredenom vrijed-nosti parametra oauth nonce prihvaca najvise jednom. Kako bi proveo ovoogranicenje, posluzitelj mora pamtiti iskoristene vrijednosti oauth nonce pa-rametra za svaki par vremenske oznake i akreditiva. Kako bi posluzitelj zas-tarjele zahtjeve mogao odbaciti bez provjeravanja oauth nonce parametra,u zahtjev se ukljucuje i parametar oauth timestamp koji sadrzi broj sekundiod pocetka 1. sijecnja 1970. godine.2.

Konacno, parametar oauth callback posluzitelju prosljeduje URL nakoji treba preusmjeriti korisnika nakon autorizacije klijentskog zahtjeva.

Posluzitelj provjerava autenticnost poruke racunanjem sazetka, kao sto jeopisano u odjeljku 2.5 i klijentu odgovara porukom s privremenim akrediti-vom.

1 HTTP/1.1 200 OK

2 Content-Type: application/x-www-form-urlencoded

3

4 oauth_token=privremeni123&oauth_token_secret=

privremeni_tajna123&oauth_callback_confirmed=true

2Specifikacija ne predvida mehanizam sinkronizacije satova klijenta i posluzitelja, ali isama vrijednost parametara nije sigurnosne prirode jer ju je lako krivotvoriti.

11

Ispis 2.2: Primjer odgovora na zahtjev za privremeni akreditiv.

Primjer odgovora posluzitelja prikazan je u ispisu 2.2. Privremeni akredi-tiv sastoji se od vrijednosti parametara oauth token i oauth token secret.Parametar oauth callback confirmed uvijek je postavljen na vrijednosttrue i sluzi za razlikovanje poruke od poruke protokola verzije 1.0.3

Kako se dijeljena tajna privremenog akreditiva nalazi nezasticena u tijeluporuke, OAuth protokol zahtijeva da se tajnost osigura nizim protokolom,na primjer koristeci SSL/TLS.

2.2 Autorizacija klijenta za pristup zasticenom

sredstvu

Nakon uspjesnog dohvacanja privremenog akreditiva, klijent preusmjeravavlasnika sredstva na URL koji posluzitelj izlaze za autorizaciju zahtjeva.Kao parametar u URL-u, klijent navodi dobiveni identifikator iz privremenogakreditiva u parametru oauth token.

1 https://posluzitelj.example.net/autoriziraj?oauth_token=

privremeni123

Ispis 2.3: Primjer URL-a za autorizaciju zahtjeva za pristup zasticenomsredstvu.

Primjer URL-a za autorizaciju zahtjeva prikazan je u ispisu 2.3. U pri-mjeru je u URL-u koristen HTTPS protokol, iako to nije nuzno.

Posluzitelj mora autenticirati korisnika koji je pristupio URL-u. Dodatno,specifikacija OAuth protokola preporuca da posluzitelj vlasniku sredstva naosnovi identifikatora iz zahtjeva prikaze koja aplikacija trazi autorizaciju.Ako vlasnik sredstva autorizira klijenta za pristup sredstvu, posluzitelj pre-usmjerava korisnicko racunalo na URL koji je klijent postavio u parametruzahtjeva za privremeni akreditiv. Dobivenom URL-u posluzitelj dodaje para-metre oauth token i oauth verifier. Vrijednost parametra oauth token jeidentifikator iz privremenog akreditiva, a vrijednost parametra oauth verifier

je slucajno generiran niz znakova koji osigurava da je vlasnik sredstva koji jeautorizirao zahtjev isti onaj koji komunicira s klijentom.3

3Vidi odjeljak 2.6.

12

1 http://klijent.example.com/spreman?oauth_token=privremeni123&

oauth_verifier=potvrda123

Ispis 2.4: Primjer URL-a na koji posluzitelj preusmjerava vlasnika sredstvanakon autorizacije zahtjeva klijenta.

Primjer URL-a na koji posluzitelj preusmjerava vlasnika sredstva prikazanje u ispisu 2.4. Posluzitelj prikazani URL gradi na osnovi oauth callback

parametra iz ispisa 2.1.

2.3 Zamjena privremenog akreditiva za pris-

tupnu znacku

Klijent zamjenjuje privremeni akreditiv za pristupnu znacku POST zahtje-vom na URL koji posluzitelj izlaze za dohvat pristupne znacke.

1 POST /znacka HTTP/1.1

2 Host: posluzitelj.example.net:443

3 Authorization: OAuth realm="domena",

4 oauth_consumer_key="klijent123",

5 oauth_token="privremeni123",

6 oauth_signature_method="HMAC-SHA1",

7 oauth_timestamp="1312201921",

8 oauth_nonce="nonce2",

9 oauth_verifier="potvrda123",

10 oauth_signature="64vLikulC3%2BEPHKmw9RKDth0Cng%3D"

Ispis 2.5: Primjer zahtjeva za dohvat pristupne znacke.

Primjer zahtjeva za dohvat pristupne znacke prikazan je u ispisu 2.5.Pri dohvacanju pristupne znacke, klijent se autorizira svojim akreditivom iprivremenim akreditivom dobivenim od posluzitelja. Identifikator klijentskogakreditiva u zahtjev se postavlja kao vrijednost parametra oauth consumer key,a identifikator privremenog akreditiva kao vrijednost parametra oauth token.Dodatno, klijent u zahtjev mora ukljuciti i oauth verifier parametar cijuvrijednost preuzima iz HTTP GET zahtjeva vlasnika sredstva. Ostali para-metri imaju isto znacenje kao u zahtjevu za privremeni akreditiv.

Posluzitelj provjerava autenticnost zahtjeva i dodatno provjerava je li vri-jednost parametra oauth verifier jednaka vrijednosti koju je generirao pri

13

preusmjeravanju vlasnika sredstva. Ako je zahtjev valjan, posluzitelj gene-rira pristupnu znacku i predaje ju klijentu. Klijent privremeni akreditiv zadohvat pristupne znacke moze iskoristiti najvise jednom.

1 HTTP/1.1 200 OK

2 Content-Type: application/x-www-form-urlencoded

3

4 oauth_token=pristupna123&oauth_token_secret=pristupna_tajna123

Ispis 2.6: Primjer odgovora na zahtjev za dohvat pristupne znacke.

Primjer odgovora posluzitelja prikazan je u ispisu 2.6. Pristupna znackasastoji se od identifikatora oauth token i dijeljene tajne oauth token secret.Isto kao kod dohvata privremenog akreditiva, posluzitelj u odgovoru dijeljenutajnu salje u nezasticenom obliku. Zbog toga specifikacija OAuth protokolaodreduje da se povjerljivost ostvari nizim protokolom, na primjer koristeciSSL/TLS kao sto je prikazano u primjeru.

2.4 Pristupanje zasticenom sredstvu

Koristeci pristupnu znacku, klijent moze pristupati zasticenom sredstvu.Specifikacija preporuca da se u implementaciji protokola vlasnicima sred-stva omoguci vremenski ogranicena autorizacija i ukidanje prava pristupa ubilo kojem trenutku. Dodatno, posluzitelj moze omoguciti razlicite razinegranulacije prava pristupa na razini vlastitog programskog sucelja.

1 GET /korisnik123/datoteka HTTP/1.1

2 Host: posluzitelj.example.net

3 Authorization: OAuth realm="domena",

4 oauth_consumer_key="klijent123",

5 oauth_token="pristupna123",

6 oauth_signature_method="HMAC-SHA1",

7 oauth_timestamp="1312201922",

8 oauth_nonce="nonce3",

9 oauth_signature="ufhuIZ2acYm0ggMlaIh%2FRgQMe7Q%3D"

Ispis 2.7: Primjer zahtjeva prema zasticenom sredstvu.

Primjer zahtjeva prema zasticenom sredstvu je prikazan u ispisu 2.7. Kli-jent zahtjeve potpisuje dijeljenom tajnom vlastitog akreditiva i dijeljenomtajnom pristupne znacke, a pripadni identifikatori zapisuju se u parametre

14

oauth consumer key i oauth token. Znacenje preostalih parametara isto jekao u prethodno prikazanim zahtjevima za privremeni akreditiv i pristupnuznacku.

2.5 Potpisivanje zahtjeva

U OAuth protokolu, provjera integriteta i autenticnosti zahtjeva zasniva se nadigitalnom potpisu.4 Specifikacija protokola opisuje tri nacina potpisivanjazahtjeva, a klijent odabrani nacin posluzitelju objavljuje koristeci parame-tar oauth signature method. Posluzitelji tipicno podrzavaju samo jedannacin potpisivanja zahtjeva. Dodatno, posluzitelj moze po volji definirati idokumentirati neki vlastiti nacin koji osigurava ista sigurnosna svojstva. Trinacina opisana u specifikaciji su HMAC-SHA1, RSA-SHA1 i PLAINTEXT.

HMAC-SHA1 i RSA-SHA1 zasnivaju se na racunanju sazetka poruke. Prijeracunanja sazetka, zahtjev se svodi na kanonski oblik. Kanonski oblik zah-tjeva je niz znakova koji redom sadrzi HTTP metodu, URL kojem se pristupai imena i vrijednosti svih OAuth parametara osim realm i oauth signature

sortiranih uzlazno po imenu parametra.5 Dijelovi kanonskog oblika su pos-totno kodirani [5] i medusobno odvojeni znakom &.

HMAC-SHA1 nacin potpisivanja zahtjeva koristi HMAC-SHA1 algoritam de-finiran u [6]. Pri racunanju sazetka, za kljuc se koristi niz dobiven spa-janjem dijeljene tajne klijentskog akreditiva i dijeljene tajne privremenogakreditiva ili pristupne znacke, ovisno o vrsti zahtjeva, znakom &. Do-datno, za dohvacanje privremenog akreditiva, drugi dio kljuca je prazanniz. Sazetak se racuna pozivom HMAC-SHA1(kljuc, kanonski zahtjev).Izracunati sazetak se kodira u bazu 64 i postavlja u zahtjev kao vrijed-nost parametra oauth signature. Posluzitelj verificira potpis ponovnimracunanjem sazetka na isti nacin.

RSA-SHA1 nacin potpisivanja zasniva se na RSASSA-PKCS1-v1 5 algoritmudefiniranom u [7]. Kako bi se mogao koristiti ovaj nacin potpisivanja zah-tjeva, klijent kod posluzitelja mora registrirati svoj javni RSA kljuc. Sazetak

4Iako se digitalni potpis tipicno povezuje s asimetricnom enkripcijom kojom se krip-tira sazetak poruke, specifikacija OAuth protokola uniformno koristi pojam potpis (engl.signature) za nekoliko nacina zastite koji ostvaruju iste sigurnosne ciljeve kao i osnovnadefinicija digitalnog potpisa. U skladu sa specifikacijom, u radu se takoder koristi pojampotpis.

5Za vazne detalje o tocnom formatu kanonskog oblika i prikazu brojnih specijalnihznakova vidjeti odjeljak 3.4.1. specifikacije [3].

15

se racuna pozivom RSASSA-PKCS1-V1 5-SIGN(K, kanonski zahtjev), gdjeje K privatni RSA kljuc klijenta. Isto kao kod HMAC-SHA1 nacina potpisi-vanja, sazetak dobiven prethodnim pozivom se kodira u bazu 64 prije pos-tavljanja vrijednosti parametra oauth signature. Pri verifikaciji potpisa,posluzitelj poziva RSASSA-PKCS1-V1 5-VERIFY((n,e), kanonski zahtjev,

S), gdje je (n,e) javni RSA kljuc klijenta, a S dekodirana vrijednost para-metra oauth signature. Dijeljene tajne privatnog akreditiva i pristupneznacke se ne koriste.

Kod HMAC-SHA1 nacina potpisivanja zahtjeva, sigurnost ovisi o dijeljenojtajni koja je poznata i klijentu i posluzitelju. I klijent i posluzitelj dijeljenutajnu moraju pohraniti u nekriptiranom obliku kako bi mogli potpisivati od-nosno verificirati zahtjeve pa je potencijalno povecana mogucnost da napadacotkrije dijeljenu tajnu. S druge strane, sigurnost RSA-SHA1 nacina potpisiva-nja zasniva se na asimetricnoj enkripciji pa posluzitelj ne mora znati privatnikljuc klijenta. Ipak, ako napadac uspije doci do privatnog kljuca klijenta,moze nesmetano slati proizvoljne zahtjeve posluzitelju, dok jedna kompromi-tirana dijeljena tajna za HMAC-SHA1 ugrozava samo jednog vlasnika sredstva.

Za PLAINTEXT zahtjeve, vrijednost oauth signature parametra postavljase na prethodno definirani kljuc za HMAC-SHA1 nacin. Specifikacija zahtijevada posluzitelj osigura povjerljivost i integritet poruka koristeci nizi protokol.

2.6 OAuth 1.0a

U travnju 2009. godine, u Twitterovoj implementaciji OAuth protokola ot-kriven je sigurnosni nedostatak, a ubrzo se pokazalo da je nedostatak inhe-rentan OAuth 1.0 specifikaciji [8]. S obzirom na to da u autorizaciji klijentaza pristup zasticenom sredstvu vlasnik sredstva komunicira s dva razlicitaposluzitelja, protokol bi morao osigurati da s oba posluzitelja komunicira istikorisnik, sto OAuth 1.0 specifikacija nije osiguravala.

Taj nedostatak bi napadacu omogucio sljedeci napad. Napadac bi se pred-stavio kao vlasnik sredstva nekoj aplikaciji-klijentu. Klijent bi od posluziteljadohvatio privremeni akreditiv i preusmjerio napadaca na posluzitelj da auto-rizira zahtjev. Tada bi napadac koristeci tehnike drustvenog inzenjeringanaveo zrtvu da se autenticira kod posluzitelja i autorizira zahtjev klijenta.Konacno, napadac bi pristupio i njemu poznatom URL-u na posluzitelju,nakon cega bi klijent zamijenio privremeni akreditiv za pristupnu znacku.Napadac bi dalje mogao upravljati klijentom u koristenju zasticenog sred-stva zrtve.

16

Prikazani napad ima nekoliko vaznih znacajki. Prvo, s obzirom na to dase napad zasniva na drustvenom inzenjeringu gdje napadac navodi zrtvu naautorizaciju zahtjeva klijenta, napadac moze pristupati zasticenom sredstvusamo kroz klijentsku aplikaciju. Napadac moze osmisliti i vlastitu klijentskuaplikaciju i na taj nacin doci do privremenog akreditiva i pristupne znackeza zasticeno sredstvo zrtve, ali je razina pristupa opet ogranicena od straneposluzitelja. Drugo, kako zrtva mora autorizirati zahtjev na posluzitelju,ako posluzitelj pravilno obavjestava korisnike o prirodi klijenta i vrsti pris-tupa koji se autorizira, steta koju napadac moze nanijeti je ogranicena.Konacno, napadac ne moze nikako znati kada je zrtva autorizirala zahtjevna posluzitelju pa mora vise puta pristupati klijentskoj aplikaciji. Klijentna svaki pristup danom URL-u pokusava zamijeniti privremeni akreditiv zapristupnu znacku, a posluzitelj takve visestruke zahtjeve moze odbaciti iliupozoriti zrtvu da nesto nije u redu. Dodatno, kako posluzitelj zrtvu na-kon autorizacije zahtjeva preusmjerava na neku stranicu, zrtva moze uocitida nesto nije u redu i odmah ukinuti pristupnu znacku ako posluzitelj toomogucuje.

Iako je opisani napad relativno ogranicen, specifikacija protokola dopu-njena je u inacicu 1.0a kako bi se nedostatak uklonio. Za sprijecavanje na-pada, dovoljno je onemoguciti pogadanje URL-a na koji posluzitelj preusmje-rava vlasnika sredstva nakon autorizacije zahtjeva. S tim ciljem, posluziteljpo OAuth 1.0a specifikaciji mora URL-u dodati parametar oauth verifier

i osigurati da je vrijednost parametra tesko pogoditi. Klijent dobiveni para-metar prosljeduje posluzitelju u zahtjevu za zamjenu privremenog akreditivapristupnom znackom, a posluzitelj usporeduje dobivenu vrijednost s generi-ranom vrijednosti. Ako se vrijednosti ne poklapaju, zahtjev se odbija.

17

Poglavlje 3

OAuth 2.0

Relativno slozena sigurnosna struktura OAuth 1.0a protokola omogucujesigurno pristupanje zasticenom sredstvu HTTP protokolom, bez dodatnezastite na nizim slojevima. Sigurni kanal koristi se samo za razmjenu di-jeljenih tajni, tj. kljuceva. U tipicnoj primjeni gdje dohvacena pristupnaznacka ima relativno dug vijek trajanja, na primjer godinu dana, samo malidio komunikacije koristi sigurni kanal.

S druge strane, slozenost protokola pokazala se prevelika za mnoge autoreklijentskih aplikacija. Naime, s obzirom na to da specifikacija protokola iz-gleda pristupacno, mnogi autori su se upustili u vlastite implementacije pro-tokola. Kako i najmanja greska u implementaciji klijenta tipicno generiraneispravne potpise, a i originalna specifikacija protokola u nekim detaljimanije bila dovoljno jasna, web-aplikacije koje su rano pocele koristiti OAuthprotokol imale su velik broj nezadovoljnih korisnika.

Kako bi se neki od spomenutih nedostataka ispravili, zapocet je razvojOAuth 2.0 protokola. OAuth 2.0 protokol znatno se razlikuje od OAuth1.0a protokola i s njim nije kompatibilan. U trenutku pisanja ovog rada,specifikacija OAuth 2.0 protokola nalazi se u 20. inacici [9]. S obzirom na toda specifikacija jos nije zavrsena, u nastavku poglavlja je dan samo kratkipregled trenutne inacice i razvoja specifikacije.

3.1 Pregled OAuth 2.0 protokola

U OAuth 2.0 protokolu je uloga posluzitelja podijeljena na dvije logicke uloge:autorizacijski posluzitelj i posluzitelj sredstava. Na taj nacin je jasno odvojen

18

dio protokola kojim vlasnik sredstva autorizira klijenta za pristup zasticenomsredstvu i sam pristup sredstvu.

Ranije spomenuti problem s implementacijom OAuth protokola za kli-jente koji su lokalne aplikacije instalirane na osobnom ili rucnom racunalunije rijesen, ali je u specifikaciji problem mnogo jasnije definiran. Naime,lokalna aplikacija od napadaca u opcenitom slucaju ne moze sakriti svojklijentski akreditiv pa zato posluzitelj ne moze koristiti takav akreditiv zaautentikaciju klijenta. U specifikaciji su definirana dva razreda klijenata:povjerljivi i javni. Povjerljivi klijenti su web-aplikacije, a korisnicki agenti(tipicno web-preglednici) i lokalne aplikacije smatraju se javnim klijentima.Specifikacija ne predvida tocno kako posluzitelj prilikom registracije klijentamoze odrediti kojem razredu klijent pripada, ali kao jednu od mogucnostispominje certifikate.

Osnovni scenarij koristenja OAuth 2.0 protokola konceptualno je slicanOAuth 1.0a protokolu, ali je koristenje MAC kodova za zastitu zahtjeva op-cionalno, a alternativa je mehanizam slican HTTP kolacicima preko HTTPSprotokola. Alternativni mehanizam zasniva se na znackama nositelja (engl.bearer tokens) i definiran je posebnom specifikacijom [10]. Ovaj mehanizamsigurnost zasniva na nizim protokolima i znacke se u zahtjevima prenose unekriptiranom obliku, a dijeljene tajne se u postupku dohvacanja pristupneznacke uopce ne generiraju.

Uz koristenje MAC koda, parametri poruka slicni su OAuth 1.0a proto-kolu. Autorizacijski posluzitelj uz identifikator znacke prilaze i MAC kljuci oznaku algoritma koji se koristi za potpisivanje. Odvojena specifikacijakoja opisuje ovaj nacin osiguravanja komunikacije predvida HMAC-SHA-1 iHMAC-SHA-256 algoritme [11].

3.2 Razvoj OAuth 2.0 specifikacije

Paralelno s razvojem OAuth 2.0 protokola, sigurnosni strucnjaci Microsofta,Googlea i Yahooa razvili su WRAP protokol. WRAP protokol se zasnivaoiskljucivo na znackama nositelja, sto je izazvalo brojne kritike [12]. Naime,iako HTTPS protokol stiti vrijednosti znacki od prisluskivanja, ako napadackrivotvorenjem certifikata uvjeri klijenta da mu posalje zahtjev, moze lakopreuzeti znacku i pristupati zasticenim sredstvima. Eran Hammer-Lahav,urednik specifikacija svih OAuth inacica i jedan od najznacajnijih clanovaOAuth zajednice, ozbiljno je kritizirao preimenovanje WRAP protokola uOAuth-WRAP bez ikakve rasprave na listi OAuth zajednice i okarakterizirao

19

ga kao zlorabljenje OAuth imena [13].

Zbog velikog utjecaja njegovih razvijatelja, WRAP protokol je integri-ran u OAuth 2.0 specifikaciju. Hammer-Lahav je kao urednik specifikacijeizjavio da je tada aktualna inacica protokola stetna za Web [14] i javnose zalozio za ukljucivanje potpisa u specifikaciju, barem kao opciju. Iakoje konacna inacica specifikacije bila najavljena za kraj 2010. godine, zbogkonacnog ukljucenja MAC kodova od inacice 11 je dovrsenje specifikacijeodgodeno, ali, cini se, u interesu sigurnosti Weba.

20

Zakljucak

Usprkos brojnim problemima u razvoju OAuth protokola koji su prikazani uovom radu, danas mnoge znacajne web-aplikacije svoja programska suceljastite OAuth protokolom i omogucuju svojim korisnicima da svoje podatkekoriste u drugim aplikacijama, na siguran nacin. Dodatno, kako je protokoldostupan vec nekoliko godina, za jednostavnije koristenje protokola postojeprogramske biblioteke u svim vaznijim programskim jezicima.

Nazalost, vise aktivnih inacica protokola i opcije unutar iste inacice, po-sebno OAuth 2.0 specifikacije, uzrokovalo je raznolikost implementacija meduweb-aplikacijama. Na primjer, Netflix i Twitter podrzavaju samo inacicu1.0a, Google i 1.0a i eksperimentalno 2.0 sa znackama nositelja, a Facebooksamo inacicu 2.0. Ipak, cini se da ce skorim zavrsetkom OAuth 2.0 specifi-kacije vecina web-aplikacija prijeci na novi protokol.

OAuth protokol predstvalja napredak u sigurnosti Weba i rjesava znacajanproblem. S tim u vidu, cinjenica da specifikacija predvida koristenje MACkodova samo kao opciju i da vecina trenutnih implementacija koristi upravojednostavniju opciju znacki nositelja, cini se kao propustena prilika. Na-ime, po kritikama nekoliko uglednih strucnjaka ukljucujuci i urednika sameOAuth 2.0 specifikacije, moze se zakljuciti da se koristenjem znacki nositeljaostvaruje bitno niza razina sigurnosti, pogotovo u buducnosti. Na primjer,OAuth 2.0 sa znackama nositelja ne moze sigurno podrzati otkrivanje usluga(engl. discovery), cime su manje aplikacije u podredenom polozaju [14].

21

Literatura

[1] J. Attwood. Please give us your email password. http://bit.ly/

bUgPQR, lipanj 2008. Pristupljeno 28. srpnja 2011.

[2] E. Hammer-Lahav. The challenges of using OAuth in de-sktop or iPhone applications. http://hueniverse.com/2009/

02/should-twitter-discontinue-their-basic-auth-api/, veljaca2009. Pristupljeno 28. srpnja 2011.

[3] E. Hammer-Lahav. RFC 5849: The OAuth 1.0 Protocol, travanj 2010.

[4] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Lu-otonen, and L. Stewart. RFC 2617: HTTP Authentication: Basic andDigest Access Authentication, srpanj 1999.

[5] T. Berners-Lee, R. Fielding, and L. Masinter. RFC 3986: UniformResource Identifier (URI): Generic Syntax, sijecanj 2005.

[6] H. Krawczyk, M. Bellare, and R. Canetti. RFC 2104: HMAC: Keyed-Hashing for Message Authentication, veljaca 1997.

[7] J. Jonsson and B. Kaliski. RFC 3447: Public-Key Cryptography Stan-dards (PKCS): RSA Cryptography Specifications Version 2.1, veljaca2003.

[8] M. Kirkpatrick. How the OAuth security battle was won, open webstyle. http://www.readwriteweb.com/archives/how_the_oauth_

security_battle_was_won_open_web_sty.php, travanj 2009. Pristup-ljeno 4. kolovoza 2011.

[9] E. Hammer-Lahav, D. Recordon, and D. Hardt. The OAuth 2.0 autho-rization protocol draft-ietf-oauth-v2-20, srpanj 2011.

[10] M. Jones, D. Hardt, and D. Recordon. The OAuth 2.0 Protocol: BearerTokens, srpanj 2011.

22

[11] E. Hammer-Lahav, A. Barth, and B. Adida. HTTP Authentication:MAC Access Authentication, svibanj 2011.

[12] B. Adida. It’s a WRAP. http://benlog.com/articles/2009/12/22/its-a-wrap/, prosinac 2009. Pristupljeno 5. kolovoza 2011.

[13] E. Hammer-Lahav. WRAP, and the demise of theOAuth community. http://hueniverse.com/2009/11/

wrap-and-the-demise-of-the-oauth-community/, studeni 2009.Pristupljeno 6. kolovoza 2011.

[14] E. Hammer-Lahav. OAuth 2.0 (without signatures) isbad for the Web. http://hueniverse.com/2010/09/

oauth-2-0-without-signatures-is-bad-for-the-web/, rujan2010. Pristupljeno 6. kolovoza 2011.

23