SIGURNOST MREŽNIH PRIMJENSKIH SUSTAVAsigurnost.zemris.fer.hr/ns/2006_pauk/diplomski.pdf · 2006-07-08 · postaju sve zastupljeniji, kako na Internetu, tako i u raznim intranet okolinama

SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD br. 1597

SIGURNOST MREŽNIH PRIMJENSKIH

SUSTAVA

Luka Pauk

Zagreb, srpanj 2006.

Sadržaj 1. Uvod ...................................................................................................................................1 2. Arhitektura Web aplikacije.................................................................................................2

2.1 Tehnologije .................................................................................................................2 2.1.1 CGI .....................................................................................................................2 2.1.2 Filtri ....................................................................................................................2 2.1.3 Skriptni jezici......................................................................................................3 2.1.4 Radni okviri za Web aplikacije ..........................................................................3

2.2 Male i srednje aplikacije.............................................................................................4 2.3 Velike aplikacije .........................................................................................................4 2.4 Sigurnost Web aplikacija............................................................................................5

2.4.1 Klasifikacija prijetnji ..........................................................................................5 2.4.2 Statistike napada .................................................................................................6

3. Autentifikacija i autorizacija ..............................................................................................8 3.1 Uobičajene tehnike Web autentifikacije.....................................................................8

3.1.1 HTTP autentifikacija ..........................................................................................8 3.1.2 Autentifikacija temeljena na obrascima .............................................................9 3.1.3 Integrirana autentifikacija...................................................................................9 3.1.4 Autentifikacija temeljena na certifikatima .........................................................9

3.2 Jaka autentifikacija ...................................................................................................10 3.2.1 Biometrijski podaci...........................................................................................10 3.2.2 Jednokratne lozinke ..........................................................................................11 3.2.3 Tvrdi certifikati.................................................................................................11 3.2.4 Odgovor na izazov............................................................................................12 3.2.5 SMS odgovor na izazov....................................................................................12 3.2.6 Potpisivanje transakcija ....................................................................................12

3.3 Savezna autentifikacija .............................................................................................13 3.4 Problemi vezani za autentifikaciju ...........................................................................13 3.5 Autorizacija ..............................................................................................................16 3.6 Upravljanje sjednicama ............................................................................................17

3.6.1 Uvod .................................................................................................................17 3.6.2 Sigurnosni problemi vezani za sjednice ...........................................................18

4. Sigurnosni problemi i metode zaštite ...............................................................................20 4.1 Validacija podataka ..................................................................................................20

4.1.1 Uvod .................................................................................................................20 4.1.2 Sprječavanje mijenjanja parametara.................................................................20

4.2 Umetanje interpreterskog koda.................................................................................22 4.2.1 Umetanje na korisničkom agentu .....................................................................22 4.2.2 Umetanje na poslužitelju ..................................................................................24

4.3 Praćenje rada i rukovanje pogreškama .....................................................................25 4.3.1 Uvod .................................................................................................................25 4.3.2 Rukovanje pogreškama.....................................................................................26 4.3.3 Bilježenje ..........................................................................................................26 4.3.4 Buka..................................................................................................................27 4.3.5 Prikrivanje tragova ...........................................................................................27

4.4 Datotečni podsustav..................................................................................................27 4.4.1 Obezličenje .......................................................................................................27 4.4.2 Šetnja po direktorijima .....................................................................................27

4.4.3 Nesigurno indeksiranje .....................................................................................28 4.4.4 Neinterpretirane datoteke .................................................................................28

4.5 Preljev meñuspremnika ............................................................................................28 4.5.1 Opis...................................................................................................................28 4.5.2 Pogoñene platforme..........................................................................................29 4.5.3 Preljev stoga .....................................................................................................29 4.5.4 Preljev gomile...................................................................................................29 4.5.5 Specijalizirani oblici preljeva meñuspremnika.................................................30 4.5.6 Zaštita od preljeva meñuspremnika..................................................................30

5. Praktični rad......................................................................................................................31 5.1 Pregled sigurnosnih alata..........................................................................................31

5.1.1 Paros .................................................................................................................31 5.1.2 Nikto .................................................................................................................32 5.1.3 Nessus...............................................................................................................32

5.2 Ispitivanje sigurnosti postojeće Web aplikacije .......................................................33 5.2.1 Uvod .................................................................................................................33 5.2.2 Automatizirano ispitivanje ...............................................................................33 5.2.3 Ručno ispitivanje ..............................................................................................38

5.3 Web aplikacija s primjerima ranjivosti.....................................................................39 5.3.1 Uvod .................................................................................................................39 5.3.2 SQL umetanje ...................................................................................................40 5.3.3 Reflektirani XSS...............................................................................................41 5.3.4 Neučinkovita autorizacija .................................................................................42 5.3.5 Razbijena kontrola pristupa ..............................................................................43

6. Zaključak ..........................................................................................................................45 7. Literatura ..........................................................................................................................46

1

1. Uvod

Mrežni primjenski sustavi (mrežni primjenski programi, Web aplikacije) u današnje vrijeme postaju sve zastupljeniji, kako na Internetu, tako i u raznim intranet okolinama. Rastom broja korisnika i uvoñenjem novih tehnologija, Web polako postaje nova aplikacijska platforma, a Web aplikacije obavljaju sve raznovrsnije zadaće.

Usporedo s porastom broja primjenskih sustava na Internetu, raste i broj sigurnosnih incidenata koji su za njih vezani. Zlouporaba Web aplikacije može dovesti do gubitka ugleda njenog vlasnika, otuñenja financijskih sredstava ili krañe korisnikovih osobnih podataka. Stoga sigurnost u svijetu Web aplikacija postaje sve zastupljenija i važnija tema.

U ovom radu su opisani česti sigurnosti problemi vezani za Web aplikacije i metode njihovog rješavanja. U praktičnom djelu, napravljena je analiza alata za ispitivanje sigurnosti Web aplikacija, te ručna i automatizirana provjera ranjivosti postojeće Web aplikacije. Za potrebe demonstracije izrañena je aplikacija s primjerima čestih sigurnosnih propusta.

U poglavlju Arhitektura Web aplikacije opisane su postojeće tehnologije primjenskih mrežnih sustava i njihove prednosti i mane sa stajališta sigurnosti. U istom poglavlju navedena je i klasifikacija prijetnji, te statistika incidenata vezanih za Web aplikacije. U poglavlju Autentifikacija i autorizacija navedeni su problemi i rješenja kod autentifikacije, autorizacije i upravljanja sjednicama. U poglavlju Sigurnosni problemi i metode zaštite navedeni su ostali sigurnosni problemi kao što su (validacija podataka, preljevi meñuspremnika...), te odgovarajuće mjere zaštite. U poglavlju Praktični rad dan je pregled sigurnosnih alata, rezultati ispitivanja i opis aplikacije s primjerima ranjivosti.

2

2. Arhitektura Web aplikacije

2.1 Tehnologije

2.1.1 CGI

Na samim početcima Weba, Web poslužitelji su posluživali isključivo statički sadržaj, koji nije omogućavao meñudjelovanje aplikacije s korisnicima. Stoga su proizvoñači Web poslužitelja otvorili mogućnost pokretanja vanjskih programa primjenom CGI (Common

Gateway Interface) mehanizma. Na taj način korisnici su mogli poslati ulazne podatke vanjskom programu ili skripti koja bi generirala Web stranicu s rezultatima. CGI je preteča svih današnjih radnih okvira za Web aplikacije, skriptne jezike i Web servise. Iako se CGI danas rijetko koristi, princip obrade ulaznih podataka koji se koriste za izradu dinamičkih Web stranica, osnova je rada svih današnjih Web aplikacija.

CGI se još uvijek primjenjuje kod nekih današnjih Web aplikacija. Njegova prednost je jednostavnost implementiranja aplikacijske logike u brzim nativnim jezicima, kao što su C i C++. Osim toga, CGI omogućuje i izradu Web sučelja za aplikacije za koje nije prethodno planirano da imaju Web pristup. Negativne strane uporabe CGI-a su sljedeće:

• Većina jezika niske razine ne podržava izravno generiranje HTML izlaza, i stoga se trebaju koristiti za tu svrhu izrañene biblioteke.

• Ciklus izrade aplikacije i njenog uvoñenja u primjenu je sporiji nego kod novijih tehnologija.

• CGI programi se izvode kao zasebni procesi, pa meñuprocesna komunikacija i stvaranje procesa mogu znatno oslabiti performanse na nekim arhitekturama.

• CGI ne podržava upravljanje sjednicama pa ono mora biti implementirano pisanjem posebne biblioteke.

• Velikom broj programera je programiranje u jezicima niske razine (kao što su C i C++) razmjerno teško, za razliku od programiranja u skriptnim jezicima.

• Većina jezika treće generacije koji se često koriste u CGI programima pate od preljeva meñuspremnika i otjecanja resursa. Kako bi se te pojave izbjegle, potrebna je znatna količina programerske vještine.

CGI omogućuje prevoñenje primjenskog programa u nativni kod prije pokretanja, pa je stoga koristan kod dugačkih i zahtjevnih procesa. Budući da svako novo pokretanje prevedenog CGI programa uključuje i stvaranje novog procesa na računalu, učinkovitost takvih aplikacija je veća kod sustava s manjim brojem korisnika.

2.1.2 Filtri

Filtri se koriste za posebne namjene, kao što su kontrola pristupa Web stranicama ili implementiranje drugog radnog okvira za Web aplikacije (na primjer, Perla, PHP-a ili ASP-a). Filtar mora biti napisan u jezicima C ili C++, i može imati visoke performanse, budući da se nalazi u izvršnom kontekstu Web poslužitelja. Tipični primjeri takvih sustava su moduli Apache Web poslužitelja, SunONE NSAPI i Microsoft ISAPI.

3

2.1.3 Skriptni jezici

Nedostatak podrške za upravljanje sjednicama i autorizaciju kod CGI tehnologije ograničavao je razvoj komercijalno isplativih aplikacija. Stoga su se programeri Web aplikacija okrenuli uporabi interpretiranih skriptnih jezika. Interpreteri izvode skriptni kod unutar procesa Web poslužitelja, a kako se skripte ne prevode, ciklus izrade i uvoñenja u primjenu je nešto kraći nego kod prevedenih CGI programa. Skriptni jezici rijetko imaju preljeve meñuspremnika i otjecanja resursa, što programerima olakšava izbjegavanje najčešćih sigurnosnih problema. Mane skriptnih jezika su sljedeće:

• Većina skriptnih jezika nije strogo tipizirana i ne promiču dobru programersku praksu.

• Skriptni jezici su općenito sporiji od svojih prevedenih dvojnika.

• Teško je (iako ne i nemoguće) razvijati višeslojne aplikacije u skriptnim jezicima, pa se prezentacijski, aplikacijski i podatkovni slojevi često nalaze na istom računalu. To ograničava skalabilnost i sigurnost.

• Većina skriptnih jezika ne podržava pozive udaljenih metoda ili Web servisa, što otežava komunikaciju s aplikacijskim poslužiteljima ili Web servisima.

Unatoč nedostatcima, mnoge velike i korisne baze koda napisane su u skriptnim jezicima. Skriptni radni okviri uključuju ASP, Perl, ColdFusion i PHP. Mnogi od njih se danas smatraju interpretiranim hibridima, posebno ColdFusion i PHP, koji optimiziraju skripte prije pokretanja.

2.1.4 Radni okviri za Web aplikacije

Kako su skriptni jezici dosegli granicu u performansama i skalabilnosti, za veće projekte se počela upotrebljavati Sun J2EE platforma za Web aplikacije. Njene prednosti su:

• uporaba programskog jezika Java za izradu brzih aplikacija koje rijetko imaju preljeve meñuspremnika i otjecanja memorije,

• posjedovanje dobrih kontrola za upravljanje sjednicama i autorizaciju,

• podržavanje relativno transparentnih višeslojnih aplikacija putem različitih mehanizama za pozivanje udaljenih komponenti, te

• stroga tipiziranost omogućuje sprječavanje čestih sigurnosnih i programerskih pogrešaka prije samog pokretanja programa.

Učenje programskog jezika Java je složenije i dugotrajnije od učenja skriptnih jezika, što je i najveći nedostatak J2EE platforme.

Tvrtka Microsoft je svoju ASP tehnologiju značajno unaprijedila i stvorila ASP.NET platformu koja koristi .NET Framework. .NET Framework u velikoj mjeri oponaša J2EE radni okvir, ali ima odreñena unaprjeñenja u razvojnom procesu:

• lakoća izrade malih aplikacija za programere početnike i dizajnere,

• omogućuje izradu velikih distribuiranih aplikacija,

• posjeduje dobre kontrole upravljanja sjednicama i autorizacije,

4

• programeri mogu koristiti jezik koji im najviše odgovara, a programi se prevode u nativni kod za bolje performanse,

• programi na .NET platformi rijetko imaju preljeve meñuspremnika i otjecanje resursa,

• transparentna komunikacija s vanjskim i udaljenim komponentama, te

• stroga tipiziranost omogućuje sprječavanje čestih sigurnosnih i programerskih grešaka prije samog pokretanja programa.

Izbor izmeñu J2EE i ASP.NET radnih okvira najviše ovisi o izboru operativnog sustava. Aplikacije napisane za J2EE mogu se pokrenuti na svim zastupljenijim platformama (Linux, AIX, MacOS X, Windows, Solaris) bez značajnije izmjene u kodu. ASP.NET primarno je dostupan za Microsoft Windows platformu. Sa sigurnosnog stajališta, ne postoji značajniji razlog koji bi utjecao na odabir izmeñu ova dva radna okvira.

2.2 Male i srednje aplikacije

