3.5.2   Otmica sesije (Session Hijacking)

(izvor: Diplomski rad Miloša Miloševića, VETŠ Beograd 2008/09)

Najčešći oblik napada sesijom je otmica sesije. Otmica sesije se odnosi na bilo koji metod kojim se napadač koristi kako bi neovlašćeno pristupio nečijoj sesiji. Prvi korak napadača je da dođe do validnog identifikatora sesije i stoga je zaštita identifikator sesije jako bitna. Kao i kod fiksacije sesija ukoliko se sistem sesija sastoji samo od naredbe session_start() skripta moguć je napad iako napad otmicom sesije nije jednostavan. Identifikator sesije gotovo nije moguće sačuvati od hvatanja ali je moguće otežati samo hvatanje identifikatora. Da bi se aplikacija odbranila od otmice sesije potrebno je iskoristiti još nešto iz HTTP zahteva za identifikaciju. Tipični HTTP zahtev glasi:
GET / HTTP/1.1
Host: example.org
User-Agent: Mozilla/5.0 Gecko
Accept: text/xml, image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234
Potencijalnom napadaču treba otežati imitiranje, a da se pri tome ne ometaju legitimni korisnici. Samo je Host neophodan deo zaglavlja i ništa drugo ne izgleda kao da bi moglo da se iskoristi. Ali ukoliko se podnese drugačiji zahtev sa promenjenim User-Agent zaglavljem:
GET / HTTP/1.1
Host: example.org
User-Agent: Mozilla Compatible (MSIE)
Accept: text/xml, image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234
Iako je Cookie prisutan ovo ne može biti validan korisnik. Validan korisnik ne bi menjao User-Agent zaglavlje između zahteva. Može se izvršiti dodatna provera:

Odbrana ali ne i potpuna zaštita od otmice sesije

Napadač mora prezentovati i pored ispravnog identifikatora sesije i User-Agent zaglavlje koje nije povezano sa sesijom. Ovo dodatno komplikuje stvari i samim time aplikacija je sigurnija.

Bez ključnih reči

3.5 NAPAD NA SESIJE

3.5.1 Fiksacija sesija (Session Fixation)

(izvor: Diplomski rad Miloša Miloševića, VETŠ Beograd 2008/09)
Sesije su česta meta napada, većina napada preko sesija predstavljaju ononašanje korisnika čiju sesiju napadač želi da preuzme. Najznačajnija informacija za napadača je identifikator sesije jer je neophodan da bi napad uopšte bio moguć. Postoje tri načina pribavljanja identifikatora sesije: predviđanje, zaplena i fiksacija.

Predviđanje se oslanja na pogađanje identifikatora sesije, PHP ima mehanizam koji nasumično generiše identifikator pa je ovaj način napada gotovo nemoguć.

Najčešći tip napada preko sesija su zaplenom identifikatora. Identifikatori sesija se tipično prenose putem cookie-ja ili GET promenljive. Cookie su znatno manje eksponirani nego GET promenljive. Za korisnike koji uključe podršku za cookie oni obezbeđuju sigurniji način prenosa identifikatora sesije. Fiksacija predstavlja najjednostavniji način pribavljanja ispravnog identifikatora sesije. Iako se nije teško odbraniti ukoliko se sistem sesija sastoji samo od naredbe session_start() ta skripta je ranjiva.

Da bi se prikazala fiksacija sesije prvo treba obrisati tragove cookie-ja, onda stranu treba posetiti sa ?PHPSESSID=1234 pridruženim URL-u. Zatim se isti URL ponovo sa pridruženim ?PHPSESSID=1234 može posetiti sa drugog pretraživača ili čak drugog kompjutera, ono što je rezultat je nastavak rada sesije kao da se korisnik nije nikada odjavio. Većina napada fiksacijom sesija koriste  link ili preusmeravanje na nivou protokola da pošalju korisnika na udaljeni sajt sa identifikatorom sesija pridruženim URL-u. Korisnik neće ništa primetiti sa obzirom na to da će se aplikacija ponašati uvek isto. Izbor identifikatora sesije od strane napadača može biti iskorišćeno za napad oponašanjem poput otmicom sesije. Odbrana od ove vrste napada sastoji se u tome da se identifikator sesije obnavlja.

