diplomski informatika pervan

8/15/2019 Diplomski Informatika Pervan

http://slidepdf.com/reader/full/diplomski-informatika-pervan 1/45

SVEUČILIŠTE U MOSTARU

FAKULTET PRIRODOSLOVNO – MATEMATIČKIH I ODGOJNIH ZNANOSTI

MATEMATIKA - INFORMATIKA

Marija Pervan

Modeli autentifikacije i autorizacije korisnika

u web aplikacijama

Diplomski rad

Mostar, rujan 2014.



SVEUČILIŠTE U MOSTARU

FAKULTET PRIRODOSLOVNO – MATEMATIČKIH I ODGOJNIH ZNANOSTI

MATEMATIKA - INFORMATIKA

Modeli autentifikacije i autorizacije korisnika

u web aplikacijama

Diplomski rad

Mentor: Student:

Doc.dr.sc. Goran Kraljević Marija Pervan

Mostar, rujan 2014.



SADRŽAJ:

SAŽETAK ............................................................................................................................ 1

1.

UVOD ............................................................................................................................ 2

2. AUTENTIFIKACIJA .................................................................................................. 4

2.1. Brute Force napadi ............................................................................................................. 4

2.1.1. Napad rječnikom ........................................................................................................ 7

2.1.2. Proboji kriptografskih algoritama ............................................................................. 8

2.1.3. Detekcija i zaštita od Brute Force napada ............................................................... 10

2.2. Nedovoljna razina autentifikacije ..................................................................................... 12

2.3. Nedovoljna zaštita korisnikove lozinke ........................................................................... 13

3. AUTORIZACIJA ....................................................................................................... 15

3.1. NagaĎanje vjerodajnog identifikacijskog broja ................................................................ 15

3.2. Nedovoljna autorizacija .................................................................................................... 17

3.3. Nedovoljna kontrola trajanja korištenja usluge ................................................................ 18

3.4. Fiksacija usluge ................................................................................................................ 19

4. PRIMJER WEB APLIKACIJE ................................................................................ 21

5. SSO (SINGLE-SIGN-ON) ......................................................................................... 28

5.1. Zahtjevi pred SSO ............................................................................................................ 28

5.2. Djelovanje SSO-a ............................................................................................................ 29

5.3.

Sigurnost i SSO ................................................................................................................ 32

5.4. Sinkronizacija lozinki ....................................................................................................... 32

5.5. Automatizirana prijava ..................................................................................................... 33

5.6. Autentifikacija temeljena na oznakama ........................................................................... 33

5.7. SSO i Web ....................................................................................................................... 34

5.8. Središnji autentifikacijski sustav za Web (CAS) ............................................................. 36

5.8.1. CAS djelovanje ......................................................................................................... 37

5.9. Povezani pristup u SSO-u ................................................................................................ 38

5.9.1. SAML i Web Single Sign On ..................................................................................... 38

5.10.

Autorizacija temeljena na atributima ........................................................................... 39

6. ZAKLJUČAK ............................................................................................................. 40

7. LITERATURA ........................................................................................................... 42



1

SAŽETAK

Napadi na proces autentifikacije korisnika su Brute Force napadi, nedovoljna razina

autentifikacije i nedovoljna zaštita korisnikove lozinke. Brute Force napadi se odnose na

metode pokušaja i pogrešaka, a nedovoljna razina autentifikacije omogućuje napadaču

pristup podacima bez da se propisno autenficirao. Nedovoljna zaštita lozinke dovodi do

lažnog prijavljivanja na sustav. Može se dogoditi putem tajnog pitanja ili druge metode

uključene u slučaju zaboravljanja lozinke.

Napadi na autorizaciju su: pogaĎanje vjerodajnog identifikacijskog broja, nedovoljna

autorizacija, nedovoljna kontrola trajanja korištenja usluge i fiksacija usluge. PogaĎanje

vjerodajnog identifikacijskog broja je važno jer taj broj ( Session ID) dovodi korisnika do

odreĎenih podataka i sadržaja. Nedovoljnom autorizacijom korisniku se dodjeljuju uloge

za koje nije ovlašten, a ne kontrolom trajanja korištenja usluge dolazi do zloupotrebe

korisničkog računa ukoliko se korisnik propisno ne odjavi i na njegovo mjesto doĎe druga

osoba. Fiksacija usluge podrazumjeva fiksiranje Session ID-a na eksplicitnu vrijednost

kako napadač ne bi mogao razviti tehniku za pogaĎanje sljedećeg Session ID-a. SSO

(Single-Sign-On) služi za autentifikaciju i autorizaciju korisnika putem jednostruke

prijave.



2

1. UVOD

Web aplikacije su programska rješenja kojima možemo pristupiti koristeći internet preglednike preko interneta ili intraneta.1 Vrtoglavi rast i razvoj treba zahvaliti tome da su

dostupne u bilo koje doba i s bilo kojeg mjesta. Osim toga web programe nije potrebno s

vremenom nadograĎivati na svakom računalu, jer im se pristupa isto kao i ostalim web

stranicama, putem internet browsera.

Arhitektura Web aplikacija se sastoji od tri sloja, tzv. troslojna arhitektura. U nju su

uključeni: prezentacijski slo j (prikaz informacija korisniku putem preglednika),

aplikacijski sloj (upravljanje aktivnostima koje aplikacija treba izvršiti), podaktovni sloj

(upravljanje pohranjivanjem podataka u bazu i prikazom podataka iz baze poslužitelju).

Prednost Web aplikacija je i u tome što rade bez obzira na operacijski sustav računala s

kojeg joj se pristupa, a jedan od nedostataka je problem sa sigurnošću (zaštita protiv upada,

virusa i sl.). Upravo taj problem jedan je od najvažnijih elemenata kojim se svaki

administrator treba baviti. Naime, Web aplikacije koje omogućuju svojim korisnicima

prijavu na sustav putem odreĎenih podataka dužne su voditi računa o zaštiti kako svojihkorisnika tako i zaštiti same aplikacije. Prilikom prijave na sustav, korisnik unosi odreĎene

informacije na samu aplikaciju i aplikacija izvršava provjeru identiteta korisnika koji je

pristupio. Nakon uspješne prijave na aplikaciji se odvija proces koji utvrĎiva koja prava i

privilegije taj korisnik dobiva. Naime, različiti korisnici imaju različite prikaze. Npr.

administrator će dobiti mnogo više mogućnosti za rad na aplikaciji od „običnog korisnika“.

Postupak identificiranja korisnika naziva se proces autentifikacije, dok se proces dodjele

uloga, prava i privilegija nakon autentifikacije naziva autorizacija korisnika. Upravo

napadi na autentifikaciju i autorizaciju korisnika, jedan su od najčešćih napada s kojim se

možemo susresti na Web-u. Budući da često možemo naići na aplikacije koje stavljaju

funkcionalnost ispred sigurnosti, povećana je i mogućnost potencijalnog ulaza

zlonamjernim napadačima.

1

Internet: javna mreža temeljena na TCP/IP protokolu. Intranet: privatna mreža neke tvrtke ili institucije kojom se podaci takoĎer prenose preko TCP/IPI protokola.(zaštićen pristup samo korisnicima unutar tvrtke)



3

Osim kraĎe identifikacijskih podataka korisnika, neovlašteni pristup Web aplikacijama

može imati i mnoge druge posljedice. Pristup osjetljivim sadržajima kao i njihovo

mjenjanje dovodi do promjene rada same aplikacije, a sadržaji unutar nje mogu ugroziti i

administratore i aplikaciju i korisnike.



4

2. AUTENTIFIKACIJA

2.1.

Brute Force napadi

Brute Force je metoda pokušaja i pogrešaka koja se koristi za dobivanje informacija kao

što su korisničke lozinke, neki identifikacijski brojevi, brojevi kreditnih kartica itd. Koristi

automatizirani softver koji generira velik broj podataka i provjerava da li neki od tih

podataka odgovara odreĎenoj traženoj informaciji. Ova vrsta napada može biti korištena od

strane kriminalaca za razbijanje šifri ili od strane sigurnosnih analitičara za testiranje

sigurnosti.

Budući da danas mnogi sustavi omogućuju korisnicima korištenje kratkih lozinki i

jednostavnih kriptografskih ključeva brute force je vrlo česta i uspješna metoda iako

vrijeme napada može varirati od nekoliko minuta do nekoliko godina. Zbog toga zahtjeva