Većina postojećih aplikacija spada u kategoriju malih i srednjih. Uobičajena arhitektura je jednostavna linearna proceduralna skripta. Takva vrsta programiranja najčešća je kod PHP, ASP i Cold Fusion skripti, a rjeña kod ASP.NET i J2EE aplikacija. Razlog uporabe ovakve arhitekture je jednostavnost pisanja i održavanja koda. Za manje aplikacije, količina posla potrebna za prebacivanje na skalabilniju arhitekturu se u većini slučajeva ne može opravdati eventualnim poboljšanjem performansi. U ovakvim aplikacijama su uobičajeni mnogi sigurnosni problemi. Primjeri takvih su dinamički upiti bazi podataka konstruirani iz nedovoljno provjerenog korisničkog ulaza, loše rukovanje pogreškama i slabe autorizacijske kontrole.

2.3 Velike aplikacije

Velike aplikacije zahtijevaju drugačiju arhitekturu od one koja se koristi u malim i srednjim aplikacijama. Izrada skalabilnih aplikacija postaje prijeka potreba kada aplikacija koristi veći broj vanjskih resursa i nudi više različitih funkcija korisniku. Skalabilna aplikacijska arhitektura je često podijeljena u slojeve i sadrži više ponovno iskoristivih dijelova korištenjem dizajnerskih smjernica za postizanje modularnosti. Podjela aplikacije na slojeve omogućuje distribuciju aplikacije na različite poslužitelje, čime se unaprjeñuje skalabilnost na račun složenosti. Jedna od najčešćih arhitektura za Web aplikacije je model-pogled-upravljač (Model-View-Controller - MVC), koji implementira aplikacijsku arhitekturu programskog jezika SmallTalk 80. MVC se pronalazi u mnogim J2EE aplikacijama, a ASP.NET tehnologija može se smatrati djelomičnom implementacijom ove vrste pristupa.

Pogled (ili prezentacijski sloj) je prednji dio aplikacije koji služi za izradu prikaza, a ima za cilj generirati HTML izlaz s malo ili bez aplikacijske logike. Kako mnoge aplikacije postaju internacionalizirane (ne sadrže lokalizirane znakove ili informacije o kulturi u prezentacijskom sloju), moraju pozivati funkcije upravljača (aplikacijske logike) kako bi dobili podatke o korisnikovom jeziku, kulturi, mjernim jedinicama, itd. Sav korisnički ulaz se prosljeñuje natrag upravljaču u aplikacijskoj logici.

5

Upravljač (ili aplikacijska logika) prihvaća korisnikov ulaz i provlači ga kroz različite procese koji pozivaju objekte aplikacijskog modela kako bi dohvatili, obradili ili pohranili podatke. Dobro napisani upravljači centralizirano provjeravaju ulazne podatke na poslužiteljskoj strani kako bi otkrili moguće sigurnosne probleme prije prosljeñivanja podataka modelu, te osiguravaju da je izlaz u sigurnom obliku za prosljeñivanje pogledu.

Model omotava funkcionalnost u Web aplikacijama. Dobar model treba biti transparentan prema pozivatelju i treba omogućavati upravljanje poslovnim procesima na visokoj razini. Uloga modela je provjeravanje je li podaci odgovaraju odreñenim poslovnim pravilima i rizicima jedinstvenim za korišteno spremište podataka. Sučelje izmeñu upravljača i modela treba biti pažljivo razmotreno kako bi se osiguralo da su podaci strogo tipizirani, a istovremeno treba biti dovoljno fleksibilno kako bi zadovoljilo buduće potrebe. Pozivi modela prema spremištu podataka se trebaju izvoditi najsigurnijom mogućom metodom koja ovisi o samom spremištu podataka (baza podataka, datoteka, Web servis itd.).

2.4 Sigurnost Web aplikacija

2.4.1 Klasifikacija prijetnji

Prema organizaciji WASC (Web Application Security Consortium) [7] postoje sljedeće klase napada na Web aplikacije:

1. Autentifikacija 1.1. Gruba sila 1.2. Neučinkovita autentifikacija 1.3. Slaba validacija prilikom obnavljanja lozinki

2. Autorizacija 2.1. Predviñanje sjednice/akreditacije 2.2. Neučinkovita autorizacija 2.3. Neučinkoviti istek sjednice 2.4. Fiksacija sjednice

3. Napadi na klijentskoj strani 3.1. Lažiranje sadržaja 3.2. Cross-site Scripting

4. Izvršavanje naredbi 4.1. Preljev meñuspremnika 4.2. Napad formatiranjem niza znakova 4.3. LDAP umetanje 4.4. Izvršavanje naredbi operativnog sustava 4.5. SQL umetanje 4.6. SSI umetanje 4.7. XPath umetanje

5. Razotkrivanje informacija 5.1. Indeksiranje direktorija 5.2. Curenje informacija 5.3. Šetnja po direktorijima 5.4. Predvidljiva lokacija resursa

6

6. Logički napadi 6.1. Zlouporaba funkcionalnosti 6.2. Uskraćivanje usluge 6.3. Neučinkovita anti-automatizacija 6.4. Neučinkovita validacija procesa

Detaljnije informacije o ovim napadima i metodama zaštite mogu se pronaći u idućim poglavljima. Kao posebnu vrstu napada valja istaknuti phishing, krañu korisničkog identiteta temeljenu na metodama socijalnog inženjeringa. Phishing napadi nisu nužno povezani s ranjivostima u Web aplikacijama, pa stoga nisu navedeni u ovoj klasifikaciji. Ipak valja napomenuti kako phishing napadi često koriste ranjivosti u Web aplikacijama, posebice reflektirani Cross-site Scripting, kako bi učinkovitije varali korisnike.

2.4.2 Statistike napada

WHID (Web Hacking Incidents Database) je javna baza podataka koju održava organizacija WASC, a sadrži podatke o poznatim napadima na Web aplikacije. U bazi se nalaze samo incidenti o kojima je izvještavano u medijima i koji se mogu povezati s nekom ranjivošću u Web aplikaciji. Baza se takoñer nastoji ograničiti samo na ciljane napade. Zbog relativno strogih kriterija uvrštenja, brojevi incidenata navedeni u WHID-u manji su nego u drugim repozitorijima iste vrste.

Prema podacima od 2002. do 2005. godine, broj incidenata vezanih za Web aplikacije je u stalnom porastu. Ako se u obzir uzme podatak da je prvih pet mjeseci 2006. godine zabilježeno 34 incidenta, može se očekivati kako će se isti trend nastaviti i dalje.

Svaki incident naveden u WHID-u nastoji se klasificirati prema WASC klasifikaciji prijetnji. Najzastupljenija klasa meñu klasificiranim incidentima je Cross-site Scripting s 44 incidenta. Slijede predviñanje sjednice/akreditacije, nedovoljna autorizacija i SQL umetanje s po 15 incidenata.

Tablica 2.1. Broj incidenata po godinama

Godina Broj

1999. 1 2000. 5 2001. 6 2002. 4 2003. 9 2004. 17 2005. 59

7

0

10

20

30

40

50

60

Bro

j in

cid

enat

a

1999. 2000. 2001. 2002. 2003. 2004. 2005.

Godina

Slika 2.1. Prikaz broja incidenata po godinama

Tablica 2.2. Broj incidenata po klasifikaciji

Klasa Broj incidenata

Cross-site Scripting 44 Nepoznato 23 Predviñanje sjednice/akreditacije 15 Neučinkovita autorizacija 15 SQL umetanje 15 Nedovoljna autentifikacija 11 Naredbe operativnom sustavu 8 Predvidljiva lokacija resursa 5 Curenje informacija 4 Slaba validacija kod obnavljanja lozinke 4 Lažiranje sadržaja 3 Ostalo 3 Zlouporaba funkcionalnosti 2 Gruba sila 1 Obezličenje 1 Uskraćivanje usluge 1 Indeksiranje direktorija 1 Razdvajanje HTTP odgovora 1 Nedovoljna protu-automatizacija 1 Poznata ranjivost 1 Šetnja po direktorijima 1 Phishing 1 Preusmjeravanje 1 Crv 1

8

3. Autentifikacija i autorizacija

Autentifikacija predstavlja proces provjere korisničkog identiteta tj. da li je korisnik zbilja onaj za kojeg se izdaje. Provjera identiteta može se izvoditi temeljem nečega:

• što „korisnik zna“ (lozinka, PIN, itd.),

• što „korisnik posjeduje“ (pametna kartica, token, itd.),

• što „korisnik jest“ (biometrijski podaci)

• ili kombinacijom navedenoga.

Proces autentifikacije kritičan je element sigurnosti informacijskog sustava, budući da predstavlja prvi korak prilikom prijave korisnika u sustav. Prilikom odabira modela autentifikacije za pojedini sustav, osim njegove sigurnosti, treba voditi računa i o praktičnosti, financijskoj isplativosti, jednostavnosti i drugim zahtjevima. Ispravno odabran model ne mora nužno biti i najsigurniji, već mora uravnoteženo ispuniti zahtjeve koji su bitni za njegovu primjenu.

3.1 Uobičajene tehnike Web autentifikacije

3.1.1 HTTP autentifikacija

Gotovo svi Web i aplikacijski poslužitelji podržavaju uporabu osnovne (eng. basic) i sažetkovne (eng. digest) autentifikacije koje su specificirane u HTTP protokolu. Kod tih vrsta autentifikacije, od preglednika se traži postavljanje prozora za dijalog koji traži od korisnika da unese svoje korisničko ime i lozinku. Nakon unosa, preglednik šalje podatke poslužitelju koji ih usporeñuje sa podacima u svom imeniku ili bazi podataka.

Napomene za osnovnu i sažetkovnu autentifikaciju:

• Osnovna autentifikacija šalje korisničko ime i lozinku u obliku jasnog teksta. Ne bi se smjela upotrebljavati ako nije u kombinaciji sa SSL-om.

• HTTP 1.1 sažetkovna autentifikacija koristi mehanizam odgovora na izazov, što je relativno sigurno za aplikacije niske vrijednosti.

Glavni razlozi protiv uporabe osnovne i sažetkovne autentifikacije su:

• nesiguran prijenos podataka,

• oba oblika autentifikacije ranjiva su na napade ponavljanjem ili s čovjekom u sredini,

• oba oblika zahtijevaju SSL kako bi se omogućio bilo kakav oblik povjerljivosti ili integriteta,

• nije omogućeno dizajniranje korisničkog sučelja i

• nije omogućena veća razina kontrole na poslužitelju.

9

Navedeni razlozi ne znače da osnovna i sažetkovna autentifikacija nije korisna. Mogu se koristiti za zaštitu administratorskih sučelja niske vrijednosti ili drugih resursa koji ne zahtijevaju višu razinu zaštite.

3.1.2 Autentifikacija temeljena na obrascima

Autentifikacija temeljena na obrascima pruža programerima aplikacije najviše kontrole nad korisničkim sučeljem, što je ujedno i glavni razlog zašto se često koristi. Autentifikacija temeljena na obrascima zahtijeva da aplikacija implementira razmjerno velik dio posla vezan za autentifikaciju i autorizaciju. Rijetki su slučajevi postojećih aplikacija u kojima je taj posao obavljen kako treba. Ako je to ikako moguće, preporučuje se uporaba postojećeg modula za autentifikaciju umjesto izrade vlastitog.

Ukoliko se ne koristi SSL protokol za enkripciju, autentifikacija temeljena na obrascima može biti ranjiva na napade ponavljanjem i na napade s čovjekom u sredini. Kako bi se sprječilo namamljivanje korisnika da svoje podatke za autentifikaciju upisuju na lažiranu stranicu, potrebno je osigurati autentifikaciju poslužitelja valjanim poslužiteljskim certifikatom.

3.1.3 Integrirana autentifikacija

Integrirana autentifikacija najčešće se koristi u intranet aplikacijama koje koriste Microsoft IIS i ASP.NET. Kod većine drugih Web poslužitelja integrirana autentifikacija nije podržana. Ovaj način autentifikacije pruža visoku razinu sigurnosti ako se koriste klijentski certifikati i Active Directory temeljen na Kerberos protokolu. Neke od prednosti su:

• lozinke se ne spremaju ni na klijentskoj, ni na poslužiteljskoj strani,

• korisnici ne moraju pamtiti lozinku,

• manje posla oko implementacije autentifikacijskih i autorizacijskih kontrola i

• uporaba postojeće autentifikacijske i autorizacijske infrastrukture.

Ipak, ovaj model rijetko se koristi u postojećim Web aplikacijama na Internetu.

3.1.4 Autentifikacija temeljena na certifikatima

Autentifikacija temeljena na certifikatima često se koristi na Web i aplikacijskim poslužiteljima. Javni certifikati se unose u autentifikacijsku bazu Web poslužitelja i usporeñuju s ponudama dolaznih sjednica. Ako se certifikati poklapaju, korisnik je autentificiran.

Kvaliteta ove vrste autentifikacije izravno je povezana s kvalitetom infrastrukture javnog ključa koja se koristi za izdavanje certifikata. Postoje neke prepreke korištenju autentifikacije temeljene na certifikatima:

• Mnogi korisnici dijele računala i trebaju nositi svoje certifikate sa sobom. To nije jednostavno ako aplikacija instalira certifikat umjesto korisnika. Većina korisnika je neupućena kako uvoziti i izvoziti certifikate.

• Upravljanje certifikatima u pregledniku nije jednostavno u većini slučajeva.

10

• Opoziv certifikata izdanih od strane korisnika je gotovo neizvediv u ekstranet okolinama.

• Da bi krajnji korisnik imao povjerenje u certifikat privatnog poslužitelja, mora donositi vlastite odluke o povjerenju, poput uvoza certifikata vrhovnog autoriteta za certifikate. Većina korisnika nije kvalificirana za donošenje takvih odluka.

• Troškovi certifikata i njihovog udjela u poslovnom modelu tvrtki za javne certifikate nije razmjeran s troškovima provizije. Stoga je održavanje baze javnih certifikata razmjerno skupo kod većeg broja korisnika.