Fiksacija sesije - Odbrana obnavljanjem identifikatora sesije

Ako se ovaj postupak primenjuje kada god se izmeni nivo privilegija praktično se eliminiše rizik od napada fiksacijom sesije.

Obnova identifikatora sesije pri promeni privilegija korisnika

Izmena identifikatora sesije se ne preporučuje na svakoj strani web aplikacije.

Bez ključnih reči

3.4.2    Ubacivanje SQL koda (SQL Injection)

(izvor: Diplomski rad Miloša Miloševića, VETŠ Beograd 2008/09)

Ubacivanje SQL koda je jedna od najčešćih slabosti u PHP aplikacijama. Da bi neka aplikacija mogla da ima ovu vrstu propusta developer zapravo mora napraviti dve greške pri pravljenju aplikacije:

-   Propust pri filtriranju ulaznih podataka u aplikaciju

-   Propust da se uradi “escape” ulaznih podataka pre nego što se pošalju bazi podataka

Nijedan od ovih koraka ne treba zaobići i oba koraka mogu značajno da umanje rizik od napada. Napadači moraju da imaju neko znanje o bazama podataka, da poznaju SQL jezik i da pogode šemu baze podataka, imena tabela i atributa tabela ili da imaju izvorni kod aplikacije kako bi mogli da izvrše napad.

Primer napada

Kada napadač prvi put vidi formu on mora da pogodi kakav tip upita stoji iza forme koji vrši validaciju podataka. Pošto pogleda HTML izvorni kod napadač može da pogodi koje konvencije se držao programer pri pravljenju aplikacije. Obično je konvencija imenovanja atributa u formama ista kao i atributi koji stoje u tabelama baze podataka.

Primer zaštite od ubacivanja SQL koda

Napadaču nije neophodno da iz prvog puta pogodi šemu baze podataka. Mnogi developeri koriste funkciju mysql_error() koja vraća tekst greške tokom izvršavanja upita.

Prikaz greške pri izvršavanju SQL upita u PHP jeziku

Ukoliko napadač unese znak ‘ umesto korisničkog imena na ekranu se može ispisati deo upita u kome je došlo do greške i samim time napadaču je olakšan posao. Napadač može da sazna i da li se podaci pravilno filtriraju (ukoliko aplikacija ne pokazuje da je korisničko ime pogrešno) i da li se vrši ‘escape’ podataka (ukoliko aplikacija prikazuje grešku baze podataka). Napadač sa ovim podacima može da proba više načina da zaobiđe autentifikaciju. Najčešči oblik napada je da se kod korisničkog imena unese korisnicko’ or ‘bilo_sta’ = ‘bilo_sta’ — .

Primer izvršavanja izmenjenog SQL koda

Zato što počinje sa SQL komentarom (–) upit se tu prekida. Ovaj pristup dozvoljava napadaču upad čak i ako ne zna ni korisničko ime. A ako napadač zna neko korisničko ime onda može i da preuzme taj nalog. Sprečavaje napada se sastoji u tome da se podaci pravilno filtriraju i da se vrši ‘escape’ podataka.

Primer zaštite ubacivanja SQL koda između PHP aplikacije i MySQL baze

Za ‘escape’ podataka se koristi PHP ugrađena funkcija, za MySQL bazu podataka ovo je funkcija mysql_real_escape_string( ). Ali ako funkcija za bazu podataka ne postoji onda se može koristiti i funkcija addslashes(). Sa ovakvom zaštitom rizik od napada gotovo i da ne postoji.

Bez ključnih reči

3.4       Baze podataka i SQL

3.4.1  Otkriveni podaci pristupa

(izvor: Diplomski rad Miloša Miloševića, VETŠ Beograd 2008/09)
Većina PHP aplikacija komuniciraju sa bazama podataka. Ovo uključuje i povezivanje na server baze podataka i autentifikaciju. Obično se podaci o pristupu serveru baze podataka drže u jednoj datoteci smeštenoj blizu korena dokumenata. Ovo predstavlja uobičajan pristup jer olakšava korišćenje naredbi include( ) i require( ) ali može i prouzrokovati potencijalne probleme. Ukoliko korisnici mogu da pristupe takvoj datoteci tu nastaju problemi.