ili velike resurse za isprobavanje svih različitih kombinacija ili veliku količinu vremena

dovoljnu da se s malim resursima izvede isprobavanje svih kombinacija. U stvarnoj

primjeni to znači da je cijena resursa potrebnih za rješavanje nekog problema ovom

metodom često veća nego što vrijedi samo rješenje.

Brute Force napad isprobava sva moguća rješenja bez obzira na nelogičnost neke od njih.

Stoga ih ne treba mijenjati sa nekim sličnim metodama koje odreĎenim načinima

reduciraju broj mogućih rješenja za isprobavanje. Ukoliko korisnik za lozinku odabere

riječ jednostavnu za zapamtiti i koju je lako naći u rječniku, napadač može odabirom riječi

iz rječnika stvoriti na tisuće netočnih upita. Metoda će biti uspješna kada se pronaĎe

lozinka odreĎenog korisnika i pristupi njegovom korisničkom računu. 2

Primjer Brute force alata je Hydra, paralizirajući Web-cracker. Hydra posjeduje rječnik u

kojeg se mogu upisati riječi koje se najčešće koriste od strane korisnika, npr. Auta, Brzina,

Motori itd. Nakon što se odredi sadržaj rječnika, Hydra-i se zadaje put do tražene

aplikacije, te započinje izvoĎenje Brute force napada za traženo korisničko ime.

Uspješnost napada ovisi o veličini i sadržaju rječnika.

2 Brute Force napadi ( Carnet Cert i LS&S, CCERT-PUBDOC-2007-08-201)



5

Postoje dvije vrste brute force napada:

Normalni ( uobičajeni)

Reverzni

Normalni brute force napad koristi jedno korisničko ime i veliki skup lozinki, dok reverzni

brute force napad koristi velik broj korisničkih imena i samo jednu lozinku.

R everzni napad se koristi u sustavima koji imaju jako velik broj korisnika i šansa da dvije

osobe imaju istu lozinku je vrlo velika.

Brute force napad je jednostavan za implementaciju i sastoji se od četiri osnovne

procedure:

1. prvi(P) – generiraj prvi kandidat k za problem P.

2. slijedeći(P, k) – generiraj slijedeći kandidat k za problem P nakon trenutnog

kandidata k.

3. važeći(P, k) – pr ovjeri je li kandidat k važeće rješenje problema P.

4. izlaz(P, k) – upotrijebi rješenje k za problem P kao prikladno rješenje za aplikaciju.

Procedura slijedeći(P, k) trebala bi takoĎer detektirati situacije kad se iscrpe svi kandidati ikao rezultat poslati neku vrijednost (npr. null) koja bi omogućila prekid daljnjeg izvoĎenja

algoritma. Jednako bi tako procedura prvi(P) trebala vratiti null vrijednost ako ne postoji

nijedan kandidat za rješenje problema. Algoritam se tako može prikazati slijedećim

pseudokodom:

prvi (P)

dok je k različito od null radi

ako je važeći (P, k) tada izlaz (P, k)

inače slijedeći (P, k)

Na primjer , ukoliko želimo naći djelitelja nekog broja n, P poprima vrijednost broja n.

Procedura prvi(P) vraća prvi važeći kandidat k , a to je broj 1 ako broj 1 nije veći od n ili

null ako je odabrani broj n = 1. Procedura slijedeći(P, k) vraća prvi slijedeći kandidat koji

ima vrijednost k + 1 ako je k + 1 < n ili null ako je k + 1 > n. Procedura važeći(P, k) vratit

će vrijednost ISTINA samo ako je k djelitelj broja n.



6

TakoĎer, algoritam možemo pojednostaviti ako se umjesto null koristimo vrijednost n+1.

Brute force algoritam će pozivati proceduru izlaz za svaki generirani kandidat, ali ga se

može lako modificirati da prestane s izvoĎenjem nakon što pronaĎe prvo rješenje ili

odreĎen broj rješenja. Moguće ga je modificirati tako da prestane s izvoĎenjem nakon

odreĎenog broja kandidata ili nakon što je izvoĎenjem potrošena odreĎena količina

procesorskog vremena.

Glavni nedostatak brute force metode je postojanje izrazito velikog broja mogućih

kandidata za veliku većinu stvarnih problema. Na primjer, ako ovim algoritmom tražimo

djelitelje broja n, algoritam će isprobati n kandidata. Ako je n šesnaesteroznamenkasti broj

isprobavanje zahtijeva izvršavanje najmanje 1015 instrukcija što bi na uobičajenom

računalu potrajalo nekoliko dana. Ako je n neki 64-bitni broj koji u prosjeku ima 19

decimalnih znamenki isprobavanje ovim algoritmom ispitivanje bi potrajalo oko 10

godina. Ovaj nagli porast br oja kandidata s porastom veličine podataka se pojavljuje

prilikom rješavanja svih vrsta problema. Na primjer, ako se traži odreĎeni raspored 10

slova tada postoji 10! = 3,628,800 mogućih kandidata koje će tipično računalo isprobati

unutar jedne sekunde. MeĎutim ako dodamo još jedno slovo, što predstavlja samo 10%-no

povećanje veličine podataka, broj kandidata povećava se 11 puta ili 1000 %. Za 20 slova

broj kandidata iznosi 2,4 x 1018 i isprobavanje svih njih potrajalo bi oko 10,000 godina.

Ovaj fenomen drastičnog porasta broja mogućih kombinacija naziva se još i kombinatorna

eksplozija i glavni je razlog zbog kojeg je nužno optimizirati brute force metodu da bi ona

bila primjenjiva.

Budući da je glavni problem brute force metode prevelik broj mogućih kandidata pa je

prva logična optimizacija ona kojom se pokušava smanjiti broj kandidata korištenjem

heuristike ili mehanizama učenja. Na primjer ako pogledamo prije spomenuti problem s 8kraljica koji ima 178,462,987,637,760 mogućih rješenja. Ako uzmemo u obzir činjenicu da

su sve kraljice identične i da dvije kraljice ne mogu biti postavljene na isto polje proizlazi

da su mogući kandidati sve kombinacije 8 polja na ploči od 64 polja ili ukupno 64! / 56! /

8! = 4,426,165,368 mogućih kandidata. Daljnjom upotrebom logike može se zaključiti da

nijedna kombinacija u kojoj se dvije kraljice nalaze u istom redu ili stupcu na ploči ne

može biti rješenje. To znači da je broj kandidata reduciran na sve kombinacije u kojima se

svaka kraljica nalazi u svom retku i u bilo kojem stupcu. Takve kombinacije mogu se

opisati poljem od 8 brojeva čije vrijednosti mogu biti u ras ponu od 1 do 8 gdje vrijednost



7

broja predstavlja stupac, a redni broj člana polja redak u kojem se kraljica nalazi. Iz toga je

vidljivo da je broj mogućih kandidata jednak broju svih permutacija vrijednosti članova

polja ili brojkom 8! = 40,320 mogućih kandidata, tj. 1/100,000 izvornog broja mogućih

kandidata. Iz ovog je vidljivo da se čak i jednostavnom analizom može drastično smanjiti

broj mogućih kandidata i pretvoriti kompleksan problem u znatno jednostavniji.

TakoĎer , vidljivo je da procedure za odabir kandidata (prvi i slijedeći) čak i za ovakav

reducirani skup kandidata nisu složene, nego mogu biti i jednostavnije od izvornih. 3

2.1.1. Napad rječnikom

Napad rječnikom (eng. dictionary attack) je ciljana tehnika za probijanje šifri ili

mehanizam provjere autentičnosti kod koje se pokušava pronaći tražena zaporka ili tajni

ključ uzastopnim isprobavanjem velikog broja riječi ili kombinacija tih riječi.

Koristi stotine ili ponekad tisuće vjerojatnih mogućnosti iz sustava koji je prethodno

pripremljen i kojeg nazivamo rječnikom. Varijacija je brute force napada kod koje je izbor

mogućih kandidata sužen sa skupa svih mogućih kombinacija slova na one kombinacije

koje imaju neko značenje na odreĎenom jeziku. Veća je vjerojatnost da će osoba za

zaporku ili ključ uzeti neki skup slova koji ima značenje, nego neki niz znakova koji

korisniku ništa ne znači i zato mu je teško pamtljiv.

