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: Doc.dr.sc. Goran Kraljević Student: 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. 2.1.2. 2.1.3. 2.2. 2.3. 3. Napad rječnikom ........................................................................................................ 7 Proboji kriptografskih algoritama ............................................................................. 8 Detekcija i zaštita od Brute Force napada ............................................................... 10 Nedovoljna razina autentifikacije..................................................................................... 12 Nedovoljna zaštita korisnikove lozinke ........................................................................... 13 AUTORIZACIJA ....................................................................................................... 15 3.1. NagaĎanje vjerodajnog identifikacijskog broja ................................................................ 15 3.2. 3.3. 3.4. Nedovoljna autorizacija.................................................................................................... 17 Nedovoljna kontrola trajanja korištenja usluge ................................................................ 18 Fiksacija usluge ................................................................................................................ 19 4. PRIMJER WEB APLIKACIJE ................................................................................ 21 5. SSO (SINGLE-SIGN-ON) ......................................................................................... 28 5.1. Zahtjevi pred SSO ............................................................................................................ 28 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. Djelovanje SSO-a ............................................................................................................ 29 Sigurnost i SSO ................................................................................................................ 32 Sinkronizacija lozinki ....................................................................................................... 32 Automatizirana prijava ..................................................................................................... 33 Autentifikacija temeljena na oznakama ........................................................................... 33 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 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. 1 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 sloj (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 svojih korisnika 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) 2 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. 3 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) 4 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. Reverzni 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) – provjeri 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 i kao 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. 5 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 broja 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 8 kraljica 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 rasponu od 1 do 8 gdje vrijednost 6 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) 7 Npr. može se naći hrvatski rječnik uz neke druge na stranici http://www.word-list.com/. Jedna od poboljšanih inačica ovog napada je hybrid napad kod kojeg su dodani odreĎeni simboli i brojevi u rječnik. Napadi rječnikom su prilično uspješni jer ljudi pokazuju sklonost odabiru zaporki od 7 ili manje znakova koje su, još i riječi s nekim značenjem ili neki predvidivi anagrami, skraćenice ili pak riječi nadopunjene jednoznamenkastim brojem. Vjerojatnost razbijanja lozinki raste povećavanjem korištenja većeg ili više rječnika ili na više stranih jezika. Obično koristi neki alat koji sadži ugraĎen rječnik i implementiran algoritam pretraživanja. Napadi rječnikom se uglavnom upotrebljavaju u dvije svrhe: • U kriptografskoj analizi za otkrivanje ključa za deskripciju odreĎenog teksta • Za probijanje autentifikacije, tj. otkrivanje zaporke nekog sustava sa svrhom ostvarenja neovlaštenog pristupa. TakoĎer, imamo i treću primjenu napada rječnikom koja se temelji na slanju e-mail poruka. Autori tih poruka koriste rječnike za formiranje adresa elektroničke pošte koje postaju potencijalni primaoci neželjenih poruka. Npr. mogu generirati poruke za adrese: ana@example.com, ivan@example.com, josip@example.com, itd. Ukoliko na neku od tih adresa bude dostavljena poruka, tj. ako se ne dobije poruka o nemogućnosti dostave, autor će tu adresu označiti kao važeću i koristiti za daljnje slanje odreĎenih poruka. 2.1.2. Proboji kriptografskih algoritama Kriptografski algoritmi su česta meta napada. Pri tome mnogi napadači koriste Brute Force napade. Takav napad na kriptografski algoritam predstavlja dobavljanje ključa pomoću kojeg će se iz nekog zaštićenog teksta dobiti njegov izvoran oblik. Uz pretpostavku da je algoritam kriptiranja poznat, ako se ključevi biraju slučajno, tekst će biti probijen nakon što je isprobano pola mogućih ključeva. I zapravo, možemo reći da je temelj kriptiranja upravo u ključu jer je uglavnom algoritam poznat. 8 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.) 9 2.1.3. Detekcija i zaštita od Brute Force napada Brute Force 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. 10 Uz to postoje i alati za zaštitu od brute force napada koji se uglavnom temelje na prethodno navedenim koracima. Njihova uloga svodi se na automatizaciju opisanih postupaka tj. na analizu dnevničkih zapisa i onemogućavanje pristupa sustavu s napadajućih IP adresa. Primjeri takvih alata koji se distribuiraju besplatno su: • APF vatrozid & BFD skripta – rješenje temeljeno na IPtables vatrozidu koje nudi i tzv. Antidos zaštitu i zaštitu od Brute Force napada (eng. Brute Force Detection- BFD) . Zaštita se temelji na analizi dnevničkih zapisa ( podržana su dva formata zapisa- system kernel log i snort portscan log) na osnovu kojih se poduzimaju odreĎene akcije. Konfiguracijom je moguće odabrati sljedeće: 1) Dubinu analize dnevničkog zapisa, odnosno broja redaka za analizu 2) Prag tolerancije tj. broj neuspjelih pokušaja pristupa nakon kojih se detektira napad 3) Akcije nakon detekcije, odnosno izmjene vatrozidnih pravila kojim se onemogućava daljnji pristup poslužiteljima ili IP adresama od kojih je došao napad. • Log Watch – alat za praćenje i analizu dnevničkih zapisa koji kreira periodičke izvještaje o aktivnosti poslužitelja. Izvještaji sadrže podatke o utrošenom diskovnom prostoru, uspjelim i neuspjelim pokušajima pristupa poslužitelju i slične informacije. Neuspjeli pokušaji se u izvještaju evidentiraju na slijedeći način: anonymous/none from (IP HERE): 8 Time(s) anonymous/password from (IP HERE): 8 Time(s) guest/none from (IP HERE): 8 Time(s) guest/password from (IP HERE): 8 Time(s) root/password from (IP HERE): 24 Time(s) Dodatna aktivnost koja neizravno pomaže u zaštiti od brute force napada je prijava napadača. Naime nakon detekcije napada i provedbe zaštite blokadom izvorišne IP adrese dobro je tu adresu prijaviti davatelju usluge pristupa Internetu. Web stranica www.dnsstuff.com omogućava dobivanje podataka o davatelju usluge pristupa na osnovu IP adrese. 11 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 autentifikacije 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) 12 Primjer nedovoljne razine autentifikacije su Web aplikacije koje posjeduju administratorsku mapu /admin/ direktno unutar osnovne mape Web aplikacije (root). Iako ova mapa nije povezana (nema link) ni sa jednim dokumentom Web aplikacije koji se daje na raspolaganje korisniku, korisnik može direktno pristupiti mapi korištenjem Web preglednika i na taj način zaobići proces autentifikacije.6 Najčešći uzrok nedovoljne razine autentifikacije je previd administratora koji smatra da pristup administratorskoj mapi nije moguć ukoliko ne postoji poveznica (link) na /admin/ mapu, i pritom ne postavi dozvole pristupa /admin/ mapi. 2.3. Nedovoljna zaštita korisnikove lozinke Nedovoljnom zaštitom korisnikove lozinke se omogućava napadaču da ilegalno dobije, promijeni ili obnovi lozinku drugog korisnika. Proces autentifikacije odreĎene Web aplikacije zahtjeva od korisnika pamćenje lozinke ili odreĎene fraze koja omogućava pristup korisničkom računu. Korisnik bi trebao biti jedina osoba koja točno zna lozinku. Kako vrijeme prolazi, korisnikova sposobnost pamćenja lozinke se smanjuje, pogotovo ako se uzme u obzir da korisnik ima desetak i više korisničkih računa za različite Web aplikacije. Ukoliko korisnik zaboravi lozinku, tada pristupa procesu za obnovu lozinke. Najčešći primjer procesa za obnovu lozinke je proces koji koristi princip “tajnog pitanja” (engl. secret question) koje korisnik definira prilikom registracije računa. Ukoliko korisnik zaboravi lozinku, odgovorom na “tajno pitanje” može obnoviti svoju lozinku. Još jedan primjer procesa za obnovu lozinke je specificiranje trika (engl. hint) koji pomaže korisniku da se prisjeti svoje lozinke. Drugi mehanizmi obnove zahtijevaju od korisnika osobne podatke kao što su e-mail, adresa, broj kartice, kako bi potvrdili svoj identitet. Najveći problem procesa za obnovu je mogućnost prevare samog procesa od strane napadača. To se najčešće dogaĎa kada su informacije potrebne za provjeru korisničkog identiteta lako dostupne ili se daju naslutiti. Sustavi za obnovu se najčešće kompromitiraju korištenjem brute force napada, naslijeĎenom ranjivošću sustava ili “tajnim pitanjima” koja se daju naslutiti. 6 http://www.aquilonis.hr/acunetix/authentication_hacking.html 13 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 7 Sigurnost Web aplikacija (Mario Kozina, Sveučilište u Zagrebu, Zagreb, 2006.g.) 14 3. AUTORIZACIJA Autorizaciju možemo definirati kao dodjelu uloga po nekim odreĎenim pravilima. Ako promatramo sa strane Web 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 15 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 zloupotreba korisnič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 pohraniti 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 9 Sigurnost Web aplikacija (Mario Kozina, Sveučilište u Zagrebu, Zagreb, 2006.g.) 16 Slika 1. Primjer baziran na Session ID-u 3.2. Nedovoljna autorizacija 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 ureĎ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 njihovo neprikladno 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. 10 Sigurnost Web aplikacija (Mario Kozina, Sveučilište u Zagrebu, Zagreb, 2006.g.) 17 3.3. Nedovoljna kontrola trajanja korištenja usluge Kao što je već pojašnjeno Web aplikacije koriste HTTP stateless protokole, tj protokole koje na pamte prethodni posjet korisnika Web stranici i koje dodjeljuju identifikacijske brojeve (Session ID) da bi identificirali korisnika pri svakom posjetu. Zbog toga, Session ID mora biti jedinstven i trajno čuvan jer njihovim gubljenjem i ne pamćenjem omogućava se višekorisnički pristup istom korisničkom računu. Za svaku Web aplikaciju vrlo je važna kontrola trajanja korištenja usluge. Ukoliko aplikacija ne vodi računa o vremenskom trajanju usluge prema korisniku, otvara put napadima na nedozvoljeno korištenje tih usluga. To nedozvoljeno korištenje usluga od strane „lažnih“ korisnika može dovesti prave korisnike u neugodne situacije. Naime, napadač korištenjem starih vjerodajnih identifikacijskih brojeva za autorizaciju koristi tuĎa prava i sadržaje i time ugrožava Web aplikaciju. Važnost ograničenja životnog vijeka Session ID-a može se vidjeti na primjeru u kojem korisnik ne obavi propisnu odjavu sa aplikacije (logout). Tada, sljedeći korisnik računala može putem back zahtjeva na Web pregledniku pregledati sve stranice koje su se koristile prije njega. I ukoliko nije pravilno prekinuta sjednica, može posjetiti stranicu i sadržaje za koje se prethodni korisnik autentificirao i time mu dodjeljena odreĎena autorizacija. Mjesta na kojima najčešće dolazi do ovakve vrste napada su Internet kafići, knjižnice, računalne učionice itd., tj. mjesta gdje je zastupljena višekorisnička računalna okolina. Kontrola trajanja usluge, tj. trajanja Session ID-a ima i brojne druge uloge. Neke od njih su smanjenje rizika za odreĎene vrste napada, sprečavanje trajnog korištenja prethodno ukradenog Session ID-a, onemogućavanje napadaču da izračuna sljedeći korisnički Session ID, smanjivanje broja korisničkih prijava na korisnički račun odreĎene Web aplikacije itd. Danas su osmišljene brojne strategije preuzimanja Session ID-a. Tako npr. napadač može prisluškivati mrežu i preuzimati pakete koji sadrže Session ID ili može koristiti Cross-site scripting napad kako bi došao u posjed Session ID-a. Stoga administratori moraju biti u hodu s tim načinima kako bi spriječili kraĎu i time zaštitili sebe i svoje korisnike. 18 3.4. Fiksacija 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. 19 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 11 Sigurnost Web aplikacija (Mario Kozina, Sveučilište u Zagrebu, Zagreb, 2006.g.) 20 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 se korisniku 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. ) 21 Slika 3. Registracija korisnika Slika 4. Autentifikacija korisnika Prilikom registracije, 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 svakom korisniku aplikacije i osigurava lakšu organizaciju i pretragu baze podataka. To se postiže upotrebom Java Script forme: 22 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 prijave u aplikaciju 23 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 adresu http://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 24 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 voditi računa o pravilnom kreiranju lozinke prilikom registracije na aplikaciju. Kada korisnik unosi podatke za registraciju, provjerava se unos lozinke, tj. provjerava se njena dužina. Ne dozvoljava se kreiranje lozinke koja ima manje od 6 znakova. TakoĎer, da bi se smanjio broj nevažećih korisničkih računa, provjerava se i ispravnost 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. 25 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 koji time 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ć http://localhost/apartmani/korisnik.php, spomenutim načinom stranicama 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žaja 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 samo administratoru aplikacije te time dobio i neovlaštenu ulogu. 26 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. 27 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 aplikacija. 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 dugotrajan proces, jer je potrebno mijenjati aplikacije 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 pred SSO. 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/ 28 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 na definiranim 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 dojavama o 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 29 Takva situacija je opisana na sljedećoj slici: Slika 12.: Višestruka prijava korisnika na višestruke sustave 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 30 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 31 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 autorizacija 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 aplikaciji 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/ 32 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 prijava 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. Autentifikacija temeljena 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. 33 Naime, tada postoji mogućnost direktne 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ćoj sigurnosti, 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 slabljenja posjećenosti Web stranice. Naime, zahtjevanje više unosa osim imena i lozinke korisnike odvlač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. 34 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-a 3. 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. 35 5.8. Središnji autentifikacijski sustav za Web (CAS) Središnji autentifikacijski sustav za Web ( u daljnjem tekstu skraćeno CAS) je single-signon 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 sigurnosni ulaz. 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. „multitier“ 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. 36 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 opcionalni URL 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 potrebe 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 lozinke koriš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 aplikacija preusmjeri na CAS, tj. dobiva se single-sign-on za više Web aplikacija. 15 http://en.wikipedia.org/wiki/Central_Authentication_Service 37 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 odjavulogout 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). 38 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 protokol 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. Autorizacija temeljena na atributima 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 39 6. ZAKLJUČAK Kako smo svjedoci sve bržeg rasta i razvoja tehnologija, interneta i Web aplikacija, to je i teže biti u koraku sa raznim napadima na osjetljive podatke kao što su korisnička imena i lozinke. Napadi na resurse aplikacija orijentirani su na slabosti sustava koje se uz trud i uloženo vrijeme mogu lako iskoristiti. Problem slabosti web aplikacija i sustava koji održavaju web aplikacije su veliki problem ako se ne uspiju riješiti odmah nakon njihovog otkrivanja ili u vrlo brzom vremenskom razdoblju nakon toga. Ako se radi o složenim problemima neke slabosti bi se mogle iskoristiti za stvaranje novih koje u tom trenutku nisu uočene, pa bi problem bio jednak ili možda čak i veći u odnosu na prethodnu situaciju. Zbog toga je brzo djelovanje jedan od najvažnijih čimbenika u tom procesu. Stoga, razvoj raznih tehnika i metoda proboja zaštite, tjeraju na neprestano traganje za modelima zaustavljanja tih napada. Danas su korisnici sve veća meta prilikom prijave na odreĎene Web aplikacije. Osiguravanje zaštite u Web aplikacijama može se ostvariti na mnoge načine. Početak svega je dobro poznavanje tehnika i metoda napada. Za procese autentifikacije i autorizacije korisnika važno je postavljanje zapreka prilagoĎavajući modele provjere identiteta, a time i provjere dodjeljenih uloga i prava. Sprječavanje kraĎe podataka o korisničkim imenima i lozinkama jedna je od važnijih stvari za svaku Web aplikaciju. Korisnike prilikom registracije treba uputiti na sigurniji način kreiranja lozinke. To se postiže postavljanjem mjerača jačine lozinke. Lozinke ne bi trebale sadržavati osobna imena, datume ili neke druge osobne podatke koje napadač može lako otkriti. TakoĎer, treba općenito izbjegavati smislene riječi i rečenice jer npr. upotrebom Brute Force metode, moguće je pogoditi odreĎenu riječ koja je karakteristična za samog korisnika. Osim, lozinke, treba voditi računa i o korisničkom imenu. Za njega vrijede slična pravila kao i za lozinke s tim da se izbjegaje kreiranje računa s istim korisničikm imenom i lozinkom. Korisnika se treba upozoriti i na mnoge druge elemente koje pomažu u sigurnosti Web aplikacije. Upravo je na administratoru glavni naglasak, jer pravilno i dovoljno postavljena ograničenja jedina mogu zaštititi kako administratore, tako i korisnike, jer administrator ima veća ovlaštenja i mogućnost djelovanja na aplikaciju. 40 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. 41 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.) 42
© Copyright 2024 Paperzz