Neka se takva datoteka naziva db.inc web server kao što je Apache će prikazivati ovakvu datoteku kao tekstualnu i svi korisnici će moći da vide pristupno korisničko ime i lozinku. Datotekama ne treba davati ekstenzije .inc jer je to prevaziđeno, ili ako je to baš potrebno web server Apache se može konfigurisati da odbacuje zahteve za datoteke sa određenom ekstenzijom. Datoteke koje treba da sadrže poverljive podatke mogu se smestiti izvan direktorijuma u kome se nalazi web aplikacija jer require i include funkcije mogu da učitavaju datoteke sa sistemskom putanjom i time korisnici ne mogu da pristupaju tim datotekama.

Bez ključnih reči

3.3  Podnošenje obmanjivačkog formulara (Spoofed Form Submissions)

Ova vrsta napada je gotovo isto tako laka kao i napad izmenom URL adrese. Slanje forme je isto što i slanje HTTP zahteva od strane pretraživača. Format zahteva odlučuje forma a neke od podataka unutar zahteva unosi korisnik. Većina formi sadrži atribut acion kao relativnu adresu <form action=”login.php” method=”post”>. Pretraživač traži URL koji daje atribut action nakon slanja forme i koristi trenutnu URL adresu kako bi pronašao zadatu relativnu adresu. Napadaču je dovoljno da zna tačnu apsolutnu lokaciju skripte login.php. On može da napravi sličnu formu smeštenu na bilo kojoj lokaciji sa action atributom forme koji pokazuje na apsolutnu adresu skripte login.php.

Na ovaj način napadač može da zaobiđe klijentske restrikcije namenjene da izvedu osnovno filtriranje podataka. Napadaču čak nije potreban ni web server jer je dovoljno da napravi html dokument čitljiv iz bilo kog pretraživača. Ovaj tip napada nije moguće sprečiti niti je to i potrebno sve dok se ulaz pravilno filtrira unutar skripte login.php, šta god da napadač pošalje iz neke svoje forme mora da prođe kroz filtriranje ciljane skripte. Primer obmanjivačkog formulara:

Originalna forma

Primer obmanjivačke forme

Bez ključnih reči

3.2.4 Cross-site falsifikovanje zahteva (Cross-site request forgeries)

(izvor: Diplomski rad Miloša Miloševića, VETŠ Beograd 2008/09)

Cross-site falsifikovanje zahteva je tip napada koji dozvoljava napadaču da šalje HTTP zahteve od žrtve napada. Žrtva napada to i ne znaju i učestvuje u napadu, falsifikovane zahteve šalje žrtva a ne napadač. Iz ovoga je jako teško zaključiti kada je došlo do ove vrste napada. Zapravo ukoliko se ne preduzmu koraci da se smanji rizik od ove vrste napada aplikacija je vrlo verovatno ranjiva. Karakteristike ove vrste napada su:

- Zloupotreba poverenja koje sajt ima za određenog korisnika

Mnogim korisnicima se ne može verovati ali je uobičajno da pojedine web aplikacije nude određene privilegije nakon prijavljivanja korisnika. Korisnici sa ovim povišenim privilegijama su nesvesni saučesnici.

- U osnovi uključuju web aplikacije koje se oslanjaju na identitet korisnika. Tipično je da identitet korisnika nosi neku težinu. Sa mehanizmom bezbednog rukovanja sesijama, ove vrste napada i dalje mogu biti uspešne. U ovakvim sredinama su CSRF napadi uspešni.

- Izvršavanje HTTP zahteva po izboru napadača.

CSRF napadi obuhvataju sve vrste napada u kojima napada falsifikuje HTTP zahtev od drugog korisnika (u osnovi, varanje korisnika za slanje HTTP zahteva za napadača).

Način CSRF napada i zaštita:

Na lokaciji http://akcije.primer.org/forma.html se nalazi slede i formular

Primer forme za CSRF napad