Moguća su dva načina provoĎenja napada: offline i online. Offline metoda testira riječi

pohranjene u rječniku, koje prethodno propusti kroz osnovne funkcije šifriranja, te

dobivene hash vrijednosti usporeĎuje s poznatom hash vrijednošću nepoznate lozinke.Online napad koristi riječi iz rječnika za prijavu na željeni sustav pri čemu je potrebno

poznavati korisničko ime.

Riječi za ovaj napad se uzimaju iz rječnika koji su dostupni na Internetu i ne predstavljaju

potpun rječnik odreĎenog jezika već uključuju veći ili manji skup najvjerojatnijih riječi, tj.

riječi koje se najčešće koriste u zaporkama.

3 Brute Force napadi ( Carnet Cert i LS&S, CCERT-PUBDOC-2007-08-201)



9

Važno je da se algoritmi dizajniraju na način da otežaju proboj brute force metodom,

odnosno oblik bi trebao biti takav da je potrebno mnogo vremena i resursa da bi se došlo

od njega.

Postavlja se i pitanje dužine ključeva koji mogu zaštiti proboj. Krajem 90-ih godina EFF

grupa je probila DES algoritam koj koristi 56- bitni ključ. Vrlo lako se moglo zaključiti da

će neka uspješnija i profitabilnija institucija zbog veće dostupnosti sredstava uspjeti

ponoviti taj napad. Preporuka stručnjaka je bila korištenje sigurnijeg algoritma i minimalno

128- bitnog ključa. Uz efektivnu dužinu ključa vrijeme potrebno za napad se jako puno

smanjuje.

Kada se govori o asimetričnim algoritmima, sve ovisi upravo o algoritmu o kojem se radi.Sadašnja preporuka je korištenje ključeva koji imaju dužinu 128 bita za eliptične algoritme

i 1024 bita za RSA algoritme. Budući da mnogi algoritmi koriste složene matematičke

probleme, preporuča se uvijek upotreba dužih ključeva. Naime, uvijek je moguće u

izračunu pronaći neke prečice.

Dakle, općenito se smatra da je 128- bitni ključ dovoljno siguran od brute force napada kod

simetričnih algoritama. Vrijeme potrebno da se doĎe do ključa postavlja pitanje o

smislenosti takvog pokušaja. Ponekad izvorni tekst nije poznat,a treba provjerti smislenost

dobivenog rješenja. Tada se to rješenje usporeĎiva s riječima iz riječnika. Stoga, ukoliko

napadač i uspije dešifrirati tekst, rješenje neće biti nešto što nije smisleno, pa ga i neće

prepoznati. 4

4 Sigurnost Web aplikacija (Mario Kozina, Sveučilište u Zagrebu, Zagreb, 2006.g.)



10

2.1.3. Detekcija i zaštita od Brute Force napada

Brute For ce napadi se najčešće provode sljedećim načinima:

1) pokušajima pogaĎanja korisničkih imena i lozinki unoseći podatke ručno

2) upotrebom posebno oblikovanih rječnika koji unose različite podatke crpeći ih iz

vlastite baze

3) kreiranje različitih korisničkih računa sa različitim korisničkim imenima i

lozinkama pomoću kojih se sustavu pristupa zlonamjerno

Mnogi sustavi imaju mogućnost zapisa svih pokušaja prijavljivanja. Za to služe dnevnički

zapisi računala. Upravo ti zapisi mogu pomoći u otkrivanju pokušaja napada brute force

metodom. Naime, ukoliko je došlo do takvog napada, u dnevniku će biti zabilježen svaki

pokušaj i ako ih ima više nego je uobičajeno velika je vjerojatnost da je na snazi upravo ta

tehnika napada.

Pregledom dnevnika potrebno je tražiti zapise slične ovom:

Apr 11 19:02:10 fox proftpd[6950]: poslužitelj

(usersip[usersip]) - USER korisničkoime (Login failed):

Incorrect password.

Postoji i nekoliko osnovnih metoda zaštite od ovakvih napada. One uključuju slijedeće

korake:

• ograničenje broja neuspješnih pokušaja pristupa sustavu,

• zabranu pristupa s IP adrese s koje su došli neuspjeli pokušaji pristupa,

• redovito traženje zapisa o neuspješnim pokušajima pristupa u dnevničkim zapisima,

• zatvaranje korisničkih računa za tzv. "gost" korisnike jer će oni biti prva točka upada za

potencijalne napadače te

• kreiranje samo jednog korisničkog računa s najvišim ovlastima.



12

MeĎu podacima o davatelju usluge Internet pristupa obično se nalaze i kontakt podaci

odgovorne osobe kojoj se može poslati poruka o počinjenom brute force napadu. U poruku

je dobro uključiti dijelove dnevničkog zapisa koji evidentiraju napad te podatke o IP adresi

s koje je napad došao i vremenu napada .

Osim izravno na poslužitelje brute force napadi mogu se usmjeriti i na web aplikacije. One

su obično zaštićene na dva načina:

• standardnom HTTP autentikacijom - u slučaju Windows web poslužitelja ona je vezana

uz SAM (eng. Security Account Database) bazu podataka u kojoj se nalaze podaci o

korisničkim računima, te

• autentifikacijom putem web forme - nešto je složenija jer zahtijeva razvijanje zasebne

web stranice koja služi za autentifikaciju kao i baze podataka u kojoj će se nalaziti

autentifikacijski podaci. 5

2.2. Nedovoljna razina autenti fi kacije

Nedovoljna razina autentifikacije nastupa kada Web aplikacija omogućava potencijalnom

napadaču pristup osjetljivom sadržaju ili funkcionalnosti, a da se pritom napadač nije

propisno autentificirao. Ograničavanje pristupa osjetljivom sadržaju je uobičajeno za

većinu Web aplikacija, dok je pristup funkcionalnosti uobičajan uglavnom za

administratorske Web alate. Kako bi se Web aplikacija zaštitila procesom autentifikacije,

njeni resursi se najčešće štite skrivanjem lokacija, odnosno puta do njih (URL).

Iako potencijalni napadač ne zna o kojima se točno resursima radi, on im može direktno

pristupiti korištenjem URL-a. OdreĎeni URL se može otkriti korištenjem Brute Force alata

kojima se pronalaze lokacije mapa i datoteka, poruka s greškama i administratorskih zapisa

(engl. logs). Ove resurse je potrebno dodatno zaštititi dozvolama ili drugim metodama,

kako se ne bi zloupotrijebili.

5 Simson Garfinkel:Web Security & Commerce, O'Reilly, 1997.

Brute Force napadi ( Carnet Cert i LS&S, CCERT-PUBDOC-2007-08-201)



14

Primjeri napada:

● Napadač pošalje zahtjev s odreĎenim korisničkim imenom procesu za obnovu lozinke.

Proces odgovori na njegov zahtjev s “tajnim pitanjem” tipa “U kojem mjestu si roĎen?”. Ukoliko napadač posjeduje brute force alat u čijem se rječniku zapisani svi gradovi u

Hrvatskoj, postoji velika mogućnost da će ponuditi točan odgovor, odnosno prevariti

proces za obnovu i saznati korisnikovu lozinku.

● Korisnik koristi trik kako bi upamtio svoju lozinku tipa “Ime+datum roĎenja”. Ukoliko

napadač sazna o kojem se triku radi (trik je najčešće dostupan) može značajno smanjiti

područje pretrage, odnosno smanjiti broj zapisa u rječniku brute force alata i povećati

mogućnost uspješnog napada.7




15

3. AUTORIZACIJA

Autorizaciju možemo definirati kao dodjelu uloga po nekim odreĎenim pravilima. Ako

promatramo sa strane We b aplikacija, ona je postupak koji služi za odreĎivanje

korisnikovih prava i privilegija. Naime, korisniku se na temelju njegovog identiteta

dodjeljuju odreĎene ovlasti i pristup pojedinim sadržajima. Većina Web aplikacija

postavlja ograničenja da bi zaštitila odreĎene elemente i sadržaje. Stoga, ukoliko korisnik

želi pristupiti tim sadržajima, mora imati već dodjeljena dopuštenja Postoje mnogobrojne

tehnike i metode kojima napadači zaobilaze ta dupuštenja i na taj način dolaze do resursa

za koje nisu ovlašteni. Tu se otvara velika mogućnost nanošenja štete samoj aplikaciji jer