Mnogi autoriteti za certifikate imaju loše izvedeno upravljanje certifikatima, posebno njihovo obnavljanje. Zbog toga je, kao i zbog gore navedenih razloga, autentifikacija temeljena na certifikatima doživjela propast u većini slučajeva.

3.2 Jaka autentifikacija

Jaka autentifikacija pruža veću razinu sigurnosti od korisničkih imena i lozinki. Glavna karakteristika jake autentifikacije jest da se ne oslanja samo na nešto što „korisnik zna“ (kao u slučaju s lozinkama). Umjesto toga traži se nešto što „korisnik posjeduje“ (certifikat, token, USB ključ, pametna kartica, …) u kombinaciji s nečim što „korisnik zna“ (PIN, lozinka, …). Tako se povećava razina sigurnosti u odnosu na upotrebu samog korisničkog imena i lozinke ili biometrijskih podataka.

Slučajevi prilikom kojih je potrebno koristiti jaku autentifikaciju:

• kod transakcija visoke vrijednosti,

• kod sustava koji sadrže osjetljive podatke,

• kod sustava koji zakonski zahtijevaju kontrolu knjiženja i čvrstu povezanost izmeñu podataka kontrole knjiženja i osobe,

• kod administrativnog pristupa sustavima visoke vrijednosti ili rizika.

3.2.1 Biometrijski podaci

Biometrijski podaci mogu zamijeniti nešto što „korisnik posjeduje“, ali ne mogu zamijeniti nešto što „korisnik zna“. Biometrijske podatke uvijek treba koristiti u kombinaciji s korisničkim imenom i lozinkom. Biometrija nije toliko sigurna kao ostali oblici jake autentifikacije za pristup udaljenim Web aplikacijama. Razlozi su slijedeći:

• Biometrijski ureñaji pod kontrolom su napadača. Većina jeftinijih ureñaja nije otporna na manipulacije i imaju slabu zaštitu od napada ponavljanjem.

• Ne može se utvrditi da li udaljena osoba oponaša nekog drugog. Korisnici mogu zamjenjivati druge uporabom staklenog oka ili slike iz časopisa.

• Biometrijske osobine ne mogu se opozvati. Svaka osoba ima samo dva oka, deset prstiju i jedno lice. Zbog toga je biometrija previše rizična za uporabu u sustavima visoke vrijednosti.

11

• Izmjerene biometrijske osobine se ne mijenjaju (za usporedbu, USB ključevi s ugrañenim ureñajima za kriptiranje imaju pseudo slučajan izlaz koji se mijenja svakih 30 sekundi).

• Biometrijski sustavi imaju visok postotak lažno pozitivnih rezultata u usporedbi s cijenom sustava. Kod drugih oblika jake autentifikacije, nema lažno pozitivnih rezultata.

Kad se koristi kao autentifikacija s jednom razinom (na primjer, uporaba otiska prsta bez korisničkog imena i lozinke), biometrija predstavlja najslabiji oblik autentifikacije koji postoji i nije prikladna čak ni za sustave s umjerenim rizikom. Takva uporaba treba biti ograničena na ureñaje koje korisnik posjeduje i koji ne sadrže rizične ili osjetljive podatke.

3.2.2 Jednokratne lozinke

Ureñaji za jednokratne lozinke su jeftini, ali omogućuju samo zaštitu od napada ponavljanjem. Takvi ureñaji obično imaju broj prikazan na ekranu i korisnik na aplikacijskom sučelju unosi svoje korisničko ime, lozinku i jednokratnu lozinku dobivenu od ureñaja.

Jednokratne lozinke ne pomažu u napadima s čovjekom u sredini i ne prikazuju korisniku nikakve detalje o korištenju. Stoga lažirane Web stranice mogu pokupiti jednokratnu lozinku, koja se nakon toga može upotrijebiti za prijavu u stvarni sustav.

3.2.3 Tvrdi certifikati

USB ključ, pametna kartica i drugi ureñaji koji se spajaju na sustav mogu biti najbolje rješenje za spremanje korisnikovih identifikacijskih podataka. Takvi ureñaji obično imaju ugrañenu zaštitu od manipulacije algoritma i neovlaštenog dupliciranja. Ipak, kako se ti ureñaji spajaju na sustave kojima se ne može uvijek vjerovati, moguće je da napadač postavi Web stranicu na koju se korisnik izravno autentificira. Na taj način može se zaobići, inače pouzdan autentifikacijski mehanizam.

Većina ovih ureñaja iscrtava prozor na korisničkom sučelju koji traži od korisnika dopuštenje za slanje certifikata. Napadač može izbaciti sličan prozor, dohvatiti podatke za autentifikaciju i proslijediti ih „pravom“ sustavu, pritom izvodeći sasvim druge transakciju. Ovakav napad moguć je zbog sljedećih razloga:

• korisnik ne može jednostavno utvrditi vezu izmeñu prozora za autentifikaciju i aplikacije kojoj pripada. Ovaj problem postoji sa svim JavaScript upozorenjima i nije vezan samo za ovu funkcionalnost

• većina korisnika koji su upoznati s aplikacijom jednostavno će se složiti s dijalogom kojeg vide prilikom svakog korištenja. Ako izradi dobru kopiju prozora za odobravanje aplikacije, korisnici će se složiti s njim

Mnogi drugi problemi vezani su za povezane ureñaje, uključujući probleme s potporom ako upravljački programi za ureñaje utječu na rad korisničkog računala. Povezani ureñaji pogodni su za interni pristup pouzdanom sustavu i za zatvorene i pouzdane zajednice korisnika.

12

3.2.4 Odgovor na izazov

Ureñaji za odgovaranje uzimaju vrijednost od sustava i obrañuju je na kriptografski siguran način. Rezultat te obrade koristi se kao podatak za autentifikaciju. Kalkulatori za odgovor na izazov imaju tipkovnicu, i stoga se lozinkom obično smatra PIN koji je potreban da bi korisnik pristupio kalkulatoru. Korisnik unosi svoje korisničko ime i odgovor u sustav, koji se zatim provjeravaju na autentifikacijskom poslužitelju. Iako štite od napada ponavljanjem, ureñaji za odgovaranje na izazov pate od već spomenutog problema bespojne autentifikacije. Korisnik odobrava nešto, ali ne zna što.

3.2.5 SMS odgovor na izazov

SMS odgovor na izazov funkcionira u zemljama s visokom propusnošću mreže mobilnih telefona koji podržavaju tekstualne poruke. Tipična metoda je pouzdana prijava korisnika registriranjem njihovog telefonskog broja. Kad je potrebna autentifikacija ili potpis transakcije, aplikacija šalje korisniku broj transakcije na njihov mobilni telefon, po mogućnosti s popratim tekstom kojim se provjerava što se potpisuje (npr. referentni broj transakcije).

Problemi s SMS odgovorom na izazov uključuju:

• tekstualne poruke šalju se preko javnog puta, te zato nisu prikladne za slanje osjetljivih informacija

• ukoliko se šalje iznos transakcije, korisnik može vjerovati podatku, ali napadač može poslati jedan iznos, a odobriti drugi

• korisnik ne može vjerovati izvoru SMS poruke, već samo može očekivati njen primitak za vrijeme korištenja sustava

Unatoč navedenom, SMS odgovor na izazov je bitno sigurniji od korisničkog imena i lozinke uz minimalno povećanje troškova.

3.2.6 Potpisivanje transakcija

Potpisivanje transakcija izvodi se kalkulatorima za odgovaranje na izazov. Korisniku se predstavljaju različite vrijednosti koje treba unijeti u kalkulator. Odgovor na izazov računa se na temelju tih vrijednosti. To je najjači oblik autentifikacije, jer korisnik mora unijeti detaljne informacije o transakciji. Unos drugačijih informacija rezultirat će pogrešnim odgovorom na izazov. Za najbolji rezultat, izazov treba sadržavati barem:

• referentni identifikacijski broj,

• odlazni račun i

• iznos transakcije.

Kalkulatori najčešće imaju ugrañeni sat za datum i vrijeme, pa te podatke nije potrebno unositi. Negativne strane kalkulatora su:

• Za jednu transakciju može biti potrebno 20 do 40 pritisaka tipki, na kalkulatoru što može biti problematično ako korisnik mora odobravati svaku pojedinu transakciju

13

• Ako je kalkulator spojen na korisnikovo računalo ili upotrebljava neki oblik automatiziranog unosa, sustav može biti jednostavniji za korištenje, ali korisniku ne prezentira detalje transakcije. Od njega se traži samo odobravanje prozora za potpis, što se ne razlikuje od uporabe mekog certifikata.

Stoga, iako većina kalkulatora za potpisivanje transakcija ima mogućnost spajanja na klijentsko računalo, ova mogućnost ne bi se trebala koristiti.

3.3 Savezna autentifikacija

Savezna autentifikacija znači davanje pristupa bazi podataka o korisnicima trećoj strani ili pristupanje većem broju poslužitelja s jedim korakom prijave. Glavni razlog za korištenje savezne autentifikacije je omogućavanje korisniku da, nakon što se jednom prijavi, može pristupiti svim poslužiteljima iz istog autentifikacijskog područja.

Prednosti savezne autentifikacije su:

• smanjivanje količine podataka potrebnih za prijavu koje korisnici moraju pamtiti,

• omogućavanje vlasniku poslužitelja da bude dio većeg trgovinskog partnerstva,

• omogućavanje personaliziranih usluga za korisnike koji bi inače bili anonimni.

Vlasnik resursa ne bi smio koristiti saveznu autentifikaciju ako:

• nema povjerenja u pružatelja usluge autentifikacije ili ako

• njegovi zahtjevi za poštivanje privatnosti nisu podržani od strane pružatelja usluge autentifikacije.

3.4 Problemi vezani za autentifikaciju

Autentifikacijske kontrole na klijentskoj strani

Prednost autentifikacijske kontrole na klijentskoj strani jest što se akcije korisnika provjeravaju neposredno i bez opterećenja mreže i Web poslužitelja. Ipak, kod implementacije tih provjera treba imati na umu da se one lako zaobilaze. Stoga sva poslovna pravila aplikacije moraju biti implementirana na poslužitelju.

Pozitivna autentifikacija

Kod pozitivne autentifikacije, u dizajnu aplikacije se pretpostavlja de će korisnik biti autentificiran prije nego li je sam proces autentifikacije završen. Ukoliko u kodu takve aplikacije postoji neka pogreška koja nije ispravno obrañena (nema siguran pad), može se dogoditi da se autentificiraju korisnici koji nisu ispravno prošli postupak autentifikacije. Stoga, u dizajnu aplikacije treba na svim mjestima prethodno pretpostavljati kako korisnik nije autentificiran.

14

Provjere Referer polja

Referer polje je opcionalno polje unutar HTTP zaglavlja koje obično sadrži prethodnu lokaciju koju je korisnik posjetio. Budući da se Referer polje može jednostavno izmijeniti, aplikacija ga ne bi smjela koristiti za implementaciju sigurnosnih kontrola. Ukoliko se Referer polje koristi u aplikaciji, treba razmotriti njegovu zamjenu korištenjem varijabli sjednice i autorizacijske matrice.

Pohranjivanje lozinki na pregledniku

Moderni Web preglednici omogućuju korisnicima da lakše upravljaju velikom količinom korisničkih računa pohranjujući lozinke na računalu. Kako bi se izbjegle sigurnosne implikacije nesigurnog pohranjivanja lozinki, može se koristiti opcija AUTOCOMPLETE =“Off“ unutar definicije HTML obrasca. Većina preglednika kod takvih formulara neće korisniku nuditi opciju pohranjivanja lozinki, iako to nije slučaj sa svim preglednicima.

Početni korisnički računi

Početni korisnički računi česta su ranjivost u informacijskim sustavima, budući da imaju poznata korisnička imena i lozinke koje korisnici često zaboravljaju promijeniti prije uvoñenja sustava u primjenu. Kako bi se riješio ovaj problem, potrebno je omogućiti korisniku da sve račune, posebno one administratorske, sam definira prilikom pokretanja programa.

Izbor korisničkih imena

Ako se za izbor korisničkih imena upotrebljava predvidivi postupak, aplikacija je vjerojatno ranjiva na napade uskraćivanja usluge. Primjeri takvih postupaka su brojevi bankovnih računa, matični brojevi, oznake oblika ime.prezime, adrese elektroničke pošte i ostali javni podaci. Stoga je potrebno, u situacijama gdje je to moguće, dati korisnicima mogućnost da sami biraju korisnička imena. Pritom treba voditi računa o njihovoj jedinstvenosti. Korisnička imena trebaju biti sigurna kod uporabe u HTML-u, SQL-u ili LDAP-u. Stoga je najjednostavnije dopustiti samo mala i velika slova, te brojeve. Ukoliko se primjenjuje širi skup znakova, potrebno je provesti odgovarajući postupak validacije.

Promjena lozinke

Korisnici ponekad imaju potrebu da promjene lozinku, npr. ako su je slučajno otkrili trećoj strani ili zbog nekog drugog razloga. Obrazac za promjenu lozinke treba sadržavati staru lozinku, novu lozinku i potvrdu nove lozinke. Za aplikacije visokog rizika, treba spriječiti prečesto mijenjanje lozinki, što uvjetuje voñenje evidencije starih lozinki. Evidencija starih lozinki ne smije sadržavati lozinke u jasnom obliku, već njihove sažetke.

Složenost lozinki

Mnoge sigurnosne politike i standardi propisuju složenost lozinki kojima se štite korisnički računi. Zahtjevi za složenosti lozinki najčešće se odnose na njihovu duljinu. U pravilu, lozinke ne bi smjele biti kraće od 4 znaka. Uvjetovati se može i skup znakova koji se koristi u

15

