You are on page 1of 14
(Izvor: Jovan Popovié — Testiranje softvera u praksi) Testiranje sigurnosti obzirom da se danas softver pravi za sisteme u Kojima se radi sa bitnim privatnim i finansijskim podacima, postoji sve veéa potreba da se proveri da li je sistem dovoljno siguran i otporan na napade. Pored toga, imajuci u vidu da je danas wobigajeni trend napad na sve sisteme bilo preko virusa, trojanaca ili direktnih napada, svaki sistem mora imati neku zastitu, Zbog toga je bitno izvrSiti i testiranje sigumosti sistema uporedo sa ostalim testovima. Dizajn sigurnosti Zahtevi 0 sigumosti sistema se obiéno samo delimino definisu od strane klijenata tako dla je u vecini sluéajeva odgovornost projektnog tima da definise sigumosna pravila. Sigunosna pravila su uglavnom tehni¢ka pravila kojima se definise gde i kako treba primenjivati sigurmosne mere. Pravila zavise od konkretnog slugaja ali neka od pravila mogu biti: 1. Definisanje privatnih podataka — potrebno je definisati koji podaci su privatni i na koji nagin se Stite, Privatni podaci su korisniéka imena, sifte, kontakt podaci(adrese, email, telefoni), brojevi bankovnih raéuna i sligno, Ako se ove informacije stalno drée u nekom. skladistu podataka u sistemu, one ne mogu biti unete u izvornom obliku, nego se moraju Sifrovati pri upisu i desifrovati pri gitanju. 2. Definisanje protokola sigumnosti —potrebno je definisati metode kojima se privatni pod: Stite. Metode predstavijaju vrste sifrovanja koje ée se koristiti u sistemu (DE: TripleDES, AES, RSA, PGP) kao i u kojim sluéajevima ée se koris skladistenja privatnih podataka, prilikom razmene poruka kao sto su email, prilikom autentifikacije i sligno). Definisanje uloga i prava pristupa, éime se definige ko ée sve koristiti sistem i sa kojim pravima, Ovi zahtevi se uglavnom definiSu od strane klijenata posto moraju da budu u skladu sa njihovim poslovnim pravilima. U sluéaju da sistem koristi vise uloga (administrator, menadzer, operator), potrebno je proveriti da neki korisnik sa. nizim 1a ne moze nekako da koristi i funkcionalnosti koje su namenjene korisnicima sa vvigim pravima, 4, Definisanje prava pristupa i privatno: nika sa istim ulogama koji mogu da koriste ali ne smeju da vide podatke drugih korisnika sa istim pravima. banke koji pristupaju sistemu i proveravaju stanje racuna, ali ne smeju da vide stanja raguna drugih klijenata. Kao Sto su zahtevi i specifikacija osnova za definisanje test sluéaja za funkeionalno testiranje, tako je dizajn sigumosti osnova za definisanje test slufajeva za testiranje sigumost. Testiranje upada u sistem Testiranja upada predstavlja skup testova kojima se pokuSava upasti u sistem, pod pretpostavkom da napadat iniijalno nema informacije kako se moze ui. U slutaju da napadat neku funkeionalnost ili otvori neku stranu koja nije javno dostupna, ili ako sa nizom ulogom moze da uradi nesto sto je dozvoljeno samo korisnicima sa je uspeo. U praksi se vrse sledeca testiranja upada: 1. Probijanje korisni¢kih imena i lozinki — kori8éenjem nekog protokola za pristup sistemu (forme za prijavijivanje, FTP konekcije, povezivania na email server) i slanjem parova sluéajnih vrednosti za korisni¢ko ime i lozinku pokuSava se pronaéi par koji omoguéava ulaz u sistem, am Verovali ili ne, danas postoji veliki broj aplikacija koje imaju jednostavna korisni¢ka im ulogama, upad nena i lozinke kao Sto su admin/admin, admin/root, tesVtest. Za neke od nijih vlasnici nisu ni svesni da ti parovi omoguéavaju upad u sistem posto koriste druga korisnicka ena i lozinke tokom rada. 2. Otvaranje strana bez. dozvole — otvaranje slutaj trebalo da dozvoljavaju javni pristup svima. Desifrovanje informacija — pokusaji da se siftovane informacije desifruju kako bis pronagao ili originalni sadréaj, kljué Koji je kori8éen za Sifrovanie ili algoritam koji se Koristi prilikom Sifrovanja (u sluéaju da nije javan). Kada se jednom otkrije kliué (i eventualno algoritam Sifrovanja ako nije javan), sve poruke se mogu desifrovati 4. Testiranje prava pristupa — kojim se proverava da li regulami korisnici kojima su data prava pristupa mogu da pristupe informacijama koje ne bi smeli da vide. 5. Testiranje kvaliteta sigumosti — kojim se testira jagina primenjenih mera sigumnosti kao Sto su duzina kljuéeva u algoritmima za sifrovanje, jagina Sifara koje se dozvoljavaju korisnicima i sligno. 6. Unos nedozvoljenih informacija — u internet aplikacijama je éest pokuSaj unosa podataka Koji bi prikupili_neke podatke o sistemu ili oborili ceo sistem. Ovi napadi se vrse unoSenjem malicioznog HTML/JavaSkripta (eng. Cross-site scripting) ili SQL. komandi (eng. SQL injection). Ovakvi napadi su detaljnije opisani u poglaviju 4. h strana internet aplikacije koje ne bi $ obzirom da se internet aplikacije najvi’e napadaju usled éinjenice da su celog sveta, najvie paznje se posvesuje testiranju ovih aplikacija. Trenutno postoji veliki broj alata za testiranje upada na internet sajtove i aplikacije. Oni rade po prineipu hvatanja zahteva Koji Salje pregledaé ka serveru uz pruzanje moguénosti korisniku da promeni neke vrednosti Kao primer alata za testiranje upada ovde je prikazan TamperData dodatak za FireFox pregledat. Seo Slika 3.4. Testiranje sigurnosti pomocu TamperData alata ‘TamperData dodatak presreée zahteve koje tester Salje stvarnim aplikactjama i pokazuje © poslatom zahtevu kao Sto je prikazano na slici 3.4, Korisnik (tester) moze da promeni vrednosti parametara koji se Salju serveru i ispita da li postoji neka vrednost preko koje moze upasti. Pored jednostavne promene vrednosti, ovaj dodatak nudi i nekoliko predefinisanih vrednosti koje se mogu poslati serveru i koje predstavljaju neke Ge8ée kljugne resi k moze izvrsiti upad na sajtove. Primer iz prakse Posmatra se internet aplikacija koja omoguéava agencijama da postave oglase za p koje nude i da sami: menjaju podatke o tim poslovima (ponudena plata, uslovi rada i . Zaposleni u agenciji moze da se prijavi u aplikaciju, vidi svoje poslove i otvori detalie 0 postovima, Kada oor detae 0 nekom od svojh poslove otvara se sania u ij parametru identifikator posla koji se otvara na pri vidi identifikator posta sa kojim se radi je 73. Postovi koje agencija menja pripadaju toj agenciji i druge agencije ne bi smele da vide niti da menjaju njene poslove, kao sto agencije. Ovo normalnim radom sa apli mm nije ni moguée, posto se u pretragama prikazuju samo poslovi koji pripadaju trenutnoj agenciji. Trenutni korisnik ne moze da otvori detalje tudih poslova posto mu se nikada neée ni prikazati. Medutim, korisnik moze direktno u pregledaéu da promeni identifikator posla i umesto jobid=73 ruéno upise jobid=74 sime bi dobio neki drugi posao koji verovatno pripada drugoj ageneiji. Tokom testiranja je primeéeno da je napravljen propust i da, kada se otvori posao po identifikatoru, ne proverava se da li taj posao stvamo pripada trenutno} agenciji &ime se naruSava privatnost podataka, jje implementirana provera prava ivaraju po identifikatoru, Sift ili broju, a podaci Koji se prikazuju nisu javni nego su vezani za trenutnog korisnika, pottebno je napraviti jedan test sluéaj po strani kojim se pokuSava pristup promenom parametra, kako bi se testirala provera prava pristupa, Primeri ovakvih podataka mogu biti proizvodi i usluge koji pripadaju Kompanijama, pacijenti lekara, slutajevi koje rade advokati, bankovni raéuni koji pripadaju intima i sligno. U ovakvim sluéajevima, uvek kada se prikazuje privatni podatak, potrebno je proveriti da li mu neki drugi korisnik moze neovlaséeno pristupiti ‘Testiranje privatnosti podataka je vazno posto kraj koriste sistem ili da tuze projektni tim ili organizaciju kojoj pripada sistem. Kao primer, ako bi Klijenti banke koji pristupaju svojim bankovnim raéunima preko interneta shvatili da mogu da upadnu u tad racun samom promenom broja u parametru, sigumo bi tuzili banku i ugasili racune u njoj zauvek. Korisnici mogu prestati da Veliki problem u sigumosti internet aplikacija je moguénost otvaranja strana direktnim unosom URL-a strane u pregledacu. Ovaj propust se uglavnom deSava zato Sto programeri zaborave na neuobigajene tokove koriséenja, Tokom rada, svako ée se prvo prijaviti na sistem, pa onda otvoriti odredenu stranu, Malo ko ée se setiti da pokusa da direktno otvori stranu bez, prijavijivanja. Ovo je posebno opasno u aplikacijama u kojima kod sa klijentske strane direktno poziva serversku stranu (na primer u slutaju Ajax poziva), gde se na da samo programski kod vr8i ovakve pozive, U tom slucaju se malo ko seti da pokusa da ovakve servise pozove direktno. Testiranje sigurnosti ‘Tokom testiranja sigumosti, sistem se posmatra kao crna kutija kojoj Korisnik moze ako zna korisniéko ime i Sifru ili bilo koju drugu informaciju kojom se moze jem, Kada jednom ude u sistem, korisnik moze vrsi odredene akcije u skladu i tako pristupa odredenim delovima sistema (stranama, podacima, i lie zahtev ka sistemu i dobija odgovor, ako za to ima prava, Pri tome, sistem gledamo kao crnu kutiju koja na osnovu zahteva odlucuje da i ée vratiti odgovor korisniku ili ne. ‘Tokom testiranja sigurnosti u sistemu se proverava da li su podaci sigurni, da li kori mogu da pristupe delovima sistema u skladu sa svojim pravima i da li Korisnik moze da izv napad na aplikaciju. pristupi identifikovati u Provera sigurnosti podataka Veéina softverskih sistema sadrze neke poverljive podatke kao sto su korisnitka imena i lozinke, brojevi kreditnih kartica, stanja na raéunu i sliéno. Ovi podaci su nekada Sifrovani posebnim Siframa i tako stalno uskladisteni u bazi podataka, a nekada samo maskirani u poljima za unos gde korisnik unosi lozinku koja se ne moze videti, ali se u tekstualnom formatu Salje sistem, Cilj testiranja sigumosti podataka je pokuSaj da se na neki natin otkriju stvame vrednosti privatnih podataka, Ovi pokuSaju mogu biti pogadanje sifara kori8éenih. prilikom podataka, pogadanje kombinacija korisni¢kih imena i lozinki, i slitno. Provera sigumosti se, po pravilu, visi automatski, kori8éenjem nekog alata za analizu podataka koji primenjuje nel algoritam ili grubu silu pri pogadanju. Alati koji koriste grubu silu generiSu sve moguée kombinacije korisnigkih imena i lozinki dok ne pronadu pravu kombinaciju. Malo bolji alati Koriste heuristi¢ke ulaze kako bi ubrzali proces pogadanja. Pored toga, ovi alati mogu da generi8u i Sifre Kojima pokuSavaju da deSifruju podatke po poznatim algoritmima kako bi pronasli onu koja radi. Drugi primer su analizatori Sifrovanog teksta koji porede tekst sa njegovim kriptogramom i primenjuju algoritme sifrovanja kako bi pronasli koji kljué se koristi. Postoje i alati Koji Salju sekvence podataka sistemu koji vraéa odgovor sa porukom da li je Sifrovanie uspelo ili ne kako bi pronasli prave algoritme i kljuéeve. Druga grupa alata su alati za nadgledanje protokola komunikacije u mrezi (eng. Network Sniffers) kojima se nadgleda komunikacija izmedu korisnika i sistema. Primer ovakvog nadgledanja je nadgledanje komunikacije izmedu internet pregledaa koji koriste korisnici i servera interet aplikacija u cilju otkrivanja vrednosti koje se razmenjuju. Sve alate iz ovih grupa je potrebno primeniti nad aplikacijama kako bi se ispitalo ima li nekih nagina da napadaé otkrije Korisniéke podatke. ‘Test sluéajevi su jednostavni iskazi na pi Fiddler proveriti da li se informacije o kredi ne“, i alat za pracenje HTTP protoka im karticama Salju u Sifrovanom obliku ili Prilikom testiranja sigumosti potrebno je izvrSiti pregled zahteva za zastitu podataka kojima se definige da li se Sifriraju kritiéni podaci u bazi podataka, da li se Sifriraju podaci koji se Salju izmedu aplikacija (na primer, da li internet pregledaé i server komuniciraju_preko zastigenog HTTPS protokola, da li se e-mailovi razmenjuju sa PGP sistemom zastite i sliéno), i koja je jagina primenjenih algoritama za Sifriranje (tip algoritama, duzina kljuéeva i sligno). Provera preuzimanja identiteta Cak i ako su podaci korisnika sigumi ostaje problem sigumosti i krade identiteta. moze da se prijavi u aplikaciju ali se informacija o njegovom identitetu stalno Salje sistemu zajedno sa ostalim podacima. Na primer, kada se u internet aplikacijama korisnik prija u sistem, informacije o njegovom identitetu se svaki put Salju aplikaciji u kolagigu (eng. Cookie) zajedno sa ostalim informacijama koje korisnik Salje. Aplikacija na osnovu informacija u kolaéicu prepoznaje korisnika i omoguéava mu da izvrsi akciju, Cak i ako se ne koriste kol: w internet aplikacijama, u svim ostalim vidovima autentifikacije Salje se neka informacija o korisnikovom identitetu. Problem u ovoj identifikaciji Korisnika je u Cinjenici da, ako neko uspe da kopira kolatié ili protitainformacie iz njega, ima moguénost da ga staviu svoj internet regledad ju svakom zahtevu koji je poslat internet aplikaciji biée autentifikovan kao i originalni korisnik iako se uuopite nije prijavio na sistem. S obzirom da je kolagié koji se Salje jedini vid provere, aplikacija nema razloga da misli da to nije validan korisnik Primer U mnogim modernim pregledagima korisnici mogu u vi8e tabova da otvaraju razli sajtove, Na primer, u jednom tabu mogu da otvore sajt svoje banke gde su se prijavili, a u drugi tabovima mogu da imaju otvorene druge sajtove kao Sto je prikazano na slici 4.6. form action="hitpZiww bark comiTransterMoney aspx”> “ ‘omm> Ovo je deo JavaSkript koda koji izvrSavaju internet pregledadi kada naidu na njega i koji trenutnu lokaciju u pregledaéu postavlja na sajt htip/iwww.site,com umesto lokacije koju je korisnik Zeleo da otvori. U konkretnom sluéaju ovaj skript bi bio izvrsen na stranama sajta koje tvaraju posetioci foruma, i svaki put kada je strana otvorena internet pregledaé bi izvrSavao ovaj kod i prebacivao bi ih na drugi sajt. Cesto se razvojni tim osigurava od skript upada tako Sto u tekstu koji unosi korisnik proverava da li postoji reé seript. Ako takva reé postoji onda je to znak da neko pokuSava XSS upad. Medutim postoje dosta napredniji napadi Koji su_potpuno neoéekivani. Na primer napadaé moze da unese sliku koja se ,uitava" sa lokacije na kojoj je neki JavaScript. Primer takvog HTML koda bi bio . Pregledaé u ovom. sluéaju uditava JavaScript fajl i moze da ga izvrsi umesto da ga prikaze (ovo zavisi od pregledaéa do pregledata). Cak nije dovoljno proveriti da li postoji .js ekstenzija posto napadaé moze da preimenuje svoj JavaScript fajl u skriptpng i da mu postavi MIME tip na tekst/javascript. Pregledaé Ge ucitati fajl ne znajuci da li je to skript ili prava slika, a posto je tip tekst/javaskript, od pregledaéa do pregledaéa zavisi da li ée ga shvatiti kao skript fajl ili kao sliku, Pored toga postoje razligiti nagini da se ubaci opasan skript u sre atribut slike, Na primer neko moze u atribut staviti direktan JavaScript kod Koji ée biti izvrgen kad pregledaé krene da uéitava ,sliku*. Druga moguénost je da napadaé u sre atribut stavi link ka nekoj strani na serveru na primer DeleteProduct.php?id=17 (pod uslovom da zna kako se zove strana i koji parametar prima). U vom slugaju ée korisnik obrisati proizvod dim otvori stranu posto ée pregledaé pokusati da sliku sa lokacije za brisanje proizvoda. Tag za slike nije jedini koji je potencijalna preinja posto jo3 neki tagovi kao Sto su