se na raspolaganju daju povjerljivi i „osjetljivi “ sadržaji.8

3.1. Nagađanje vjerodajnog identifikacijskog broja

Mnoge Web aplikacije su dizajnirane tako da se provodi autentifikacija korisnika i

praćenje rada korisnika nakon uspostave veze. Da bi se to ostvarilo, korisnici moraju

dokazati svoj identitet Web aplikaciji, i to najčešće upisivanjem vlastitog korisničkog

imena i lozinke. Prilikom posjete Web stranici korisnik je poslužitelju prikazan kao da prvi

put pristupa aplikaciji bez obzira koliko je puta ranije bio na toj stranici. Razlog toga je

korištenje HTTP protokola za izmjenu informacija. Budući da HTTP protokol spada u

grupu protokola bez stanja, poslužitelj će zaboraviti sve o korisniku nakon svakog

njegovog zahtjeva, osim ako na neki način ne označi samog korisnika. Označavanje je potrebno ako želimo informacije o korisniku koji je trenutno na stranici iskoristiti za svaki

njegov sljedeći posjet toj stranici. Za označavanje se koristi vjerodajni identifikacijski broj.

Zove se još i Session ID i dodjeljivanjem korisniku omogućuje korisniku odreĎena stalna

prava. Session ID služi i da se spriječi unošenje povjerljvih korisničkih podataka tokom

svake sjednice prilikom autentifikacije. Zbog toga on mora biti jedinstven.

8 ]http://en.wikibooks.org/wiki/Fundamentals_of_Information_Systems_Security/Access_Control_Systems

http://en.wikibooks.org/wiki/Fundamentals_of_Information_Systems_Security/Access_Control_Systems






16

U današnjim Web preglednicima, tehnološki sinonim za Session ID je kolačić (eng.

Cookie). Cookie se dodjeljuje od strane Web aplikacije u obliku znakovnog niza koji se

čuva u memoriji Web preglednika.

Za cookie je postavljeno odreĎeno vrijeme za koje neki odreĎeni korisnik može koristiti

usluge Web aplikacije, a da se pred korisnika ne postavi zahtjev za ponovnom

idenitifikacijom kako bi se cookie obnovio.

Budući da je upravo Session ID odnosno cookie taj koji omogućava korištenje usluga Web

aplikacije, on je i česta meta napada. Jer, pogaĎanjem tog vjerodajnog identifikacijskog

broja omogućava se kraĎa identiteta drugog korisnika. Ako je napadač sposoban

pretpostaviti ili naslutiti Session ID odreĎenog korisnika, tada je moguća zloupotrebakorisničkih privilegija i povreda autorizacije. Saznanjem tog broja napadač može iskoristiti

korisnikove privilegije za kompromitirajuće radnje.

Za primjer ove vrste napada možemo uzeti Web aplikacije koje generiraju Session ID tako

što koriste jednostavne i predvidljive algoritme. Napad je još češći kod situacija gdje se

trenutni Session ID generira oslanjajući se na prethodno generirani Session ID. Session ID

se pohranjuje unutar Cookie-a ili URL-a, a takoĎer ga je moguće pohr aniti i unutar

skrivenog polja ( eng. Hidden form.) . Ukoliko napada odredi algoritam pomoću kojeg se

generira Session ID, tada se napad može izvesti na sljedeći način:

1) Napadač pristupa Web aplikaciji kako bi dobio trenutni Session ID. Web aplikacija

mu vraća Session ID s nekom vrijednošće, npr. 1500.

2) Pošto napadač zna da se radi o algoritmu za generiranjem Session ID-a koji je

oslonjen na prethodni Session ID, može jednostavno izračunati vrijednost sljedećeg

Session ID-a (npr. 1501)

3) Napadač mjenja vrijednost Session ID-a unutar Cookie-a ili URL-a na vrijednost

1501 i šalje zahtjev Web aplikaciji sve dok se ne prijavi sljedeći korisnik. Nakon

što se korisnik prijavi, napadač može koristiti njegove privilegije koristeći

izračunati Session ID.9




17

Slika 1. Primjer baziran na Session ID-u

3.2. Nedovoljna autor izacija

Svaka Web aplikacija mora voditi računa o što većoj razini sigurnosti svojih sadržaja. Ti

sadržaji su najčešće od velike važnosti za Web stranicu jer sadrže podatke koje služe

administratorima za kontrolu i voĎenje aplikacije. Ukoliko Web aplikacija posjeduje

mogućnost registracije korisnika, dodjeljuje im odreĎena prava na odreĎene sadržaje , Tj.

vrši autorizaciju svojih korisnika. Autorizacijska prava se dodjeljuju poslije procesa

autentifikacije i ureĎena su sigurnosnom politikom jer sama prijava ne znači da svaki

korisnik ima pristup svakom sadržaju.10 Ukoliko sigurnosni sustav nije dovoljno dobro

ur eĎen napadaču se može omogućiti pristup „osjetljivom sadržaju“. Pod njima se

podrazumjevaju sadržaji i resursi namjenjeni isključivo administratorima i služe za

kontrolu i voĎenje Web aplikacije. Te funkcionalnosti treba dodatno zaštititi jer njihovoneprikladno korištenje može dovesti do povrede prava ostalih korisnika i uništiti ugled

Web stranice.

Primjer nedovoljne autorizacije su aplikacije koje su administratorske podatke skrivali u

mapama s nazivima /admin/ ili /logs/ , kojima je mogao pristupiti bilo koji autentificirani

korisnik i poduzeti neželjene radnje kao što su rekonfiguracija poslužitelja itd.




19

3.4. F iksacij a usluge

Vjerodajni identifikacijski brojevi se jedinstveno ( Session ID) korisniku dodjeljuju pri

svakoj posjeti Web aplikacije i trajno se čuvaju kako se prethodni Session ID ne bi

koristio za lažnu autorizaciju. Ukoliko bi se korisniku dodjeljivao Session ID kojeg može

koristiti pri ulasku u Web aplikaciju, a kojeg napadač poznaje, tada mi mogao jednostavno

otkiriti korisnikovo korisničko ime i lozinku i na taj način koristiti iste usluge i prava kao

on.

Upravo zbog takve mogućnosti, postoji mnoštvo napadačkih tehnika pomoću kojih se

Session ID može fiksirati na neku eksplicitnu vrijednost. Naime, fiksacijom usluge

napadač podvaljuje korisniku fiksni vjerodajni identifikacijski broj, koji napadač kasnije

koristi za autorizaciju.

Najčešće tehnike su Cross-site scripting napadi i posebno prilagoĎeni HTTP zahtjevi.

Princip ove tehnike je sljedeći: Nakon što napadač postavi Session ID na neku fiksnu

vrijednost, korisnik se prijavi na tu predefiniranu sjednicu s podvaljenim Session ID-om,

zatim napadač upotrebljava taj Session ID i pridobiva korisnikov identitet i koristi njegove

privilegije. Ukoliko nema stalne i aktivne borbe protiv fiksacije usluge, napad se može

izvršiti nad bilo kojom Web aplikacijom koja koristi Session ID za identifikaciju

korisnika. Za Session ID koriste Cookie, URL i skrivena polja. Najčešća metoda je

korištenje Cookie-a i te Web aplikacije su najviše podložne napadima.

Za uobičajenu fiksaciju usluge vrijede sljedeće faze:

1. Postavljanje Session ID-a

Napadač postavlja klopku za odreĎenu Web aplikaciju koja služi da bi se pridobio

njen Session ID, ili se postavlja neki vlastiti skrojeni Session ID.

2. Fiksacija usluge

Postavljena klopka ili vlastiti skrojeni Session ID se predstavlja odreĎenom

korisniku i uvjerava ga se da ta usluga potječe od same Web aplikacije.



20

3. Ulazak i korištenje usluge

Čeka se na korisnikovo ulogiranje na traženu Web aplikaciju. Kada korisnik izvrsi

logiranje, tada napadač posjeduje Session ID i njime preuzima korisnička prava i

identitet.11




21

4. PRIMJER WEB APLIKACIJE

Za primjer je uzeta stranica napravljena za iznajmljivanje apartmana. Bit će prikazani i

objašnjeni pojedini elementi ovog diplomskog rada uz pojašnjene načine zaštite od napada

na autentifikaciju i autorizaciju korisnika.

Prilikom posjete stranici korisnik ima mogućnost pregledati općenite informacije o