Postoji nekoliko stvari kako bi se web aplikacija zaštitila od potencijalnih CSRF napada:

- Koristiti POST više nego GET u formularima kao metod slanja. Prikladnije je korišćenje POST metoda kada formular obavlja neku akciju. U suštini HTTP specifikacija zahteva da se GET smatra bezbednim.

- Ne treba se oslanjati na register_globals. Korišćenje POST metoda slanja je beskorisno ukoliko se programer osloni na register_globals i poziva na promenljive $simbol ili $kolicina iz formulara. Takođe se ne preporučuje korišćenje $_REQUEST.

- Dok se čini sve da se korisnikovo iskustvo učini što ugodnijim, mnogo ugodnosti može imati previše ozbiljne posledice. Pristupi jednog klika mogu se u činiti bezbednim ali jednostavnija primena je više podložna CSRF napadima.

- Treba prisiliti korisnike na korišćenje isključivo formulara web aplikacije. Ako korisnik ne koristi formular web aplikacije onda ni zahtev koji šalje nije ispravan.

Metoda zaštite od CSRF napada:

Zaštita od CSRF napada

Sa ovakvom modifikacijom koda da bi do lo do CSRF napada mora se i poslati i jedinstveni token kako bi se uspe no falsifikovao zahtev. Zato to je token smešten u sesiji korisnika neophodno je i da napada koristi token jedinstven žrtvi napada. Ovakva zaštita svaki napad uspešno smanjuje samo na jednog korisnika i napadaču je potrebno da validan token koji pripada drugom korisniku. Napad nije mogu čak ni ako korisnik koristi svoj token kako bi falsifikovao napad za drugog korisnika. Provera tokena:

Provera tokena na prijemnoj strani

Dodajući mogućnost tokena u formama praktično se eliminiše CSRF napad.

Ovakav pristup treba imati u svim formama koje obavljaju neku akciju.

CSRF, napad

3.2.3 Cross-Site skriptovanje (XSS)

(izvor: Diplomski rad Miloša Miloševića, VETŠ Beograd 2008/09)
Cross-site skriptovanje je jedna od najpoznatijih i najčešćih sigurnosnih propusta u web aplikacijama. Karakteristike XSS napada:
1. Zloupotreba poverenja koje korisnika ima na odre enoj web aplikaciji
Korisnici ne moraju da imaju visok nivo poverenja u web aplikacijama koje koriste ali njihovi web pretraživači imaju.
2. U osnovi uključuju web aplikacije koje prikazuju spoljne podatke
Aplikacije sa povišenim rizikom uključuju forume, web aplikacije i bilo šta što prikazuje uređeni spoljni sadržaj (poput RSS unosa).
3. Ubacivanje sadržaja po izboru napadača
Kada spoljni sadržaj nije pravilno filtriran može se desiti da prikaže sadržaj po napadačevom izboru. Ovo može biti isto toliko opasno kao i dopustiti napadaču da obrađuje izvorni kod aplikacije. Ukoliko aplikacija prikazuje neki sadržaj a da on nije pravilno filtriran onda je aplikacija podložna XSS napadu. Tipičan primer XSS napada predstavljaju nefiltrirane informacije koje unosi korisnik na nekoj stranici. Ukoliko stranicu poseti korisnik koji zna da se služi XSS napadima on može uneti sledeći kod kao informaciju:

Cross-site skriptovanje (XSS)

Svaki slede i korisnik koji poseti ovu stranicu biće preusmeren na web stranicu
evil.example.org i korisnikov web pretraživač će poslati kola i asociran na pravu stranicu na ovu web stranicu. Samim time će korisnički podaci biti otkriveni trećoj strani koja ih može zloupotrebiti.
Rizik od XSS napada se može umanjiti sledećim postupcima:
1. Filtriranje spoljnih podataka
2. Korišćenjem PHP funkcija kao to su htmlentities(), striptags(), …
3. Proveravanjem du ine unetih podataka i obezbeđivanjem da su samo ispravni karakteri dozvoljeni
4. Strikna pravila davanja imena mogu omogućiti programerima da razlikuju filtrirane i nefiltrirane podatke