lozinki. Primjerice, lozinka mora sadržavati barem jedan broj i barem jedno slovo. Složenije lozinke teže je probiti uporabom brute-force tehnike ili napadom uz uporabu rječnika.

Reverzibilno kriptiranje lozinki

Lozinke su tajni podaci koji se ne bi trebali dekriptirati ni u kom slučaju. Djelatnici korisničke podrške ne bi smjeli čitati lozinke korisnika, već bi korisnici u slučaju gubitka lozinke trebali moći postaviti novu lozinku. Stoga ne postoji razlog za pohranjivanje lozinki u reverzibilnom obliku. Uobičajeni postupak je pohranjivanje sažetka lozinki uporabom MD5 ili SHA1 algoritama za računanje sažetka. Neki algoritmi se s vremenom pokažu slabima, pa treba razmotriti prelazak na pozdanije algoritme.

Automatizirana obnova lozinki

Automatizirano obnova lozinki je tehnika koja se koristi u mnogim sustavima kako bi se izbjegli veliki troškovi podrške korisnicima. Iako je ova tehnika prihvatljiva u mnogim sustavima, njeno korištenje značajno oslabljuje autentifikacijski mehanizam. Odgovori na pitanja koja se često postavljaju prilikom obnove lozinki lako se pronalaze u javnim zapisima (npr. majčino djevojačko prezime, boja automobila itd.). Kod mnogih implementacija od korisnika se traže podaci koje je nezakonito ili jako problematično sakupljati, primjerice matični brojevi grañanina. Sustavi s transakcijama visoke vrijednosti ne bi smjeli koristiti automatiziranu obnovu lozinki.

CAPTCHA

CAPTCHA (Completely Automated Public Turing Test to tell Computers and Humans Apart – potpuno automatizirani Turingov test za razlikovanje računala od ljudi) sustavi zamišljeni su kako bi spriječili da se računala registriraju u Web aplikacije. Na taj način se želi spriječiti u prvom redu korisnike koji koriste Web aplikacije za postavljanje propagandnog sadržaja, a pritom koriste automatizirane metode.

Slika 3.1. CAPTCHA slika

Najčešća metoda probijanja CAPTCHA testa je dohvaćanje slike i korištenje ljudi za njezino prepoznavanje. Slika se obično postavi na stranice sa sadržajima za odrasle i u zamjenu za besplatni pregled sadržaja, od korisnika se traži da riješi CAPTCHA test. Na taj način se u potpunosti razbija CAPTCHA mehanizam.

Vizualni ili zvučni CAPTCHA mehanizmi zbog svoje prirode mogu biti nepristupačni slijepim ili gluhim osobama. Ukoliko koriste boje, mogu biti nepristupačni i osobama

16

slijepima na boje (koji mogu imati udio i do 10% u muškom dijelu populacije). Stoga uporaba CAPTCHA može biti nezakonita u sustavima kod kojih je zakonski propisano da moraju biti dostupni svima.

3.5 Autorizacija

Proces autorizacije predstavlja pridruživanje skupa ovlasti autentificiranim korisnicima. Sukladno pripadnim ovlastima, korisniku se prilikom rada u sustavu dozvoljavaju izvoñenje radnji ili pristup sadržajima. Proces autorizacije mora osiguravati:

• da samo autorizirani korisnici smiju obavljati radnje dozvoljene unutar njihove razine ovlasti

• upravljanje pristupom zaštićenim resursima odlučivanjem temeljenom na ulozi ili razini ovlasti

• sprječavanje napada podizanjem razine ovlasti.

Prilikom implementacije sustava autorizacije, treba voditi računa o slijedećem:

• Pravilo najmanje ovlasti - većina postojećih Web aplikacija izvodi se s prekomjernim ovlastima na sustavima koji ih udomaćuju. Prekomjerne ovlasti olakšavaju posao napadaču, koji ih, ukoliko pronañe neki drugi sigurnosni propust, može iskoristiti za lakše preuzimanje sustava. Pravilo najmanje ovlasti uvjetuje da se Web aplikacijama daju minimalne ovlasti potrebne za njihov rad.

• Vlastite autorizacijske kontrole – većina popularnih radnih okvira za aplikacije (J2EE ili .NET) imaju dobro izrañene mehanizme autorizacije. Ipak, velik broj aplikacija ima vlastiti kod za autorizaciju što povećava složenost i izvor je mnogih grešaka. Stoga bi, ukoliko ne postoji poseban razlog za izradu vlastitog autorizacijskog koda, aplikacije trebale koristiti autorizacijske kontrole ugrañene u radni okvir.

• Centralizirane autorizacijske rutine – česta pogreška u postojećim aplikacijama je prepisivanje ili lijepljenje koda za autorizaciju na mjesta gdje je potreban. Dobro dizajnirane aplikacije centraliziraju rutine za kontrolu pristupa, posebno one za autorizaciju. Ukoliko se u takvim aplikacijama pronañe pogreška, ispravak je dovoljno obaviti na jednom mjestu.

• Autorizacijska matrica – aplikacije s kontrolom pristupa moraju provjeriti jesu li korisnicima dopušten pregled stranice ili izvoñenje radnje prije nego se stranica izradi ili radnja obavi.

• Autorizacijske kontrole na klijentskoj strani – česta pogreška u dizajnu Web aplikacije jest spremanje varijabli za kontrolu pristupa ili drugih tajnih podataka na klijentskoj strani, u obliku kolačića ili skrivenih polja u obrascima. Varijable za kontrolu pristupa trebaju se spremati na poslužitelju u obliku varijabli sjednice.

• Kontrola pristupa zaštićenim resursima – mnoge aplikacije provjeravaju je li korisniku dozvoljeno izvršavanje odreñene radnje, ali pri tom ne provjeravaju da li je dozvoljen pristup resursu koji je korisnik zatražio.

17

• Kontrola pristupa statičkim resursima – neke aplikacije generiraju statični sadržaj i dopuštaju Web poslužitelju da omogućuje pristup tim sadržajima. Ukoliko pritom nije implementirana prikladna kontrola pristupa, može se dogoditi da neautorizirani korisnici dobiju pristup tim sadržajima. Najbolje rješenje za ovaj problem jest ne spremati sadržaje u datotečni sustav Web poslužitelja, već ih izravno slati korisnicima.

3.6 Upravljanje sjednicama

3.6.1 Uvod

Sva komunikacija izmeñu klijenta i Web poslužitelja odvija se u obliku zahtjev – odgovor. Prema specifikaciji HTTP protokola [11], HTTP poslužitelj ne mora pamtiti nikakve informacije o klijentu nakon što posluži njegov zahtjev. Takav način komunikacije dobro funkcionira na poslužiteljima koji imaju statički sadržaj. Meñutim, kod Web aplikacija, javlja se potreba da poslužitelj pamti odreñene informacije o klijentu. Za tu svrhu uveden je pojam sjednice.

Sjednica označava niz od više zahtijeva i odgovora u komunikaciji izmeñu jednog klijenta i poslužitelja. Svakoj sjednici pridružuje se jedinstveni identifikator sjednice; kriptografski slučajna vrijednost koja se razmjenjuje u komunikaciji izmeñu klijenta i poslužitelja. Na poslužiteljskoj strani svakoj se sjednici pridružuje skup varijabli, što klijentskom korisniku stvara dojam aplikacije sa stanjima. Dobro upravljanje sjednicama kritično je za sigurnost Web aplikacija. Aplikacijski radni okviri, kao što su J2EE, PHP, ASP i ASP.NET imaju ugrañenu podršku za upravljanje sjednicama na nižoj razini.

Uporaba ugrañenog sustava za upravljanje sjednicama, općenito je bolja praksa od izrade vlastitog. Ipak, kod uporabe postojećeg sustava valja obratiti pažnju na njegovu inačicu. Starije inačice imaju značajne nedostatke u robusnosti i snazi kriptografije. Prilikom izrade aplikacije posebnu pozornost treba posvetiti odabiru gdje će se spremati stanje aplikacije:

• Autorizacijski podaci smiju se nalaziti isključivo na poslužitelju.

• Navigacijski podaci mogu se spremati u URL ukoliko se mogu provjeravati i ukoliko su autorizacijske provjere učinkovite.

• Prezentacijski podaci (kao što su korisnikov jezik ili tema) mogu se spremati u kolačiće .

• Osim u posebnim slučajevima, obrasci ne bi trebali sadržavati skrivena polja. Ukoliko su polja skrivena, čest je slučaj da podatke treba zaštititi i pohraniti isključivo na poslužitelju.

Podaci iz obrazaca koji zauzimaju više stranica smiju biti poslani natrag korisniku u dva slučaja:

• kad postoje kontrole integriteta i

• kad se podaci vrednuju nakon popunjavanja svake pojedine stranice ili nakon popunjavanja čitavog obrasca.

Tajni podaci (poput autorizacijskih podataka) ni u kom slučaju ne bi smjeli biti vidljivi klijentu.

18

3.6.2 Sigurnosni problemi vezani za sjednice

Dopustivo stvaranje sjednice

Mnogi radni okviri za Web aplikacije jednostavno stvaraju novu sjednicu s valjanim identifikatorom ako on već ne postoji. Taj načina rada zove se „dopustivo stvaranje sjednice“. U kombinaciji s nekim oblicima phishing napada i nedostatcima u autorizaciji, dopustivo stvaranje sjednice može otvoriti put opasnim napadima. Da bi se spriječila takva vrsta napada potrebno je osigurati sljedeće:

• Kada se stvara novi objekt sjednice za korisnika, treba osigurati da se nalazi u nije

prijavljen stanju i da mu nije dodijeljena uloga.

• Svaka zaštićena stranica ili radnja treba provjeravati autentifikacijsko stanje i autorizacijsku ulogu, prije nego obavi bilo kakvu značajniju količinu posla.

• Sve nezaštićene stranice trebaju upotrebljavati što je moguće manje resursa, kako bi se spriječili napadi uskraćivanjem usluge i kako se ne bi odavale informacije o zaštićenom dijelu aplikacije.

Izložene varijable sjednice

Neki radni okviri koriste dijeljena područja diska na Web poslužitelju za spremanje varijabli sjednice. Na primjer, PHP koristi direktorij /tmp na UNIXu i c:\windows\temp na Windowsu po početnoj konfiguraciji. Ova područja ne pružaju zaštitu za podatke o sjednicama i mogu dovesti do kompromitiranja aplikacije ako se Web poslužitelj dijeli ili provaljen.

Ovaj problem može se riješiti uvoñenjem privatnih područja u datotečnom sustavu za svakog korisnika ili za svaku pojedinu aplikaciju. Alternativno rješenje može biti kriptiranje podataka sjednice ili nespremanje osjetljivih podataka u varijable sjednice.

Slabi kriptografski algoritam sjednice

Ako upravljač sjednice izdaje oznake koje su predvidive, napadač ne mora dohvaćati varijable sjednice od udaljenih korisnika, već ih može jednostavno „pogoditi“. Oznake sjednice moraju biti jedinstvene, nepredvidive i otporne na reverzno inženjerstvo. Kako bi se izbjegao ovaj problem, potrebno je upotrebljavati pouzdani izvor slučajnih brojeva. Za veću sigurnost, oznake sjednice mogu se vezati za jednu instancu HTTP klijenta (na primjer, za IP adresu) kako bi se spriječili napadi ponavljanjem ili otimanjem sjednice. Općenito, oznake sjednice ne bi smjele biti vezane za bilo kakvu osobnu informaciju (korisničko ime, lozinku, JMBG, itd.).

Prikladna veličina ključa

Čak i uz uporabu najsigurnijih kriptografskih algoritama, aktivna oznaka sjednice može se lako predvidjeti ako prostor za ključ u oznaci nije dovoljno velik. Napadač jednostavno može „ispucati“ većinu mogućnosti uporabom brute-force skripte. Ključ mora biti dovoljno velik da spriječi ovakvu vrstu napada. Osim veličine ključa, treba voditi računa i da oznaka sjednice koristi najveći dostupni skup znakova, kako bi njena efektivna duljina bila maksimalna.

19

Istek vremena sjednice

Oznake sjednice koje imaju neograničen rok valjanosti na poslužitelju daju napadaču neograničeno vrijeme za pogañanje valjane oznake. Kao primjer, može se navesti „Zapamti me“ opcija u mnogim Web aplikacijama. Ovaj problem posebno je ozbiljan na dijeljenim klijentskim računalima.

Kako bi se izbjegao ovaj problem, potrebno je uvesti rok valjanosti za sjednicu čija duljina odgovara sigurnosnim zahtjevima aplikacije. Funkcionalnost „Zapamti me“ ne bi se smjela koristiti u aplikacijama koje zahtijevaju visoku razinu zaštite.

Detekcija napada grubom silom

Mnoge Web aplikacije ograničavaju pogañanje lozinki zaključavanjem korisničkih računa ili prestankom osluškivanja IP adrese. Istovremeno, moguće je isprobati stotine ili tisuće oznaka sjednice, a da Web poslužitelj ne poduzme nikakvu zaštitnu radnju. Mnogi sustavi za detekciju upada nisu u stanju prepoznati ovu vrstu napada. Penetracijski testovi takoñer ne mogu previdjeti ovaj nedostatak.

Moguće rješenje ovog problema je postavljanje oznaka sjednice koje se nikad ne dodjeljuju, već funkcioniraju kao „zamke“. Na taj način moguće je prepoznati da li napadač pokušava pogoditi oznaku sjednice unutar nekog raspona. Drugi način je konfiguriranje Web poslužitelja (na primjer, modula mod_security ili mod_dosevasive kod Apache poslužitelja) kako bi otkrio ovu vrstu napada.

Prijenos oznake sjednice