hrvatskoj kao turističkoj zemlji, razne korisne linkove, ponuĎene apartmane za

iznajmljivanje kao i cijene i karakteristike svakog apartmana rasporeĎenih po regijama i

mjestima. (slika 2.) Najam željenog apartmana može samo registrirani korisnik te sekorisniku nudi i opcija registracije, a ukoliko je već registrirani član, ima opciju prijave na

stranicu. (slika 2).

Slika 2. Početna stranica aplikacije

Kada se korisnik želi registrirati klikne na opciju registracije i u ponuĎena polja unosi

potrebne podatke. Nakon unosa traženih podataka klikom na opciju prijava završava

postupak registracije.

TakoĎer, za registrirane korisnike za opciju logiranja potrebno je popuniti polja koja traže

korisničko ime i lozinku. (slika 3. i slika 4. )



22

Slika 3. Registracija korisnika Slika 4. Autentifikacija korisnika

Prilikom registr acije, ukoliko korisnik ne ispuni sva ponuĎena polja, otvara se prozor koji

ga upozorava na prazno polje te se time ograničava slanje nepotpunih podataka:

Slika 5. Poruka o greški prilikom autentifikacije

Ova postavka omogućuje administratoru posjedovanje svih potrebnih podataka o svakomkorisniku aplikacije i osigurava lakšu organizaciju i pretragu baze podataka.

To se postiže upotrebom Java Script forme:



23

Slika 6. Primjer JavaScript forme za provjeru korisničkih podataka

Primjer Brute-Force napada je generiranje rječnika koji će sadržavati ženska hrvatska

imena. Naime, u aplikaciji se dozvoljava odabir lozinke koja je jednaka korisničkom

imenu. U praksi se često dogaĎa da korisnici za korisnička imena biraju upravo vlastita

imena, te radi lakšeg pamćenja ista postavljaju kao lozinku za prijavu na aplikaciju.

Upravo se tu krije mogućnost napada, odnosno ne ovlaštenog pristupa tuĎim profilima.

(slika 7.)

Slika 7. Primjer uspješne pr ijave u aplikaciju



24

Nedovoljna razina autentifikacije se može očitovati u pristupu sadržajima za koje ovlasti

ima samo administrator, odnosno, korisnik sa razinom pristupa 2.

Ako napadač bez logiranja, odnosno bez propisne autentifikacije napiše URL adresuhttp://localhost/apartmani/mjesto.php, dobiva pristup popisu svih mjesta u kojima se nalaze

ponuĎeni apartmani.

TakoĎer se isto dogaĎa unošenjem adrese http://localhost/apartmani/regija.php što dovodi

do popisa svih regija kojima pripadaju ta mjesta.

Slika 8. Primjer nedozvoljenog pristupa podacima

Iako pristup navedenim sadržajima može ugroziti aplikaciju, daleko veća šteta se može

načiniti pristupom spisku svih korisnika. Narušava se privatnost i povjerenje čime se

dovodi u pitanje daljnja posjeta i korištenje aplikacije.

Kao i kod spomenutog napada na popise mjesta i regija, popisu korisnika se pristupa URL

adresom http://localhost/apartmani/korisnik.php .

Slika 9. Primjer nedozvoljenog pristupa podacima o korisnicima aplikacije

http://localhost/apartmani/korisnik.php






25

Prilikom logiranja korisnik unosi korisničko ime i lozinku. Ukoliko napadač poznaje

korisnikovu lozinku može obaviti lažno autentificiranje, odnosno izvršiti kraĎu identiteta.

Vrlo je čest već spomenuti Brute-Force napad, stoga je administratorova obaveza voditiračuna o pravilnom kreiranju lozinke prilik om registracije na aplikaciju.

Kada korisnik unosi podatke za registraciju, provjerava se unos lozinke, tj. provjerava se

njena dužina. Ne dozvoljava se kreiran je lozinke koja ima manje od 6 znakova.

TakoĎer, da bi se smanjio broj nevažećih korisničkih računa, provjerava se i is pravnost

unosa e-mail adrese. (slika 10.)

Slika 10. Primjer programskog koda za provjeru korisničke lozinke

Da bi mjere zaštite bile veće potrebno je postaviti tzv. „mjerač jačine lozinke“ koji bi

upozoravao da se za lozinku odabire neki niz slova, znakova i brojeva kombinirano. Na

stranici je potrebno dodati i opciju mjenjanja lozinke za neregistrirane članove.

TakoĎer, zbog mogućnosti zaboravljanja lozinke, uz inpute za logiranje treba postaviti

opcije slanja lozinke na unešenu e-mail adresu ili opciju sigurnog pitanja.



26

Primjer o nedovoljnoj zaštiti lozinke je i već spomenuti Brute Force napad preko rječnika

osobnih hrvatskih imena.

Nedovoljna autorizacija podrazumijeva neovlašteno dodjeljivanje uloga korisnicima kojitime dobivaju pristup sadržajima i omogućuju im se odreĎene radnje nad tim sadržajima.

Naime, na stranici su dodjeljene tri uloge:

1) neregistrirani korisnik,

2) registrirani korisnik

3)

administrator.

Neregistrirani korisnik ima mogućnost pregleda početne stranice i popratnih sadržaja na

njoj što se vidi na slici 1.

Registrirani korisnik ima još mogućnost objave novog oglasa i rezervacije željenog

smještaja.

Ukoliko se korisnik logira kao administrator dobiva puno veće ovlasti i mogućnosti.

Moguće je pregledati, mjenjati i brisati sve korisnike, oglase, smještaje, regije i mjesta.

Kada napadač pristupi već spomenutim načinom stranicama

http://localhost/apartmani/korisnik.php, http://localhost/apartmani/mjesto.php, ili

http://localhost/apartmani/regije.php, izravno preko URL adrese, dobiva mogućnost

djelovanja na odreĎene sadržaje. Omogućava mu se brisanje, mjenjanje i dodavanje

sadrža ja kojima je pristupio (slika 11.) i upravo je to primjer nedovoljne autorizacije.

Napadač je na taj način sebi prisvojio prava i privilegije koje su dopuštene samoadministratoru aplikacije te time dobio i neovlaštenu ulogu.



http://localhost/apartmani/mjesto.php


http://localhost/apartmani/regije.php







27

Slika 11. Primjer neautoriziranog pristupa podacima

Mjesta za napad ima mnogo, stoga je prije puštanja u rad potrebna provjera svih

sigurnosnih aspekata aplikacije kako bi se postigla bolja zaštita podataka poboljšanjem

autentifikacije i autorizacije korisnika.



28

5. SSO (SINGLE-SIGN-ON)

SSO se po tradiciji smatra tehnologijom kojoj je temeljni zadatak autentifikacija i

autorizacija korisnika. Dakle, glavni naglasak ima sigurnosni dio. U kombinaciji s drugim

sigurnosnim tehnologijama pruža mogućnost izrade različitih sigurnosnih rješenja. No

danas se više ne smije gledati na SSO samo kroz autorizaciju i autentifikaciju. Zbog sve

veće količine informacija dostupnih oko nas, potrebno ih je razvrstati i organizirati na

način koji može pružiti bolju preglednost pojedinom korisniku. Dakle, prikaz podataka se

prilagoĎava pojedincu, prilagoĎava korisniku prema njegovim željama i potrebama. SSO

se razvija u smjeru da će se aplikacije pouzdati u SSO, da način na koji se podaci

prezentiraju ovisi o tome tko ih gleda. To se najviše odnosi na Internet, gdje je pojam

personalizacije već dugo poznat.

SSO ima svoje prednosti kao što su povećana produktivnost korisnika, jedna sigurnosna

baza, lakša administracija, ali i mane poput jedne točke napada, prilagodbe gotovih

aplikaci ja. Ovisno o željama korisnika potrebno je proučiti njihov omjer i ovisno o željama

upustiti se u ostvarenje SSO-a. Integracija u gotove aplikacije može biti skup i dugotra jan proces, jer je potrebno mijenjati aplikaci je u odreĎenoj mjeri. Mnogo je bolje i lakše

razvijati SSO paralelno s razvojem novih aplikacija. 12

5.1. Zahtjevi pred SSO

Gledanje na SSO s raznih gledišta rezultiralo je različitim zahtjevima postavljenim predSSO. Provedene analize funkcionalnosti usmjerile su pažnju na primjene u raznim poljima

