Blog Instituta za Matematiku i Informatiku

Studenti informatike PMF-a u Kragujevcu pišu o aktuelnim IT temama

Bezbednost Programiranje 

OWASP Top 10 – Bezbednost na Internetu

Aleksandar Vujinovic 0 Komentara

Internet je postao deo naše svakodnevnice, što je neminovno dovelo do prilagođavanja naših svakodnevnih aktivnosti novim okolnostima. Elektronska trgovina, novčane transakcije, komunikacija sa prijateljima i poslovnim partnerima, je na samo par klikova mišem, ili dodira prstom. Sve ove aktivnosti pokreću još jednu ozbiljnu temu – Bezbednost na internetu. Mogućnost da se, uz samo nekoliko linija koda, otuđi velika suma novca sa nečijeg bankovnog računa, ili dođe u posed vrednih i poverljivih informacija, navela je hakere da razviju mnoštvo zlonamernih alata i strategija. Brojne zajednice i kompanije ulažu podjednake napore da se poveća bezbednost veb aplikacija i sajtova. Najveće pretnje koje vrebaju na Internetu, kao i jedna od organizacija koje se bore protiv njih, će biti predstavljene u narednim redovima. OWASP (The Open Web Application Security Project) je projekat bezbednosti veb aplikacija otvorenog koda. Ova zajednica obuhvata korporacije, obrazovne ustanove i pojedince iz celog sveta. OWASP fondacija je registrovana kao neprofitna organizacija i nije povezana ni sa jednom tehnološkom organizacijom. Misija ove organizacije je da pruži pomoć i obuku programerima i kompanijama u cilju unapređenja bezbednosti.

OWASP Top 10

Najznačajniji projekat ove organizacije je OWASP top 10, lista deset najvećih bezbednosnih pretnji na Internetu i taj spisak se stalno ažurira. Zbog posvećenosti, ažurnosti, i velikog broja članova, poput velikih korporacija i obrazovnih ustanova koje uređuju ovu listu, OWASP top 10 je uvršćen u bezbednosne standarde današnjice. Neke od institucija koje ga koriste su Center for Internet Security (CIS) USA, Defense Information Systems Agency (DISA) USA, Centre for the Protection of National Infrastructure (CPNI) UK, Cloud Security Aliance (CSA) Worldwide, European Union Regulations EU, European Network and Information Security Agency (ENISA), National Institute of Standards and Technology (NIST) USA, National Security Agency USA, i mnoge druge. U nastavku je opisana svaka od tih pretnji.

1. Injection (umetanje)

Napadi umetanjem se javljaju kada se nevalidirani podaci uneti od strane korisnika direktno ugrađuju u kod programa. Najpoznatija tehnika je SQL injection. Napad se vrši tako što se u formu za unos podataka umeću delovi SQL komandi, čiji je cilj da izvuče podatke iz baze, ili da izmeni sadržaj baze. Zbog neiskustva ili žurbe, programeri često prave sitne greške prilikom projektovanja sistema, i komunikacije istog sa bazom. Primer. Aplikacija koristi nevalidirane podatke koje joj šalje korisnik, i direktno ih umeće u SQL kod. Primer nepouzdanog SQL upita:

String query = “SELECT * FROM accounts WHERE username=’” + request.getParameter(“username”)+”’ and password=’” + request.getParameter(“password”) + “’”;

Korisnik može, umesto korisničkog imena, poslati sledeći string: “user’ or ‘1’=’1”. Ovaj upit će uvek vratiti true, tj. čitav sadržaj tabele Accounts će potencijalno biti poslat napadaču. Da bi se preventivno zaštitili od ovakve vrste napada, poželjno je koristiti “bele” i “crne” liste, tj. liste dozvoljenih i nedozvoljenih karaktera koje prihvatamo od korisnika. Još popularniji pristup je korišćenje bezbednih API koji sadrže parametrizovane interfejse. Ovi interfejsi obrađuju i proveravaju podatke unete od strane korisnika, pre njihovog umetanja u SQL upite. Ovaj pristup je danas najzastupljenijiu prevenciji od ove vrste napada. Primer za ovakav API je Hibernate u okviru Java platforme.

2. Kompromitovana autentifikacija i rad sa sesijom