Ukoliko se oznaka sjednice „uhvati“ na putu preko mreže, Web aplikacija postaje izložena napadima ponavljanjem ili otimanjem sjednice. Uobičajena metoda zaštite protiv ovakve vrste napada je upotreba Secure Socket Layer (SSLv3) ili Transport Layer Security (TLSv1) protokola za enkripciju. Osim enkripcije, može se upotrijebiti i povezivanje oznake sjednice i IP adrese klijenta (ili neke druge informacije o klijentu).

Oznake sjednice i odjava

Prilikom odjave korisnika, od vitalnog je značaja uništiti podatke o sjednici. Isto treba napraviti i prilikom vremenskog isteka trajanja sjednice. Na taj se način onemogućuje ponovna uporaba sjednice u dijeljenim računalnim okolinama.

Validacija oznake sjednice

Kao i svi drugi podaci, podaci sjednice moraju biti provjereni, kako bi se osiguralo da su ispravnom obliku, da ne sadrže neočekivane znakove, te da se nalaze u tablici valjanih sjednica.

20

4. Sigurnosni problemi i metode zaštite

4.1 Validacija podataka

4.1.1 Uvod

Najčešći sigurnosni propust u Web aplikacijama je neuspješna validacija podataka koji dolaze od klijenta ili iz okoline. Ovaj propust dovodi do skoro svih glavnih ranjivosti u aplikacijama, kao što je umetanje interpretiranog koda, neovlašteni pristup datotečnom sustavu i prepunjenje meñuspremnika. Podacima koji stižu s klijentske strane se ne može ni u kom slučaju vjerovati, jer korisnik uvijek ima mogućnost da ih lažira.

Validacija podataka je provjera da li su podaci strogo tipizirani, ispravne sintakse, ispravne duljine, da li sadrže samo dozvoljene znakove i, ako su numerički, da li su u dozvoljenim intervalima.

Validacija podataka mora se provoditi na svakom sloju aplikacije. Ipak, validaciju treba prilagoditi prema funkciji koju poslužitelj izvodi dok koristi podatak. Na primjer, prezentacijski sloj treba provoditi validaciju vezanu za taj sloj, kao što je umetanje JavaScript ili HTML koda. Sloj koji pristupa bazi podataka ili LDAP imeniku treba provjeravati SQL ili LDAP umetanje.

Osim navedenog, aplikacija često mora provjeravati i jesu li podaci mijenjani na nedozvoljen način (provjera integriteta), te da li poštuju poslovna pravila aplikacije.

Provjera integriteta

Provjera integriteta se mora provoditi kad god aplikacija šalje podatke iz pouzdanog u manje pouzdano područje, kao što je klijentski preglednik ili neki drugi sustav (na primjer, ulaz za obradu naplate koji pripada trećoj strani).

Vrsta provjere integriteta (sažetak, HMAC, digitalni potpis) treba odgovarati osjetljivosti podataka koji se provjeravaju.

4.1.2 Sprječavanje mijenjanja parametara

Izvori parametara su:

• HTTP zaglavlja kao što su REMOTE_ADDR, PROXY_VIA ili slični,

• varijable okoline,

• svi GET, POST i Cookie podaci.

Svi navedeni izvori su nepouzdani i podaci koji iz njih stignu trebaju biti provjereni prije uporabe.

21

Skrivena polja

Upotreba skrivenih polja je jednostavan način za spremanje stanja aplikacije. Ipak, na taj način, osim što se otkriva unutarnja funkcionalnost aplikacije, napadaču se omogućuje manipuliranje njihovim vrijednostima. Općenito, skrivena polja je preporučljivo upotrebljavati samo u slučaju slijeda stranica.

U slučaju da je uporaba skrivenih polja neizbježna, trebaju se poštivati sljedeća pravila:

• Tajni podaci poput lozinki nikad se ne smiju slati u jasnom obliku.

• Skrivena polja trebaju imati provjeru integriteta i poželjno je da su kriptirana uporabom promjenjivog početnog vektora.

• Kriptirana skrivena polja moraju biti otporna na ponavljanje, što povlači za sobom uporabu privremenih ključeva.

• Podaci poslani korisniku moraju biti provjereni na poslužitelju kad se primi zadnji zahtjev, čak i ako su prethodno već provjereni. Na taj načina se smanjuje rizik od napada ponavljanjem.

Poželjna provjera integriteta bi trebala biti barem HMAC algoritam koji koristi SHA-256, ili digitalni potpis uporabom PGP-a.

Umjesto u skrivenim poljima, podatke je jednostavnije spremati u objekt sjednice. Upotreba objekta sjednice je najsigurnija, jer podaci nisu vidljivi korisniku, a zahtijeva se manje koda za implementaciju, te manje računalnih i mrežnih resursa.

Kod velikih količina podataka prikladno je provjerene podatke spremati u bazu podataka. Pritom je preporučljiva uporaba transakcija, pri čemu se transakcija označi kao završena tek kad su svi podaci zaprimljeni i provjereni.

Elementi HTML obrasca

Meñu dizajnerima aplikacija uvriježeno je pogrešno mišljenje kako se elementima HTML obrasca kao što su SELECT, CHECKBOX i RADIO ne može manipulirati. Zbog toga je čest slučaj da se vrijednosti dobivene iz tih elemenata ne provjeravaju na poslužiteljskoj strani.

Da bi se izbjegao ovaj problem, potrebno je provjeriti jesu li vrijednosti dobivene iz ovih polja unutar skupa koji je ponuñen korisniku prilikom slanja obrasca.

URL kodiranje

Ukoliko se podaci šalju preko URL-a, treba se provesti URL kodiranje i dekodiranje. Na taj način smanjuje se rizik od Cross Site Scripting napada. Općenito, podaci se ne bi smjeli slati preko URL-a ako ne služe za navigaciju.

HTML kodiranje

Podaci koji se šalju korisniku moraju se prethodno provjeriti, kako ne bi sadržavali nepredviñeni HTML ili JavaScript kod. HTML kodiranjem prevodi se skup znakova u pripadajuće HTML entitete. Na primjer, znak '<' (veće od) prevodi se u '<', što je sigurnija varijanta, jer sprječava umetanje nepredviñenog HTML sadržaja.

22

4.2 Umetanje interpreterskog koda

4.2.1 Umetanje na korisničkom agentu

Umetanje na korisničkom agentu označava umetanje napadačevog koda u HTTP odgovore koji se šalju korisniku nakon čega se nevedeni kod izvršava na korisničkom agentu (Web pregledniku). Umetanje na korisničkom agentu predstavlja značajan je problem za Web aplikacije. Ne postoji način da poslužitelj upravlja korisnikovom radnom okolinom (niti bi takvo što bilo primjereno) što pitanje povjerenja čini znatno složenijim.

Postoji nekoliko problema vezanih za povjerenje u podatke koji stižu od strane korisnika, kao i za pouzdanost slanja istih korisniku:

• preglednik može biti zaražen spywareom ili Trojanskim konjem

• preglednik ima nekoliko ugrañenih podsustava za prikaz uključujući: HTML, XHTML, XML, Flash, JavaScript, XUL (Firefox i Mozilla), XAML (IE 7 i noviji) itd.

Sustavi za iscrtavanje i priključci (plug-inovi) mogu biti zloporabljeni:

• pokušajima phishinga – HTML može biti uporabljen za iscrtavanje uvjerljive lažne stranice

• povredom pouzdanosti – XUL i XAML služe za stvaranje korisničkog sučelja. Ako su zlorabljeni, ničemu se s preglednika ne može vjerovati, uključujući URL i certifikate

• kao put za instaliranje zlonamjernog softvera

• kao sakupljači informacija – krañom podataka o korisniku.

Vektori umetanja u korisnički agent

• Cross-site Scripting (XSS) uporabom DHTML-a ili JavaScripta

• Flash / Shockwave

• Mocha (Netscape)

• ActiveX (samo IE)

• Priključci (kao što su QuickTime, Acrobat Reader, Windows Media Player)

• BHO (često korišten od strane spywarea i trojanskih konja)

• HTML pogreške (svi preglednici)

• XUL (Firefox) Chrome

• XAML (IE 7) Chrome

23

Izravno umetanje

Izravna refleksija najčešći je oblik umetanja u korisnički agent i jednostavna je za izvoñenje. Žrtva se namamljuje ili prisiljava da posjeti ranjivu stranicu. Prilikom posjeta, aktivira se napadačev kod koji koristi ranjivost u navedenoj stranici. Skoro svi pokušaji phishinga temelje se na izravnoj refleksiji.

Pohranjeno umetanje

Kod pohranjenog umetanja, samo umetanje se obavi prije nego korisnici posjete ranjivu stranicu. Obično se koristi u komentarima vijesti, forumima i drugim javnim aplikacijama koji se mogu na neki način iskoristiti.

XSS umetanje temeljeno na DOM-u

XSS umetanje temeljeno na DOM-u (Data Object Model) dopušta napadaču da upotrijebi DOM za prenošenje malicioznog koda u ranjivi JavaScript.

Zaštita od napada temeljenih na DOM-u:

• treba izbjegavati prepisivanje dokumenta, preusmjeravanje i ostale osjetljive radnje na klijentskoj strani. Većina ovih efekata može se postići uporabom dinamičkih Web stranica (na poslužiteljskoj strani).

• Analiziranje i osiguravanje koda na klijentskoj strani. Pregledavanje referenci na objekte na koje korisnik (napadač) može utjecati

Zaštita od izravnog i pohranjenog XSS-a

Validacijom ulaznih podataka trebaju se ukloniti sumljivi znakovi. Za zaštitu od pohranjenog XSS-a, potrebno je provesti i validaciju izlaznih podataka, ako se dobavljaju iz nepouzdanih izvora. Za primjer, u PHP-u se mogu koristiti funkcije:

• htmlentities() i htmlspecialshars() za validaciju HTML izlaza i

• urlencode() za validaciju GET zahtijeva.

Razdvajanje HTTP odgovora

Razdvajanje HTTP odgovora [10] je vrsta napada koja koristi slabost u definiciji HTTP protokola za umetanje neprijateljskog koda u preglednik korisnika. Postoje iduće klase napada:

• Cross-Site Scripting,

• trovanje priručne memorije preglednika (Web Cache Poisoning),

• Cross User napadi, te

• otimanje stranica.

Kod HTTP protokola, zaglavlja i tijelo poruke je odvojeno s dvostrukom kombinacijom znakova CR/LF. Ukoliko napadač može ubaciti podatke u zaglavlja (na primjer zaglavlje za

24

lokaciju koje se upotrebljava za preusmjeravanje), a aplikacija nema zaštitu za ubacivanje CR/LF znakova, vrlo je vjerojatno da postoji ranjivost na razdvajanje HTTP odgovora. Prilikom napada, umeću se dva odgovora. Prvi odgovor je napadačev sadržaj, a drugi je stvarni korisnikov izlaz koji se obično ignorira od strane poslužitelja.

Kako bi se aplikacija zaštitila od navedene vrste napada, potrebno je proučiti sve uporabe HTTP zaglavlja u aplikaciji, kao što su:

• postavljanje kolačića,

• preusmjeravanje,

• postavljanje MIME tipova sadržaja, veličine datoteke, itd.,

• postavljanje vlastitih zaglavlja.

Korisnički ulazni podaci koji se koriste za zaglavlja trebaju proći odgovarajuću validaciju u kojoj se eliminiraju LF ili CR/LF vrijednosti. Mnogi aplikacijski poslužitelji i radni okviri imaju ugrañenu zaštitu od razdvajanja HTTP odgovora, ali je preporučljivo implementirati je u samoj aplikaciji.

4.2.2 Umetanje na poslužitelju

SQL umetanje

SQL umetanje može se pojaviti kod bilo kojeg oblika pristupa bazi podataka. Ipak, neke oblike SQL umetanja je teže ukloniti od ostalih, na primjer:

• pohranjene procedure, posebno one sa strogo tipiziranim parametrima,

• pripremljene naredbe,

• ORM,

• dinamički upiti.

Kako bi se spriječilo SQL umetanje treba obratiti pozornost na slijedeće:

• sve SQL naredbe trebaju osiguravati da kad korisnik pristupa podacima, isti se dohvaćaju ili mijenjaju sukladno ovlastima korisnika,

• u kodu koji pristupa drugom sloju aplikacije, treba izmaknuti znakove sukladno potrebama tog sloja,

• potrebno je provesti automatizirani test kojim se pokušava izvesti SQL umetanje.

ORM umetanje

Uvriježeno je mišljenje da su ORM slojevi otporni na SQL umetanje. To mišljenje je pogrešno, budući da npr. Hibernate uključuje podskup SQL-a nazvan HQL koji omogućuje izvoñenje standardnih SQL upita. ORM sloj najčešće samo minimalno manipulira ulaznim upitom prije nego ga proslijedi bazi podataka.

Za sprječavanje ORM umetanja, treba provesti isti postupak kao za SQL umetanje s razlikom što dodatno treba provjeriti i ORM pozive koji se prevode u dinamičke upite.

25

LDAP umetanje

LDAP umetanje je rijetka pojava koja može biti jako opasna ako ispravna zaštita ne postoji. Sprječavanje LDAP umetanja je relativno lagano uporabom pozitivne validacije koja ne dozvoljava uporabu specijalnih LDAP znakova.

XML umetanje

Mnogi sustavi upotrebljavaju XML za prijenos i transformaciju podataka. Stoga je bitno da takvi sustavi nisu ranjivi na XML umetanje.

Slijepo XPath umetanje

Slijepo XPath umetanje [10] je tehnika koja omogućuje napadaču da izvede potpuni napad bez prethodnog znanja o XPath shemi.

Kako se XPath koristi za razne namjene, od pretraživanja čvorova u XML dokumentu, pa sve do autentifikacije korisnika, ova vrsta napada može biti jako opasna ako u aplikaciji postoji ranjivost.

Za sprječavanje XPath umetanja treba izmaknuti slijedeće znakove:

• < > / ' = “ – za sprječavanje izravnog umetanja parametara,