što je dovelo do klasifikacije i podjele djelovanja SSO. Pred SSO se postavljaju razni

zahtjevi iako je primarna realizacija jednokratne identifikacije korisnika. Pri tome se misli

na identifikaciju korisničkog procesa što može biti temeljeno na certifikatima ili

biometrijskim obilježjima. Poslije identifikacije se usmjerava pažnja na autentifikaciju i

autorizaciju korisnika na sustavu.

12 http://en.wikipedia.org/wiki/Single_sign-on

http://www.onelogin.com/single-sign-on-sso/

http://en.wikipedia.org/wiki/Single_sign-on






29

U radu kompleksnog informatičkog okruženja, pred SSO se postavljaju i drugi, ne manje

važni zahtjevi:

• upravljanje i kontrola korisničkih podataka, analiza tih podataka što se temelji nadefiniranim ulogama

• premještanje aplikacija bez prekidanja usluge ( obavlja se automatski ukoliko doĎe do

prestanka rada)

• generiranje središnjeg sustava koji sadržava podatke o reviziji te promatranje ponašanja

korisnika u vremenu

• uvid nad cijelim sustavom i uslugama i upravljanje odgovarajućim specifičnim dojavamao kvaru i ažuriranje alarma bez dodatnih troškova

• specifična autentifikacija za različite korisnike, tj različite uloge u aplikaciji ( npr.

administratori, oglašivači, unajmljivači itd. ) 13

5.2. Djelovanje SSO-a

Danas se u svakodnevnom radu istovremeno koristi nekoliko sustava odnosno aplikacija.

Zbog te složenosti postoji administrator koji upravlja korisničkim podacima na svakom od

sustava jer je važno omogućiti korisnicima pristupanje uz visoku razinu očuvanja

integriteta i sigurnosti

Takvi sustavi koji se sastoje od različitih povezanih komponenti se nazivaju distribuirani

sustavi. Te povezane komponente se ponašaju kao zasebne i neovisne. Svaka od njih

podrazumjeva individualnu platformu s operacijskim sustavima i aplikacijama. Budući da

su neovisne, svaki korisnik se mora predstaviti i autentificirati na svakoj domeni na kojoj

želi raditi.

13 T. Pavić, “Diplomski rad: Autentifikacija i autorizacija korisnika na jednom mjestu”,

Fakultet elektrotehnike i računarstva, Zagreb, 2006



30

Takva situacija je opisana na sljedećoj slici:

Slika 12.: Višestruka prijava korisnika na višestruke sust ave

Uspostavlja se komunikacija izmeĎu korisnika i primarne domene. S primarnom domenom

korisnik uspostavlja sjednicu i to je prikazano na slici u kvadratiću na kojem piše: „Prijava

na primarnu domenu“. Korisnik je tada dužan predočiti autentifikacijske podatke ako što

su korisničko ime i lozinka. S primarne domene je takoĎer moguće pozvati usluge i na

drugim domenama. Da bi se omogućio poziv druge domene potrebno je izvršiti prijavu na

toj željenoj domeni. TakoĎer, i nova pozvana domena će tražiti podatke o autentifikaciji

korisnika. Dakle, korisnik obavlja zasebne, neovisne dijaloge sa svakom sekundarnom

domenom kojoj želi pristupiti. To zahtjeva dobru koordinaciju i inegraciju te smanjuje i

odreĎene troškove kao što su:

vrijeme za prijavu

vrijeme za dodjelu dozvola

količina podataka za pamtiti



31

Upravo ta usluga koja omogučuje povezivanje funckija za prijavu svih domena, naziva se

Singl Sign-On.

Pristup ovakvoj prijavi je prikazan na sljedećoj slici:

Slika 13.: Jednostruka prijava na višestruke sustave

Sustav koji ima ulogu prikupljana svih korisničkih podataka koji su potrebni za

autentificiranje smješten je u primarni SSO. Prikupljaju se samo oni podaci koji su

potrebnu za prijavu sekundarnih domena za koju korisnik ima pravo tražiti pristup. Postoji

više načina za korištenje tih podataka:

izravno prosljeĎivanje sekundarnoj domeni

pribavljanje drugih podataka iz baze koji se koriste za prijavu na drugim domenama

trenutna uspostava sjednice sa sekundarnom domenom

korištenje podataka prilikom zahtjevanja usluge



32

Vrlo važne značajke SSO modela u pogledu sigurnosti su povjerenje sekundarne domene

primarnoj da će provjeriti identitet i zaštititi autentifikacijske podatke te briga o zaštiti

podataka tijekom prijenosa izmeĎu primarne i sekundarne domene.

• zaštita kod prijenosa podataka izmeĎu primarne i sekundarne domene14

5.3. Sigurnost i SSO

U smislu sigurnosti možemo reći da SSO ide u dva pravca. Pri tom se misli na

autentifikaciju i autorizaciju. Procesom autentifikacije se korisnik identificira, dok

autorizaci ja služi za odreĎivanje prava i dodjelu uloga. Uloge se dodjeljuju na temelju

dozvola i time se ograničavaju i kontroliraju odreĎene radnje. Danas, mnoga SSO rješenja

za autentifikaciju koriste središnji sustav, a autorizacija se vrši na nekoj ciljanoj apl ikaciji

do koje korisnik želi doći.

SSO je tradicionalno smatran sigurnosnom tehnologijom, no treba uvijek sagledati i malo

širu sliku. Mnoge tehnologije kao što su vatrozidi ( engl. firewalls), virtualne privatne

mreže (VPN), enkripcija itd. djeluju neovisno na različitim sigurnosnim sustavima. Sve te

tehnologji se mogu ujediniti u jednu cjelinu i oblikovati i dopunjavati po želji korisnika.

5.4. Sinkronizacija lozinki

Sinkronizacija lozinki služi za lakše održavanje zaboravljenih ili izgubljenih lozinki.Ukoliko se želi samo smanjiti trošak oko tog održavanja nije nužno koristiti SSO.

Sinkronizacija lozinki je manje kompleksna i osigurava istu lozinku za pojedinog korisnika

na svim sustavima. No, korisnik se mora prijaviti na svaki sustav koji želi koristiti, ali sada

pamti samo jednu lozinku.

14 http://www.authenticationworld.com/Single-Sign-On-Authentication/

http://www.authenticationworld.com/Single-Sign-On-Authentication/






33

Sinkronizacija lozinki se temelji na poslužiteljskim agentima. Kada se lozinka promjeni,

poslužiteljski agent dobiva informaciju o promjeni. Primljenu informaciju prosljeĎuje svim

drugim poslužiteljima za koje korisnik ima pravo pristupa. Dakle, kada se lozinka promjeni

na jednom sustavu, onda se mjenja na svim sustavima. Glavni nedostatak ovakvog rješenja

jest da ukoliko je lozinka ugrožena na jednom mjestu, tada su svi sustavi u opasnosti.

Upravo zbog toga, sinkronizacija lozinki nije SSO rješenje jer posjeta novoj aplikaciji

podrazumjeva novi postupak identifikacije a time i autorizacije. I naravno, takav česti

postupak zahtjeva dodatni trošak održavanja i vremena.

5.5.

Automatizirana pri java

Za automatiziranu prijavu možemo reći da je najjednostavnije SSO rješenje. Ona

predstavlja pristup željenim elementima preko autentifikacijskog poslužitelja. Naime,

autentifikacijski poslužitelj služi za pohranu svih podataka koji su potrebni korisniku za

prijavu na sustav. Korisnik pristupa poslužitelju pomoću klijentskog programa, a zatim se

korisniku nudi popis svih resursa kojemu može pristupiti. Korisnik će izabrati željeni

resurs i pristupit mu preko poslužitelja.

Takav način pristupa čini pomak u sigurnosti. Zaista, za razliku od sinkronizacije lozinki

kod koje je ista lozinka pohranjena na svakom sustavu, kod automatizirane prijave to nije

slučaj. Autentifikacijski poslužitelj može održavati bazu različitih lozinki povezanih sa

svakim ciljanim resursom tj. sustavom što automatiziranu prijavu čini daleko efikasnijom.

5.6. Autenti fi kacija temelj ena na oznakama

U svijetu sve bržeg rasta tehnologija postavlja se potreba za boljim rješenjima sigurnosti, tj

sigurnijim načinima autentifikacije korisnika. Automatizirana prijava u SSO sustavu je