Podaci o korisniku mogu biti kompromitovani na više načina. Najčešći način je nepravilno čuvanje osetljivih podataka u bazi. Lozinke nikad ne bi trebalo čuvati u originalnom obliku, već koristiti neki oblik heširanja. Ukoliko je sadržaj baze na bilo koji način dostupan napadaču, on može doći u posed osetljivih podataka svih korisnika. Čak i prilikom heširanja, lozinke nisu potpuno bezbedne. Ukoliko se od korisnika ne zahteva da osmisli iole složeniju lozinku, kao kombinaciju velikih i malih slova, i nekih specijalnih karaktera, već za istu odabere neke opšte, često korišćene reči, napadač može uz pomoć duginih tabela (rainbow tables), tj. skupa unapred heširanih opštih lozinki, da prepozna korisnikovu lozinku. Na Internetu su dostupne javne baze sa više milijardi potencijalnih heširanih lozinki, i velika je verovatnoća da je i vaša slaba lozinka među njima, što puno olakšava posao napadaču. Potencijalni propusti u radu sa sesijama:

  • Ukoliko je održavanje naloga loše implementirano u aplikaciji, napadač može pomoću opcija promene lozinke, zaboravljene lozinke, ili slabih identifikatora sesije, da ugrozi regularnog korisnika.
  • Tokeni sesije se šalju ugrađeni u URL zahtev. Tako su izloženi i dostupni napadaču u istoriji Internet pregledača.
  • Tokeni sesije nemaju ograničen rok trajanja. Ukoliko na javnim računarima korisnik zaboravi da se odjavi sa sistema, sledeći korisnik može zloupotrebiti njegovu sesiju.
  • Tokeni sesije se ne rekreiraju prilikom svake nove prijave na sistem. Tako napadač može koristiti prethodno ukradeni token, kada ga korisnik ponovo obnovi.

3. Cross-Site scripting (XSS)

XSS napadi najčešće pogađaju korisnike aplikacije, a ne samu aplikaciju. Do njih dolazi kad veb aplikacije prihvataju podatke od korisnika i dinamički ih uključuju u veb stranice bez prethodne validacije podataka. Oni omogućavaju napadaču da izvršava proizvoljne komande u Internet pregledaču korisnika. Potencijal ovog napada leži u činjenici da se zlonamerni kod izvršava u sklopu sesije korisnika, omogućavajući napadaču da zaobiđe normalna bezbednosna ograničenja. Postoji više metoda odbrane od ove vrste napada, a neke od njih su korišćenje Content Security Policy (CSP), X-XSS bezbednosnih zaglavlja, i belih listi.

4. Neautorizovan pristup zaštićenim resursima

Aplikacije često ne proveravaju da li je korisnik autorizovan za pristup određenom resursu. Često je, iako pogrešno, dovoljno da korisnik bude uspešno prijavljen na sistem, da bi mu svi delovi sistema bili dostupni. Napadač (autentifikovani korisnik sistema) može samo promeniti URL vrednost parametra koji se odnosi na neki deo aplikacije (admin sekciju na primer), za koje kao običan korisnik ne bi smeo da ima pristup. Da bi se zaštitili od ovoga, trebalo bi proveravati prava pristupa za svaki zatraženi resurs.

Scenario lošeg pristupa obezbeđivanju objekata: Aplikacija koristi nevalidirane podatke u generisanju SQL upita:

String query = “select * from accounts where accountId = ?”;
PreparedStatement preparedStatement = connection.prepareStatement(query);
preparedStatement.setString(1, request.getParameter(“acctId”));
ResultSet results = preparedStatement.executeQuery();

Napadač modifikuje parametar acctId u zahtevu: http://www.example.com/app/accountInfo?acctId=notmyacct

Na ovaj način napadač može pristupiti informacijama bilo kog korisnika.

5. Security Misconfiguration

Prilikom kreiranja i testiranja sistema, programeri i sistemski admini često ostave sigurnosne rupe u konfiguraciji – back doors. Ukoliko kasnije zaborave da to otklone, napadači uh mogu zloupotrebiti. Takođe, redovno treba ažurirati softver, jer starije verzije mogu sadržati sistemske propuste. Probne korisničke naloge nakon razvoja softvera treba brisati, jer mogu biti iskorišćeni za neovlašćen pristup aplikaciji.

6. Način čuvanja i prenosa osetljivih podataka

Zaštita osetljivih podataka, poput lozinki, brojeva kreditnih kartica isl. korišćenjem kriptografije je postala ključni element velikog broja veb aplikacija. Ne postoji softverski okvir za kreiranje veb aplikacija koji je otporan na korišćenje nesigurnog kriptografskog skladišta. Prilikom trasporta osetljivih podataka, koriste se mnogi kriptografski algoritmi koji, u slučaju da su podaci kompromitovani, otežavaju napadaču da ih zloupotrebi. Najpoznatiji algoritmi su RSA (koristi strategiju javnih i privatnih ključeva) i AES, koji prihvaćen kao standard i zvanično je u upotrebi vlade SAD, kao trenutno najpouzdaniji. Podatke poput lozinki ne bi trebalo čuvati u osnovnom obliku u bazi. Pošto služe samo za autentifikaciju korisnika, mnogo je sigurnije koristiti značajno pouzdanije heš algoritme, koji od podataka prave kreiraju besmislenih znakova, koji se ne mogu vratiti u prvobitni oblik.

7. Nedostatak kontrole nivoa pristupa

Aplikacije bi trebalo da imaju module za proveru autorizacije nezavisno od biznis logike. Velika greška prilikom konstruisanja sistema je nedostatak provere prava pristupa korisnika koji je poznat sistemu. Primer napada: Napadač je korisnik koji je poznat aplikaciji, ulogovan je, ali nema admin privilegije. Primer njegovog validnog zahteva aplikaciji je: https://example.com/app/userMenu. Međutim, ukoliko autorizacija nije dobro dizajnirana, njegov sledeći zahtev, http://example.com/app/adminMenu, sistem može prepoznati kao validan, što se nikako ne bi smelo desiti. Da bi se od ovoga zaštitili, potrebno je svaki zahtev ka zaštićenom resursu proveriti, tj. da li korisnik koji je uputio zahtev ima potrebne dozvole.