• meta znakove ( //, ? * ili slični)

Umetanje aplikacijskog koda

Umetanje aplikacijskog koda dogaña se na mjestima gdje aplikacija dinamički uključuje kod za izvoñenje, a pritom se koriste parametri dobiveni od korisnika. Da bi se spriječilo umetanje koda, potrebno je izbjegavati dinamičko uključivanje koda ili prethodno provjeriti podatke dobivene od korisnika. Korisno je i postavljanje pravila vatrozida koji sprječava vezu aplikacijskog poslužitelja prema Internetu.

4.3 Praćenje rada i rukovanje pogreškama

4.3.1 Uvod

Mnoge gospodarske grane trebaju zbog zakonskih ili drugih pravilničkih zahtijeva omogućavati:

• praćenje – sve aktivnosti koje utječu na stanje korisnika se formalno bilježe

• ostavljanje traga – moguće je odrediti gdje se aktivnost dogodila u svim slojevima aplikacije

• visoki integritet – dnevnici ne mogu biti prepisivani ili mijenjani od strane lokalnih ili udaljenih korisnika

26

Dobro osmišljene aplikacije omogućuju da dnevnici i tragovi aktivnosti imaju dvostruku namjenu pregleda i nadzora, što olakšava praćenje transakcije. Takvi sustavi trebaju posjedovati mogućnost da jednostavno prate i identificiraju potencijalnu prijevaru ili anomaliju s kraja na kraj.

4.3.2 Rukovanje pogreškama

Rukovanje pogreškama ima dva oblika: strukturirano rukovanje iznimkama i funkcijska provjera pogreške. Strukturirano rukovanje iznimkama je bolje, budući da je lakše pokriti čitavi kod. Funkcijski jezici, kao PHP 4 nemaju iznimke i stoga je teško pokriti čitav izvorni tekst programa s provjerama za sve moguće pogreške.

Motivirani napadači mogu imati koristi od poruka o pogreškama, budući da im mogu korisne dati informacije za buduće napade. Stoga je bitno osigurati da aplikacija u produkciji, ne šalje nikakve poruke o greškama korisniku. To se može postići odgovarajućom konfiguracijom radnog okvira koji aplikacija koristi. Aplikacije uvijek trebaju „sigurno padati“ (eng. fail

safe), što znači da ne smiju doći u nepoznato stanje. Takvo stanje može biti iskorišteno od strane napadača za izvoñenje nedozvoljenih radnji.

4.3.3 Bilježenje

Dnevnici se trebaju voditi na način da nije moguće prepisati stare informacije novima. Kopije dnevnika trebaju se stvarati redovito, ovisno o njihovoj veličini i opsegu. Da bi se dnevnici lakše pronalazili, potrebno ih je imenovati po pravilima.

Dnevnici mogu u stvarnom vremenu služiti kao ulaz za sustave za detekciju upada ili sustave za praćenje rada i performansi sustava. Sve komponente koje sudjeluju u stvaranju dnevničkih zapisa, trebaju biti redovito sinkronizirane s vremenskim poslužiteljem.

Dnevnici su korisni kod rekonstrukcije dogañaja nakon pojave problema, koji ne moraju nužno biti vezan za sigurnost. Rekonstrukcija dogañaja može omogućiti sigurnosnom administratoru da otkrije puni opseg upada i da lakše pokrene proces obnove. Dnevnici, u nekim slučajevima, mogu služiti kao zakonski dokaz ilegalnih radnji. U ovom slučaju je ispravno voñenje dnevnika krucijalno. Dnevnici su ponekad jedini izvor informacija o neovlaštenom upadu. Stoga se zapisi iz dnevnika u stvarnom vremenu mogu prosljeñivati sustavima za detekciju upada. Programeri aplikacija ponekad stvaraju dnevnike da dokažu kupcima kako se aplikacije ponašaju prema očekivanjima.

Politika tvrtke ili zakoni mogu zahtijevati da se, na primjer, spremaju informacije o zaglavljima svih transakcija aplikacije. Ti dnevnici se moraju čuvati na sigurnom šest mjeseci pije nego mogu biti obrisani.

Postoji nekoliko razloga zašto je potrebno planirati sustav bilježenja prija njegove implementacije. Gore navedeno pokazuje različitosti u namjeri koje rezultiraju različitim zahtjevima i strategijama. Nadalje, neuspjeh kod dizajniranja prikladnog sustava bilježenja može rezultirati nemogućnošću detekcije pokušaja nedopuštenog pristupa. Osim toga, u nekom zemljama zakoni definiraju koji osobni podaci se smiju bilježiti i analizirati. Primjerice, u Švicarskoj, tvrtke ne smiju bilježiti osobne podatke o svojim zaposlenicima bez da ih obavijeste o namjeri.

28

Zaštita od šetnje direktorijima slična je zaštiti od obezličenja. Dodatno, može se ograničiti područje datotečnog sustava kojem aplikacija može pristupati (chroot na UNIX-u ili nekim drugim načinom).

4.4.3 Nesigurno indeksiranje

Na Internetu postoje mnogi servisi koji omogućuju automatizirano pretraživanje Web stranica (Google, Yahoo, itd.). Ukoliko nema prikladne zaštite, ti servisi mogu pomoći napadaču da doñe do osjetljivih informacija o aplikaciji. Za zaštitu od nesigurnog indeksiranja trebaju se poduzeti sljedeće mjere:

• Uporabom datoteke robots.txt može se spriječiti indeksiranje spomenutih sadržaja kod većine pretraživača. Navedena datoteka se postavlja u korijenski direktorij za Web dokumente i služi kao prepuruka pretraživaćima koje sadržaje smiju, a koje ne smiju indeksirati.

• Strogom kontrola pretraživača koji su pokrenuti na poslužitelju gdje se nalazi aplikacija treba se onemogućiti pretraživanje osjetljivih sadržaja.

4.4.4 Neinterpretirane datoteke

Radni okviri za Web aplikacije će interpretirati samo vlastite datoteke korisniku, a sav drugi sadržaj prikazati kao čisti tekst ili HTML kod. Zbog toga postoji rizik da Web poslužitelj prikaže korisniku sadržaj datoteke koja nije predviñena za pregledavanje. Na taj način mogu se odati tajne informacije i podatke o konfiguraciji koje napadač može iskoristiti za napad na aplikaciju.

Za zaštitu treba poduzeti slijedeće:

• ukloniti ili premjestiti sve datoteke iz korijenskog direktorija za Web dokumente koje tamo ne pripadaju

• preimenovati datoteke za uvrštavanje tako da imaju standardne nastavke (npr. preimenovati foo.inc u foo.inc.php)

• u konfiguraciji poslužitelja i radnog okvira aplikacije, podesiti da se ne prikazuju datoteke koje nisu za to predviñene (npr. one s nastavcima .conf ili .xml)

4.5 Preljev meñuspremnika

4.5.1 Opis

Napadači koriste preljev meñuspremnika kako bi poremetili izvršni stog Web aplikacije. Slanjem pažljivo složenog ulaza, napadač može prouzročiti da Web aplikacija izvrši proizvoljni kod, što kao rezultat može imati potpuno preuzimanje kontrole na računalom. Napadači su uspjeli otkriti preljev meñuspremnika u velikom broju aplikacija i komponenti. Nedostatci preljeva meñuspremnika mogu se pronaći u Web i aplikacijskim poslužiteljima koji poslužuju dinamički ili statički sadržaj, te u samim Web aplikacijama. Preljevi

29

meñuspremnika pronañeni u široko korištenim poslužiteljskim programima često postanu javno poznati i mogu predstavljati značajan rizik korisnicima tih programa

Kad se Web aplikacijama koje imaju preljev meñupremnika pošalje veliki ulazni podatak, može se dogoditi da aplikacija ili pripadajuća baza podataka prestane ispravno raditi. Tako je moguće, ovisno o ozbiljnosti pogreške, izvesti napad uskraćivanja usluge na Web poslužitelj. Veliki ulazni podaci mogu uzrokovati i ispisivanje detaljne poruke o pogrešci, koja može dovesti do uspješnog napada na sustav.

4.5.2 Pogoñene platforme

Gotovo sve platforme za Web aplikacije pogoñene su preljevom meñuspremnika, osim nekih iznimaka:

• J2EE platforma, ukoliko se ne pozivaju nativne metode ili pozivi sustava.

• .NET, ukoliko se ne koristi nativni kod ili kod koji je označen kao nesiguran.

• PHP, ukoliko se ne pozivaju eksterni programi ili ranjive PHP ekstenzije pisane u jezicima C ili C++.

4.5.3 Preljev stoga

Preljevi stoga su najčešći oblik preljeva meñuspremnika. Osnovne karakteristike preljeva stoga su jednostavne:

• Postoje dva meñuspremnika: izvorišni meñuspremnik koji sadrži proizvoljni napadački ulaz i odredišni meñuspremnik koji je premalen da primi navedeni ulaz. Drugi meñuspremnik treba biti na stogu, iznad povratne adrese funkcije.

• Neispravni kod ne provjerava da li je prvi meñuspremnik prevelik za drugi meñuspremnik i kopira napadačke podatke u drugi meñuspremnik. Pritom prebriše podatke i povratnu adresu funkcije na stogu.

• Prilikom povratka iz funkcije, procesor dohvaća promijenjenu povratnu adresu koja pokazuje na napadački kod.

• Umjesto da se aplikacija vrati u pozivnu funkciju, izvodi se napadački kod.

Neki sustavi omogućuju isključivanje izvršavanja na stogu i na toj način se štite od ove vrste napada.

4.5.4 Preljev gomile

Gomila je područje memorije alocirano od strane aplikacije tijekom izvršavanja, a služi za spremanje lokalno deklariranih varijabli. Mogućnosti preljeva gomile jednake su onima preljeva stoga, s razlikom što se preljev stoga učinkovito može spriječiti uporabom procesora podesivog da ne izvršava stog. Meñutim, takva zaštita nije uvijek učinkovita protiv preljeva gomile.

30

4.5.5 Specijalizirani oblici preljeva meñuspremnika

Meñu specijalizirane oblike preljeva meñuspremnika spadaju:

• Formatiranje stringa – visoko specijalizirani oblik prepunjenja meñuspremnika kojim se mogu izvesti iste vrste napada, uključujući potpuno preuzimanje sustava.

• Unicode preljev – nešto teži za iskorištavanje od ostalih oblika preljeva meñuspremnika. Ovaj propust koristi izrazito štetni trojanski konj imena Code Red.

• Cijelobrojevni preljev – ova vrsta preljeva se dogaña kod operacija nad cijelim brojevima fiksne duljine.

4.5.6 Zaštita od preljeva meñuspremnika

Za zaštitu od preljeva meñuspremnika mogu se poduzeti slijedeće radnje:

• uporaba sustava koji omogućuje isključivanje izvršavanja na stogu

• izbjegavanje uporabe programskih jezika s nesigurnim rukovanjem memorije (C i C++)

• validacija korisničkih ulaza, kako bi se osiguralo da nisu preveliki i da ne sadrže nedozvoljene znakove

• ukoliko se koriste sustavi napisani u jezicima C ili C++, osigurati da je na njih primijenjeno pravilo najmanje ovlasti, te da su primijenjene najnovije zakrpe

31

5. Praktični rad

5.1 Pregled sigurnosnih alata

5.1.1 Paros

Paros [14] je alat za ručno i automatizirano ispitivanje sigurnosti Web aplikacija. Glavne značajke ovog alata su:

• HTTP/HTTPS proxy funkcija omogućuje presretanje i izmjenu zahtijeva i odgovora koje izmjenjuju preglednik i aplikacija

• Ugrañena pauk (eng. spider) funkcija za automatizirano popisivanje dostupnih dokumenata na poslužitelju

• Mogućnost filtriranja HTTP/HTTPS prometa • Moduli za automatizirano ispitivanje na ranjivosti Web aplikacija • Podrška za klijentske certifikate • Ugrañene funkcije za URL, MD5, SHA1 i Base64 kodiranje • Mogućnost pohranjivanja zabilježenog prometa

Programski paket je u potpunosti napisan u programskom jeziku Java, što ga čini platformski neovisnim Sve funkcije programa dostupne su preko grafičkog sučelja.

Slika 5.1: Sučelje alata Paros

32

5.1.2 Nikto

Nikto [13] je alat koji omogućuje automatizirano pregledavanje Web poslužitelja u potrazi za propustima u konfiguraciji i problematičnim CGI skriptama. Alat provodi testove za više od dvije tisuće sigurnosnih problema i podržava oko dvjesto različitih inačica Web poslužitelja.

Programski paket sastoji se od skupa skripti napisanih u programskom jeziku Perl. Perl skripte su platformski neovisne, ali im je za izvoñenje potreban Perl interpreter. Nikto se pokreće iz naredbene linije, a opcije testiranja se odabiru unosom u konfiguracijsku datoteku i zadavanjem argumenta u naredbenom retku. Rezultati testova se ispisuju na zaslon ili u datoteku, koja može biti u tekstualnom ili HTML formatu.

Za vrijeme testiranja, Nikto generira velik broj zahtijeva prema poslužitelju. Stoga se testiranje može lako otkriti ad strane administratora poslužitelja ili sustava za detekciju upada. Nikto ima ugrañenu funkcionalnost za prikrivanje tragova testiranja, čime se omogućuje zaobilaženje sustava za detekciju upada na poslužitelju. Tragovi testiranja prikrivaju se slijedećim tehnikama:

1. slučajno URI kodiranje

2. dodavanje niza "/../" unutar URL niza

3. prerano završavanje URL adresa,

4. dodavanje dugačkih slučajnih znakovnih nizova u HTTP zahtjevima

5. pridjeljivanje lažnih parametara datotekama,

6. korištenje TAB umjesto SPACE znaka

7. slučajna promjena malih i velikih slova unutar URL adrese,

8. korištenje znaka '\' umjesto '/' u URL adresama

9. isprepletanje sjednica.

Nikto ima mogućnost pregledavanja portova na udaljenom računalu u svrhu pronalaženja aktivnih Web poslužitelja. Kako bi se ubrzao ovaj proces, omogućeno je korištenje vanjskog alata za pregled portova.

5.1.3 Nessus

Nessus [12] je općeniti alat za ispitivanje ranjivosti računalnih mreža i udaljenih računalnih sustava. Izveden je kao poslužiteljski program za UNIX sustave, a njime se može upravljati posebnim klijentskim aplikacijama za Windows ili UNIX platformu. Nessus koristi plug-in

tehnologiju koja omogućuje jednostavno dodavanje novih definicija ranjivosti. Za pisanje definicija razvijen je i poseban programski jezik – NASL (Nessus Attack Scripting

Language). Meñu brojnim definicijama ranjivosti napisanih za Nessus, postoje i stotine njih vezane za sigurnosne probleme u Web poslužiteljima i CGI skriptama. Budući da je Nessus namijenjen općenitoj provjeri ranjivosti svih umreženih ureñaja, njegova primjena na Web poslužitelje zahtijeva pažljivo konfiguriranje.

33

Slika 5.2: Sučelje NessusWX klijenta za Nessus

5.2 Ispitivanje sigurnosti postojeće Web aplikacije

5.2.1 Uvod

U okviru praktičnog rada napravljeno je ispitivanje sigurnosti Web aplikacije dostupne na http://os2.zemris.fer.hr. Ispitivanje je obavljeno dvjema metodama:

• automatiziranim ispitivanjem uporabom alata Nessus i Nikto,

• ručnom inspekcijom koda i ispitivanjem unutar crne kutije.

5.2.2 Automatizirano ispitivanje

Automatizirano ispitivanje uporabom alata Nikto dalo je sljedeće rezultate:

-***** SSL support not available (see docs for SSL install instructions) *****

---------------------------------------------------------------------------

- Nikto 1.35/1.34 - www.cirt.net

+ Target IP: 161.53.65.23

+ Target Hostname: os2.zemris.fer.hr

+ Target Port: 80

+ Start Time: Mon Apr 3 17:36:41 2006

---------------------------------------------------------------------------

- Scan is dependent on "Server" string which can be faked, use -g to override

+ Server: Apache/1.3.27 (Win32)

34

+ Allowed HTTP Methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, P

ROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE

+ HTTP method 'PUT' method may allow clients to save files on the Web server.

+ HTTP method 'CONNECT' may allow server to proxy client requests.

+ HTTP method 'DELETE' may allow clients to remove files on the Web server.

+ HTTP method 'PROPFIND' may indicate DAV/WebDAV is installed. This may be used

to get directory listings if indexing is allowed but a default page exists. OSVD

B-13431.

+ HTTP method 'PROPPATCH' may indicate DAV/WebDAV is installed.

+ HTTP method 'TRACE' is typically only used for debugging. It should be disable

d. OSVDB-877.

+ Apache/1.3.27 appears to be outdated (current is at least Apache/2.0.54). Apac

he 1.3.33 is still maintained and considered secure.

+ Apache/1.3.27 - Windows and OS/2 version vulnerable to remote exploit. CAN-200

3-0460

+ Apache/1.3.27 - Apache 1.3 below 1.3.29 are vulnerable to overflows in mod_rew

rite and mod_cgi. CAN-2003-0542.

+ /icons/ - Directory indexing is enabled, it should only be enabled for specifi

c directories (if required). If indexing is not used all, the /icons directory s

hould be removed. (GET)

+ /manual/images/ - Apache 2.0 directory indexing is enabled, it should only be

enabled for specific directories (if required). Apache's manual should be remove

d and directory indexing disabled. (GET)

+ / - TRACE option appears to allow XSS or credential theft. See http://www.cgis

ecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACE)