dovoljna ukoliko se SSO uvodi isključivo iz razloga smanjenja troškova i povećanja

efikasnosti. No, ako se želi dobiti na povećanju sigurnosti resursa potreban je sigurniji

mehanizam.



34

Naime, tada postoji mogućnost direk tne prijave na pojedini resurs kao i bez SSO-a.

Poboljšanje mehanizma autentifikacije i autorizacije kontrolira korisničke privilegije i time

pruža veću sigrunost cijelog sustava.

Napredna autentifikacijska rješenja su bazirana na oznakama (engl. tokenima). Kada se

korisnik jednom autentificira generira se jedinstvena i jednom iskoristiva oznaka koja

predstavlja korisnika resursu za kojeg je autoriziran. Jedan od najpoznatijih sustava

temeljenih na oznakama je Kerberos razvijen na MIT-u. I danas skoro sva SSO rješenja su

bazirana na Kerberosu.

5.7. SSO i Web

Za sve Web aplikacije koje nude svoje usluge, sigurnosne provjere čine jednu od važnijih

karika pri ostvarivanju kvalitete ponuda i time povoljnom proširivanju djelovanja. Tu svoju

ulogu imaju i SSO rješenja jer imaju mogućnost jamstva sigurne autentifikacije i

autorizacije nad svim sustavima. Naravno, SSO na različitim mjestima ima i različite

uloge. Dok je na pojedinom poduzeću stavljen naglasak na smanjenju troškova i većojsigurnosti, na Web-u su ti zahtjevi u drugom planu. Web je više okrenut korisnicima

usluga stoga SSO dobro služi pri dopuni sigurnosnih mehanizama iako na mnogim Web

stranicama korisnici nisu ni svjesni da su u opticaju SSO rješenja. Web tehnologija

omogućava pristup i korištenje odreĎenih usluga i resursa preko zajedničkog korisničkog i

pristupnog sustava korištenjem višeslojne arhitekture. Pri oblikovanju pristupa odreĎenim

elementima preko više zahtjeva koji se postavljaju korisniku dolazi do slabl jenja

posjećenosti Web stranice. Naime, zahtjevanje više unosa osim imena i lozinke korisnikeodvlači i djeluje zamorno.

Dakle, upotreba manjih količina informacija je jedno od prihvatljivijih rješenja. Poslužitelj

preko preglednika pohranjuje informacije na klijentsko računalo i ima mogućnost kasnijim

pristupima tim informacijama. Jedna takva informacija se naziva kolačić (cookie).

Prilikom prve prijave na sustav, cookie se zajedno sa korisničkim imenom pohranjuje na

klijentsko računalo. Poslije, kod svakog sljedećeg zahtjeva poslužitelj dohvaća korisničko

ime iz pohranjenog cookie i donosi odluke o sljedećim akcijama.



35

Danas svi internetski preglednici koriste cookie, stoga se s pravom može reći da je njihova

uloga u korištenju SSO-a jako velika. Kao i uvijek, može se postaviti pitanje sigurnosti.

Kako je cookie jako važan za privilegije koje se dodjeljuju odreĎenim korisnicima,

njegova kraĎa imala bi velike posljedice kako za samog korisnika, tako i za cijeli sustav.

Postoji više načina dolaska do cookie-a. Naime,cookie se može uhvatiti prisluškivanjem

paketa koje preglednik šalje poslužitelju. Može se djelovati na preglednik kako bi poslao

cookie lažnom poslužitelju. To se ostvaruje onesposobljavanjem DNS-a jer se preko njega

saznaje koji cookie pripada kojem poslužitelju. Ako se cookie trajno pohranjuje na

korisnikov disk, moguće ga je pročitati direktno s diska. No to nije slučaj kod SSO-a jer se

u primjeni cookie čuva isključivo u radnoj memoriji.

Prilikom aktiviranja i oblikovanja sustava potrebno je voditi računa o što boljoj zaštiti

cookie-a pogotovo na mjestima gdje služi za autentifikaciju korisnika. Poželjno je da

sadržava što manje informacija a one koje sadržava da nisu u čitkom tekstualnom obliku.

Neke od njih su korisničko ime i lozinka. No, važno je da sadrži informacije koje služe za

autorizaciju korisnika za njegovo korištenje. Preporuka je da cookie sadržava sljedeće:

1. ID (sjednički identifikator)

2.

Vrijeme i datum kreiranja cookie-a3.

Vrijeme isteka valjanosti

4. IP adresa preglednika kojemu je cookie poslan

5. Poruku o potvrdi autentičnosti ( MAC)

Ove informacije su važne jer ograničavaju kraĎu cookie. Naime, ukoliko i doĎe do kraĎe,

cookie se neće moći trajno koristiti jer je postavljeno ograničeno trajanje valjanosti. Uz to,

IP adresa točno definira adresu s koje je poslan,a MAC poruka potvrĎuje da se ostala polja

nisu neovlašteno mjenjala. Najčešće se izračunava pomoću hash algoritama, npt. MD5 ili

SHA. TakoĎer, cookie se može zaštititi kriptiranjem, npr. DES algoritmom.

Za osjetljive aplikacije postoji mogućnost i kriptiranja cijelog komunikacijskog kanala

izmeĎu preglednika i polsužitelja. Za to služi SSL protokol. Tada će cookie biti kriptiran s

ostatkom podataka koji se šalju kroz kanal, pa da bi se došlo do cookie mora se presresti

cijeli kanal što zahtjeva dosta znanja i vremena.



36

5.8. Središnji autenti f ikacij ski sustav za Web (CAS)

Središnji autentifikacijski sustav za Web ( u daljnjem tekstu skraćeno CAS) je single-sign-

on protokol za Web. Svrha mu je omogućiti korisniku pristup više aplikacija, a njima se

pristupa preko web preglednika. Razvijen je na Sveučilištu Yale i svoje akreditacije (poput

Session ID-a) dodjeljuje samo jedanput. TakoĎer omogućuje web aplikacijama

autentificiranje korisnika bez dobivanja pristupa korisnikovim sigurnosnim akreditacijama

kao što su lozinke.

CAS protokol je dostupan svima, a programski kod se može skinuti sa službenih stranica.

CAS se takoĎer odnosi na programski paket koji implementira ovaj protokol. Protokol

CAS uklučuje najmanje tri stranke: klijentski web preglednik, web aplikaciju koja traži

provjeru autentifikacije i CAS poslužitelj. TakoĎer može uključivati povrat usluge kao što

je poslužitelj baze podataka koji nema svoje vlastito HTTP sučelje, ali komunicira sa web

aplikacijama. Kada klijent posjećuje aplikaciju koja provjerava autentičnost, aplikacija ga

usmjerava na CAS. CAS potvrĎuje autentičnost korisnika, obično provjerom korisničkog

imena i lozinke na osnovu baze podataka (kao što su Kerberos, LDAP ili Active

Directory). Ako autentičnost uspije, CAS vraća klijenta do aplikacije prolazeći sigurnosniulaz. Zahtjev zatim potvrĎuje ulaz kontaktiranjem CAS-a preko preko sigurne veze i

pružanjem vlastitog identifikatora ulaza. CAS tada daje aplikaciji povjerljive informacije o

tome da li je prijava odreĎenog korisnika uspješno dovršena. CAS omogućuje tzv. „multi -

tier“ provjeru autentičnosti putem proxy adrese. Koristeći povrat usluge kao što su baze

podataka ili mail poslužitelj, može se sudjelovati u CAS-u, potvrdom autentičnosti

korisnika putem informacija koje prima od web aplikacija. Dakle, kod webmail klijenta i

webmail poslužitelja može sve provoditi CAS.

Usluge koje dobivamo od CAS-a su:

Nesigurne i nepouzdane aplikacije imaju mogućnost autentifikacije korisnika bez

pristupa njihovim lozinkama.

Proces autentifikacije korisnika koji svaka aplikacija mora slijediti je

pojednostavljen.

Olakšava SSO na višestrukim Web aplikacijama.



37

Lakši rad sa jezgrom za servise koja nije nužno temeljena na Web -u, ali sadržava

grafičko sučelje.

Autentifikacija se odvija na jednoj Web aplikaciji, čime se pojednostavljuje

čuvanje i promjena lozinki, bez izmjena ostalih aplikacija.15

5.8.1. CAS djelovanje

