FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
SPECIJALISTIČKI STUDIJ “INFORMACIJSKA SIGURNOST”
Ranjivosti web-aplikacija prema OWASP-u
Seminarski rad iz predmeta “Sigurnost računalnih mreža”
Iva Musić
Sadržaj
1.
Uvod ................................................................................................................................................ 3
2.
Umetanje ......................................................................................................................................... 4
3.
2.1.
Primjeri napada ....................................................................................................................... 4
2.2.
Izbjegavanje napada umetanjem ............................................................................................ 6
2.2.1.
Parametrizirani izrazi ....................................................................................................... 6
2.2.2.
Izbjegavanje ..................................................................................................................... 6
2.2.3.
Provjera uzoraka .............................................................................................................. 7
2.2.4.
Dozvole za bazu podataka ............................................................................................... 7
Cross-site scripting .......................................................................................................................... 8
3.1.
4.
Tipovi XSS ranjivosti................................................................................................................. 8
3.1.1.
Nepostojana XSS ranjivost ............................................................................................... 9
3.1.2.
Postojana XSS ranjivost ................................................................................................... 9
3.2.
Primjeri iskorištavanja XSS ranjivosti..................................................................................... 10
3.3.
Smanjivanje prijetnje ............................................................................................................. 10
3.3.1.
Kontekstualno kodiranje/provjera ulaznog niza ........................................................... 10
3.3.2.
Sigurnosna provjera nepouzdanog HTML unosa........................................................... 11
3.3.3.
Sigurnost cookieja ......................................................................................................... 11
3.3.4.
Onemogućavanje skripti ................................................................................................ 11
3.3.5.
Nadolazeće obrambene tehnologije ............................................................................. 12
Loša autentifikacija i upravljanje sjednicama ................................................................................ 13
4.1. Autentifikacija............................................................................................................................. 13
4.1.1. Smanjivanje prijetnje kod autentifikacije ............................................................................ 13
4.2. Upravljanje sjednicama .............................................................................................................. 15
4.2.1. Svojstva identifikatora sjednice........................................................................................... 16
4.2.2. Implementacija upravljanja sjednicama .............................................................................. 17
4.2.3. Životni ciklus identifikatora sjednice ................................................................................... 19
4.2.4. Istek sjednice ....................................................................................................................... 20
4.2.5. Dodatne zaštite za upravljanje sjednicom na klijentskoj strani .......................................... 22
4.2.6. Otkrivanje napada na sjednicu ............................................................................................ 23
5.
6.
Nesigurne reference na objekte .................................................................................................... 25
5.1.
Primjer ranjivosti ................................................................................................................... 25
5.2.
Provjera ranjivosti na nesigurne reference na objekte ......................................................... 26
5.3.
Zaštita od nesigurnih referenci na objekte ........................................................................... 26
Krivotvorenje zahtjeva na drugom sjedištu................................................................................... 28
6.1. Primjer napada ........................................................................................................................... 28
6.2. Sprječavanje napada .................................................................................................................. 29
7.
Pogrešno postavljene sigurnosne postavke .................................................................................. 30
7.1. Primjeri pogrešno postavljenih sigurnosnih postavki ................................................................ 31
7.2. Sprječavanje pogrešno postavljenih sigurnosnih postavki......................................................... 31
8.
Nesigurna pohrana šifriranih podataka......................................................................................... 32
8.1. Primjeri nesigurne pohrane šifriranih podataka ........................................................................ 32
8.2. Sprečavanje kriptografskih nedostataka .................................................................................... 32
8.3.
9.
Zaštita od kriptografskih nedostataka ................................................................................... 33
Nezaštićeni pristup URL-ovima...................................................................................................... 34
9.1. Primjer nezaštićenog pristupa URL-ovima ................................................................................. 34
9.2. Provjera sigurnosti pristupa URL-ovima ..................................................................................... 35
9.3. Zaštita pristupa URL-ovima ........................................................................................................ 35
10. Nedovoljna zaštita na transportnom sloju .................................................................................... 37
10.1. Primjer nedovoljne zaštite na transportnom sloju................................................................... 37
10.2. Provjera sigurnosti na transportnom sloju............................................................................... 38
10. 3. Zaštita na transportnom sloju ................................................................................................. 38
11. Neprovjerena preusmjeravanja i proslijeđivanja .......................................................................... 39
11.1. Primjeri neprovjerenih preusmjeravanja i proslijeđivanja ....................................................... 39
11.2. Sprječavanje neprovjerenih preusmjeravanja i proslijeđivanja ............................................... 39
12. Popis literature .............................................................................................................................. 41
1. Uvod
The Open Web Application Security Project (OWASP) je otvorena zajednica posvećena tome da
omogući organizacijama razvijanje, kupnju i održavanje aplikacija koje se mogu smatrati sigurnima.
OWASP svake tri godine izrađuje dokument kojem je cilj ojačati svijest o važnosti sigurnosti web
aplikacija. OWASP Top Ten predstavlja široki konsenzus o tome koji su najkritičniji sigurnosni propusti
web aplikacija. Suradnici na projektu su razni sigurnosni stručnjaci iz cijelog svijeta koji su podijelili
svoje znanje za izradu ovog popisa.
Usvajanje savjeta iz dokumenta OWASP Top Ten je možda najučinkovitiji prvi korak prema promjeni
kulture razvoja aplikacija unutar organizacije u onu koja proizvodi siguran kôd.
Na OWASP-ovom popisu deset najvećih ranjivosti iz 2010. godine su:
A1. Umetanje
A2. Cross-site scripting
A3. Loša autentifikacija i upravljanje sjednicama
A4. Nesigurne reference na objekte
A5. Krivotvorenje zahtjeva na drugom sjedištu
A6. Pogrešno postavljene sigurnosne postavke
A7. Nesigurna pohrana šifriranih podataka
A8. Nezaštićeni pristup URL-ovima
A9. Nedovoljna zaštita na transportnom sloju
A10. Neprovjerena preusmjeravanja i proslijeđivanja
U daljnjem tekstu biti će pobliže objašnjena svaka od navedenih ranjivosti, biti će navedeni uvjeti u
kojima se ranjivosti pojavljuju, te kako se one mogu iskoristiti. Osim toga biti će navedeni i načini na
koje se aplikacije može zaštititi od ovih ranjivosti.
2. Umetanje
Nedostaci vezani uz umetanje javljaju se kada aplikacija preuzima i obrađuje nepouzdane podatke.
Napadi umetanjem su vrlo rasprostranjeni, posebice su česti u SQL, LDAP i XPath upitima, OS
naredbama itd. [2]
SQL umetanje je tehnika koja se često koristi za napad na web stranicu. Umetanje se obavlja
uključujući dijelove SQL izraza u ulazno polje web obrasca s ciljem prosljeđivanja SQL naredbe bazi
podataka (npr. za slanje sadržaja baze podataka napadaču). SQL umetanje je tehnika ubrizgavanja
kôda koja iskorištava sigurnosni propust u kôdu web stranice.
Ranjivost se iskorištava kada se iz korisničkog unosa krivo filtriraju evakuacijski znakovi ugrađeni u
SQL naredbe ili kada je unos nepravilno upisan i neočekivano izvršen. SQL naredbe se tada umeću iz
web obrasca u bazu podataka (kao i upiti) kako bi promjenili sadržaj baze podataka ili izvukli iz nje za
napadača podatke kao što su brojevi kreditnih kartica ili lozinke.
SQL umetanje je uglavnom poznat kao napad na web stranice, ali se može koristiti kao napad na bilo
koju vrstu SQL baze podataka.
U produkcijskom okruženju je primijećeno da je učestalost napada na aplikacije u prosjeku 71
pokušaj u satu.
Napad SQL umetanjem (SQLIA) sadrži pet glavnih pod-klasa ovisno o tehničkim aspektima napada na
implementaciju:
-
Klasična SQLIA
Zaključivanje SQL umetanjem
Interakcija s SQL umetanjem
SQLIA specifična za sustave upravljanja bazama podataka
Složena SQLIA
2.1.
Primjeri napada
Primjer 1: Pogrešno filtriranje znakova „escape“
Ovaj oblik SQL umetanja događa se kada se iz korisničkog unosa ne filtriraju znakovi „escape“, te se
proslijeđuju u SQL naredbu. To rezultira mogućim manipulacijama izjava koje se provode na bazi od
strane krajnjeg korisnika zahtjeva.
Sljedeća linija kôda ilustrira ovu ranjivost:
statement = "SELECT * FROM users WHERE name = '" + userName + "';"
Ovaj SQL kôd je dizajniran kako bi izvukao evidenciju o navedenom korisničkom imenu iz svoje baze
korisnika. Međutim, ako je varijabla "userName" izrađena na specifičan način od strane zlonamjernog
korisnika, SQL naredba može učiniti više nego što joj je autor namijenio. Na primjer, ako se varijabla
"userName" postavi kao:
' or '1'='1
ili pomoću komentara čak i blokira ostatak upita (postoje tri vrste SQL komentara):
' or '1'='1' -- '
' or '1'='1' ({ '
' or '1'='1' /* '
dobiva se jedna od sljedećih SQL naredbi:
SELECT * FROM users WHERE name = '' OR '1'='1';
SELECT * FROM users WHERE name = '' OR '1'='1' -- ';
Ako se taj kôd koristi u postupku autentifikacije, onda se na ovaj način može na silu odabrati valjano
korisničko ime, jer je izjava '1 '= '1' uvijek istinita.
Sljedeća vrijednost varijable "userName" u niže navedenoj izjavi će uzrokovati brisanje baze "users"
kao i dohvaćanje svih podataka iz baze "userinfo" (u suštini otkriva podatke o svakom korisniku),
koristeći API koji dozvoljava višestruke izraze:
a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't
S ovim unosom, konačna SQL naredba je definirana kao:
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM
userinfo WHERE 't' = 't';
Dok većina implementacija SQL servera omogućuje višestruke izjave koje se izvršavaju iz jednog
poziva na ovaj način, neki SQL API-ji kao što je PHP-ova funkcija mysql_query(); to ne dopuštaju iz
sigurnosnih razloga. Na taj način napadača se sprječava pri ubrizgavanju potpuno odvojenih upita, ali
ne zaustavlja ih se od modificiranja upita.
Primjer 2: Nepravilno rukovanje tipovima podataka
Ovaj oblik SQL umetanja događa se kada se ne provjerava tip podataka unesen u korisničko polje. To
bi se moglo dogoditi kada se u SQL izjavi koristi brojčano polje, ali programer ne provjerava da bi
potvrdio da je korisnikov unos numerički. Na primjer:
statement := "SELECT * FROM userinfo WHERE id = " + a_variable + ";"
Iz ove izjave je jasno da je autor namjeravao koristiti a_variable kao broj koreliran s poljem "id".
Međutim, ako je to u stvari string onda krajnji korisnik može manipulirati izjavom kako želi,
zaobilazeći tako potrebu za znakom „escape“. Na primjer, postavljanje a_variable na:
1;DROP TABLE users
će izazvati brisanje tablice „users“ iz baze podataka, jer bi SQL izjava bila izvedena kao:
SELECT * FROM userinfo WHERE id=1;DROP TABLE users;
Primjer 3: Slijepo SQL umetanje
Slijepo SQL umetanje se koristi kada je web aplikacija ranjiva na SQL umetanje, ali rezultati umetanja
nisu vidljivi napadaču. Stranica sa prepoznatom ranjivosti možda neće prikazati podatke, ali će prikaz
biti drugačiji ovisno o rezultatima logičke izjave umetnute u legitimnu SQL izjavu koja se poziva na toj
stranici. Ova vrsta napada može postati vremenski intenzivna jer nova izjava mora biti izrađena za
svaki otkriveni dio. Postoji nekoliko alata kojima se ovi napadi mogu automatizirati jednom kada je
otkriveno mjesto ranjivosti i meta napada.
Jedna vrsta slijepog SQL umetanja prisiljava bazu podataka da procjeni logičnu izjavu na običnom
zaslonu aplikacije.
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND '1'='1';
će rezultirati normalnom stranicom dok će
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND '1'='2';
vjerojatno dati drugačiji rezultat, ako je stranica ranjiva na SQL umetanje. Ovakvo umetanje može
usmjeriti napadača da je slijepo SQL umetanje moguće, ostavljajući napadaču mogučnost da razlikuje
izjave koje su dale kao rezultat istinu ili laž, ovisno o sadržaju drugog stupca ili tablice izvan stupca
naredbe SELECT.
SELECT 1/0 FROM users WHERE username='ooo';
Druga vrsta slijepog SQL umetanja koristi uvjetno vrijeme kašnjenja koje napadača navodi na
zaključak je li SQL naredba rezultirala istinitim ili lažnim stanjem. [3]
2.2.
Izbjegavanje napada umetanjem
Za izbjegavanje napada umetanjem koriste se parametrizirani izrazi, izbjegavanje umetanja, provjera
uzoraka, te dozvole za baze podataka. [3]
2.2.1. Parametrizirani izrazi
Kod većine razvojnih platformi, mogu se koristiti parametrizirani izrazi u radu s parametrima
(ponekad se nazivaju vezivne varijable) umjesto ugrađivanja korisničkog unosa u izraz. Takvi
parametri mogu samo pohraniti vrijednost danog tipa, a ne i proizvoljni SQL fragment. Stoga bi SQL
umetanje jednostavno bilo tretirano kao čudna (a vjerojatno i nevažeća) vrijednost parametra.
U mnogim slučajevima, SQL je fiksiran, a svaki parametar je skalar, ne tablica. Korisnički unos je tada
pridijeljen (vezan) za parametar.
2.2.2. Izbjegavanje
Jednostavan, iako neprecizan, način da se spriječi umetanje je izbjegavanje znakova koji imaju
posebno značenje u SQL-u. Priručnik za SQL DBMS objašnjava koji znakovi imaju posebno značenje,
što omogućava stvaranje sveobuhvatne crne liste znakova koji trebaju translaciju. Na primjer, svaka
pojava jednog jednostrukog navodnika (') u izrazu mora biti zamijenjena s dva jednostruka navodnika
('') da se formira valjan SQL string. Na primjer, u PHP-u je uobičajeno izbjegavanje parametara
pomoću funkcije mysql_real_escape_string(); prije slanja SQL upita:
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND
Password='%s'",
mysql_real_escape_string($Username),
mysql_real_escape_string($Password));
mysql_query($query);
Funkcija mysql_real_escape_string () poziva MySQL-ovu biblioteku mysql_real_escape_string, koja na
početak dodaje znakove '\': \x00, \n, \r, \', \" i \x1a. Ova funkcija se uvijek (uz nekoliko iznimaka)
mora koristiti kako bi podaci bili sigurni prije slanja upita MySQL-u.
Postoje i druge funkcije za ostale vrste baza podataka u PHP-u poput pg_escape_string() za
PostgreSQL. Postoji također jedna funkcija koja se koristi za izbjegavanje znakova, a koristi se
posebno za upite bazama podataka koje nemaju funkcije za izbjegavanje u PHP-u. Ta funkcija je:
addslashes (string $str). Ona vraća string sa znakovima '\' prije znakova koje treba staviti pod
navodnike u upitima bazama podataka, itd. Ti znakovi su jednostruki navodnici ('), dvostruki
navodnici ("), backslash (\) i NUL.
Rutinska pretraga stringova za izbjegavanje u SQL-u može lako dovesti do pogrešaka, jer je lako
zaboraviti izbjeći određeni string. Stvaranje transparentnog sloja koji bi osigurao unos može smanjiti
broj pogrešaka, ako ne i u potpunosti ih eliminirati.
2.2.3. Provjera uzoraka
Parametri tipa integer, float ili boolean se mogu provjeriti (da li njihova vrijednost odgovara tom
tipu). Za stringove koji moraju biti određenog formata (datum, samo alfanumerički znakovi, itd.) se
može provjeriti da li odgovaraju tom formatu.
2.2.4. Dozvole za bazu podataka
Ograničavanje dozvola kod prijave na bazu podataka koju koristi web aplikacija na samo ono što je
potrebno može pomoći smanjiti učinkovitost bilo kakvih napada umetanjem SQL-a koji iskorištavaju
greške u web aplikaciji.
Na primjer za SQL Server, prijava na bazu podataka može biti ograničena na odabir samo nekih
stupaca u sustavu kako bi se ograničila eksploatacija kojom se pokušava ubaciti JavaScript u sve
tekstualne stupce u bazi podataka.
deny
deny
deny
deny
SELECT
SELECT
SELECT
SELECT
ON
ON
ON
ON
sys.sysobjects TO webdatabaselogon;
sys.objects TO webdatabaselogon;
sys.TABLES TO webdatabaselogon;
sys.views TO webdatabaselogon;
3. Cross-site scripting
Cross-site scripting (XSS) je vrsta ranjivosti koja se obično nalazi u web aplikacijama kao što su web
preglednici, a očituje se kroz povrede sigurnosti preglednika, te omogućuje napadačima da na strani
klijenta unesu skripte koje će biti vidljive drugim korisnicima. Ovu ranjivost napadač može iskoristiti
da bi zaobišao kontrolu pristupa. Cross-site scripting na web stranicama čini oko 84% svih sigurnosnih
propusta dokumentiranih od strane Symanteca 2007. godine. Njihov učinak može biti na razini od
sitne neugodnosti do značajnog sigurnosnog rizika, ovisno o osjetljivosti podataka kojima ranjiva
stranica barata kao i o prirodi implementiranih metoda izbjegavanja/umanjivanja ranjivosti.
Sigurnost na webu se temelji na različitim mehanizmima, ali većina se temelji na konceptu politike
istog podrijetla. Takvo se povjerenje bazira na tome, da ako se vjeruje da je sadržaju iz
https://mybank.example dano dopuštenje za pristup resursima na nekom sustavu, onda će bilo koji
sadržaj s te stranice imati ta dopuštenja, dok će sadržaju s druge stranice https://othersite.example
dopuštenje trebati biti dodijeljeno zasebno.
Cross-site scripting koristi poznate ranjivosti u web aplikacijama, njihovim serverima ili ostalim
sustavima na koja se aplikacije oslanjaju. Iskorištavanjem jednog od njih, napadači umeću
zlonamjeran sadržaj u sadržaj koji se isporučuje s kompromitirane stranice. Kada kombinirani sadržaj
stigne na klijentsku stranu web preglednika, sav je dostavljen iz pouzdanog izvora, a time djeluje pod
dozvolama odobrenima tom sustavu. Pronalaženjem načina za umetanje zlonamjernih skripti na web
stranicama, napadač može steći povišeni pristup ovlaštenja za osjetljivi sadržaj stranice, sjednične
cookieje i razne druge informacije koje preglednik vodi u ime korisnika. Cross-site scripting napadi su
ustvari poseban slučaj umetanja kôda.
Izraz "cross-site scripting"se izvorno odnosio na čin učitavanja napadnute web aplikacije od strane
stranice koja nije povezana s napadom, na način da se izvršava JavaScript fragment koji je napadač
pripremio u sigurnosnom kontekstu ciljane domene (reflektirana ili nepostojana XSS ranjivost).
Definicija se postupno proširila te obuhvaća i druge oblike umetanja kôda, uključujući i postojane i
ranjivosti nevezane uz Javascript (uključujući Java, ActiveX, VBScript, Flash ili čak čisti HTML i SQL
upite).
XSS ranjivost je poznata i iskorištavana još od 1990-tih godina. Ugledne stranice koje su u prošlosti
imale ovu ranjivost uključuju društvene stranice Twitter, Facebook, MySpace i Orkut. U posljednjih
nekoliko godina, cross-site scripting je nadmašio probleme sa prepunjavanjem spremnika te postala
sigurnosna ranjivost o kojoj se najčešće javno izviještava. Prema nekim istraživačima u 2007.
pregledavanje čak 68% web stranica je osjetljivo na XSS napade. [4]
3.1.
Tipovi XSS ranjivosti
Ne postoji niti jedna standardizirana klasifikacija cross-site scripting ranjivosti, ali većina stručnjaka
razlikuje barem dvije osnovne vrste XSS ranjivosti: nepostojana i postojana. Neki izvori dodatno dijele
ove dvije skupine u tradicionalne (uzrokovana propustima u kôdu na strani servera) i one utemeljene
na kôdu na klijentskoj strani.
Tradicionalne cross-site scripting ranjivosti će se pojaviti na strani servera nadležnog za pripremu
HTML odgovora koji mora biti poslužen korisniku. Ranjivosti temeljene na kôdu na klijentskoj strani
javljaju se u fazi obrade sadržaja koja se provodi na strani klijenta, obično na klijentskoj strani
JavaScript-a.
3.1.1. Nepostojana XSS ranjivost
Nepostojana (ili reflektirajuća) cross-site scripting ranjivost je najčešći tip ove ranjivosti. Ove
manjkavosti se pojavljuju kada podatke koje pruža web klijent, najčešće u parametrima HTTP upita ili
HTML obrascima, odmah koriste skripte na strani poslužitelja za generiranje rezultantne stranice za
tog korisnika, bez ispravne obrade zahtjeva.
HTML dokumenti imaju serijsku strukturu u kojoj se kombiniraju kontrolne naredbe, one za
formatiranje i stvarni sadržaj, te će bilo koji neprovjereni sadržaj dobiven od korisnika biti sadržan u
rezultantnoj stranici bez odgovarajućeg HTML kodiranja što može dovesti do umetanja. Klasičan
primjer potencijalnog problema je stranica nekog pretraživača: ako se traži neki niz, traženi niz će
obično biti doslovno označen na pronađenoj stranici kako bi se naznačilo ono što je traženo. Ako ta
rezultantna stranica neispravno odbacuje HTML-ove kontrolne znakove, iskoristit će se cross-site
scripting ranjivost.
Reflektirajući napad se obično izvodi putem e-maila ili neutralne web stranice. Mamac je URL
ispravnog izgleda, koji ukazuje na pouzdano mjesto, ali sadrži XSS vektor. Ako je pouzdana stranica
ranjiva na vektor, klikom na link žrtvin preglednik može pokrenuti umetnute skripte.
3.1.2. Postojana XSS ranjivost
Postojana (ili pohranjena) XSS ranjivost je razornija varijanta cross-site scripting ranjivosti. Pojavljuje
se kada se podaci koje je napadač pripremio spremaju na poslužitelju, a zatim trajno prikazuju na
"normalnim" stranicama koje se vraćaju drugim korisnicima tijekom redovitog pregledavanja, bez
odgovarajućeg izbjegavanja HTML-a. Klasičan primjer ove ranjivosti se javlja na javnim online
forumima gdje korisnici mogu postavljati HTML formatirane poruke koje čitaju ostali korisnici.
Na primjer, pretpostavimo da postoji web stranica za romantično uparivanje na kojoj članovi mogu
pregledavati profile drugih članova te izabrati one koji im izgledaju zanimljivo. Zbog zaštite
privatnosti ova stranica skriva stvarno ime i e-mail adrese svojih članova. Ti su tajni podaci čuvani na
poslužitelju. Pravo ime i e-mail adresa člana su u pregledniku jedino kada je član prijavljen, a te
podatke ne može vidjeti nitko drugi.
Pretpostavimo da se napadač, pridružuje stranici i želi saznati stvarna imena ljudi čije profile vidi na
stranici. Da bi si to omogućio, sastavlja skriptu koja se pokreće iz preglednika ženskih članova kada
posjete neki muški profil. Skripta zatim šalje brzu poruku napadačevom serveru, koji prikuplja ove
podatke. Da bi to učinio, na pitanje "Opišite vaš idealan prvi izlazak" napadač daje kratki odgovor
(kako ne bi izazvao sumnje), ali na kraju svog odgovora dodaje skriptu koja će ukrasti imena i e-mail
adrese. Ako je skripta zatvorena unutar <script> elementa, ona neće biti prikazana na zaslonu.
Pretpostavimo da neka članica ove stranice pregleda napadačev profil koji sadrži ovaj odgovor na
pitanje o prvom izlasku. Preglednik će automatski pokrenuti njegovu skriptu i ukrasti njeno pravo ime
i e-mail adresu direktno s njezinog računala.
Postojani XSS može imati veći utjecaj od drugih vrsta, jer se napadačeva zlonamjerna skripta prenosi
automatski, bez potrebe za individualnim ciljanjem žrtava ili njihovim mamljenjem na web stranicu
treće strane. Osobito u slučaju socijalnih mreža, kôd može biti dodatno dizajniran tako da se
autonomno širi s računa na račun stvarajući neku vrstu crva na klijentskoj strani.
Načini umetanja se mogu vrlo mnogo razlikovati. U nekim slučajevima, napadač čak ne mora izravno
komunicirati sa samom funkcionalnosti web-a kako bi iskoristio ovu ranjivost. Svi podaci koje web
aplikacija zaprimi (putem e-maila, sustava za prijavu itd.) a koje napadač može kontrolirati mogu
postati vektor umetanja. [4]
3.2.
Primjeri iskorištavanja XSS ranjivosti
Napadači koji namjeravaju iskoristiti cross-site scripting ranjivost moraju drugačije pristupiti svakoj
vrsti ranjivosti. Ovdje je opisan specifičan način napada za svaku vrstu. [4]
Primjer nepostojane XSS ranjivosti:
1. Ana često posjećuje određenu web stranicu, koju objavljuje Marko. Markova web stranica
omogućuje Ani da se prijavi pomoću para korisničko ime/lozinka i pohrani osjetljive podatke
kao što su podaci o naplati računa.
2. Marija primjećuje da je Markova web stranica osjetljiva na XSS ranjivost.
3. Marija kreira URL koji će iskoristiti ovu ranjivost, te šalje Ani e-mail kojim je potiče da klikne
na link za URL pod lažnim izlikama. Ovaj URL će biti usmjeren na Markovu web stranicu, ali će
sadržavati Marijin zlonamjerni kôd koji će web stranica reflektirati.
4. Ana posjećuje URL koji joj je Marija poslala dok je prijavljena na Markovu web stranicu.
5. Zlonamjerna skripta ugrađena u URL se izvršava u Aninom pregledniku, kao da je došla
izravno s Markovog poslužitelja (to je stvarna XSS ranjivost). Skripta se može koristiti za slanje
Aninog sjedničnog cookieja Mariji. Marija tada može iskoristiti sjednični cookie i ukrasti
povjerljive informacije koje su dostupne Ani (autentifikacijske podatke, podatke o naplati
itd.) bez da Ana sazna za to.
Primjer postojane XSS ranjivosti:
1. Marija objavljuje poruku sa zlonamjernim kôdom na društvenoj mreži.
2. Kad Marko čita poruke, Marijin XSS krade Markov sjednični cookie.
3. Marija sada može oteti Markovu sjednicu i imitirati ga.
3.3.
Smanjivanje prijetnje
Postoji nekoliko načina za smanjivanje prijetnje od cross-site scripting napada:
3.3.1. Kontekstualno kodiranje/provjera ulaznog niza
Primarni obrambeni mehanizam za zaustavljanje XSS napada je kontekstualno kodiranje/provjera
korisničkog unosa. Postoji nekoliko različitih shema koje se moraju koristiti ovisno o tome gdje je
nepouzdani string smješten unutar HTML dokumenta, uključujući HTML kodiranje entiteta,
iznjegavanje JavaScript-a, izbjegavanje CSS-a i URL kodiranje. Većina web aplikacija koje ne trebaju
prihvatiti složene podatke mogu na ovaj način u velikoj mjeri eliminirati rizik od XSS napada na
prilično jednostavan način.
Važno je napomenuti da, iako se obično preporuča, jednostavno entitetsko HTML kodiranje na pet
XML-u značajnih znakova nije uvijek dovoljno kako bi se spriječilo mnoge oblike XSS napada.
Kodiranje može biti nezgodno, a pritom se preporuča korištenje biblioteke sigurnosti kodiranja.
3.3.2. Sigurnosna provjera nepouzdanog HTML unosa
Mnogi operateri pojedinih web aplikacija (npr. forumi i webmail) žele omogućiti korisnicima da
koriste neke od značajki koje HTML pruža, kao što je ograničeni podskup HTML oznaka. Kada
prihvaćaju korisnički HTML unos (na primjer <b> vrlo </b> velik), samo njegovo kodiranje (na primjer
&lt;b&gt;vrlo&lt;/b&gt; velik) neće biti dovoljno jer korisnički unos treba biti predan
pregledniku kao HTML (kako bi se prikazao kao "vrlo velik", umjesto "<b> vrlo </ b> velik").
Zaustavljanje XSS napada prilikom prihvaćanja korisničkog HTML ulaza je u ovom slučaju puno
složenije. Nepouzdani HTML unos mora se uskladiti sa HTML politikom kako bi se osiguralo da ne
sadrži XSS. HTML alati za pročišćavanje kao što su OWASP AntiSamy i http://htmlpurifier.org/
ostvaruju taj zadatak.
3.3.3. Sigurnost cookieja
Osim filtriranja sadržaja, često se koriste i druge nesavršene metode za ublažavanje cross-site
scriptinga. Jedan primjer je korištenje dodatnih sigurnosnih kontrola pri rukovanju korisničkom
autentifikacijom baziranom na cookiejima. Mnoge web aplikacije se oslanjaju na sjednične cookieje
za autentifikaciju između pojedinih HTTP zahtjeva, te budući da klijentske skripte generalno imaju
pristup tim cookiejima, jednostavni XSS napadi ih mogu ukrasti. Za ublažavanje ovog tipa prijetnji
(iako ne i XSS problema općenito), mnoge web aplikacije vežu sjednične cookieje za IP adresu
korisnika kojom se u početku prijavio, te dozvoljavaju samo toj IP adresi korištenje tog cookieja. Ta je
metoda u većini situacija učinkovita (ako je napadaču cilj ukrasti cookie), ali ne djeluje u situacijama u
kojima napadač prisvoji tuđu IP adresu.
Druga metoda ublažavanja koja je prisutna u Internet Exploreru (od verzije 6), Firefoxu (od verzije
2.0.0.5), Safariju (od verzije 4), Operi (od verzije 9.5) i Google Chromeu je zastavica HttpOnly koja
omogućuje web serveru postavljanje cookieja koji nisu dostupni klijentskim skriptama. Iako se
pokazala korisnom, ova metoda ne spriječava krađu cookieja u potpunosti niti može spriječiti napade
unutar preglednika.
3.3.4. Onemogućavanje skripti
Dok dizajneri Web 2.0 i Ajaxa preferiraju korištenje JavaScripta, neke web aplikacije su pisane
(ponekad opcionalno) tako da nemaju nikakve potrebe za klijentskim skriptama. To omogućuje
korisnicima, ako se odluče na to, da onemoguće skripte u svojim preglednicima prije korištenja
aplikacije. Na taj način, čak i potencijalno zlonamjerne klijentske skripte mogu biti umetnute na
stranici bez ikakvih provjera, a korisnici neće biti ranjivi na XSS napade.
Neki preglednici ili njihovi dodaci mogu biti konfigurirani tako da onemogućavaju klijentske skripte
ovisno o pojedinoj domeni. Ako je skriptiranje inicijalno postavljeno kao dozvoljeno, tada ovaj pristup
ima ograničen uspjeh, jer se blokira loše stranice tek nakon što korisnik zna da su loše kada je već
prekasno. Funkcionalnost da se inicijalno blokiraju sve skripte i vanjski dodaci, a zatim omogući
korisniku da ih omogući za pojedinu domenu je učinkovitiji. Ova mogućnost postoji u Internet
Exploreru od verzije 4 postavljanjem takozvanih "sigurnosnih zona", te u Operi od verzije 9
korištenjem postavke "Site Specific Preferences". Rješenje za Firefox i druge preglednike bazirane na
Gecko-u je open source dodatak NoScript koji, uz mogućnost da se omogućava korištenje skripti za
pojedine domene, daje neke zaštite od XSS napada čak i kada su omogućene skripte.
Najznačajniji problem s blokiranjem svih skripti na svim stranicama je značajno smanjenje
funkcionalnosti i brzine (klijentske skripte mogu biti puno brže nego serverske jer ne trebaju spajanje
na udaljeni poslužitelj pa se stranica ne treba iznova učitavati). Drugi problem s blokiranjem skripti je
u tome da ga mnogi korisnici ne razumiju i ne znaju kako pravilno osigurati svoje preglednike. Još
jedan nedostatak je da mnoge web stranice ne rade bez klijentskih skripti, prisiljavajući tako korisnike
da si onemoguće zaštitu za tu domenu i tako otvaraju svoj sustav ranjivostima. Firefoxov dodatak
NoScript omogućuje korisnicima selektivno omogućavanje skripti na određenoj stranici dok ostale
istovremeno ostaju blokirane na istoj stranici. Primjerice, skripte iz example.com mogu biti
dopuštene, dok skripte iz advertisingagency.com koje se pokušavaju pokrenuti na istoj stranici mogu
biti onemogućene.
3.3.5. Nadolazeće obrambene tehnologije
Postoje tri kategorije XSS obrane koje su u nastajanju. To uključuje Mozilla-in „Content Security
Policy“, Javascript Sandbox alati i predlošci za automatsko izbjegavanje XSS napada. Ti mehanizmi se
još uvijek razvijaju, ali obećavaju budućnost sa znatno umanjenim mogućnostima XSS napada. [4]
4. Loša autentifikacija i upravljanje sjednicama
4.1. Autentifikacija
Autentifikacija je proces provjere da je pojedinac ili subjekt ono što tvrdi da je. Obično se izvodi tako
da korisnik da korisničko ime ili identifikacijsku oznaku te jednu ili više privatnih informacija koje bi
samo korisnik trebao znati. [5]
4.1.1. Smanjivanje prijetnje kod autentifikacije
Preporuke za smanjivanje prijetnje kod autentifikacije odnose se na pravilan izbor korisničkog imena,
te pravilo provođenje provjere snage zaporke.
4.1.1.1. Odabir korisničkog imena
Preporuča se ne razlikovati mala i velika slova u korisničkom imenu. Mnoge stranice koriste e-mail
adrese kao korisnička imena te one već same po sebi ne razlikuju velika i mala slova. Bilo bi naime
vrlo čudno da korisnička imena 'Ivan' i 'ivan' pripadaju različitim korisnicima. U tom bi slučaju moglo
doći do ozbiljnih zabuna.
4.1.1.2. Pravilno provođenje provjere snage zaporke
Ključna briga kod korištenja lozinke kao metode autentifikacije je snaga zaporke. Politika "jake"
lozinke otežava ili čak potpuno onemogućava pogađanje lozinke bilo ručno ili automatskim putem.
Sljedeće karakteristike definiraju snažnu lozinku:
- duljina lozinke
Dulje lozinke pružaju veću kombinaciju znakova, te time otežavaju pogađanje napadaču.
Minimalnu duljinu lozinke treba provjeravati aplikacija. Lozinke kraće od 10 znakova smatraju se
slabima. Minimalna dužina lozinke može uzrokovati probleme s pamćenjem lozinki među nekim
korisnicima, pa ih aplikacije trebaju potaknuti da ih postave kao fraze (rečenice ili kombinacije riječi)
koje mogu biti puno dulje od uobičajenih lozinki a opet mnogo lakše za zapamtiti.
Maksimalna duljina lozinke ne bi trebala biti postavljena prenisko, jer će spriječiti korisnika da za
lozinku postavi frazu. Tipično je maksimalna duljina 128 znakova. Lozinke kraće od 20 znakova se
obično smatra slabima ako se sastoje samo od malih latiničnih slova.
Treba se pobrinuti da svaki znak koji korisnik upiše bude uključen u lozinku. Neki sustavi skrate
lozinku koju je korisnik upisao (npr. Korisnik je unio 20 znakova što je skraćeno na 15 znakova). Ovo
se obično rješava postavljanjem duljine svih lozinki na točno maksimalnu duljinu lozinke. To je
osobito važno ako je maksimalna dužina lozinke mala.
- složenost lozinke
Aplikacije bi trebale nametati složenost lozinki kako bi smanjile broj lozinki koje je lako pogoditi.
Mehanizmi lozinki bi trebali omogućiti upis gotovo bilo kojeg znaka kao dijela korisničke lozinke,
uključujući razmak. Lozinke bi trebale razlikovati velika i mala slova u cilju povećanja njihove
složenosti. Povremeno se mogu pronaći sustavi gdje se u lozinkama ne razlikuju velika i mala slova.
Mehanizam promjene lozinke treba zahtijevati minimalnu razinu složenosti koja ima smisla za
određenu primjenu i tip korisnika.
Na primjer:
Lozinka mora zadovoljiti barem tri od sljedeća četiri pravila složenosti
barem 1 veliko slovo (A-Z)
barem 1 malo slovo (a-z)
barem 1 znamenka (0-9)
barem jedan poseban znak ("£ $% & ...!)
Mora imati najmanje 10 znakova.
Mora imati najviše 128 znakova.
Ne smije imati više od dva identična znaka u nizu (npr. Niz 111 nije dopušten)
Što veći stupanj složenosti lozinke aplikacija zahtjeva, to zahtjevi moraju biti jasnije naglašeni.
Potrebna politika mora biti izričito navedena na stranici promjene lozinke (trebalo bi navesti svaki
poseban znak koji je dozvoljen kako bi korisniku pravila bila jasna).
U idealnom slučaju, aplikacija bi trebala ukazivati korisniku na to koliki stupanj složenosti zadovoljava
njegova nova lozinka. Aplikacija ne bi trebala prihvatiti unos nove lozinke dok nova lozinka ne
zadovolji politiku složenosti lozinke i dok drugi primjerak nove lozinke ne odgovara prvom. Tako će
korisnik lakše razumjeti i prilagoditi složenost svoje lozinke.
Ako nova lozinka nije usklađena sa politikom složenosti, poruka o pogrešci treba opisati sva pravila
složenosti s kojima nova lozinka nije u skladu, a ne samo prvo pravilo.
Promjena lozinke bi ponajprije trebala biti jednostavan postupak.
4.1.1.3. Osiguranje sigurnog mehanizma za oporavak lozinke
Uobičajeno je imati mehanizam koji osigurava pristup korisnika svom računu u slučaju da zaboravi
svoju lozinku.
4.1.1.4. Zahtijevanje ponovne autentifikacije za osjetljive značajke
Kako bi se ublažili utjecaji CSRF napada i otmice sjednice, važno je zahtijevati trenutne
autentifikacijske podatke vezane za račun prije otkrivanja osjetljivih podataka o računu kao što su
korisnikova lozinka ili korisnikov e-mail, ili prije osjetljivih radnji kao što je slanje pošiljke na neku
novu adresu. Bez te protumjere, napadač može biti u mogućnosti izvršiti osjetljive transakcije kroz
CSRF ili XSS napade bez potrebe da zna korisnikove trenutne autentifikacijske podatke. Osim toga,
napadač može dobiti privremeni fizički pristup korisnikovom pregledniku ili ukrasti njegov ID sjednice
te preuzeti korisnikovu sjednicu.
4.1.1.5. Korištenje višefaktorske autentifikacije
Višefaktorska autentifikacija koristi više od jednog autentifikacijskog faktora za prijavu ili obradu
transakcije:
- Nešto što korisnik zna (pojedinosti računa ili lozinki)
- Nešto što korisnik ima (token ili mobilni telefon)
- Nešto što korisnik je (biometrija)
Autentifikacijska shema kao što je jednokratna lozinka (eng. One time password, OTP) provedena
pomoću hardverskog tokena također može biti ključna u borbi protiv napada poput CSRF i
zlonamjernog kôda s klijentske strane. Velik broj hardverskih tokena pogodnih za višefaktorsku
autentifikaciju i dostupnih na tržištu omogućuju dobru integraciju s web aplikacijama.
4.1.1.6. Pravilno postavljene poruke o pogreškama pri autentifikaciji
Pogrešno postavljene poruke o pogreškama pri autentifikaciji mogu se iskoristiti za potrebe
pobrojavanja korisničkih imena i pripadnih lozinki. Na zahtjev za autentifikacijom treba odgovoriti na
generički način bez obzira je li netočno korisničko ime ili lozinka. Odgovor nikako ne bi trebao dati
naznake o statusu postojećeg korisničkog računa.
Autentifikacijski zahtjev može vratiti drugačiji HTTP error code ovisno o odgovoru na pokušaj
autentifikacije. Može odgovoriti sa 200 za pozitivan rezultat a 403 za negativan rezultat. Iako se
korisniku prikaže stranica sa generičkom pogreškom, HTTP response code se može razlikovati te
može odati informacije o valjanosti računa.
4.1.1.7. Prijenos lozinke samo preko TLS-a
Stranici prijave i svim kasnijim autentificiranim stranicama mora se pristupiti isključivo preko TLS-a.
Nekorištenje TLS-a za pristup stranici prijave omogućuje napadaču promjenu obrasca prijave, te
slanje korisničkih podataka i njihovu objavu na proizvoljnom mjestu. Nekorištenje TLS-a za ostale
autentificirane stranice nakon stranice prijave omogućuje napadaču da vidi nekriptirani ID sjednice te
kompromitira autentificiranu korisničku sjednicu.
4.1.1.8. Implementacija blokiranja računa
Ako je napadač u stanju pogoditi lozinku prije nego korisnički račun postane blokiran zbog neuspjelih
pokušaja autentifikacije, napadač ima priliku nastaviti s „brute force“ napadom dok račun ne postane
kompromitiran.
Automatiziranje napada nagađanja lozinke na web aplikacijama je trivijalan izazov. Mehanizam
blokiranja lozinke treba biti korišten tako da blokira račun ako je napravljeno više od određenog
broja neuspjelih pokušaja prijave.
Mehanizmi blokiranja lozinke imaju logičku slabost. Napadač koji izvede veliki broj pokušaja
autentifikacije na poznatim imenima računa može uzrokovati blokiranje cijelih blokova korisničkih
računa. S obzirom da je svrha sustava blokiranja lozinke zaštitita od „brute force“ napada, dobra
strategija je blokiranje računa na određeno vremensko razdoblje (npr. 20 minuta). Time se značajno
usporava napadače, a legitimni korisnici svojim računima mogu ponovno pristupiti. [5]
4.2. Upravljanje sjednicama
Upravljanje sjednicom je proces kojim poslužitelj održava stanje subjekta s kojim je u interakciji. Ono
je potrebno kako bi poslužitelj zapamtio kako reagirati na naknadne zahtjeve u cijeloj sjednici.
Sjednice se održavaju na poslužitelju pomoću varijable SESSION ID koja se može prenositi više puta
između klijenta i poslužitelja kod slanja i primanja zahtjeva. Sjednica bi trebala biti jedinstvena po
korisniku i računski vrlo teška za predvidjeti.
Web sjednica je slijed HTTP transakcija zahtjeva i odgovora povezanih s istim korisnikom. Moderne i
složene web aplikacije zahtijevaju zadržavanje informacija ili statusa o svakom korisniku za vrijeme
trajanja višestrukih zahtjeva. Dakle, sjednice pružaju mogućnost uspostave varijabli - kao što su prava
pristupa i lokalizirane postavke - koje će se primijeniti na svaku interakciju korisnika sa web
aplikacijom za vrijeme trajanja sjednice.
Web aplikacije mogu kreirati sjednice za praćenje anonimnih korisnika nakon prvog zahtjeva od
strane korisnika (primjerice za pamćenje odabranih jezičnih postavki). Dodatno, web aplikacije će
koristiti sjednice nakon autentifikacije korisnika. Time se osigurava sposobnost identifikacije korisnika
za naknadne zahtjeve, kao i mogućnost primjene sigurnosne kontrole pristupa, ovlaštenog pristupa
privatnim podacima korisnika, te povećanje iskoristivosti aplikacije. Stoga današnje web aplikacije
mogu osigurati primjenu sjednica i prije i poslije autentifikacije.
Nakon uspostavljanja autentificirane sjednice, ID sjednice (ili tokena) je privremeno ekvivalentan
najjačoj metodi autentifikacije koju koristi aplikacija, kao što je korisničko ime i lozinka, jednokratna
lozinka, klijentski digitalni certifikat, pametna kartica ili neka biometrijska metoda (otisak ili šarenica
oka).
HTTP je protokol koji ne zadržava stanje, u kojem je svaki par zahtjev i odgovor neovisan od drugih
web interakcija. Zbog toga je za uvesti pojam sjednice, potrebno uvesti sposobnost upravljanja
sjednicama kojom se povezuje i modele autentifikacije i modele kontrole pristupa koji su obično
dostupni u web aplikacijama kako je prikazano na slici 1.
Autentifikacija
Upravljanje
sjednicama
Kontrola
pristupa
Slika 1. Povezivanje modela autentifikacije i kontrole pristupa
ID ili token sjednice veže podatke za korisničku autentifikaciju (u obliku korisničke sjednice) s HTTP
prometom korisnika uz odgovarajuće kontrole pristupa koje nameće web aplikacija. Kompleksnost
ove tri komponente (autentifikacija, upravljanje sjednicama i kontrola pristupa) u modernim web
aplikacijama, uz činjenicu da njihova provedba i povezivanje ovisi o programeru, čini izvedbu sigurnog
modula za upravljanje sjednicama vrlo izazovnom.
Otkrivanje, hvatanje, predviđanje, pogađanje ili fiksacija identifikatora sjednice će dovesti do napada
otimanja sjednice, gdje je napadač u mogućnosti u potpunosti imitirati žrtvu korisnika te web
aplikacije. Napadači mogu obavljati dvije vrste napada otimanja sjednice, ciljane ili općenite. Kod
ciljanog napada napadaču je cilj utjeloviti točno određenog korisnika web aplikacije. Kod općenitog
napada napadaču je cilj utjeloviti bilo kojeg legitimnog korisnika web aplikacije. [6]
4.2.1. Svojstva identifikatora sjednice
Kako bi se pratilo autentificirano stanje te kretanje korisnika unutar web aplikacije, aplikacija
pridružuje korisniku identifikator sjednice (ID ili token sjednice) koji se dodjeljuje prilikom
započinjanja sjednice, a dijele ga i razmjenjuju strana korisnika i strana web aplikacije za čitavo
vrijeme trajanja sjednice (šalje se sa svakim HTTP zahtjevom). Identifikator sjednice je par „ime =
vrijednost“.
Radi osiguranja sigurnog identifikatora sjednice, generiranje identifikatora (ID-a ili tokena) mora
ispunjavati sljedeća svojstva:
-
Naziv identifikatora sjednice
Naziv koji koristi identifikator sjednice ne bi trebao biti opisan niti otkrivati nepotrebne pojedinosti o
svrsi i značenju identifikatora. Imena identifikatora sjednica koja koriste najčešći alati za razvoj web
aplikacija mogu se lako prepoznati, primjerice PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN
(ColdFusion), ASP.NET_SessionId (ASP. NET) itd.. Prema tome imena identifikatora mogu otkriti
tehnologije i programske jezike koje koriste web aplikacije. Preporuča se promijeniti zadani naziv
identifikatora sjednice u neko generičko ime kao što je "ID".
-
Duljina identifikatora sjednice
Identifikator sjednice mora biti dovoljno dug kako bi se spriječilo „brute force“ napade, gdje napadač
može proći kroz cijeli niz mogućih vrijednosti i provjeriti postojanje važećih sjednica s tim
identifikatorom. Duljina identifikatora sjednice mora biti najmanje 128 bita (16 bajtova).
-
Entropija identifikatora sjednice
Identifikator sjednice mora biti nepredvidljiv (dovoljno slučajan) kako bi se spriječilo napade
nagađanja, gdje je napadač u stanju pogoditi ili predvidjeti identifikator valjane sjednice kroz tehniku
statističke analize. U tu svrhu mora se koristiti dobar pseudo generator slučajnih brojeva.
Vrijednost identifikatora sjednice mora osigurati najmanje 64 bita entropije (ako se koristi dobar
pseudo generator slučajnih brojeva, ova vrijednost se procjenjuje na pola duljine identifikatora
sjednice).
Napomena: na entropiju identifikatora sjednice uvelike utječu vanjski i teško mjerljivi faktori, kao što
je uobičajen broj istodobnih aktivnih sjednica web aplikacije, apsolutno vrijeme isteka sjednice, broj
nagađanja identifikatora sjednice koje napadač može napraviti a ciljana web aplikacija podržati, itd.
Ako se koristi identifikator sjednice sa 64 bita, napadaču će trebati barem 292 godine da uspješno
pogodi valjani identifikator sjednice, pod pretpostavkom da napadač može pokušati 10.000 puta u
sekundi sa 100.000 valjanih istovremenih sjednica dostupnih u web aplikaciji.
-
Sadržaj (ili vrijednost) identifikatora sjednice
Sadržaj (ili vrijednost) identifikatora sjednice mora biti besmislen kako bi spriječio napade za
otkrivanje informacija, gdje je napadač u mogućnosti dekodirati sadržaj identifikatora i razotkriti
podatke o korisniku, sjednici ili unutarnjem ustroju web aplikacije.
Na strani klijenta identifikator sjednice jednostavno mora biti identifikator, a njegova vrijednost
nikada ne smije sadržavati osjetljive podatke. Značenje i uloga povezana s identifikatorom sjednice
mora biti pohranjena na strani poslužitelja, u sjedničnim objektima ili u bazi podataka za upravljanje
sjednicom. Pohranjeni podaci mogu uključivati IP adresu klijenta, e-mail, korisničko ime, korisnički ID,
ulogu, razinu privilegija, prava pristupa, jezične postavke, ID računa, trenutno stanje, posljednju
prijavu, istek vremena sjednice i druge detalje. Ako sjednični objekt i svojstva sadrže osjetljive
informacije kao što su brojevi kreditnih kartica, potrebno je propisno šifrirati i zaštititi repozitorij
upravljanja sjednicom.
Preporučljivo je stvoriti kriptografski jaki identifikator sjednice korištenjem kriptografskih hash
funkcija kao što je SHA1 (160 bita). [6]
4.2.2. Implementacija upravljanja sjednicama
Implementacija upravljanja sjednicama definira mehanizam razmjene koji će se koristiti za dijeljenje i
kontinuirano razmjenjivanje identifikatora sjednice između korisnika i web aplikacije. Postoje brojni
mehanizmi dostupni u HTTP za održavanje stanja sjednice unutar web aplikacije, kao što su cookieji
(standardno HTTP zaglavlje), URL parametri, URL argumenti za zahtjeve GET, argumenti tijela na
zahtjeve POST, kao što su skrivene HTML forme ili obavezna HTTP zaglavlja.
Korišteni mehanizam razmjene identifikatora sjednice bi trebao omogućiti definiranje naprednih
svojstava tokena, kao što je istek datuma i vremena tokena ili korištenje ograničenja. To je jedan od
razloga zašto su cookieji (RFC 2109 i 2965 i 6265) jedan od najčešće korištenih mehanizama razmjene
identifikatora sjednice. Oni nude napredne mogućnosti koje nisu dostupne u drugim metodama.
Korištenje nekih mehanizama razmjene identifikatora sjednice, kao što su oni u kojima je
identifikator uključen u URL, može otkriti identifikator sjednice (u web linkovima i logovima, povijesti
web preglednika i zabilježbama, zaglavljima ili tražilicama), kao i olakšati druge napade kao što su
manipulacije identifikatorom ili napadi fiksiranja sjednica.
-
Ugrađene implementacije upravljanja sjednicama
Alati za razvoj web sučelja kao što su J2EE, ASP. NET, PHP nude svoje vlastite implementacije za
upravljanje sjednicama. Preporuča se koristiti ova ugrađena sučelja (više nego ona samostalno
napravljena) budući da se ona koriste u cijelom svijetu na više web okruženja, te je njihova sigurnost
istestirana tijekom vremena od strane brojnih stručnjaka za razvoj i sigurnost.
Međutim, treba imati na umu da su i na tim sučeljima također pronađene ranjivosti i slabosti u
prošlosti, te se stoga uvijek preporuča korištenje najnovije dostupne verzije koja potencijalno
popravlja sve poznate ranjivosti, kao i pregledavanje i promjena početne konfiguracije kako bi se
poboljšala njena sigurnost.
Baza podataka ili repozitorij za upravljanje sjednicom koji se koristi za privremenu pohranu
identifikatora sjednice mora biti siguran, štititi identifikator od slučajnog odavanja bilo lokalno bilo na
daljinu ili od neovlaštenog pristupa.
-
Prihvaćeni i korišteni mehanizmi razmjene identifikatora sjednice
Neka web aplikacija može koristiti određeni mehanizam razmjene ID-a sjednice po defaultu, kao što
su primjerice cookieji. Međutim, ako korisnik pošalje identifikator sjednice kroz drugi mehanizam
razmjene, kao što je primjerice URL parametar, web aplikacija ga možda prihvati. Web aplikacija
može koristiti oba mehanizma, cookieje i URL parametre, ili čak prebacivati s jednog na drugi
(automatsko URL prepisivanje) ako su ispunjeni određeni uvjeti (na primjer postojanje web klijenata
bez potpore cookiejima ili kada cookieji nisu prihvatljivi zbog privatnih postavki korisnika).
Iz tog razloga, bitno je razlikovati mehanizme koje koriste web aplikacije inicijalno za razmjenu
identifikatora sjednica i mehanizme koje prihvati web aplikacija za obradu i upravljanje
identifikatorima sjednica. Web aplikacije moraju ograničiti prihvaćene mehanizme za praćenje
sjednice samo na one odabrane i korištene pri dizajnu.
-
Sigurnost transportnog sloja
Radi zaštite razmjene identifikatora sjednice od aktivnog prisluškivanja i pasivnog odavanja mrežnog
prometa, obavezno je koristiti enkriptiranu HTTPS (SSL/TLS) vezu za cijelo vrijeme trajanja web
sjednice, a ne samo pri autentifikacijskom procesu gdje se razmjenjuju povjerljivi korisnički podaci.
Osim toga mora se koristiti opcija „siguran“ cookie kako bi se osiguralo da se ID sjednice razmjenjuje
samo kriptiranim kanalom. Korištenje kriptiranog komunikacijskog kanala također štiti sjednicu protiv
nekih napada fiksiranja sjednice gdje je napadač u stanju presresti web promet i manipulirati njime
kako bi uveo (ili popravio) ID sjednice žrtve na web pregledniku.
Sljedeći skup savjeta najbolje prakse vezani uz HTTPS (SSL/TLS) usmjereni su na zaštitu identifikatora
sjednice (posebno kada se koriste cookieji) te pomažu kod integracije HTTPS-a unutar web aplikacije:
 Web aplikacije nikada ne bi trebale prebaciti sjednicu iz HTTP u HTTPS ili obrnuto, jer će se
tada identifikator sjednice objaviti u čistom obliku na mreži.
 Web aplikacije ne bi trebale miješati kriptirani i nekriptirani sadržaj (HTML stranice, slike,
CSS, Javascript datoteke itd.) na istom hostu (ili čak i domeni), jer bi zahtjev za bilo kojim web
objektom preko nekriptiranog kanala mogao otkriti identifikator sjednice.
 Web aplikacije općenito ne bi trebale davati javne nekriptirane sadržaje i one privatne
kriptirane s istog hosta. Preporuča se umjesto toga koristiti dva različita hosta kao što je
primjerice www.example.com preko HTTP-a za javne sadržaje i secure.example.com preko
HTTPS-a (kriptiran) za privatne i osjetljive sadržaja (gdje postoje sjednice). Prvi host ima
otvoren samo port TCP/80, a drugi samo port TCP/443.
 Web aplikacije bi trebale izbjegavati iznimno česta preusmjeravanja s HTTP-a na HTTPS na
početnoj stranici, jer tada napadač može iskoristiti samo jednu nezaštićenu razmjenu HTTP
zahtjev/odgovor da bi otkrio (ili popravio) valjani identifikator sjednice.
 Web aplikacije bi trebale koristiti „HTTP Strict Transport Security (HSTS)“ za primjenu HTTPS
veze.
Važno je naglasiti da SSL/TLS (HTTPS) ne štiti od predviđanja identifikatora sjednice, napada grubom
silom, napada na strani klijenta ili fiksacija. Ipak, otkrivanje identifikatora sjednice iz mrežnog
prometa je još uvijek jedan od najčešćih napada. [6]
4.2.3. Životni ciklus identifikatora sjednice
4.2.3.1. Generiranje i verifikacija identifikatora sjednice
Postoje dvije vrste mehanizama za upravljanje sjednicama web aplikacija s obzirom na ranjivosti
fiksiranja sjednice, popustljivi i strogi. Popustljivi mehanizmi dopuštaju web aplikacijama da u
početku prihvate bilo koju vrijednost identifikatora sjednice postavljenu od strane korisnika kao
valjanu, stvarajući za njega novu sjednicu. S druge strane strogi mehanizam dozvoljava samo da web
aplikacija prihvati vrijednosti identifikatora sjednice koju je prethodno generirala web aplikacija.
Najčešći mehanizam koji se danas koristi je onaj strogi (sigurniji je). Pri razvoju web aplikacija mora se
osigurati da se pod raznim okolnostima ne koriste popustljivi mehanizmi. Web aplikacija nikada ne bi
trebala prihvatiti identifikator sjednice koji ona nikada nije generirala, a u slučaju zaprimanja takvog
identifikatora trebala bi generirati i ponuditi korisniku novi valjani identifikator sjednice. Ovaj scenarij
bi svakako trebalo prepoznati kao sumnjivu aktivnost te izdati upozorenje.
4.2.3.2. Upravljanje identifikatorom sjednice
Identifikator sjednice mora se smatrati nepouzdanim, kao i svaki drugi korisnički unos kojeg web
aplikacija obrađuje, te se mora temeljito provjeriti i potvrditi. Ovisno o korištenom mehanizmu
upravljanja sjednicom, identifikator sjednice će biti primljen u GET ili POST parametru, u URL ili HTTP
zaglavlju (npr. cookie). Ako web aplikacija ne provjeri i filtrira nevažeće vrijednosti identifikatora
sjednice prije nego ih obradi, one se mogu iskoristiti za iskorištavanje drugih web ranjivosti, kao što je
SQL umetanje ako su identifikatori sjednice pohranjeni na relacijskoj bazi podataka ili trajni XSS ako
web aplikacija identifikatore sjednice pohrani i takve pošalje natrag.
4.2.3.3. Obnavljanje identifikatora sjednice nakon bilo koje promjene razine privilegija
Web aplikacija mora obnoviti ili ponovno kreirati identifikator sjednice nakon svake promjene razine
privilegija pridružene korisniku sjednice. Najčešći scenarij u kojem je obvezno obnavljanje
identifikatora sjednice je tijekom procesa autentifikacije, budući da se tada razina privilegija korisnika
mijenja iz neprovjerenog (ili anonimnog) stanja u autentificirano (provjereno) stanje. Druge česte
scenarije također treba uzeti u obzir, kao što je promjena lozinke, promjena dozvola ili prebacivanje
iz redovne korisničke uloge u ulogu administratora unutar web aplikacije. Zbog svih tih kritičnih
stranica web aplikacije, prethodni identifikatori sjednice moraju biti zanemareni, a svakom novom
zahtjevu za kritičan resurs mora biti dodijeljen novi identifikator sjednice, a stari identifikator
sjednice mora biti uništen.
Najčešći alati za razvoj web aplikacija pružaju funkcije sjednice i metode za obnavljanje identifikatora
sjednice kao što su „request.getSession (true) & HttpSession.invalidate ()“ (J2EE), „Session.Abandon
() & Response.Cookies.Add (new...)“ (ASP. NET) ili „session_start() & session_regenerate_id(true)“
(PHP).
Obnavljanje identifikatora sjednice je obavezno kako bi se spriječili napadi fiksiranja sjednice, gdje
napadač postavlja identifikator sjednice na korisničkom web pregledniku žrtve umjesto skupljanja
identifikatora sjednice žrtve kao u većini drugih napada temeljenih na sjednicama, neovisno o tome
koristi li se HTTP ili HTTPS. Ova zaštita ublažava utjecaj drugih ranjivosti web-a koje se također mogu
koristiti za pokretanje napada fiksiranja sjednice, poput HTTP cijepanja odgovora ili XSS napada.
Uz ovo se preporuča i korištenje različitog identifikatora sjednice ili imena tokena (ili niz
identifikatora sjednice) prije i poslije autentifikacije, tako da web aplikacija može pratiti anonimne
korisnike i one autentificirane bez rizika od izlaganja ili povezivanja korisničke sjednice između ta dva
stanja.
4.2.3.4. Upotreba višestrukih cookieja
Ako web aplikacija koristi cookieje kao mehanizam razmjene identifikatora sjednice, a za pojedinu
sjednicu su postavljeni višestuki cookieji, web aplikacija mora provjeriti sve cookieje (i kontrolirati
odnose između njih) prije nego dopusti pristup korisničkoj sjednici.
Uobičajeno je za web aplikaciju postaviti korisnički cookie prije provjere autentičnosti preko HTTP-a
radi praćenja neprovjerenih (anonimnih) korisnika. Nakon što se korisnik autentificira u web
aplikaciji, novi post-autentifikacijski cookie se postavlja preko HTTPS-a, a uspostavlja se poveznica
između tih cookieja. Ako web aplikacija ne potvrdi oba cookieja za autentificiranu sjednicu, napadač
može iskoristiti nezaštićeni cookie prije autentifikacije kako bi dobio pristup autentificiranoj
korisničkoj sjednici.
Web aplikacije trebaju pokušati izbjeći isti naziv cookieja za različite puteve ili domene unutar iste
web aplikacije, jer se time povećava složenost rješenja i potencijalno uvodi pitanje djelokruga.
4.2.4. Istek sjednice
Kako bi se smanjilo vremensko razdoblje u kojem napadač može pokrenuti napad na aktivne sjednice
i oteti ih, obavezno je postaviti vremenski period u kojem će sjednica biti aktivna. Nedovoljno malo
vrijeme isteka sjednice će povećati izloženost web aplikacije drugim napadima temeljenima na
sjednicama, budući da sjednica da bi napadač mogao iskoristiti valjani identifikator sjednice i preoteti
sjednicu, mora još uvijek biti aktivna.
Što je vremenski period aktivnosti sjednice kraći, to napadač manje vremena ima za iskoristiti valjani
identifikator sjednice. Vrijeme isteka sjednice mora biti postavljeno u skladu sa svrhom i prirodom
web aplikacije, te dati ravnotežu između sigurnosti i upotrebljivosti, tako da korisnik stigne komotno
završiti operacije unutar web aplikacije bez čestih isteka njegovih sjednica. I vremenski period
mirovanja i apsolutno vrijeme isteka sjednice su vrijednosti koje su vrlo ovisne o kritičnosti web
aplikacije i podataka koje ona koristi. Uobičajeno vrijeme mirovanja kreće se u rasponu od 2 do 5
minuta za aplikacije visoke vrijednosti i 15-30 minuta za aplikacije niskog rizika primjene.
Kad sjednica istekne, web aplikacija mora poduzeti aktivne mjere poništavanja sjednice na objema
stranama, klijentskoj i poslužiteljskoj. Najvažnije je poništiti sjednicu na strani poslužitelja što je
obavezno iz sigurnosnih razloga.
Za većinu mehanizama razmjene sjednice, aktivnosti na strani klijenta za poništenje identifikatora
sjednice se temelje na poništavanju vrijednosti tokena. Na primjer, za poništavanje cookieja je
preporučljivo dati prazan (ili nevažeću vrijednost) identifikator sjednice, te postaviti atribut „Expires“
(ili „Max-Age“) na datum iz prošlosti (kada se koristi trajni cookie):
Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT
Kako bi se zatvorila i poništila sjednica na strani poslužitelja, web aplikacija je obavezna poduzeti
aktivne mjere pri isteku sjednice ili odjavi aktivnog korisnika, pomoću funkcija i metoda koje nude
mehanizami upravljanja sjednicom, kao "HttpSession.invalidate ()" (J2EE), "Session.Abandon ()"
(ASP.NET) ili "session_destroy()/unset()" (PHP).
4.2.4.1. Automatski istek sjednice
Za sve sjednice treba definirati vrijeme isteka mirovanja ili neaktivnosti. To vrijeme definira
vremenski period u kojem će sjednica ostati aktivna u slučaju da ne postoji aktivnost na sjednici. Ako
je toliko vremena prošlo od posljednjeg HTTP zahtjeva kojeg je web aplikacija primila za određeni
identifikator sjednice, sjednica se zatvara i poništava.
Vrijeme isteka mirovanja ograničava mogućnosti napadača pri pogađanju i iskorištavanju valjanog
identifikatora sjednice drugog korisnika. Međutim, ako je napadač u stanju oteti određenu sjednicu,
vrijeme isteka mirovanja ne ograničava aktivnosti napadača, budući da on tada može periodički
generirati aktivnost na sjednici te držati sjednicu aktivnom dugi vremenski period.
Upravljanje vremenima isteka sjednice mora se provoditi na strani poslužitelja. Ako bi klijent
određivao vrijeme isteka sjednice, primjerice pomoću tokena sjednice ili drugih klijentskih
parametara za praćenje vremenskih referenci (npr. broj minuta od vremena prijave), napadač bi
mogao manipulirati tim vremenima radi produženja trajanja sjednice.
Za sve sjednice treba definirati apsolutno vrijeme isteka koje je neovisno o aktivnosti sjednice. Ovo
vrijeme isteka definira maksimalan vremenski period u kojem sjednica može biti aktivna. Nakon što
istekne tako definirani vremenski period od trenutka kada je web aplikacija stvorila sjednicu,
sjednica se zatvara i poništava. Nakon ukidanja sjednice, korisnik je prisiljen ponovno se
autentificirati u web aplikaciji te uspostaviti novu sjednicu.
Apsolutno vrijeme isteka sjednice ograničava količinu vremena u kojem napadač može iskoristiti
ukradenu sjednicu i utjeloviti korisnika žrtvu.
4.2.4.2. Ručni istek sjednice
Web aplikacija treba osigurati mehanizme koji omogućuju korisnicima svjesnima sigurnosti aktivno
zatvaranje njihove sjednice nakon što su završili s korištenjem web aplikacije.
Web aplikacije moraju osigurati vidljivu lako dostupnu tipku za odjavu koja je dostupna na zaglavlju
web aplikacije ili njenom izborniku, te je dohvatljiva iz svake stranice web aplikacije tako da korisnik
može u bilo kojem trenutku ručno zatvoriti sjednicu.
4.2.5. Dodatne zaštite za upravljanje sjednicom na klijentskoj strani
Web aplikacije mogu nadopuniti prethodno opisane zaštitne mjere upravljanja sjednicom s dodatnim
protumjerama na klijentskoj strani. Zaštitne mjere na klijentskoj strani, obično u obliku JavaScript
provjera, nisu neprobojne i stručni napadač ih može lako probiti, ali mogu biti uvod u drugi sloj
obrane kojeg uljezi moraju zaobići.
4.2.5.1. Vrijeme isteka prijave
Web aplikacije mogu koristiti JavaScript kôd za stranicu prijave kako bi procjenile i izmjerile vrijeme
od učitavanja stranice i odobravanja identifikatora sjednice. Ako se pokušala prijava nakon
definiranog vremenskog perioda, klijentski kôd može obavijestiti korisnika da je prošao maksimalni
vremenski period za prijavu te ponovno učitati stranicu za prijavu, čime će korisnik dobiti novi
identifikator sjednice.
Ovaj dodatni mehanizam zaštite pokušava prisiliti obnavljanje identifikatora sjednice prije
autentifikacije, te izbjegavanje scenarija gdje se ranije korišteni (ili ručno postavljeni) identifikator
sjednice ponovno koristi kada sljedeća žrtva koristi isto računalo, primjerice prilikom napada
fiksiranja sjednice.
4.2.5.2. Tjeranje na odjavu sjednice prilikom zatvaranja prozora web preglednika
Web aplikacije mogu koristiti JavaScript kôd kako bi uhvatile svako zatvaranje kartice ili prozora web
preglednika (ili čak i vraćanje na prethodnu stranicu) te poduzele odgovarajuće mjere kako bi
zatvorile trenutnu sjednicu prije zatvaranja web preglednika, kao da je korisnik ručno zatvorio
sjednicu pomoću tipke za odjavu.
4.2.5.3. Onemogućavanje sjednica između kartica
Web aplikacije mogu koristiti JavaScript kôd nakon što je korisnik prijavljen a sjednica uspostavljena
kako bi se prisililo korisnika na ponovnu autentifikaciju ako se otvara nova kartica ili prozor web
preglednika a odnosi se na istu web aplikaciju. Web aplikacija ne želi dopustiti više kartica ili prozora
web preglednika koji dijele istu sjednicu. Stoga, aplikacija pokušava prisiliti web preglednik da ne
dijeli isti identifikator sjednice istovremeno između njih.
4.2.5.4. Automatska odjava klijenta
Web aplikacija može koristiti JavaScript kôd u svim (ili samo kritičnim) stranicama za automatsku
odjavu klijenta sjednice nakon isteka vremena mirovanja, primjerice preusmjeravanjem korisnika na
stranicu odjave (kao da je korištena tipka za odjavu).
Korist jačanja funkcionalnosti vremena isteka mirovanja na serverskoj strani sa onom na strani
klijenta je da korisnik može vidjeti da je sjednica završila zbog neaktivnosti ili čak može biti unaprijed
obaviješten da sjednica uskoro ističe kroz odbrojavanje i poruke upozorenja. Ovakav pristup pomaže
pri izbjegavanju gubitka obavljenog posla u web stranicama koje zahtijevaju opsežne unose ulaznih
podataka nasuprot tihom isteku sjednice sa strane poslužitelja.
4.2.6. Otkrivanje napada na sjednicu
4.2.6.1. Pogađanje identifikatora sjednice i „brute force“ napad
Ako napadač pokušava pogoditi ili grubom silom otkriti valjani identifikator sjednice, on treba
pokrenuti više uzastopnih zahtjeva prema ciljnoj web aplikaciji pomoću različitih identifikatora
sjednice iz jednog (ili skupa) IP adresa. Osim toga, ako napadač pokuša analizirati predvidljivost
identifikatora sjednice (npr. koristeći statističku analizu), on također treba pokrenuti više uzastopnih
zahtjeva iz jednog (ili skupa) IP adresa prema ciljanoj web aplikaciji radi prikupljanja novih valjanih
identifikatora sjednice. Web aplikacije moraju biti u mogućnosti otkriti oba navedena scenarija na
temelju broja pokušaja prikupljanja (ili korištenja) različitih identifikatora sjednice i upozorti i/ili
blokirati napadačeve IP adrese.
4.2.6.2. Otkrivanje anomalija identifikatora sjednice
Web aplikacije trebaju obratiti pažnju na otkrivanje anomalija povezanih s identifikatorom sjednice,
kao što su manipulacije njime. OWASP AppSensor Project daje okvir i metodologiju za korištenje
ugrađenih sposobnosti za otkrivanje upada u web aplikacije koje su usmjerene na otkrivanje
anomalija i neočekivanih ponašanja u obliku točaka otkrivanja i rezultantnih odgovora. Umjesto
korištenja vanjskih slojeva zaštite, ponekad su detalji poslovne logike i napredna inteligencija
dostupni samo iz unutrašnjosti web aplikacije, gdje je moguće uspostaviti više točaka detekcije
vezanih za sjednicu (primjerice prilikom mijenjanja ili brisanja postojećeg cookieja, te dodavanja
novog cookieja, identifikator sjednice drugog korisnika se ponovno koristi ili kada se lokacija korisnika
promijeni usred sjednice).
4.2.6.3. Povezivanje identifikatora sjednice s drugim postavkama korisnika
S ciljem otkrivanja anomalija u ponašanju korisnika i otmica sjednice, preporuča se vezati
identifikator sjednice za neke druge korisničke postavke, kao što su IP adresa klijenta ili klijentski
digitalni certifikat. Ako web aplikacija otkrije bilo kakvu promjenu ili anomaliju među tim svojstvima
usred uspostavljene sjednice, što je vrlo dobar pokazatelj manipulacija sjednicom i pokušaja otmice,
ta se jednostavna činjenica može iskoristiti za upozorenje i/ili prekid sumnjive sjednice.
Iako web aplikacija ta svojstva ne može iskoristiti za učinkovitu obranu protiv napada na sjednicu, ona
će znatno povećati sposobnosti aplikacije za njihovo otkrivanje. Vješti napadač može zaobići ove
kontrole tako da koristi istu IP adresu koja je dodijeljena žrtvi dijeleći istu mrežu (vrlo često u NAT
okruženjima, kao što su mjesta s javnim Wi-Fi-jem), koristeći isti izlazni web proxy (što je vrlo često u
korporativnim okruženjima) ili mijenjanjem svog korisničkog agenta da izgleda točno kao žrtva.
4.2.6.4. Praćenje životnog ciklusa sjednice
Web aplikacija bi trebala povećati svoje sposobnosti praćenja uključujući u zapisnike informacije
vezane za cijeli životni ciklus sjednice. Ovo se preporuča za snimanje događaja povezanih sa
sjednicama poput stvaranja, obnove i uništavanja identifikatora sjednica, kao i detalje oko njihovog
korištenja između operacija prijave i odjave, promjena razine privilegija unutar sjednice, vremena
isteka, nedozvoljenih djelatnosti sjednice (kada se otkriju) te kritičnih poslovnih operacija tijekom
sjednice.
Zapisani detalji mogu uključivati vremenski žig, izvornu IP adresu, tražene resurse (koji su uključeni u
rad sjednice), HTTP zaglavlja, GET i POST parametre, identifikatore i poruke o pogreškama, korisničko
ime (ili korisnički ID), identifikator sjednice (cookieje, URL, GET, POST...). Osjetljivi podaci poput
identifikatora sjednice ne bi trebali biti uključeni u zapisnicima kako bi se sjednični zapisnici zaštitili
od lokalnog ili udaljenog otkrivanja identifikatora sjednice ili neovlaštenog pristupa identifikatoru.
Međutim, neke informacije specifične za pojedinu sjednicu moraju biti uključene u zapisnik radi
korelacije zapisnika sa pripadnim sjednicama. Preporučuje se zapisati hash identifikatora sjednice
umjesto samog identifikatora kako bi se omogućila korelacija sjednice i pripadnog zapisa bez
izlaganja identifikatora sjednice.
Web aplikacije moraju temeljito zaštititi administrativna sučelja koja imaju mogućnost upravljati svim
trenutno aktivnim sjednicama. Ta sučelja često koriste osobe zadužene za davanje podrške pri
rješavanju problema sa sjednicama ili čak općih problema, pritom se lažno predstavljajući kao
korisnik i gledajući na web aplikaciju iz korisnikove perspektive.
Zapisnici o sjednici postali su jedan od glavnih izvora za otkrivanje upada u web aplikacije, a također
ih mogu koristiti sustavi zaštite od upada za automatsko prekidanje sjednice i/ili onemogućavanje
korisničkih računa kada su napadi otkriveni. Ako se koriste aktivne mjere zaštite, te obrambene akcije
također moraju biti zabilježene.
4.2.6.5. Istovremene prijave sjednica
Na dizajnu web aplikacije ostaje odluka hoće li višestruke istovremene prijave istog korisnika biti
dozvoljene s iste ili različitih IP adresa klijenta. Ako web aplikacija ne želi dopustiti istovremene
prijave sjednica, ona mora poduzeti djelotvorne mjere nakon svakog novog događaja autentifikacije,
implicitno prekidajući ranije dostupnu sjednicu ili pitajući korisnika (preko stare, nove ili obje
sjednice) o tome koja sjednica treba ostati aktivna.
Preporuča se za web aplikacije dodati korisničke mogućnosti provjere podataka o aktivnim
sjednicama u bilo koje vrijeme, praćenje i upozoravanje korisnika o istovremenim prijavama,
pružanje korisniku mogućnosti ručnog prekidanja sjednice na daljinu, te praćenje aktivnosti
korisničkog računa kroz dnevnik zapisivanjem višestrukih detalja o klijentu, kao što su IP adrese,
datumi i vremena prijave, vrijeme mirovanja itd. [6]
5. Nesigurne reference na objekte
Izravna referenca na objekt nastaje kada programer izloži referencu objektu unutarnje
implementacije kao što je datoteka, direktorij, zapis u bazi podataka ili ključ. Napadač može
manipulirati izravnim referencama na objekte kako bi pristupio drugim objektima bez odobrenja
osim kada je implementirana provjera kontrole pristupa na odgovarajućem mjestu.
Primjerice, u aplikacijama za internet bankarstvo uobičajeno je koristiti broj računa kao primarni
ključ. Iz tog je razloga primamljivo koristiti broj računa izravno na web sučelju. Čak i ako su
programeri koristili parametrizirane SQL upite kako bi se spriječilo SQL umetanje, ako ne postoji
dodatna provjera da je trenutni korisnik stvarni vlasnik računa i da je ovlašten za promatranje tog
računa, napadač koji manipulira parametrom s brojem računa može vidjeti ili promijeniti sve račune.
Ova vrsta napada dogodila se 2000. godine na stranici austalskog poreznog ureda kada je legitiman
ali zlonamjeran korisnik jednostavno promijenio porezni broj tvrtke prisutan u URL-u. Korisnik je
došao do detaljnih podataka o 17 000 tvrtki u sustavu. Ova vrsta ranjivosti je vrlo česta, ali je
uglavnom slabo istestirana u trenutnim aplikacijama.
Mnoge aplikacije izlažu korisnicima svoje unutarnje reference na objekte. Napadači koriste te
parametre kako bi promijenili reference te prekršili predviđenu politiku kontrole pristupa. Često su te
reference povezane sa datotekama i bazama podataka, pa bilo kakvo izlaganje aplikacije može
pokazati ranjivost.
Na primjer, ako kôd omogućuje korisniku unos imena datoteka ili path-ova, to može omogućiti
napadačima prelazak iz direktorija aplikacije te tako dobivanje pristupa drugim resursima.
<select name="language"><option value="fr">Français</option></select>
…
require_once ($_REQUEST['language’]."lang.php");
Takav kôd može biti napadnut pomoću stringa ".. /.. /.. /.. /etc/passwd% 00" pomoću umetanja
praznog bajta za pristup bilo kojoj datoteci web-poslužitelja.
Isto tako su često izložene reference na ključeve baza. Napadač može napasti te parametre
jednostavnim nagađanjem ili potragom za drugim valjanim ključem. Često su ključevi u svojoj prirodi
sekvencijalni. U niže navedenom primjeru, čak i ako aplikacija ne dozvoli pristup neovlaštenim
sadržajima, a nije ni moguće SQL umetanje, napadač još uvijek može promijeniti parametar cartID u
koji god želi. [7]
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );
String query = "SELECT * FROM table WHERE cartID=" + cartID;
5.1.
Primjer ranjivosti
Aplikacija koristi neprovjerene podatke u SQL pozivu kojim se pristupa računu:
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query , ... );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery();
Napadač jednostavno mijenja parametar 'acct' u žrtvinom pregledniku kako bi poslao koji god broj
računa on želi. Ako nije provjereno, napadač može pristupiti bilo kojem korisničkom računu, umjesto
samo onom kojem namjerava. [8]
http://example.com/app/accountInfo?acct=notmyacct
5.2.
Provjera ranjivosti na nesigurne reference na objekte
Najbolji način da bi se provjerila ranjivost aplikacije na nesigurne reference na objekte je provjera da
li sve reference na objekte imaju odgovarajuću zaštitu. Da bi se to provjerilo potrebno je razmotriti:
- Za izravne reference na ograničene resurse, aplikacija treba potvrditi je li korisnik ovlašten za
pristup upravo tom resursu koji traži.
- Ako je referenca neizravna, mapiranje do izravne reference mora biti ograničeno na
vrijednosti za koje trenutni korisnik ima ovlasti. [8]
Cilj je provjeriti da aplikacija ne dopušta napadaču manipulaciju izravnim referencama na objekte
-
Automatizirani pristupi: alati za traženje ranjivosti će imati poteškoća pri utvrđivanju koji su
parametri osjetljivi na manipulacije te je li manipulacija uspjela. Statički alati za analizu
nikako ne mogu znati za koje se parametre mora napraviti provjera kontrole pristupa prije
njihove upotrebe.
-
Ručni pristupi: Provjerom kôda mogu se pratiti kritični parametri te utvrditi jesu li oni
podložni manipulacijama u mnogim slučajevima. Penetracijska testiranja mogu potvrditi da je
manipulacija moguća. Međutim obje navedene tehnike zahtjevaju mnogo vremena i nisu
dosljedne. [7]
5.3.
Zaštita od nesigurnih referenci na objekte
Radi sprječavanja nesigurnih referenci na objekte zahtijeva se odabir pristupa za zaštitu svakog
objekta dostupnog korisniku (npr. broj objekta, ime datoteke):
- Korištenje indirektnih referenci na objekte za pojedinog korisnika ili sjednicu. Tako će
napadač biti sprječen u izravnom napadu na neovlaštene resurse. Na primjer, umjesto
korištenja ključa baze podataka koristi se padajuća lista od šest stavki koje su autorizirane za
trenutnog korisnika koja može koristiti brojeve od 1 do 6 kojima se označava vrijednost koju
je korisnik odabrao. Aplikacija mora povezati neizravnu korisničku referencu natrag do
stvarnog ključa baze podataka na poslužitelju. ESAPI uključuje i slijedni i slučajni pristup
referentnoj mapi koju programeri mogu koristiti kako bi uklonili izravne reference na objekte.
- Pristup s provjerama - Svaka upotreba izravne reference na objekt iz nepouzdanog izvora
mora uključivati provjeru kontrole pristupa kako bi se osigurala autorizacija korisnika za
pristup željenom objektu. [8]
Najbolja zaštita je izbjegavanje izlaganja izravnih referenci na objekte korisnicima pomoću indeksa,
neizravne mape referenci ili drugog neizravnog načina koji je lako provjeriti. Ako se mora koristiti
izravna referenca na objekt, potrebno je provjeriti da je korisnik ovlašten prije njezine upotrebe. [7]
Važno je uspostaviti standardni način korištenja objekata:
- Kad god je moguće izbjegavati izlaganje privatnih referenci na objekte kao što su primarni
ključevi ili nazivi datoteka korisnicima
- Detaljno provjeriti sve privatne reference na objekte u skladu s pristupom „prihvati dobro
poznato“
- Provjeriti autorizaciju za sve korištene objekte
Najbolje rješenje je korištenje indeksa ili mape referenci kako bi spriječili napade manipuliranja
parametrima. Primjerice:
http://www.example.com/application?file=1
Ako se moraju izložiti izravne reference na strukture baze podataka, potrebno je osigurati da SQL
izjave i druge metode pristupa bazama podataka dopuštaju prikaz samo ovlaštenih zapisa:
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );
User user = (User)request.getSession().getAttribute( "user" );
String query = "SELECT * FROM table WHERE
cartID=" + cartID + " AND userID=" + user.getID();
6. Krivotvorenje zahtjeva na drugom sjedištu
Krivotvorenje zahtjeva na drugom sjedištu (eng. Cross Site Request Forgery, CSRF) je napad u kojem
se krajnji korisnik namami na izvršavanje neželjene radnje na ranjivoj web aplikaciji za koju je dobio
ovlaštenje. Pomoću socijalnog inženjeringa (kao što je slanje linka putem elektroničke pošte ili chata), napadač može navesti korisnika web aplikacije na izvršavanje akcije koju je napadač odabrao.
Uspješan CSRF napad može ugroziti podatke i radnje krajnjih korisnika kada se radi o standardnom
korisniku. Ako je ciljani krajnji korisnički račun administratorski, napad može ugroziti cijelu webaplikaciju.
CSRF je napad u kojem se žrtva prijevarom navodi na učitavanje stranice koja sadrži zlonamjerni
zahtjev. Zahtjev je zlonamjeran u smislu da nasljeđuje identitet i privilegije žrtve radi izvođenja
neželjene funkcije u ime žrtve, kao što je primjerice promjena e-mail adrese žrtve, njene kućne
adrese ili lozinke, kupnje nečega itd. CSRF napad uglavnom cilja na funkcije koje uzrokuju promjenu
stanja na poslužitelju, ali se također može koristiti za pristupanje osjetljivim podacima.
Na većini internet stranica, preglednici automatski uključuju u zahtjeve neke povjerljive podatke, kao
što su korisnikov sjednični kolačić, osnovni podaci za autorizaciju, IP adresa, autentifikacija na
Windows domenu itd. Prema tome, ako je korisnik u tom trenutku autenticiran za tu stranicu,
stranica neće nikako moći razlikovati napadačev od legitimnog zahtjeva korisnika. Na taj način
napadač može natjerati žrtvu na obavljanje radnji koje nije namjeravala (kao što je odjava, kupovina
artikala, promjena podataka o računu, dohvat podataka o računu ili bilo koja druga funkcija koja je
omogućena na toj ranjivoj web stranici).
Ponekad je moguće pohraniti CSRF napad na samu ranjivu stranicu. Takva ranjivost se zove
pohranjeni CSRF nedostatak. Ovo se može ostvariti jednostavnim pohranjivanjem jedne IMG ili
IFRAME oznake u polju koje prihvaća HTML ili složenijim cross-site scripting napadom. Ako se napad
može pohraniti na stranici, on će biti jači. Tada se vjerojatnost napada povećava, jer je veća
vjerojatnost da žrtva vidi stranicu koja sadrži napad nego neku slučajnu stranicu na internetu.
Vjerojatnost je također povećana, jer će žrtva sigurno do tada biti autenticirana. [9]
6.1. Primjer napada
Postoje brojni načini na koje se krajnji korisnik može namamiti na očitavanje podataka iz ili njihovo
slanje na web aplikaciju. Kako bi se izvršio napad, prvo treba znati generirati zlonamjerni zahtjev koji
žrtva treba izvršiti. Na primjer: Ana želi prenijeti 100kn sa svog računa na Markov pomoću aplikacije
bank.com. Ana generira slijedeći zahtjev:
POST http://bank.com/transfer.do HTTP/1.1
...
...
...
Content-Length: 21;
acct=MARKO&amount=100
Međutim Marija primjećuje da će ista web aplikacija izvršiti isti taj prijenos pomoću URL parametara
kako slijedi:
GET http://bank.com/transfer.do?acct=MARKO&amount=100 HTTP/1.1
Marija sada odlučuje iskoristiti ovu ranjivost koristeći Anu kao svoju žrtvu. Marija prvo konstruira
sljedeći URL koji će prenijeti 100.000 kuna sa Aninog računa na njezin:
http://bank.com/transfer.do?acct=MARIJA&amount=100000
Sada kada je generirala zlonamjeran zahtjev, Marija mora navesti Anu da pošalje taj zahtjev.
Uobičajeni način je poslati Ani HTML e-mail koji sadrži sljedeće:
<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my
Pictures!</a>
Ako će Ana biti autenticirana unutar aplikacije u trenutku kada klikne na link, doći će do prijenosa
100.000 kuna na Marijin račun. Međutim Marija shvaća da će Ana, ako klikne na link, primijetiti da je
došlo do prijenosa. Stoga Marija odlučuje sakriti napad u sliku veličine nula bajtova:
<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1"
height="1" border="0">
Ako bi ovaj zapis slike bio uključen u e-mail, Ana bi vidjela samo mali okvir koji pokazuje da
preglednik nije mogao prikazati sliku. Međutim preglednik će i dalje podnijeti zahtjev prema
bank.com bez vizualne naznake da se prijenos dogodio. [9]
6.2. Sprječavanje napada
Pojedinačni korisnici koji koriste nemodificirane verzije najpopularnijih preglednika vrlo malo mogu
učiniti kako bi se spriječilo krivotvorenje zahtjeva na drugom sjedištu. Odjava sa web aplikacija i
izbjegavanje njihove opcije za pamćenje podataka za prijavu mogu ublažiti CSRF rizik. Pomaže i
izbjegavanje prikaza vanjskih slika, klikanja linkova u spam pošiljkama ili nepouzdanoj elektoničkoj
pošti.
Proširenja preglednika poput police „RequestPolicy“ (za preglednik Mozilla Firefox) može spriječiti
CSRF napade politikom automatskog odbijanja zahtjeva sa drugog sjedišta. Ta opcija međutim može
značajno utjecati na normalan rad mnogih web stranica. Proširenje „CsFire“ (također za Firefox)
može ublažiti utjecaj CSRF napada na normalno pregledavanje uklanjanjem autentifikacijskih
podataka iz zahtjeva s drugog sjedišta. Proširenje „NoScript“ ublažava CSRF prijetnje razlikovanjem
pouzdanih i nepouzdanih web stranica, te uklanjanjem suvišnih podataka iz POST zahtjeva poslanih
od nepouzdanih web stranica prema pouzdanima.
Web stranice imaju različite CSRF protumjere na raspolaganju:
- Zahtjevati tajnu (token) specifičan za korisnika u svim zahtjevima te time i URL-u za
sprječavanje CSRF napada. Napadačeva stranica neće moći dodati ispravan token u svojim
zahtjevima.
- Zahtjevati od klijenta slanje podataka za autentikaciju u istom HTTP zahtjevu koji se koristi za
obavljanje bilo kakve operacije sa sigurnosnim implikacijama (prijenos novca itd.)
- Ograničavanje trajanja sjedničnih kolačića
- Osigurati da nema datoteke clientaccesspolicy.xml za dodjelu neovlaštenog pristupa
Silverlight kontrolama
- Osigurati da nema datoteke crossdomain.xml za dodjelu neovlaštenog pristupa flash
filmovima
Jednostavno i učinkovito rješenje je korištenje CSRF filtera kao što je OWASP-ov CSRFGuard. Filter
presreće odgovore, detektira radi li se o HTML dokumentu te umeće token u dokumente i opcionalno
umeće skripte za umetanje tokena u funkciju ajax. Filter također presreće zahtjeve kako bi provjerio
je li u njima prisutan token. [10]
7. Pogrešno postavljene sigurnosne postavke
Pogrešno postavljene sigurnosne postavke mogu se dogoditi na bilo kojoj razini aplikacije, uključujući
platformu, web-poslužitelja, aplikacijskog poslužitelja, prilagođeni kôd... Razvojni inženjeri i mrežni
administratori trebaju surađivati kako bi se osiguralo da je svaka razina ispravno konfigurirana.
Automatizirani skeneri su korisni za otkrivanje nedostataka, pogrešnih postavki, načina korištenja
korisničkih računa, nepotrebnih usluga itd. [11]
Konfiguracije web i aplikacijskog poslužitelja igraju ključnu ulogu u sigurnosti web aplikacija. Ti
poslužitelji su odgovorni za posluživanje sadržaja i pozivanje aplikacija koje stvaraju sadržaj. Osim
toga, mnogi aplikacijski poslužitelji pružaju niz usluga koje web aplikacije mogu koristiti, uključujući i
pohranu podataka, usluge direktorija, poruke i još mnogo toga. Neuspjeh u upravljanju pravilnom
konfiguracijom servera može dovesti do raznih sigurnosnih problema.
Često su osobe zadužene za web razvoj odvojene od onih koje upravljaju stranicom. Često postoji jaz
između onih koji su napisali aplikaciju i onih koji su odgovorni za njeno operativno okruženje. Radi
sigurnosti web aplikacija potrebno je premostiti taj problem te zahtijevati suradnju obiju strana kako
bi se osigurala sigurnost aplikacije.
Postoji širok raspon problema sa konfiguracijom poslužitelja koji mogu ugroziti sigurnost web
aplikacije. On uključuje:
- Sigurnosni propusti u softveru poslužitelja koji nisu zakrpani
- Nedostatci u kôdu servera ili njegovoj konfiguraciji koji dopuštaju ispisivanje direktorija i
omogućavaju s time povezane napade
- Nepotrebne inicijalne ili datoteke s primjerima, uključujući skripte, aplikacije, konfiguracijske
datoteke i web-stranice
- Neprikladne dozvole pristupa datotekama i direktorijima
- Omogućavanje pristupa nepotrebnim uslugama uključujući upravljanje sadržajem i
administraciju s udaljenog mjesta
- Inicijalni korisnički računi s njihovim inicijalnim lozinkama
- Administrativne funkcije ili funkcije ispravljanja pogrešaka koje su omogućene ili dostupne
- Pretjerano informativne poruke o pogreškama
- Pogrešno konfigurirani SSL certifikati i postavke kriptiranja
- Korištenje inicijalnih certifikata
- Neprikladna autentifikacija s vanjskim sustavima
Neki od ovih problema mogu biti otkriveni pomoću lako dostupnih sigurnosnih skenera. Nakon što su
otkriveni, ovi problemi mogu lako biti iskorišteni i rezultirati kompromitiranjem čitave web stranice.
Uspješni napadi također mogu ugroziti i krajnji sustav, uključujući baze podataka i korporativne
mreže. Oboje, siguran kôd i sigurna konfiguracija, su potrebni kako bi se napravila sigurna web
aplikacija.
Ako web i aplikacijski server nisu zaključani, aplikacija je najvjerojatnije ranjiva. Malo je servera, ako
uopće postoje, koji su inicijalni sigurni. Sigurna konfiguracija platforme mora biti dokumentirana i
redovito ažurirana. Redovito se treba raditi pregled dokumentacije o konfiguraciji kako bi se
osiguralo da je aktualna i ažurirana. Također se preporuča usporedba sa stvarnim sustavom.
Osim toga, postoji niz proizvoda za skeniranje sustava koji će izvana skenirati web ili aplikacijski
poslužitelj na poznate ranjivosti. Te bi alate trebalo redovito koristiti. Preporuča se koristiti ih barem
jednom mjesečno, kako bi se problemi pronašli što je prije moguće. Alate bi trebalo pokrenuti i
iznutra i izvana. Vanjsko skeniranje se pokreće na hostu koji je lociran izvan mreže ciljanih
poslužitelja. Unutarnje skeniranje treba pokrenuti iz iste mreže na kojoj su ti poslužitelji. [12]
7.1. Primjeri pogrešno postavljenih sigurnosnih postavki
Primjer 1:
Neka aplikacija se oslanja na snažan framework kao što je Struts ili Spring. U njegovim
komponentama na koje se aplikacija oslanja pronađene su XSS ranjivosti. Pušteno je ažuriranje kojim
se popravljaju ti nedostaci, ali ne ažuriraju se biblioteke aplikacije. Dok se to ne učini, napadači mogu
lako pronaći i iskoristiti ove nedostatke u aplikaciji.
Primjer 2:
Administratorska konzola aplikacijskog servera se automatski instalira i ne uklanja. Inicijalni računi
nisu promijenjeni. Napadač otkriva standardne administratorske stranice na tom poslužitelju,
prijavljuje sa inicijalnom lozinkom i preuzima upravljanje.
Primjer 3:
Popisivanje direktorija nije onemogućeno na nekom poslužitelju. Napadač otkriva da jednostavno
može popisati direktorije kako bi pronašao datoteku koju želi. Napadač pronalazi i preuzima sve
kompajlirane dokumente Java klase, iz kojih reverznim inženjeringom dobiva njen izvorni kôd.
Napadač tada nalazi ozbiljan nedostatak kontrole pristupa u aplikaciji.
Primjer 4:
Konfiguracija aplikacijskog poslužitelja dozvoljava vraćanje korisniku logova sa stoga, time
potencijalno izlažući temeljne nedostatke. Napadači koriste sve dodatne podatke o pogreškama koje
im se pružaju. [11]
7.2. Sprječavanje pogrešno postavljenih sigurnosnih postavki
Primarne preporuke su utvrditi sljedeće stavke:
- Ustanoviti ponovljivi proces konfiguriranja koji će omogućiti brzo i jednostavno
implementiranje drugog okruženja koje je pravilno osigurano. Razvojno, testno i proizvodno
okruženje bi trebali biti konfigurirani identično. Ovaj proces bi trebao biti automatiziran kako
bi se smanjio napor potreban za konfiguriranje novog sigurnog okruženja.
- Utvrditi postupak za održavanje i implementaciju svih novih ažuriranja kôda kao i zakrpa
pravodobno na svakom okruženju koje se koristi. To treba uključiti i sve biblioteke što se
često previdi.
- Napraviti jaku arhitekturu aplikacije koja pruža dobro odvajanje i sigurnost između
komponenata.
- Dogovoriti povremena skeniranja i revizije pomoću kojih bi se mogla otkriti buduća pogrešna
postavljanja sigurnosnih postavki ili nedostatak zakrpa. [11]
8. Nesigurna pohrana šifriranih podataka
Zaštita osjetljivih podataka pomoću kriptografije postala je ključni dio većine web aplikacija. Vrlo je
uobičajeno da se osjetljivi podaci jednostavno ne uspiju šifrirati. Aplikacije koje koriste šifriranje često
imaju loše napisan kôd za šifriranje. Ili koriste neprimjerene metode šifriranja ili uzrokuju ozbiljne
pogreške koristeći snažne metode šifriranja. Ovi nedostaci mogu dovesti do otkrivanja osjetljivih
podataka i povrede ovlaštenja. [13]
8.1. Primjeri nesigurne pohrane šifriranih podataka
Primjer 1:
Aplikacija šifrira podatke o kreditnim karticama u bazu podataka kako bi se spriječilo njihovo izlaganje
krajnjim korisnicima. Međutim, baza je konfigurirana tako da automatski dešifrira upite vezane za
stupce podataka o kreditnim karticama, omogućujući tako da se pomoću SQL injekcije dohvaćaju svi
podaci o kreditnim karticama kao čisti tekst. Sustav bi trebao biti konfiguriran tako da dopušta samo
pozadinskim upitima aplikacije dešifriranje tih podataka, a ne izravnim upitima web aplikacija.
Primjer 2:
Napravljena je dodatni (backup) medij na kojem su spremljeni svi šifrirani zdravstveni podaci iz
evidencije, ali ključ za šifriranje pohranjen je na istom mediju.On nikada ne stigne na lokaciju za
dodatnu pohranu (backup) podataka.
Primjer 3:
Baza podataka za pohranu lozinki koristi sažetke bez dodatnog parametra salt za pohranu svih lozinki.
Ranjivost pri slanju dokumenta omogućuje napadaču preuzimanje datoteke lozinki. Svi sažeci bez
parametra salt mogu „brute force“ napadom biti otkriveni u četiri tjedna, dok bi za one s ispravnim
parametrom salt trebalo 3000 godina. [14]
8.2. Sprečavanje kriptografskih nedostataka
Za sprečavanje kriptografskih nedostataka potrebno je pomno planiranje. Najčešći problemi su:
- Nekriptiranje osjetljivih podataka
- Korištenje samostalno napravljenih algoritama
- Nesigurno korištenje snažnih algoritama
- Nastavljanje s korištenjem dokazano slabih algoritama (MD5, SHA-1, RC3, RC4...)
- Pohranjivanje ključeva unutar kôda, te njihovo nezaštićeno pohranjivanje
Načini provjere da bi se potvrdilo da aplikacija ispravno šifrira osjetljive informacije za pohranu dijele
se na automatizirane i ručne.
- Automatizirani pristupi: alati za skeniranje ranjivosti ne mogu uopće provjeriti pohranu
kriptografskih podataka. Oni mogu otkriti korištenje poznatih kriptografskih algoritama, ali ne
mogu otkriti koriste li se oni ispravno ili da li se kodiranje izvodi na vanjskoj komponenti.
- Ručni pristupi: Kao i skeniranje, testiranje ne može apsolutno provjeriti pohranu kriptografskih
podataka. Pregled kôda je najbolji način da se provjeri da li aplikacija šifrira osjetljive podatke
te ima ispravno implementiran mehanizam šifriranja i upravljanja ključevima. Ovo u nekim
slučajevima može uključivati ispitivanje konfiguracije vanjskih sustava. [13]
8.3.
Zaštita od kriptografskih nedostataka
Najvažniji zadatak je osigurati da sve ono što bi trebalo biti šifrirano, zapravo i bude šifrirano. Osim
toga potrebno je osigurati ispravno provođenje kriptografije. Budući da postoji toliko mnogo načina
nepravilnog korištenja kriptografije, sljedeće preporuke treba uzeti u obzir prilikom testiranja ove
ranjivosti kako bi se osiguralo sigurno rukovanje kriptografskim materijalom:
-
Ne stvarati svoje kriptografske algoritme. Trebalo bi koristiti samo odobrene javne algoritme
kao što su AES, RSA kriptografija javnog ključa, te SHA-256 ili neki bolji algoritam za
sažimanje.
-
Ne koristiti slabe algoritme, kao što su MD5 ili SHA1. Radije koristiti sigurnije alternative kao
što je SHA-256.
-
Generirati ključeve offline, a privatne ključeve pohraniti s izuzetnom pažnjom. Nikada ne
prenositi privatne ključeve preko nesigurnih kanala.
-
Osigurati da su autorizacijski podaci za primjerice baze podataka pravilno osigurani (pomoću
strogih kontrola i dozvola pristupa) ili sigurno šifrirani i teški za dešifriranje bilo lokalnim ili
udaljenim korisnicima.
-
Pobrinuti se da šifrirane podatke pohranjene na disk nije lako dešifrirati. Primjerice šifriranje
baze podataka nema svrhe ako je bazi podataka osiguran nešifrirani pristup.
-
Prema trećem zahtjevi PCI Data Security standarda, moraju se zaštititi podaci vlasnika kartice.
Usklađenost s PCI DSS standardom je obavezna od 2008. za trgovce i sve druge koji rukuju
kreditnim karticama. Dobra praksa je da se nikada ne pohranjuju nepotrebni podaci, kao što
su podaci s magnetne trake ili primarni brojevi računa (PAN, inače poznat kao broj kreditne
kartice). Ako se pohranjuje PAN, moraju se poštivati PCI DSS zahtjevi. Na primjer, nikada se
ne smije pohraniti CVV broj (tri znamenke na poleđini kartice) ni pod kojim okolnostima. [13]
9. Nezaštićeni pristup URL-ovima
Najčešće je jedina zaštita za URL-ove da poveznice na tu stranicu ne budu prikazane neovlaštenim
korisnicima. Međutim čak i tada motiviran, vješt ili jednostavno sretan napadač može biti u
mogućnosti pronaći način za pristupiti ovim stranicama, pozivati funkcije i pregledavati podatke.
Sigurnost postignuta skrivanjem nije dovoljna kako bi se zaštitile osjetljive aplikacijske funkcije i
podaci. Provjere kontrole pristupa moraju se obaviti prije odobrenja zahtjeva za osjetljivom
funkcijom što osigurava ovlašten pristup korisniku za tu funkciju.
Osnovna metoda napada za ovu ranjivost zove se "prisilno pregledavanje", koje obuhvaća nagađanje
poveznica i tehnike „brute force“ napada kako bi se pronašle nezaštićene stranice. Aplikacije obično
dozvoljavaju širenje kôda za kontrolu pristupa po cijelom kôdu, što rezultira složenim modelom
kojega teško razumiju i programeri i stručnjaci za sigurnost. Ova složenost čini vjerojatnijim pojavu
pogrešaka i propusta na nekim stranicama koje onda ostaju izložene.
Neki uobičajeni primjeri tih nedostataka su:
-
"Skriveni" ili "posebni" URL-ovi, dodjeljeni samo administratorima ili privilegiranim
korisnicima u prezentacijskom sloju, ali su dostupni svim korisnicima ako oni znaju za njihovo
postojanje kao što su /admin/adduser.php ili /approveTransfer.do. Ovo je posebno
rasprostranjeno u kôdu izbornika.
-
Aplikacije često omogućuju pristup "skrivenim" datotekama, kao što su statički XML ili
sustavno generirani izvještaji, vjerujući u sigurnost skrivanjem.
-
Postoji kôd koji provodi politiku kontrole pristupa, ali je zastario ili nedovoljan. Primjerice,
neka je /approveTransfer.do nekad bio dostupan svim korisnicima, ali su nove kontrole
donijele odluku da bi on trebao biti dostupan samo određenima. Nadogradnja aplikacije je
možda uvela da ga se ne prezentira neovlaštenim korisnicima, ali ne i kontrolu pristupa koja
se nužno provodi kada se zatraži baš tu stranica.
-
Postoji kôd koji procjenjuje ovlasti kod klijenta, ali ne i na poslužitelju, kao u napadu na
MacWorld 2007. koji je odobrio „platinaste“ ulaznice vrijedne 1700 dolara putem JavaScripta
na pregledniku a ne na poslužitelju. [15]
9.1. Primjer nezaštićenog pristupa URL-ovima
Napadač jednostavno na silu pretražuje kako bi došao do ciljanih URL-ova. Neka su to primjerice
sljedeći URL-ovi koji su oboje trebali zahtijevati autentikaciju. Za pristup stranici "admin_getappInfo"
su također potrebna administratorska prava:
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
Ako napadač nije autentificiran, a odobren mu je pristup bilo kojoj od ovih stranica, tada mu je bio
dopušten neovlašten pristup. Ako je autentificiranom korisniku koji nije administrator dopušten
pristup „admin_getappInfo“ stranici, to je mana koja može dovesti napadača na više nedovoljno
zaštićenih administratorskih stranica.
Takvi nedostaci se često javljaju kada se poveznice i tipke ne prikazuju neovlaštenim korisnicima, ali
aplikacija ne uspjeva zaštititi ciljane stranice. [16]
9.2. Provjera sigurnosti pristupa URL-ovima
Cilj je provjeriti da se kontrola pristupa dosljedno provodi u prezentacijskom sloju i poslovnoj logici za
sve URL-ove u aplikaciji.
-
Automatizirani pristupi: Oboje, i skeneri ranjivosti i alati za statičku analizu, imaju poteškoća s
provjerom kontrole pristupa URL-ovima, ali iz različitih razloga. Skeneri za provjeru ranjivosti
imaju poteškoća pri traženju skrivenih stranica i određivanja koje stranice bi trebale biti
dopuštene za kojeg korisnika, dok alati za statičku analizu imaju poteškoća pri identifikaciji
korisniku prilagođenih kontrola pristupa u kôdu i povezivanju prezentacijskog sloja s
poslovnom logikom.
-
Ručni pristupi: Najučinkovitiji i najprecizniji pristup je korištenje kombinacije pregledavanja
kôda i testiranja sigurnosti kako bi se potvrdio mehanizam kontrole pristupa. Ako je
mehanizam centraliziran, provjera može biti vrlo učinkovita. Ako je distribuiran preko cijelog
kôda, provjera može oduzeti jako puno vremena. Ako se mehanizam provodi izvana,
konfiguracija mora biti ispitana i testirana. [15]
9.3. Zaštita pristupa URL-ovima
Ključni korak u ostvarivanju zaštite protiv nezaštićenog pristupa URL-ovima je uzeti dovoljno vremena
za planiranje autorizacije stvaranjem matrice za mapiranje uloga i funkcija aplikacije. Web aplikacije
moraju provoditi kontrolu pristupa na svakom URL-u i poslovnoj funkciji. Nije dovoljno napraviti
kontrolu pristupa u prezentacijskom sloju i ostaviti poslovnu logiku nezaštićenom. Također nije
dovoljno samo jednom tokom procesa provjeriti ima li korisnik ovlaštenje, a onda ne provjeravati ima
li korisnik ovlaštenje za naredne korake. Inače napadač može jednostavno preskočiti korak kada se
provjerava autorizacija i krivotvoriti vrijednosti parametara potrebne za nastaviti na sljedećem
koraku.
Uvođenje kontrole pristupa URL-ovima zahtjeva pažljivo planiranje. Neka od najvažnijih pravila su:
-
Osigurati da matrica kontrole pristupa bude dio funkcije, arhitekture i dizajna aplikacije
-
Osigurati da svi URL-ovi i poslovne funkcije budu zaštićeni učinkovitim mehanizmom kontrole
pristupa koji provjerava ulogu korisnika i dodijeljena prava prije nego se obavi ikakva obrada.
Pobrinite se da se ova provjera obavlja tijekom svakog koraka, a ne samo jednom na početku
procesa koji zahtjeva više koraka.
-
Napraviti penetracijsko testiranje prije aktiviranja ili isporuke kôda kako bi se osiguralo da
motivirani sposoban napadač ne može zloupotrijebiti aplikaciju.
-
Obratiti pozornost na datoteke i biblioteke uključene u aplikaciju, pogotovo ako imaju izvršnu
ekstenziju kao što je primjerice .php. Tamo gdje je to moguće, one bi trebale biti izvan
početnog web-a. Trebalo bi potvrditi da im se ne može izravno pristupiti npr. provjerom
konstante koja se može obaviti samo pozivanjem biblioteke
-
Ne smije se pretpostaviti da korisnici neće biti svjesni posebnog ili skrivenog URL-a ili API-ja.
Uvijek treba osigurati da su administrativne i akcije za koje je potrebna visoka privilegija
zaštićene.
-
Blokirati pristup svim vrstama datoteka koje aplikacija nikada izravno ne koristi. U idealnom
slučaju, ovaj filter bi trebao slijediti pristup „prihvati dobro poznato“ i dopustiti samo vrste
datoteka koje se namjeravaju koristiti (primjerice .html, .pdf,.php). Na taj način bi se blokirali
bilo koji pokušaji pristupa log datotekama, XML datotekama itd. kojima se nikada ne
namjerava izravno pristupati.
-
Redovito održavati zaštitu od virusa i zakrpe komponenata kao što su XML procesori,
procesori slika itd. koje obrađuju podatke koje korisnik isporučuje. [15]
10.
Nedovoljna zaštita na transportnom sloju
Aplikacije često ne uspijevaju kodirati mrežni promet kada je to nužno za zaštitu osjetljive
komunikacije. Šifriranje (obično SSL) se mora koristiti za sva autentificirana povezivanja, posebno na
web stranicama koje su pristupačne na internetu, ali također i na pozadinskim vezama. Inače će
autentifikacija ili sjednični token aplikacije biti izloženi. Šifriranje treba koristiti svaki put kad se
prenose osjetljivi podaci kao što su brojevi kreditnih kartica ili zdravstvene informacije. Aplikaciju
koja prestaje koristiti šifrirani način rada napadač može lako zloupotrijebiti. PCI standard zahtijeva da
svi podaci o kreditnim karticama koji se prenose preko interneta moraju biti kodirani.
Neuspjeh pri šifriranju osjetljive komunikacije omogućuje napadaču njuškanje mrežnog prometa te
mu daje mogućnost prisluškivanja razgovora, uključujući i sve povjerljive ili osjetljive informacije koje
se prenose. Treba uzeti u obzir da su različite mreže više ili manje osjetljive na njuškanje. Međutim
važno je shvatiti da će takav sustav biti ugrožen na gotovo svakoj mreži, a napadači će moći brzo
uhvatiti povjerljive podatke drugih sustava.
Korištenje SSL-a za komunikaciju s krajnjim korisnicima je nužno, budući da oni vrlo vjerojatno koriste
nesigurne mreže za pristup aplikacijama. Budući da HTTP uključuje provjeru autorizacijskih podataka
ili sjedničnog tokena u svaki pojedini zahtjev, sav autenticirani promet treba ići preko SSL-a, a ne
samo zahtjev za prijavu na sustav.
Šifriranje komunikacije sa pozadinskim poslužiteljima je također važno. Iako su ove mreže vjerojatno
sigurnije, informacije i podaci za autorizaciju koje one prenose su osjetljiviji i opširniji. Stoga je
upotreba SSL-a na pozadinskom prometu također nužna.
Šifriranje osjetljivih podataka, kao što su podaci o kreditnim karticama i brojevi socijalnog osiguranja,
postalo je dio regulacije privatnosti i financijskih propisa u mnogim organizacijama. Zanemarivanje
korištenja SSL-a za rukovanje vezama kojima se prenose takvi podaci stvara rizik usklađenosti. [17]
10.1. Primjer nedovoljne zaštite na transportnom sloju
Primjer 1:
Stranica jednostavno ne koristiti SSL za sve stranice koje zahtijevaju autentikaciju. Napadač
jednostavno prati mrežni promet (kao na otvorenoj bežičnoj mreži ili susjednoj žičanoj modemskoj
mreži), te prati autentificiran sjednični cookie žrtve. Napadač tada iskorištava taj cookie i preuzima
korisničku sjednicu.
Primjer 2:
Stranica ima nepropisno konfiguriran SSL certifikat koji uzrokuje upozorenja preglednika svojim
korisnicima. Korisnici moraju prihvatiti takva upozorenja i nastaviti, kako bi se mogli koristiti tom
stranicom. Posljedica ovakvih pojava je navikavanje korisnika na takva upozorenja. Kriminalna
prijevara (eng. phishing) usmjerena protiv korisnika ove web stranice mami korisnike na drugu
stranicu koja izgleda kao originalna stranica ali nema valjani certifikat, pa pritom generira slična
upozorenja preglednika. Budući da su korisnici navikli na takva upozorenja, oni nastavljaju koristiti
stranicu koja može poslužiti za krađu identiteta, odavanje lozinki ili drugih privatnih podataka.
Primjer 3:
Stranica jednostavno koristi ODBC/JDBC standard za povezivanje baza podataka, ne shvaćajući da se
sav promet prenosi kao čisti tekst. [18]
10.2. Provjera sigurnosti na transportnom sloju
Cilj je potvrditi da aplikacija ispravno šifrira svu povjerljivu i osjetljivu komunikaciju.
-
Automatizirani pristupi: alati za skeniranje ranjivosti mogu potvrditi da li se SSL koristi pri
komunikaciji s korisnikom, te mogu pronaći mnoge nedostatke vezane za SSL. Međutim, ovi
alati nemaju pristup pozadinskoj komunikaciji i ne mogu potvrditi da li je ona sigurna. Alati za
statičku analizu mogu pomoći pri analizi nekih poziva prema pozadinskim sustavima, ali
vjerojatno neće razumjeti prilagođenu logiku potrebnu za sve vrste sustava.
-
Ručni pristupi: Testiranje može potvrditi da se SSL koristi i pronaći mnoge nedostatke vezane
za SSL pri direktnoj komunikaciji s korisnikom, ali automatizirani pristupi su u tome vjerojatno
učinkovitiji. Pregled kôda je prilično učinkovit za utvrđivanje pravilnog korištenja SSL-a za svu
pozadinsku komunikaciju. [17]
10. 3. Zaštita na transportnom sloju
Najvažnija je zaštita korištenje SSL-a za svu autenticiranu komunikaciju ili pri svakom prijenosu
osjetljivih podataka. Postoji niz detalja koji su važni pri ispravnom konfiguriranju SSL-a za web
aplikaciju, tako da je vrlo važno razumijevanje i analiziranje okoline u kojoj se pokreće aplikacija. Na
primjer, IE 7.0 daje zelenu oznaku za SSL certifikate od visokog povjerenja, ali to nije prikladna
kontrola za dokazivanje sigurnog korištenja kriptografije.
Dobro bi bilo slijediti sljedeće preporuke:
-
Koristiti SSL za svu autentificiranu komunikaciju, te pri prijenosu svih osjetljivih podataka kao
što su autentifikacijski podaci, podaci o kreditnim karticama, zdravlju kao i druge privatne
informacije
-
Osigurati da je komunikacija između infrastrukturnih elemenata, kao na primjer između web
poslužitelja i baze podataka sustava, primjereno zaštićena korištenjem sigurnosti
transportnog sloja ili šifriranja na razini protokola za autentifikacijske podatke i podatke koji
predstavljaju veliku vrijednost za sustav
-
Postaviti zastavicu „secure“ na svim osjetljivim cookiejima
-
Konfigurirati davatelja SSL-a tako da podržava samo snažne algoritme (koji zadovoljavaju FIPS
140-2)
-
Osigurati valjan certifikat, koji nije istekao, nije povučen i odgovara svim domenima
korištenima u aplikaciji
-
Prema četvrtom zahtjevu PCI standarda za podatkovnu sigurnost (PCI DSS), moraju se zaštititi
podaci o karticama pri njihovom prijenosu. Usklađenost s PCI DSS standardom je obavezna za
trgovce i sve ostale koji se bave kreditnim karticama. U principu svaki (klijentski, partnerski,
administrativni) pristup sustavu mora biti šifriran koristeći SSL ili sličnu zaštitu. [17]
11.
Neprovjerena preusmjeravanja i proslijeđivanja
Aplikacije često preusmjeravaju korisnike na druge stranice ili koriste unutarnja prosljeđivanja na
sličan način. Ponekad je ciljna stranica navedena u parametru koji nije valjan čime se napadačima
daje mogućnost odabira odredišne stranice.
Da bi se utvrdilo da li aplikacija ima neka neprovjerena preusmjeravanja ili prosljeđivanja potrebno je
napraviti sljedeće provjere:
1. Pregledati kôd za sva korištenja preusmjeravanja ili prosljeđivanja (u .NET se nazivaju
transferi). Za svaku upotrebu, identificirati je li ciljni URL uključen u bilo koju vrijednost
parametra. Ako je tako, potrebno je provjeriti jesu li parametari valjani tako da sadrže samo
dozvoljeno odredište ili element odredišta.
2. Potrebno je pregledati cijelu stranicu kako bi se vidjelo generira li neka preusmjeravanja
(HTTP kodovi odgovora 300-307, obično 302). Također, pogledati parametre predane prije
preusmjeravanja kako bi vidjeli mogu li oni biti ciljni URL ili dio takvog URL-a. Ako mogu,
treba promijeniti ciljni URL i promatrati je li stranica preusmjerena na novi cilj.
3. Ako kôd nije dostupan, treba provjeriti sve parametre da bi se vidjelo izgledaju li oni kao dio
URL odredišta za preusmjeravanje ili prosljeđivanje i testirati one koji tako izgledaju.
11.1. Primjeri neprovjerenih preusmjeravanja i proslijeđivanja
Primjer 1:
Aplikacija ima stranicu pod nazivom "redirect.jsp" koja uzima samo jedan parametar pod nazivom
"url". Napadač kreira zlonamjerni URL koji preusmjerava korisnike na zlonamjernu stranicu koja
obavlja kriminalnu prijevaru i instalira zlonamjerni kôd.
http://www.example.com/redirect.jsp?url=evil.com
Primjer 2:
Aplikacija koristi prosljeđivanje za usmjeravanje zahtjeva između različitih dijelova stranice. Da bi se
usmjeravanje olakšalo, neke stranice koriste parametar koji označava gdje treba preusmjeriti
korisnika ako transakcija bude uspješna. U ovom slučaju, napadač kreira URL koji će preskočiti
aplikacijsku provjeru prava pristupa te zatim proslijediti napadača na administrativnu funkciju kojoj
inače ne bi bio u mogućnosti pristupiti.
http://www.example.com/boring.jsp?fwd=admin.jsp
11.2. Sprječavanje neprovjerenih preusmjeravanja i proslijeđivanja
Sigurna upotreba preusmjeravanja i prosljeđivanja može biti osigurana na nekoliko načina:
-
Jednostavnim izbjegavanjem korištenja preusmjeravanja i prosljeđivanja.
-
Ako se koriste preusmjeravanja i prosljeđivanja, ne smiju se uključivati korisnički parametri u
izračun odredišta. Ovo se obično može primjeniti.
-
Ako se iz odredišta ne mogu izbaciti korisnički parametri, potrebno je osigurati da je
dobivena vrijednost valjana i ovlaštena za tog korisnika.
Preporuča se da svaki takav odredišni parametar ima neku mapiranu vrijednost umjesto stvarnog
URL-a ili njegovog dijela, te da kôd na strani poslužitelja prevede ovaj mapirani parametar u ciljni
URL.
Aplikacije mogu koristiti ESAPI kako bi nadjačale metodu sendRedirect () čime bi osigurale da su sve
destinacije preusmjeravanja sigurne. Izbjegavanje takvih propusta je izuzetno važno jer oni su
omiljena meta prevaranata koji pokušavaju steći povjerenje korisnika. [19]
12.
Popis literature
1. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
2. https://www.owasp.org/index.php/Top_10_2010-A1
3. http://en.wikipedia.org/wiki/SQL_injection
4. http://en.wikipedia.org/wiki/Cross-site_scripting
5. https://www.owasp.org/index.php/Authentication_Cheat_Sheet
6. https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
7. https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference
8. https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References
9. https://www.owasp.org/index.php/CSRF
10. http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1
11. https://www.owasp.org/index.php/Top_10_2010-A6-Security_Misconfiguration
12. https://www.owasp.org/index.php/A10_2004_Insecure_Configuration_Management
13. https://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storage
14. https://www.owasp.org/index.php/Top_10_2010-A7-Insecure_Cryptographic_Storage
15. https://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Access
16. https://www.owasp.org/index.php/Top_10_2010-A8-Failure_to_Restrict_URL_Access
17. https://www.owasp.org/index.php/Top_10_2007-Insecure_Communications
18. https://www.owasp.org/index.php/Top_10_2010-A9Insufficient_Transport_Layer_Protection
19. https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards

Управни одбор РС РС 7-a сједница 05.07.2011.

2 Krađa Sjednice

GLAVNA SKUPŠTINA društva MLINAR d.d.

Zapisnik s 18 sjednice Upravnog odbora

ispis - Hrvatski sindikat pošte

Sažetak zapisnika s 2. sjednice ZO za biološke opasnosti

zapisnik

izvještaj za web stranicu 01.01.-02.06

zapisnik - Splitski savez športova

Zapisnik s 12 sjednice Upravnog odbora