8. Cross-Site Request Forgery (CSRF)

CSRF je napad koji za cilj ima izmenu stanja nekog servera gde je žrtva autentifikovana kao legitiman korisnik, bez njihovog znanja. Napad se obično izvršava ugrađivanjem zlonamernog koda u HTML kod neke stranice i nenamernom akcijom korisnika koji ga aktivira. Ovakav napad nema za cilj otkrivanje nekih podataka napadaču, jer on nema uvid u odgovor, već samo promenu nekog stanja na serveru u njegovu korist.
Primer ovakvog napada u praktičnoj primeni je transfer novca sa računa korisnika na račun napadača bez znanja korisnika. Primer za to je veb aplikacija za onlajn bankarstvo koja prima parametre za transfer novca na sledeći način: http://ranjiva.banka.com/transfer.do?account=Napadac&amount=1000 Zahtev kreiran na ovaj način će sa računa korisnika izvršiti transfer na račun napadača u vrednosti od 1000 jedinica neke monete. Sve što napadač sada treba da uradi je da navede nekog korisnika ove banke da klikne na ovaj link. Za uspešno izvršavanje napada potrebno je da korisnik u tom trenutku ima aktivnu sesiju na sajtu banke. Jedan od efikasnih načina je da napadač ugradi ovaj URL u samu aplikaciju (stored CSRF) i bude siguran da će korisnik koji pristupa sadržaju već imati aktivnu sesiju. Neki od načina da se URL ugradi u kod neke stranice su postavljanje slika dimenzije 0x0 gde je source link za napad ili postavljanje linka čiji tekst upućuje na nešto drugo.

<'img src="http://ranjiva.banka.com/transfer.do?account=Napadac&amount=1000" width="0" height="0" border="0" />
<'a href="http://ranjiva.banka.com/transfer.do?account=Napadac&amount=1000">Nove slike!<'/a>

Zaštita od ove vrste napada postiže se korišćenjem csrf tokena za validaciju, koji je smešten kod korisnika i koji se dodaje na kraj forme za transfer. Taj token se generiše prilikom korisnikove prijave na sistem i validan je dok je aktivna sesija. Napadač ne zna njegov sadržaj, te stoga ne može da ga unapred ugradi u zlonamerni link.

9. Korišćenje komponenti sa poznatim slabim tačkama

Danas je retkost da se pri razvoju bilo kog softvera oslonimo isključivo na sopstveni kod. Najčešće se koriste poznate biblioteke, moduli, ili softveri koji su javni, besplatni ili se kupuju. Nijedan od njih nije savršen, tako da je moguće da sadrži određene sistemske propuste, koje napadač može iskoristiti. Te greške se najčešće ispravljaju u nekim narednim verzijama, pa je jedno od rešenja da uvek imamo najsvežiju verziju softvera koji koristimo. Ipak, ni to nije garancija, jer sa novim izmenama, rizikujemo da ugradimo neke nove propuste, koji su potencijalno gori od starih. Stoga se mora biti pažljiv. Postoje mnogi sajtovi koji su specijalizovani za otkrivanje takvih propusta, i na kojima mnogi korisnici razmenjuju iskustva i saznanja o propustima do kojih su došli. Pored takvog vida provera, preporučljivo je da postoje testovi u aplikacijama koji proveravaju ključne tačke i otkrivaju potencijalne propuste, pa shodno tome i alarmiraju administratore.

10. Nevalidirane redirekcije i prosleđivanja (Phishing)

Najveći broj korisnika Interneta ne obraća pažnju na tekst Internet adresa koje posećuje. Tu manu korisnika, ali i manu velikog broja aplikacija da u adrese za redirekciju ugrađuje neproverene unose korisnika, napadači koriste da bi ukrali identitet regularnih korisnika. Umesto adrese regularnog sajta, najčešće je to link ka zlonamernom sajtu koji izgledom jako podseća na originalni sajt. Korisnik unosi podatke za identifikaciju, i tako napadač lako dolazi u posed korisnikovog identiteta. Primer ovakvog napada su mejlovi koji stižu regularnom korisniku od naizgled njegove banke. U njima se traži da promeni lozinku, potvrdi prenos određenih sredstava, ili neku sličnu aktivnost. U prilogu je i link ka sajtu te banke, koja zapravo vodi korisnika do napadačevog sajta, identičnom sajtu banke tako da korisnik ne primećuje razliku. Primer linka je sledeći:

https://example.bank.com/redirect.php?redirecturl=evil-site.com

Prevencije za odbranu od ovakve vrste napada su mnogobrojne. Moguće je jednostavno izbegavati redirekcije, ili ne koristiti neproverene adrese unete od strane korisnika. Ukoliko se moraju koristiti, pre redirekcije upozoriti korisnika, i sačekati njegov pristanak za takvu akciju.

Korisni linkovi

Autor: Aleksandar Vujinovic