Za CAS se kaže da djeluje kao samostalna Web aplikacija. Koristi HTTPS protokol

kojemu pristupa kroz tri URL-a. To su : URL za prijavu, URL za validaciju i opcionalniURL za odjavu. Ostvaren je kao nekoliko Java servleta.

Pristup korisnika Web aplikacijama kod kojih se autentifikacija i SSO vrši preko CAS-a

rezultira presumjeravanjem korisnika na URL prijavu. URL će za potr ebe prijave obaviti

osnovnu autentifikaciju, odnosno, od korisnika će se tražiti unos imena i lozinke. Dobiveni

podaci se provjeravaju i dobiva se informacija o njihovoj valjanosti. URL-u za prijavu

možemo pristupiti i direktno ukoliko se želimo autentificirati bez pozivanja bilo koje

aplikacije. CAS sustav se može oblikovati da obavlja provjeru korisničkog imena i lozinkekorištenjem nekih poznatih sustava:

1. obična datoteka s lozinkama

2.

Kriptirana datoteka s lozinkama

3. baza podataka

4. LDAP server

5. ostalo

Za automatiziranu ponovnu autentifikaciju koristi se memory cookie. šalje se pregledniku i

briše se čim se preglednik ugasi. Naziva se još i cookie za dodjelu ulaznica i identificira

korisnika koji se već prije prijavio na sustav. Automatizirana autentifikacija olakšava

prijavu postojećih korisnika jer smanjuje vrijeme potrebno da korisnik pristupi željenoj

aplikaciji. Dakle, korisnik neće morati unosti ime i lozinku svaki put kada ga aplikacij a

preusmjeri na CAS, tj. dobiva se single-sign-on za više Web aplikaci ja.

15 http://en.wikipedia.org/wiki/Central_Authentication_Service



38

Jednom unešeni podaci omogućuju pristup svim aplikacijama koje koriste CAS.

Zahtjevom za odjavu, cookie za dodjelu ulaznica se uništava i tada je potrebna ponovna

prijava ako se želi pristup aplikaciji. Odjava se obavlja odlaskom na URL za odjavu-

logout URL.

Budući da aplikacije prilikom preusmjeravanja korisnika predaju svoj identifikator, CAS

pamti i aplikaciju kojoj je korisnik htio pristupiti i s koje je preusmjeren. Ukoliko je

autentifikacija uspješno obavljena, generira se ulaznica od strane CAS-a koja se povezuje

sa korisnikom i aplikacijom kojoj pristupa. Dakle, ta ulaznica je iskoristiva samo za tog

korisnika i za tu odreĎenu aplikaciju. Na završetku te primarne autentifikacije, CAS šalje

korisnika na mjesto s kojeg je došao, tj na aplikaciju za koju je slao zahtjev. Identifikator

zapravo predstavlja URL aplikacije pa će CAS dodati kreiranu ulaznicu na taj URL kao

jedan dodatni element.

5.9. Povezani pristup u SSO-u

Federativnim pristupom se naziva pristup koji obuhvaća povezivanje različitih sustava i

aplikacija. Danas postoji velika potreba za ovakvim sustavom. Naime, korisnici za različite

Web aplikacije koriste različite identifikacijske podatke što zbog zaboravljanja može

rezultirati mnogim nepotrebnim korisničkim računima. Način da se to riješi je uvoĎenje

sustava jedinstvene autentifikacije na Web-u. Taj sustav koristi standardizirane protokole

kako bi jedna aplikacija dokazala identitet korisnika drugoj aplikaciji. U isto vrijeme,

svaka aplikacija ne mora znati način ostvarenja autentifikacije i autorizacije u ostalim

aplikacijama. Temelji se na standardnim mehanizmima i sustavima razmjene korisničkih

informacija. Jedan od takvih sustava naziva se SAML (Security Assertion Markup

Language).

5.9.1.

SAML i Web Single Sign On

SAML predstavlja XML standard koji služi za sigurnu razmjenu informacija o identitetu

korisnika. Razvila ga je Organizacija za napredak standarda strukturiranih podataka

(Organization for the Advencement of Structured Information Standards-OASIS).



39

Osnovni razlozi za njegov nastanak su: uvoĎenje standarda za razmjenu infromacija

izmeĎu različitih domena, povezanost različitih sustava, smanjivanje troškova oko rada sa

korisničkim računima i jednostavnija usluga za korisnike. Rad SAML standarda se temelji

na razmjeni izjava preko poruka. U toj razmjeni sudjeluje korisnik i pružatelj usluge. Za

izražavanje elemenata u SAML jeziku koriste se poveznice, izjave, protokoli i profili.

Protokoli se bave onim što se prenosi, dok poveznice načinom na koji se prenosi. Profili

služe za definiranje točno odreĎenog slučaja korištenja tih komponenti. Izjava je osnova

SAML-a jer se prenosi izmeĎu izmeĎu pužatelja usluga i daje informacije koje utječu na

odluku o pristupu nekoj aplikaciji. SAML je fleksibilan i proširljiv pr otokol dizajniran da

ga koriste i mijenjaju drugi protokoli. Najviše je u upotrebi upravo u razvijanju SSO-a.

Korisnik se prijavljuje na jednu stranicu i nakon toga može pristupati drugim stranicama

bez dodatne prijave. SAML omogućava SSO kroz komunikaciju izjavama (engl.

assertions). Stranica na kojoj se korisnik prijavio, šalje izjavu drugoj stranici koja tada

može korisnika propustiti kao da se direktno prijavio. 16

5.10. Autorizaci ja temeljena na atri butima

Kod autorizacije korištenjem atruibuta osnova je da se podaci prenose preko atributa. Ti

podaci sadrže informacije o ulogama i pravima koje korisnik dobiva nakon uspješne

prijave. U toj komunikaciji sudjeluju dvije Web stranice i kod jedne od njih korisnik je

prethodno obavio identifikaciju. Slanje preko mreža ponekad može biti rizično u

sigurnosnom smislu pa se u tim slučajevima preporučuje autorizacija preko atributa. No,

treba voditi računa o informacijama koje nam govore o mjestu i vremenu prijave korisnika,

jer atributi ne sadržavaju takvu vrstu podataka.

16 http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language



41

Zbog sve većeg korištenja različitih Web stranica sa opcijom registracije korisniku se treba

omogućiti i sinkronizacija lozinki. Ukoliko se donose odluka za njenu provedbu potrebno

je osigurati visoku razinu sigurnosti. Napad na lozinku može učiniti veliku štetu za samog

korisnika jer napadač ima pristup svim sadržajima kojima je korisnik pristupao. Na taj

način napadnut je i sam korisnik i svaka aplikacija za koju vrijedi dobavljena lozinka. Iako

smanjenje ne važećih korisničkih računa olakšava održavanje Web stranica, ipak bi

naglasak trebao biti na zaštiti korisnika.



7. LITERATURA

[1] Simson Garfinkel: Web Security & Commerce, O'Reilly, 1997.

[2] T. Pavić, “Diplomski rad: Autentifikacija i autorizacija korisnika na jednom mjestu”,

Fakultet elektrotehnike i računarstva, Zagreb, 2006.

[3] http://en.wikipedia.org/wiki/Single_sign-on ( zadnji pristup rujan 2014.g.)

[4] http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language (zadnji pristup

rujan 2014.g.)

[5] Brute Force napadi ( Carnet Cert i LS&S, CCERT-PUBDOC-2007-08-201)

[6] http://www.aquilonis.hr/acunetix/authentication_hacking.html (zadnji pristup rujan

2014.g.)

[7] http://en.wikipedia.org/wiki/Central_Authentication_Service (zadnji pristup rujan

2014.g.)

[8] http://www.authenticationworld.com/Single-Sign-On-Authentication/ (zadnji pristup

rujan 2014.g.)

[9] http://www.onelogin.com/single-sign-on-sso/ ( zadnji pristup rujan 2014.g.)

[10]http://en.wikibooks.org/wiki/Fundamentals_of_Information_Systems_Security/Access

_Control_Systems (zadnji pristup rujan 2014.g.)

[11] Sigurnost Web aplikacija (Mario Kozina, Sveučilište u Zagrebu, Zagreb, 2006.g.)




http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language



http://www.aquilonis.hr/acunetix/authentication_hacking.html



http://en.wikipedia.org/wiki/Central_Authentication_Service




















diplomski informatika pervan

Documents