+ /index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 - PHP reveals potentially

sensitive information via certain HTTP requests which contain specific QUERY str

ings. OSVDB-12184. (GET)

+ /index.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 - PHP reveals potentially









+ /index.php?module=My_eGallery - My_eGallery prior to 3.1.1.g are vulnerable to

a remote execution bug via SQL command injection. (GET)

+ /index.php?top_message=<script>alert(document.cookie)</script> -

Led-Forums allows any user to change the welcome message, and it is vulnerable t

o Cross Site Scripting (XSS). CA-2000-02. (GET)

+ /manual/ - Web server manual? tsk tsk. (GET)

+ /db.php - This might be interesting... has been seen in Web logs from an unkno

wn scanner. (GET)

+ /index.php?base=test%20 - This might be interesting... has been seen in Web lo

gs from an unknown scanner. (GET)

+ /index.php?IDAdmin=test - This might be interesting... has been seen in Web lo

gs from an unknown scanner. (GET)

+ /index.php?pymembs=admin - This might be interesting... has been seen in Web l

ogs from an unknown scanner. (GET)

+ /index.php?SqlQuery=test%20 - This might be interesting... has been seen in we

b logs from an unknown scanner. (GET)

+ /index.php?tampon=test%20 - This might be interesting... has been seen in Web

logs from an unknown scanner. (GET)

+ /index.php?topic=<script>alert(document.cookie)</script&a

mp;gt;%20 - This might be interesting... has been seen in Web logs from an unkno

wn scanner. (GET)

+ 14362 items checked - 17 item(s) found on remote host(s)

+ End Time: Mon Apr 3 17:40:38 2006 (237 seconds)

---------------------------------------------------------------------------

+ 1 host(s) tested

Iz priloženih rezultata, vidljivo je da je Nikto pronašao sljedeće propuste:

• Omogućene su problematične HTTP metode PUT, CONNECT, DELETE, PROPFIND, PROPPATCH i TRACE. Ukoliko ne postoji poseban razlog zbog kojeg su navedene metode omogućene, trebalo bi ih onemogućiti u konfiguraciji HTTP poslužitelja.

35

• Tip poslužitelja je Apache 1.3.27 za Windows platformu. Navedena verzija je zastarjela i ima poznate ranjivosti, te se stoga ne bi smjela koristiti.

• Omogućeno je indeksiranje za odreñene direktorije. Indeksiranje direktorija bi, osim u posebnim slučajevima, trebalo isključiti.

• Pronañen je Apache korisnički priručnik na poslužitelju.

• Pronañen je My_eGallery modul koji u verzijama starijim od 3.1.1.g ima ranjivosti na udaljeno SQL umetanje.

• Pronañen je Led-Forum modul ranjiv na XSS napade.

Ispitivanje uporabom alata Nessus dalo je slijedeće rezultate:

NESSUS SECURITY SCAN REPORT

Created 13.06.2006 Sorted by host names

Session Name : os2 Web

Start Time : 07.04.2006 08:57:02

Finish Time : 07.04.2006 08:57:55

Elapsed Time : 0 day(s) 00:00:53

Total security holes found : 13

high severity : 2

Medium severity : 2

informational : 9

Scanned hosts:

Name High Low Info

------------------------------------------------

Smaug.zemris.fer.hr 2 2 1

Host: Smaug.zemris.fer.hr

Open ports:

http (80/tcp)

Service: http (80/tcp)

Severity: High

The remote host appears to be running a version of Apache which is older

than 1.3.29

There are several flaws in this version, which may allow an attacker to

possibly execute arbitrary code through mod_alias and mod_rewrite.

You should upgrade to 1.3.29 or newer.

*** Note that Nessus solely relied on the version number

*** of the remote server to issue this warning. This might

*** be a false positive

Solution : Upgrade to version 1.3.29

See also : http://www.apache.org/dist/httpd/Announcement.html

Risk factor : High

CVE : CVE-2003-0542

BID : 8911


Severity: High

36

The remote host appears to be running a version of

Apache which is older than 1.3.28

There are several flaws in this version, which may allow

an attacker to disable the remote server remotely.

You should upgrade to 1.3.28 or newer.

*** Note that Nessus solely relied on the version number

*** of the remote server to issue this warning. This might

*** be a false positive

Solution : Upgrade to version 1.3.28

See also : http://www.apache.org/dist/httpd/Announcement.html

Risk factor : High

CVE : CVE-2003-0460, CVE-2002-0061

BID : 8226


Severity: Medium

The remote Web server appears to be running a version of

Apache that is less that 2.0.49 or 1.3.31.

These versions are vulnerable to a denial of service attack where a remote

attacker can block new connections to the server by connecting to a listening

socket on a rarely accessed port.

Solution: Upgrade to Apache 2.0.49 or 1.3.31.

CVE : CVE-2004-0174

BID : 9921


Severity: Medium

The remote Web server appears to be running a version of Apache that is older

than version 1.3.32.

This version is vulnerable to a heap based buffer overflow in proxy_util.c

for mod_proxy. This issue may lead remote attackers to cause a denial of

service and possibly execute arbitrary code on the server.

Solution: Don't use mod_proxy or upgrade to a newer version.

Risk factor: Medium

CVE : CVE-2004-0492

BID : 10508

Service: general/tcp

Severity: Info

161.53.65.23 resolves as Smaug.zemris.fer.hr.


Severity: Info

The following directories were discovered:

/icons, /manual

While this is not, in and of itself, a bug, you should manually inspect

these directories to ensure that they are in compliance with company

security standards

Other references : OWASP:OWASP-CM-006


Severity: Info

The remote host is running Microsoft Windows 2000 Professional Service Pack 4


Severity: Info

37

Synopsis :

Debugging functions are enabled on the remote HTTP server.

Description :

The remote Webserver supports the TRACE and/or TRACK methods. TRACE and TRACK

are HTTP methods which are used to debug Web server connections.

It has been shown that servers supporting this method are subject to

cross-site-scripting attacks, dubbed XST for "Cross-Site-Tracing", when

used in conjunction with various weaknesses in browsers.

An attacker may use this flaw to trick your legitimate Web users to give

him their credentials.

Solution :

Disable these methods.

See also :

http://www.kb.cert.org/vuls/id/867593

Risk factor :

Low / CVSS Base Score : 2

(AV:R/AC:L/Au:NR/C:P/A:N/I:N/B:N)

Plugin output :

Solution :

Add the following lines for each virtual host in your configuration file :

RewriteEngine on

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

CVE : CVE-2004-2320

BID : 9506, 9561, 11604


Severity: Info

A Web server is running on this port


Severity: Info

The remote Web server type is :

Apache/1.3.27 (Win32)

Solution : You can set the directive 'ServerTokens Prod' to limit

the information emanating from the server in its response headers.


Severity: Info

Iz rezultata je vidljivo kako je Nessus pronašao slijedeće propuste:

• Tip poslužitelja je Apache 1.3.27 za Windows platformu. Navedena verzija je zastarjela i ima poznate ranjivosti, te se stoga ne bi smjela koristiti.

38

• Pronañeni su dokumenti koji pripadaju početnoj konfiguraciji poslužitelja: /icons i /manual.

• Omogućene su TRACE i/ili TRACK metode koje u odreñenim okolnostima mogu uzrokovati ranjivosti na XSS napade.

5.2.3 Ručno ispitivanje

Ručno ispitivanje obavljeno je inspekcijom koda i ispitivanjem unutar crne kutije. Kao radni okvir, korišten je dokument OWASP Web Application Penetration Cheklist. Ispitivanjem nisu obuhvaćeni propusti u konfiguraciji poslužitelja. Pronañene slijedeće ranjivosti:

Kategorija: KontrolaPristupa, ProvjeraUlaza.XSS Oznaka: OWASP-AC-001, OWASP-IV-005 Naziv: Razbijena kontrola pristupa manipulacijom parametara, Cross-site Scripting Opis: Propust se nalazi u datoteci index.php. Slijedi izvadak iz koda vezan za propust: // oveeride command za show

@$action = $_GET['show'];

if(isset($action)) {

$show_file = $action.'.htm';

$action = 'show';

}

.

.

.

//prikaz datoteke (index.php?show=ime_bez_nastavka)

if($action == 'show' && file_exists($show_file)) {

$content = implode("",(@file($show_file)));

break;

}

U kodu se može vidjeti kako se za argument funkcije file() koristi varijabla $show_file. Ta varijabla dobiva se iz globalne varijable $_GET['show'] na koju se dodaje nastavak '.htm'. Kako se sadržaj varijable $_GET['show'] ne provjerava prije korištenja, potencijalni napadač može manipulacijom parametra učitati bilo koju datoteku s nastavkom '.htm' kojoj PHP interpreter može pristupiti. Npr., zahtijevom oblika http://os2.zemris.fer.hr/index.php?show=../../admin/password napadač može učitati sadržaj datoteke u drugom direktoriju.To se ne odnosi samo na lokalne datoteke, budući da funkcije file_exists() i show_file() u novijim verzijama PHP-a omogućuju pristupanje udaljenima datotekama ako im se kao argument preda URL. Time se otvara put korištenju aplikacije kao HTTP proxya u svrhu prikrivanja tragova za druge ilegalne radnje na Internetu. Osim navedenih oblika zlouporabe, ovaj propust može se iskoristiti i za Cross Site Scripting napad na klijentsku stranu aplikacije. Za primjer, uzmimo da napadač postavi FTP poslužitelj s adresom ftp://ftp.hackersite.com/ i na njega datoteku malscript.htm koja sadrži HTML ili JavaScript kôd. Ako napadač uspije navesti korisnika da klikne na link oblika http://os2.zemris.fer.hr/index.php?show=ftp://ftp.hackersite.com/malscript, kôd iz datoteke malscript.htm izvršiti će se na klijentskom pregledniku. U toj datoteci može se nalaziti HTML obrazac za unos korisničkog imena i lozinke koji podatke šalje poslužitelju pod kontrolom

39