JavaScript, napadi, XSS

3.2.2 Semantički URL napadi

(izvor: Diplomski rad Miloša Miloševića, VETŠ Beograd 2008/09)
Radoznalost predstavlja motivaciju iza mnogih napada i semantički URL napadi predstavljaju savršen primer. Ovaj tip napada podrazumeva korisnika koji modifikuje URL adresu kako bi otkrio sebi zanimljive stvari koje se mogu ostvariti sa aplikacijom.
Na primer korisnik milan klikne na link u aplikaciji i stize na adresu
http://www.primer.org/private.php?user=milan, razumljivo je da će neki korisnici pokušati da promene deo adrese kako bi videli kako će se aplikacija ponašati. Korisnik može da promeni deo adrese i pristupi tuđim informacijama.
Podaci GET niza su lakše pristupačniji za manipulaciju nego kod POST niza i tako će biti podložniji napadima.

Primer forme za URL napad

Korisnik nakon ove forme stiže na adresu reset.php?user=milos&email=milos%40primer.org.
Ukoliko napada izmeni polje user reset.php?user=php&email=milos%40primer.org, sada napada preuzima nalog php sa email adresom php@primer.org i novom lozinkom.
Naćin zaštite se sastoji u tome da se pravilno koristi sesija.

napadi, url

3.2 FORME I URL ADRESE
3.2.1 Forme i podaci

(izvor: Diplomski rad Miloša Miloševića, VETŠ Beograd 2008/09)
Iako korisnici mogu slati podatke na mnogo načina, većina aplikacija prima svoje
podatke kao rezultat akcije neke forme iz pretraživača klijenata. Korisnik može slati
podatke na tri načina: putem URL adrese (primer su podaci koje daje globalni niz
$_GET), u sadržaju zahteva (primer su podaci koje daje forma kroz globalni niz
$_POST) ili u HTTP zaglavlju (primer su podaci iz $_COOKIE niza a od cookie
(kolačića) sa klijentske strane). Pri pisanju forme gotovo je uvek potrebno kao metod
slanja podataka navesti POST. Druga opcija je GET i podaci pri slanju forme će biti
vidljivi u zahtevanoj adresi slanja to nije slučaj kod POST metode slanja.
Primer GET metode slanja podataka:

Primer GET metode slanja

Primer POST metode slanja

Sa ove forme korisnik stiže na adresu login.php, vrednosti koje je uneo na prethodnoj
stranici sada nisu vidljive u adresi nove stranice.

bezbednost, podaci, url

3.1 BEZBEDNOST PHP MODULA
3.1.1 Register globals

(izvor: Diplomski rad Miloša Miloševića, VETŠ Beograd 2008/09)
Ovaj modul ne predstavlja opasnost bezbednosnoj zaštiti već programer mora da napravi grešku. Ipak postoje dva glavna razloga zbog kojih je poželjno praviti aplikacije sa isključenim modulom register globals:
- on može povećati opasnost od bezbedonosne propustljivosti
- krije poreklo podataka što može dovesti da programer više ne može da prati poreklo podataka iz aplikacije.
Kada se uključi modul register_globals tada se svi primljeni podaci iz super globalnih nizova prevode u jednostavne promenljive u kodu i time olakšavaju napadaču napad na web aplikaciju. Modul register_globals treba isključiti a sve podatke koji pristižu treba uzimati preko $_POST ili $_GET.
3.1.2 Error Reporting
Svaki programer pri razvoju aplikacije pravi greške i ovaj modul koji dolazi uz PHP omogućava detaljan prikaz greške na ekranu koji može videti i potencijalni napadač i upotrebiti u napadu na aplikaciju. Potrebno je podesiti display_errors na Off i podesiti log_errors na On i odrediti lokaciju datoteke u kojoj će biti upisani detalji greške sa error_log. U slučaju da programer nema pristup konfiguracionoj datoteci php.ini može se koristiti php ugrađena funkcija ini_set(). Funkcija ini_set() kao argumente prima naziv promenljive čije se svojstvo menja i svojstvo koje se postavlja. Dejstvo funkcije ini_set() je samo nad skriptom koja se učitava, nakon završetka skripte vraćaju se vrednosti koje su originalno bile podešene.

<?php

ini_set(‘error_reporting’, E_ALL | E_STRICT );

ini_set(‘display_errors’, ‘Off’);

ini_set(‘log_errors’,’ On’);

ini_set(‘error_log’,’/usr/local/apache/logs/error_log’);

?>

3.1.3 Allow url fopen
Allow_url_fopen predstavlja još jedan PHP modul i on dozvoljava programerima da tretiraju URL adrese kao datoteke. Obično je slučaj da se podaci iz zahteva koriste kako bi se odredila datoteka koju treba učitati:
http://www.primer.com/pogled.php?dat=index.php
Onda aplikacija koristi PHP funkciju include() na sledeći način:
$dat=$_GET[’dat’];
include($dat);
Napadač može da promeni vrednost parametra dat i da učita bilo koju datoteku sa web servera. Da bi se sprečio mogući napad ovaj modul treba unapred preventivno isključiti.
3.1.4 Filtriranje ulaza
Filtriranje ulaza predstavlja proces kojim se proverava validnost podataka koji se dobijaju sa klijentske strane. Ukoliko se svi podaci pravilno filtriraju može se smanjiti rizik da se podaci zloupotrebe u aplikaciji. Veliki broj bezbednostih propusta u PHP aplikacijama može se pripisati loše filtriranim podacima. Pri filtriranju ulaza obično se podrazumeva: identifikacija izvora ulaznih podataka, filtriranje ulaza, razlikovanje zlonamerno poslatih podataka.
Izvori podataka mogu biti i klijent i serveri baza podataka ili neke datoteke koje PHP aplikacije mogu učitavati sa udaljenih izvora. Podaci koji dolaze od klijenata se lako razlikuju i obično su smešteni u super globalne nizove kao što su $_POST ili $_GET. Drugi ulazi mogu biti teži za identifikaciju kao što je $_SERVER globalni niz gde neke od elemenata klijenti mogu zloupotrebiti. Pošto se identifikuje izvor podataka potrebno je izvršiti validaciju podataka tj. filtriranje ulaza.
Podatke koje klijenti šalju nikada ne treba ispravljati jer se pokazalo da je ovaj pristup pogrešan i samo stvara bezbedonosne probleme. Validacijom se mogu proveravati podaci tako da se određeni karakteri mogu zabraniti ili se mogu propuštati samo određeni tipovi podataka. Primer:

<?php

$cisto=array();

if(ctype_alnum($_POST[‘korisnickoime’]){//ukoliko je korisnicko ime alfanumeričkog tipa

$cisto[‘korisnickoime’]=$_POST[‘korisnickoime’];

}

?>

3.1.5 “Escape” ulaznih podataka
Jedan od stubova sigurnosti web aplikacija je praksa da se vrši enkodovanje određenih karaktera tako da njihovo originalno svojstvo bude sačuvano. Pri slanju podataka klijentu koriste se PHP ugrađene funkcije. Praksa je i da se definiše poseban niz podataka koji prima očišćene podatke klijenata. Takav niz je prvo potrebno inicijalizovati na prazan niz a potom ga popunjavati sa primljenim podacima.
Jedna od funkcija za ovaj postupak je htmlentities() koja sve karaktere koje prima kao argumente pretvara tako da se oni mogu prikazati klijentima u pretraživačima kao HTML kodovi. Ukoliko je definisano da određen podatak može biti samo alfanumeričkog tipa onda se ovaj postupak može i zaobići.
Što se tiče slanja podataka u bazu za korisnike MySQL baze podataka može se koristiti funkcija mysql_real_escape_string() koja će podatke prilagoditi za validan unos u bazu. PHP podržava dosta baza podataka i za svaku ima odgovarajuću funkciju koja vrši ovu operaciju. Ukoliko ipak za neku bazu ne postoji slična funkcija može se koristiti funkcija addslashes().
Primer:

<?php

$html=array();

$html[‘korisnickoime’]=htmlentities($_cisto[‘korisnickoime’],ENT_QUOTES,’UTF-8’);

?>

bezbednost, diplomski, mysql, php