napadača. Osim HTML koda, u datoteci se može nalaziti i JavaScript kôd koji služi za krañu privatnih podataka korisnika (npr. cookiea) ili za druge oblike zlouporabe. Rješenje: Provjeriti valjanost parametra prije nego se upotrijebi kao argument fukcije file(). Kategorija: Autentifikacija Oznaka: OWASP-AUTHN-001 Naziv. Zahtijev za autentifikacijom ne šalje se preko HTTPS protokola Opis: Kako se zahtijev za autentifikacijom ne šalje preko HTTPS protokola, korisnik na klijentu ne može utvrditi da li je udaljeni poslužitelj zbilja onaj za kojeg se izdaje. Rješenje: Upotreba HTTPS protokola kod slanja zahtijeva za autentifikaciju. Kategorija: Autentifikacija.Korisnik Naziv: OWASP-AUTHN-003 Ime: Korisničko ime i lozinka ne šalju se preko kriptiranog kanala Opis: Kako se korisničko ime i lozinka šalju u obliku jasnog teksta, moguće je da ih napadač sazna osluškivanjem mrežnog prometa. Rješenje: Upotreba SSL enkripcije za vrijeme slanja korisničkog imena i lozinke. Kategorija: Autentifikacija.Korisnik Oznaka: OWASP-AUTHN-008 Naziv: Nedostatak zaključavanja lozinki Opis: Budući da se korisnički računi ne zaključavaju ako se pogrešna lozinka unese više puta zaredom, moguće je provaljivati lozinku brute-force tehnikom. Rješenje: Uvesti privremeno zaključavanje korisničkih računa ako se pogrešna lozinka unese odreñen broj puta zaredom (npr. 5). Kategorija: Autentifikacija.UpravljanjeSjednicama Oznaka: OWASP-AUTHSM-003 Naziv: Ponovna upotreba sjednice Opis: Identifikator sjednice šalje se preko nekriptiranog kanala. To omogućuje napadaču da osluškivanjem mrežnom kanala sazna identifikator sjednice i da se prijavi u sjednicu drugog korisnika. Isti identifikator sjednice koristi se prije i nakon autentifikacije korisnika, što omogućuje napad fiksacijom sjednice[6]. Rješenje: Nakon što korisnik proñe proces autentifikacije, promijeniti identifikator sjednice. U PHP-u se to može postići pozivom funkcije session_regenerate_id(). Dok je korisnik prijavljen, koristiti SSL enkripciju i postaviti sigurnosni bit na cookieu koji se koristi za spremanje identifikatora sjednice.

5.3 Web aplikacija s primjerima ranjivosti

5.3.1 Uvod

Kao dio praktičnog rada izrañena je primjenski sustav s primjerima čestih ranjivosti. Aplikacija je napisana u skriptnom jeziku PHP s pripadajućom MySQL bazom podataka.

40

Ranjivosti ugrañene u aplikaciju su:

• SQL umetanje, • pohranjeni XSS, • reflektirani XSS, • neučinkovita autorizacija i • razbijena kontrola pristupa.

5.3.2 SQL umetanje

Kao primjer SQL umetanja izrañen je obrazac za autentifikaciju s pripadajućom skriptom.

Slika 5.3. Obrazac za autentifikaciju

Nakon što korisnik unese korisničko ime i lozinku u obrazac, oni se proslijeñuju skripti kao GET parametri username i password. Skripta zatim provjerava da li su podaci točni pretražujući tablicu u bazi podataka.

Slijedi dio koda kojim se obavlja provjera:

$logged = FALSE;

if(isset($_GET['username'])){

require("db.inc.php");

$query = "SELECT username FROM user_sql WHERE username='" .

$_GET['username'] . "' AND password='" . md5($_GET['password'])."'";

$result = mysql_query($query);

if(mysql_num_rows($result) == 1){

echo "Dobrodošli " . mysql_result($result, 0) . "!";

$logged = TRUE;

}else{

echo "Pogrešno korisničko ime ili lozinka!";

}

}

Iz priloženog koda je vidljivo kako se iz GET parametara izravno konstruira SQL upit koji se prosljeñuje bazi podataka. Ako se kao username parametar pošalje niz "' OR 1=1 LIMIT 1 #", a kao password parametar pošalje niz "bilosto", SQL upit će izgledato ovako:

SELECT username FROM user_sql WHERE username='' OR 1=1 LIMIT 1 # AND

password='bilosto'

41

Znak '#' u MySQL-u označava komentar i sav kod koji se nalazi iza njega se zanemaruje prilikom prevoñenja upita. Zbog toga dio upita kojim se propisuje uvjet za lozinku neće biti izvršen, već će ovaj upit jednostavno vratiti vrijednost username polja iz prvog retka kojeg dohvati. Na taj način se korisnik može autentificirati bez znanja korisničkog imena i lozinke.

Kako bi se izbjeglo SQL umetanje, potrebno je sve ulazne podatke koji stižu s korisničke strane validirati prije proslijeñivanja bazi podataka. Validacija se može obaviti na više načina: uporabom regularnih izraza, provjeravanjem tipova podataka ili izmicanjem specijalnih znakova. Primjerice, za MySQL se mogu izmaknuti jednostruki i dvostruki navodnici uporabom lijeve kose crte ('\').

5.3.3 Reflektirani XSS Kao primjer reflektiranog Cross-site Scriptinga izrañena je jednostavna tražilica za pretraživanje mjesta u Republici Hrvatskoj.

Slika 5.4. Obrazac za pretraživanje mjesta

Ako se za naziv mjesta upiše 'Babina Greda', tražilica će vratiti rezultat slijedećeg oblika:

Slika 5.5. Rezultati pretraživanja

Slijedi isječak iz koda koji služi za ispis rezultata pretraživanja: if(isset($_GET['naziv']))

echo 'Rezultati pretraživanja za ' . $_GET['naziv'] . ':;

Ovaj isječak služi za ispis imena traženog mjesta natrag prema korisniku. Kako se pritom koristi GET parametar naziv bez prethode validacije, preko ove stranice je moguće izvesti

42

reflektirani Cross-site Scripting napad. Primjerice, ako se kao podatak za pretraživanje unese sljedeći niz: <script> alert("Kod izvrsen!"); </script>

korisniku će se prikazati JavaScript okvir za dijalog kao na slici dolje.

Slika 5.6. JavaScript okvir za dijalog

što znači da je na klijenskom pregledniku izvršen JavaScript kod. Potencijalni napadač može iskoristiti ovaj propust tako da konstruira poveznicu na ranjivu stranicu u kojoj je kao vrijednost GET parametra postavljen maliciozni HTML ili JavaScript kod. Nakon toga se žrtva namamljuje da slijedi poveznicu što rezultira izvoñenjem malicioznog koda na pregledniku žrtve. Ova ranjivost često se koristi u phishing prijevarama.

Za sprječavanje XSS-a potrebno je provesti validaciju svih podataka pristiglih od korisnika prije nego se upotrijebe za konstruiranje HTML izlaza. Validacija se može provesti izbacivanjem znakova koji imaju posebno značenje u HTML-u (primjerice, '<' i '>').

5.3.4 Neučinkovita autorizacija

Kao primjer za neučinkovitu autorizaciju izrañen je obrazac za plaćanje u bankarskoj aplikaciji.

U obrascu korisnik popunjava podatke o nalogu i izabire polazni račun s kojeg želi izvršiti plaćanje. Odabir se vrši pomoću radio dugmeta, a korisniku su ponuñeni samo njegovi računi.

<input type="radio" name="racun" value="321321012"><td>321321012

Nakon što korisnik popuni nalog, broj polaznog računa se šalje u obliku POST parametra. Iako korisnik u pregledniku ne može odabrati tuñi račun, to može učiniti manipulacijom POST parametra. Sve što treba napraviti je izmjeniti zahtijev i poslati ga poslužitelju uporabom telnet ili proxy alata. Ukoliko na poslužiteljskoj strani ne postoje odgovarajuće autorizacijske kontrole, naplata će se izvršiti s računa drugog korisnika.

Ovakve pogreške dogañaju se zbog pogrešnog uvjerenja da korisnik ne može manipulirati parametrima ako mu to nije dozvoljeno u pregledniku. Primjeri su radio, select i checkbox

elementi u HTML obrascima ili GET parametri u poveznicama. Budući da stižu od korisnika ne mogu zamijeniti autorizacijske kontrole na poslužitelju.

43

Slika 5.7. Obrazac za plaćanje

5.3.5 Razbijena kontrola pristupa

Kao primjer razbijene kontrole pristupa izrañena je skripta preko koje korisnik može pregledavati HTML dokumente koji se nalaze na poslužitelju, ali nisu izravno dostupni preko Weba. Skripta korisniku prezentira dokumente koje može pregledavati kao poveznice. U poveznicama je kao GET parametar show navedeno ime pripadajuće HTML datoteke.

<a href="access_control.php?show=a3.html">Broken Authentication and Session

Management</a>

Slijedi isječak iz koda koji služi za prikaz HTML datoteke:

if (isset($_GET['show'])){

if(file_exists('./docs/' . $_GET['show']))

echo file_get_contents('./docs/' . $_GET['show']);

Iz priloženog koda se vidi kako se argument funkcije file_get_contents() konstruira iz GET parametra bez prethodne validacije. Zbog toga je moguće da potencijalni napadač iskoristi skriptu tako da manipulacijom GET parametra pristupi drugim datotekama u sustavu. Primjerice, zahtijevom slijedečeg oblika:

GET /access_control.php?show=../../../etc/password

44

napadač može dohvatiti datoteku s lozinkama na poslužitelju i tako kompromitirati čitavi sustav.

Kao i za mnoge druge sigurnosne probleme, i ovom rješenje leži u validaciji podataka. Ispravnom validacijom treba provjeriti sve ulazne podatke koji se koriste kao argumenti funkcija u programu.

45

6. Zaključak

Sigurne Web aplikacije ne nastaju same od sebe. One su rezultat truda i promišljanja svih koji su uključeni u proces izrade i primjene aplikacije. Od dizajna i programiranja, do uvoñenja u primjenu i održavanja, sve faze životnog ciklusa aplikacije trebaju sadržavati kontrole za postizanje tražene razine sigurnosti.

Glavni uzrok najozbiljnijih sigurnosnih propusta u Web aplikacijama su programerske pogreške. Programeri često ne razmišljaju o mogućnosti da bi netko mogao pokušati iskoristiti slabosti u njihovoj aplikaciji. Stoga je podizanje svijesti o sigurnosti najpotrebnije upravo kod programera.

Nakon analize sigurnosnih alata obavljene u okviru ovoga rada može se zaključiti kako automatizirana provjera ranjivosti još uvijek ne može zamijeniti ručno testiranje. Alati za automatiziranu provjeru su vrlo korisni kod otkrivanja ranjivosti na poslužitelju ili propusta u konfiguraciji, ali još uvijek nisu dovoljno učinkoviti kako bi otkrili bitne ranjivosti na aplikacijskom sloju sustava.

Luka Pauk

__________________

46

7. Literatura

[1] The Open Web Application Security Project – OWASP, http:/www.owasp.org/ [2] OWASP Guide to Building Secure Web Applications and Web Services v2.0,

http://www.owasp.org/index.php/Category:OWASP_Guide_Project [3] Cgisecurity.net, http://www.cgisecurity.net/ [4] Penetration Testing for Web Applications (Part One), SecurityFocus, http://www.securityfocus.com/infocus/1704 [5] Penetration Testing for Web Applications (Part Two), SecurityFocus, http://www.securityfocus.com/infocus/1709 [6] Penetration Testing for Web Applications (Part Three), SecurityFocus, http://www.securityfocus.com/infocus/1722 [7] Web Application Security Consortium, http://www.Webappsec.org/ [8] phpAdvisory, http://www.phpadvisory.com/ [9] Session Fixation Vulnerability in Web-based Applications, ACROS Security, http://www.acrossecurity.com/papers/session_fixation.pdf [10] Watchfire Security Zone Whitepapers, http://www.watchfire.com/securityzone/whitepapers.aspx [11] Hypertext Transfer Protocol, http://www.w3.org/Protocols/ [12] Nessus, http://www.nessus.org/ [13] Nikto, http://www.cirt.net/code/nikto.shtml [14] Parosproxy.org, http://www.parosproxy.org/

http://www.owasp.org/

http://www.owasp.org/index.php/Category:OWASP_Guide_Project

http://www.cgisecurity.net/

http://www.securityfocus.com/infocus/1704



http://www.webappsec.org/

http://www.phpadvisory.com/

http://www.acrossecurity.com/papers/session_fixation.pdf

http://www.watchfire.com/securityzone/whitepapers.aspx

http://www.w3.org/Protocols/

http://www.nessus.org/

http://www.cirt.net/code/nikto.shtml

http://www.parosproxy.org/index.shtml

Sažetak U ovom radu su opisani problemi vezani za sigurnost mrežnih primjenskih sustava. Navedeni su uzroci sigurnih problema i načini njihovog rješavanja. Opisane su metode izrade i održavanja sigurnih primjenskih sustava. Na stvarnom primjeru, opisani su postupci automatiziranog i ručnog ispitivanja sigurnosti, te alati za provjeru ranjivosti primjenskih sustava. U nizu primjera, prikazani su česti sigurnosni propusti u primjenskim sustavima i načini njihovog rješavanja.

Abstract This paper describes problems in the Web application security area. It defines sources of security problems and ways for solvig these problems. It also describes methods for developing and maintaining secure Web Application systems. Using the real world example, it describes procedures for manual and automated security testing, and tools for Web application vulnerability scanning. It aslo shows common security mistakes in Web applications and ways of fixing these mistakes in the series of examples.

Documents

SIGURNOST MREŽNIH PRIMJENSKIH SUSTAVAsigurnost.zemris.fer.hr/ns/2006_pauk/diplomski.pdf · 2006-07-08 · postaju sve zastupljeniji, kako na Internetu, tako i u raznim intranet okolinama