Kako da zaštitite svoje PHP aplikacije

PHP je popularan programski jezik koji se često koristi za razvoj web aplikacija i dinamičkih web stranica. PHP trenutno pokreće oko 80% globalnih web aplikacija, što ga istovremeno čini jednim od najčešće korišćenih jezika u svetu web development-a.

Uz sve svoje prednosti, PHP takođe ima nekoliko nedostataka. Vrlo često je na meti zbog donekle nespretne sintakse i nedostatka stroge tipizacije. Međutim, mnogi developeri aktivno koriste PHP za razvoj raznih web aplikacija, uključujući CMS-ove (sisteme za upravljanje sadržajem) kao što su WordPress i Joomla.

Zbog toga ćemo u ovom tekstu izneti nekoliko saveta koji će vam pomoći da poboljšate bezbednost vaših PHP aplikacija. Primena ovih malih saveta omogućava vam da vaša PHP aplikacija prođe čak i rigorozne bezbednosne provere i da nikada ne bude izložena spoljnim napadima putem weba.

SQL Injection

SQL injection je vrsta sigurnosne ranjivosti koja se javlja kada napadač ubacuje zlonamerni SQL kod putem korisničkog unosa koji se nepravilno obrađuje u SQL upitu. Ova ranjivost omogućava napadaču da manipuliše SQL upitima i dobije neovlašćeni pristup, izmeni ili obriše podatke u bazi podataka. Da bismo razumeli kako izgleda SQL injection, zamislimo jednostavan primer:

Recimo da imamo prijavu na web sajt gde korisnik unosi korisničko ime i lozinku. PHP kod za proveru korisničkog unosa i izvršavanje SQL upita može izgledati ovako:

$username = $_POST['username'];
$password = $_POST['password'];
$sql = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($connection, $sql);

U ovom primeru, korisničko ime i lozinka se direktno ubacuju u SQL upit koristeći spajanje stringova. To otvara mogućnost za SQL injection. Na primer, ako napadač u polje za korisničko ime unese `' OR '1'='1`, SQL upit će izgledati ovako:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '$password'

Ovo će vratiti sve redove iz tabele `users`, jer uslov `'1'='1'` uvek ima vrednost `true`.

Napadač može iskoristiti ovu ranjivost za različite zlonamerne svrhe, kao što su:

• Dobijanje osetljivih podataka iz baze podataka, kao što su korisnička imena, lozinke ili drugi podaci.
• Brisanje, izmena ili umetanje podataka u bazu podataka.
• Izvršavanje drugih zlonamernih radnji, kao što su stvaranje novih korisničkih naloga ili izvršavanje SQL komandi.

Da bismo se zaštitili od SQL ubrizgavanja, izuzetno je važno je koristiti parametrizovane upite ili pripremljene statemente. Ove tehnike omogućavaju odvajanje korisničkog unosa od SQL koda i pravilno tretiranje korisničkog unosa kao podataka, a ne kao deo SQL sintakse.

Evo primera koda koji koristi pripremljene izjave za sigurniju proveru korisničkog unosa:

$username = $_POST['username'];
$password = $_POST['password'];
$stmt = $connection->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
$result = $stmt->get_result();

Ovaj kod koristi parametre (`?`) u SQL upitu i koristi `bind_param` metodu da bi se vezali parametri na siguran način. Na taj način se izbegava mogućnost SQL ubrizgavanja, jer korisnički unos se tretira samo kao podaci, a ne kao deo SQL sintakse.

Korišćenje parametrizovanih upita ili pripremljenih izjava je ključna praksa zaštite od SQL ubrizgavanja i trebalo bi je primenjivati u svim PHP aplikacijama koje komuniciraju sa bazom podataka.

XSS (Cross-Site Scripting) ranjivost

XSS (Cross-Site Scripting) je vrsta napada koja omogućava napadaču da ubaci zlonamerni kod (najčešće JavaScript) koji se izvršava na strani korisnika, u kontekstu web stranice. XSS napad se javlja kada aplikacija nepravilno obrađuje korisnički unos i dozvoljava ubacivanje zlonamernog koda koji se potom izvršava u browseru korisnika.

Postoje tri vrste XSS napada:

Reflektovani XSS (Reflected XSS)

Reflektovani XSS napad se dešava kada korisnik poseti web stranicu koja sadrži zlonamerni kod koji se prosleđuje putem URL-a ili formulara. Ovaj kod se zatim reflektuje nazad korisniku i izvršava se u njegovom browseru.

Na primer, ako napadač kreira link koji sadrži zlonamerni JavaScript kod, kao što je:

https://www.example.com/?name=<script>alert('XSS!');</script>

Ako korisnik poseti taj link, kod će se izvršiti u njegovom browseru i prikazaće se upozorenje „XSS!“.

Sačuvani XSS (Stored XSS)

Sačuvani XSS napad se događa kada zlonamerni kod ostaje na web stranici ili u bazi podataka, a svaki put kad korisnik pristupi toj stranici, kod se izvršava.

Na primer, ako korisnik ostavi komentar na web stranici koji sadrži zlonamerni JavaScript kod, a taj kod se kasnije prikazuje svim posetiocima stranice, svaki put kada neko otvori tu stranicu, kod će se izvršiti u njegovom browseru.

DOM bazirani XSS (DOM-based XSS)

DOM bazirani XSS napad se javlja kada napadač iskorišćava ranjivosti u manipulaciji Document Object Model (DOM) stranice. Ova vrsta napada ne uključuje slanje podataka na server, već koristi JavaScript kod koji se izvršava direktno u browseru korisnika.

Na primer, ako web stranica ima skriptu koja preuzima vrednosti iz URL-a i ubacuje ih u HTML sadržaj stranice bez pravilne obrade, napadač može napraviti URL sa zlonamernim kodom koji će izmeniti ili prikazati sadržaj stranice na neželjen način.

Zaštita od XSS napada uključuje sledeće metode:

• Sanitizacija korisničkog unosa kako bi se uklonili potencijalno opasni karakteri i HTML tagovi. Možete koristiti funkcije kao što su `htmlspecialchars` ili biblioteke poput OWASP AntiSamy za sigurno prikazivanje korisničkog unosa.
• Korišćenje Content Security Policy (CSP) kako bi se definisala politika bezbednosti za web stranicu. CSP ograničava izvor izvršavanja skripti i sprečava ubacivanje zlonamernih skripti.
• Pažljivo upravljanje kolačićima (cookies) kako bi se smanjio rizik od XSS napada putem kolačića.
• Pravilno validiranje i filtriranje korisničkog unosa kako bi se sprečilo ubacivanje zlonamernih skripti.
• Redovno ažuriranje web aplikacija i biblioteka na najnovije verzije kako bi se ispravile poznate ranjivosti.

Implementiranje ovih sigurnosnih mera može pomoći u zaštiti od XSS napada i osigurati sigurnost vaših PHP aplikacija.

Primer XSS napada

Pretpostavimo da imate web formu gde korisnici mogu ostavljati komentare. Sledeći kod predstavlja primer ranjive implementacije gde se korisnički unos nepravilno filtrira:

<?php
// Prikazivanje komentara
echo $_GET['comment'];
?>

Kako smo već pomenuli, napadač može ubaciti zlonamerni JavaScript kod u URL-u kao vrednost parametra 'comment', na sledeći način:

`https://www.example.com/?comment=<script>alert('XSS Attack!');</script>`

Kada se ova adresa otvori u browseru, JavaScript kod će se izvršiti i prikazati upozorenje "XSS Attack!".

Primer koda za zaštitu od XSS napada

Da bismo se zaštitili od XSS napada, potrebno je da pravilno filtriramo i sanitizujemo korisnički unos. Evo primera sigurnijeg koda koji koristi funkciju `htmlspecialchars` za filtriranje korisničkog unosa:

<?php
// Prikazivanje komentara
echo htmlspecialchars($_GET['comment'], ENT_QUOTES, 'UTF-8');
?>

Funkcija `htmlspecialchars` pretvara specijalne karaktere u njihove odgovarajuće HTML entitete. Ovaj kod će konvertovati zlonamerni kod u sigurne karaktere, tako da će se prikazati kao tekst, a ne kao izvršivi JavaScript kod.

Osim toga, možete koristiti Content Security Policy (CSP) kako biste dodatno ojačali zaštitu od XSS napada. Evo primera dodavanja CSP zaglavlja u PHP kod:

<?php
header("Content-Security-Policy: script-src 'self'");
?>

Ovo zaglavlje CSP ograničava izvor izvršavanja skripti samo na sopstvenom domenu, što sprečava izvršavanje skripti sa drugih domena.

CSRF (Cross-Site Request Forgery) ranjivost

CSRF (Cross-Site Request Forgery) je vrsta ranjivosti u kojoj napadač koristi poverenje autentifikovanih korisnika kako bi izvršio neželjene akcije u njihovo ime na drugim web stranicama. CSRF napad se dešava kada napadač navodi žrtvu da nesvesno izvrši zahtev (request) prema ciljanoj web aplikaciji, koristeći ranije uspostavljene autentifikacijske kolačiće (cookies) ili druge vidove autentifikacije.

Evo kako u nekoliko koraka izgleda jedan primer CSRF napada:

1. Korisnik je prijavljen na web stranicu „Banka“ koja omogućava prenos novca na drugi račun.
2. Napadač priprema zlonamernu web stranicu ili ubacuje zlonamerni kod na drugu web stranicu koju korisnik redovno posećuje, kao što je forum ili blog.
3. Kada korisnik poseti zlonamernu web stranicu ili klikne na zlonamerni link na drugoj web stranici, iza scene se šalje zahtev prema „Banci“ kako bi se izvršio transfer novca sa korisnikovog računa na račun napadača.
4. Budući da korisnik ima aktivne autentifikacijske kolačiće (cookies) za „Banku“, zahtev će biti izvršen sa korisnikovim ovlašćenjima, iako korisnik nije nesvesno pokrenuo zahtev.

Napad može imati različite ciljeve, uključujući:

• Izvršavanje finansijskih transakcija u ime korisnika.
• Brisanje ili izmena korisničkih podataka.
• Postavljanje zlonamernih sadržaja na ciljanoj web stranici.

Da biste se zaštitili od CSRF napada, preporučuje se primena sledećih metoda:

• Upotreba CSRF tokena: Generišite jedinstveni CSRF token za svaku sesiju ili za svaki formular. Taj token se ubacuje u formular i šalje sa zahtevom. Prilikom obrade zahteva, server proverava da li se token podudara sa očekivanim tokenom za tu sesiju ili formular. To pomaže u sprečavanju CSRF napada jer napadač neće imati pristup ispravnom CSRF tokenu.
• Korišćenje metoda koje izazivaju promene: Za akcije koje izazivaju promene na serveru, poput brisanja podataka ili izmene postavki, koristite HTTP metode poput POST ili DELETE, umesto GET metode koja se može lako pokrenuti putem linkova.
• Implementacija CORS politika: Kada koristite AJAX zahteva ka drugim domenima, koristite CORS (Cross-Origin Resource Sharing) politiku kako biste ograničili dozvoljene izvore zahteve i održali kontrolu nad tome koji zahtevi se mogu izvršiti.
• Pažljivo upravljanje kolačićima (cookies): Koristite dodatne mere zaštite poput CSRF kolačića (CSRF token smešten u kolačiću), što otežava napadačima da iskoriste autentifikacijske kolačiće za izvršavanje napada.
• Edukacija korisnika: Informišite korisnike o CSRF napadima i podstičite ih na oprez prilikom kliktanja na nepoznate ili sumnjive linkove, naročito dok su prijavljeni na web stranice koje zahtevaju davanje nekih ličnih ili finansijskih podataka.

Pravilna implementacija ovih sigurnosnih mera pomaže u zaštiti od CSRF napada i održavanju sigurnosti vaših PHP aplikacija.

Evo primera koda koji ilustruje CSRF napad i kako se možete zaštititi od takvog napada:

Primer CSRF napada

Pretpostavimo da imate web stranicu „Promena lozinke“ gde korisnici mogu promeniti svoje lozinke. Sledeći kod predstavlja primer ranjive implementacije gde se ne koristi CSRF zaštita:

<?php
session_start();
if ($_SERVER['REQUEST_METHOD'] === 'POST') {

// Promena lozinke
$newPassword = $_POST['newPassword'];
// Promena lozinke za trenutno prijavljenog korisnika
// Implementacija promene lozinke...
echo 'Lozinka je uspešno promenjena!';
}

// HTML forma za promenu lozinke
echo '
<form action="change_password.php" method="POST">
<label for="newPassword">Nova lozinka:</label>
<input type="password" name="newPassword" id="newPassword" required>
<button type="submit">Promeni lozinku</button>
</form>';
?>

U ovom primeru, napadač može pripremiti zlonamernu web stranicu koja korisnika navodi da je poseti. Na primer:

<!-- Zlonamerna stranica -->
<form id="attackForm" action="https://www.example.com/change_password.php" method="POST">
<input type="hidden" name="newPassword" value="novasifra" />
</form>
<script>
document.getElementById('attackForm').submit();
</script>

Kada korisnik poseti zlonamernu web stranicu, formular se automatski podnosi ka „Promena lozinke“ stranici i lozinka se menja bez korisnikovog znanja ili pristanka.

Primer koda za zaštitu od CSRF napada

Da bismo se zaštitili od CSRF napada, koristimo CSRF token i proveravamo njegovu validnost prilikom obrade zahteva. Evo primer kako bismo zaštitili „Promena lozinke“ stranicu:

<?php
session_start();

// Generisanje CSRF tokena i čuvanje u sesiji
if (!isset($_SESSION['csrf_token'])) {
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

// Provera CSRF tokena prilikom obrade zahteva
if ($_SERVER['REQUEST_METHOD'] === 'POST' && isset($_POST['csrf_token']) && $_POST['csrf_token'] === $_SESSION['csrf_token']) {

// Promena lozinke
$newPassword = $_POST['newPassword'];

// Promena lozinke za trenutno prijavljenog korisnika
// Implementacija promene lozinke...

echo 'Lozinka je uspešno promenjena!';
}

// HTML forma za promenu lozinke sa CSRF tokenom
echo '
<form action="change_password.php" method="POST">
<input type="hidden" name="csrf_token" value="' . $_SESSION['csrf_token'] . '">
<label for="newPassword">Nova lozinka:</label>
<input type="password" name="newPassword" id="newPassword" required>
<button type="submit">Promeni lozinku</button>
</form>';
?>

U ovom primeru, generišemo jedinstveni CSRF token prilikom prikazivanja forme i čuvamo ga u sesiji. Zatim, prilikom obrade zahteva, proveravamo da li se uneti CSRF token podudara sa očekivanim tokenom iz sesije. Ako je token validan, dozvoljavamo promenu lozinke.

File Inclusion ranjivost (ili LFI, Local File Inclusion) ranjivost

File Inclusion ranjivost (ili LFI, Local File Inclusion) je sigurnosna ranjivost koja se javlja kada web aplikacija dozvoljava uključivanje ili ubacivanje lokalnih datoteka sa servera, ali nepravilno kontroliše i validira korisnički unos. Ova ranjivost omogućava napadaču da uključi i izvrši zlonamerni kod sa drugih datoteka na serveru.

Postoje dva osnovna tipa File Inclusion ranjivosti:

Uključivanje lokalnih datoteka (Local File Inclusion – LFI)

U ovom scenariju, web aplikacija omogućava korisnicima da prenesu ime datoteke ili putanju do datoteke koja će biti uključena u HTML ili PHP kodu. Međutim, ako se ne vrši pravilna validacija i filtriranje korisničkog unosa, napadač može manipulisati putanjom datoteke kako bi uključio zlonamerni kod.

Na primer, ukoliko web aplikacija ima URL parametar koji se koristi za uključivanje datoteke:

<?php
$file = $_GET['file'];
include($file);
?>

Napadač može proslediti zlonamernu putanju do datoteke na sledeći način:

`https://www.example.com/?file=/path/to/malicious/file`

Ovo će rezultirati uključivanjem zlonamerne datoteke koja sadrži zlonamerni kod, što može dovesti do izvršavanja tog koda na serveru.

Uključivanje udaljenih datoteka (Remote File Inclusion – RFI)

Ovaj oblik ranjivosti se javlja kada web aplikacija omogućava uključivanje udaljenih datoteka sa drugih servera. Napadač može manipulisati parametrom za uključivanje datoteke kako bi uključio zlonamerni kod sa udaljenog servera. Ovo može biti posebno opasno, jer napadač može imati potpunu kontrolu nad sadržajem udaljene datoteke.

Zaštita od File Inclusion ranjivosti obično uključuje sledeće metode:

• Provera korisničkog unosa: Pravilno validirajte i filtrirajte korisnički unos kako biste uklonili ili ograničili potencijalno opasne karaktere i putanje datoteka. Preporučuje se upotreba bele liste (whitelist) umesto crne liste (blacklist) prilikom odobravanja dozvoljenih datoteka za uključivanje.
• Ograničavanje pristupa: Ograničite pristup lokalnim datotekama i sprečite uključivanje datoteka iz nebezbednih ili nepouzdanih izvora. Ograničite pristup samo na potrebne direktorijume i datoteke.
• Korišćenje relativnih putanja: Umesto apsolutnih putanja, koristite relativne putanje za uključivanje lokalnih datoteka kako biste smanjili rizik od uključivanja neželjenih datoteka.
• Upotreba bezbednog API-ja za uključivanje datoteka: Ako je moguće, koristite bezbedne API-je ili funkcije koje su specifične za vaš okvir rada ili jezike, koje pružaju bolju zaštitu prilikom uključivanja datoteka.

Pravilna implementacija ovih sigurnosnih mera pomaže u sprečavanju File Inclusion ranjivosti i održavanju sigurnosti vaših PHP aplikacija.

Evo primera koda koji ilustruje kako se možete zaštititi od File Inclusion ranjivosti:

Korišćenje bele liste (whitelist) dozvoljenih datoteka

<?php
$allowedFiles = array(
'file1.php',
'file2.php',
'file3.php'
);

$file = $_GET['file'];

// Provera da li je datoteka dozvoljena pre uključivanja
if (in_array($file, $allowedFiles)) {
include($file);
} else {
echo 'Nedozvoljena datoteka';
}
?>

U ovom primeru, definišemo listu dozvoljenih datoteka `$allowedFiles` koje mogu biti uključene. Pre nego što uključimo datoteku, proveravamo da li se datoteka nalazi u listi dozvoljenih datoteka. Ako jeste, datoteka će biti uključena, inače će se prikazati poruka o nedozvoljenoj datoteci.

Korišćenje relativnih putanja

<?php
$file = $_GET['file'];

// Koristimo relativnu putanju uključivanja datoteke
$filePath = 'path/to/files/' . $file;

// Provera da li je datoteka postoji pre uključivanja
if (file_exists($filePath)) {
include($filePath);
} else {
echo 'Nedozvoljena datoteka';
}
?>

U ovom primeru, konstruišemo relativnu putanju do datoteke koristeći korisnički unos. Pre uključivanja datoteke, proveravamo da li ta datoteka postoji na serveru pomoću `file_exists` funkcije. Samo ako datoteka postoji, ona će biti uključena.

Session Hijacking ranjivost

Session Hijacking je vrsta napada u kojoj napadač pokušava da preuzme kontrolu nad sesijom autentifikovanog korisnika. Sesija je period aktivne interakcije između korisnika i web aplikacije, koja se čuva na serveru ili u kolačićima (cookies) korisnika. Napadač može pokušati da preuzme sesiju kako bi se predstavio kao legitimni korisnik i izvršavao neželjene akcije u njegovo ime.

Evo nekoliko ključnih aspekata vezanih za Session Hijacking:

Kako dolazi do Session Hijacking napada

Najčešći način izvršavanja Session Hijacking napada je putem krađe ili presretanja identifikacionih podataka sesije. Ovo se može dogoditi na nekoliko načina:

• Presretanje mrežnog saobraćaja: Napadač može koristiti metode poput snimanja mreže (sniffing) ili upotrebe zlonamernog softvera za presretanje identifikacionih podataka sesije.
• Krađa kolačića (cookies): Napadač može pokušati pristupiti kolačićima (cookies) korisnika, ili iskoristiti ranjivost web aplikacije koja omogućava krađu ili manipulaciju kolačićima.
• Napadi na stranu klijenta: Napadač može koristiti zlonamerni JavaScript kod ili drugi metod za krađu ili manipulaciju identifikacionim podacima sesije na strani klijenta.

Vrste Session Hijacking napada

• Sniffing napadi: Napadač koristi metode snimanja mreže kako bi presreo i pročitao mrežni saobraćaj kako bi došao do identifikacionih podataka sesije.
• Session Sidejacking: Napadač koristi ranjivosti na strani klijenta, poput nezaštićene mreže ili nesigurnih kolačića, kako bi presreo i iskoristio identifikacione podatke sesije.
• Session Fixation: Napadač može nametnuti ili „fiksirati“ identifikacione podatke sesije na korisnika, obično putem prijateljskih web lokacija ili manipulacijom URL-a, kako bi kasnije preuzeo kontrolu nad sesijom.
• CSRF napadi (Cross-Site Request Forgery): Napadač može iskoristiti Session Hijacking kako bi izvršio CSRF napad, manipulišući identifikacionim podacima sesije kako bi izvršio neželjene akcije u ime korisnika.

Prevencija Session Hijacking napada

• Korišćenje sigurnog protokola komunikacije: Koristite HTTPS za šifrovanje mrežnog saobraćaja kako biste otežali snimanje i presretanje identifikacionih podataka sesije.
• Sigurno upravljanje kolačićima (cookies): Postavite sigurne postavke za kolačiće (cookies), uključujući flag „Secure“ za zaštitu kolačića preko HTTPS veze i „HttpOnly“ flag kako bi se sprečio pristup kolačićima putem JavaScripta.
• Implementacija mehanizama zaštite sesija: Koristite sigurne mehanizme generisanja i upravljanja identifikacionim podacima sesije. To može uključivati upotrebu jedinstvenih identifikatora sesije, provere i verifikacije pri svakom zahtevu, i periodičnog osvežavanja identifikatora sesije.
• Kontinuirano praćenje i nadogradnja bezbednosti: Redovno ažurirajte softver i pratite bezbednosne smernice i preporuke za održavanje sigurnosti vaše web aplikacije.
  .

Primer Session Hijacking napada

Napadač može iskoristiti nezaštićenu mrežu ili drugu tehniku za presretanje identifikacionih podataka sesije. Evo jednog primerka koda za izvršavanje napada:

<?php
// Presretanje identifikacionih podataka sesije
$sessionId = $_GET['session_id'];

// Napadač može koristiti ukradene identifikacione podatke sesije
session_id($sessionId);
session_start();

// Prikazivanje podataka iz ukradene sesije
echo "Korisničko ime: " . $_SESSION['username'];
?>

U ovom primeru, napadač koristi ukradene identifikacione podatke sesije (session_id) koje je presreo sa mreže ili je do njih došao na drugi način. Zatim, on postavlja ukradeni session_id i pokreće sesiju korisnika kako bi pristupio podacima iz te sesije.

Primer koda za zaštitu od Session Hijacking napada

Zaštita od Session Hijacking napada uključuje primenu sigurnosnih mera kako bi se otežalo ili onemogućilo preuzimanje kontrole nad sesijom. Evo jednog primerka koda koji ilustruje kako možete poboljšati sigurnost sesija:

<?php
session_start();

// Generisanje novog identifikatora sesije i uništavanje stare sesije
session_regenerate_id(true);

// Generisanje novog identifikatora sesije i uništavanje stare sesije
session_regenerate_id(true);

// Označavanje sesije kao sigurne
$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];

// Provera sigurnosti sesije pri svakom zahtevu
if ($_SESSION['user_agent'] !== $_SERVER['HTTP_USER_AGENT']) {

// Sesija je sumnjiva, odjaviti korisnika ili preduzeti druge mere
session_unset();
session_destroy();
echo "Sesija nije validna!";
} else {

// Sesija je sigurna, nastaviti sa normalnim radom
echo "Dobrodošli, " . $_SESSION['username'];
}
?>

U ovom primeru, koristimo nekoliko metoda zaštite:

• `session_regenerate_id(true)` generiše novi identifikator sesije i uništava staru sesiju. Ovo otežava napadačima da preuzmu kontrolu nad prethodno izdanom sesijom.
• Čuvamo `$_SESSION['user_agent']` vrednost koja predstavlja User Agent korisnika. Prilikom svakog zahteva, proveravamo da li se vrednost User Agenta poklapa sa vrednošću u sesiji. Ako se ne podudara, smatramo sesiju sumnjivom i preduzimamo odgovarajuće mere.
• Ukoliko se sesija smatra sumnjivom, možemo odjaviti korisnika, uništiti sesiju i preduzeti druge mere zaštite.

Insecure Direct Object References (IDOR) ranjivost

Insecure Direct Object References (IDOR) je vrsta sigurnosne ranjivosti koja se javlja kada aplikacija dozvoljava korisniku direktni pristup internim objektima ili resursima preko identifikatora objekta, a nepravilno proverava ovlašćenje pristupa. Ova ranjivost može dovesti do neovlašćenog pristupa osetljivim informacijama ili obavljanja neovlašćenih operacija.

Evo nekoliko ključnih aspekata vezanih za IDOR napad:

Kako IDOR napad funkcioniše

• Aplikacija koristi identifikator objekta (npr. broj ili ID) kako bi pružila pristup određenim resursima, kao što su korisnički podaci, datoteke, porudžbine itd.
• Napadač otkriva ili pretpostavlja identifikatore objekata koji nisu javno dostupni i pokušava da pristupi tim objektima.
• Napadač direktno menja identifikatore objekata u URL-u ili zahtevu kako bi dobio pristup neovlašćenim resursima ili podacima drugih korisnika.
• Napadač može pokušati da manipuliše ID-ovima ili identifikatorima objekata kako bi dobio pristup resursima ili informacijama na koje nije autorizovan. To može uključivati promenu ID-a u URL-u, slanje posebnih zahteva ili eksploataciju drugih mehanizama koji referenciraju ID-ove objekata.
• Kada napadač uspe da manipuliše ID-ovima, može dobiti pristup resursima ili informacijama kojima inače ne bi trebalo da ima pristup. Na primer, napadač može pristupiti tuđem korisničkom nalogu, osetljivim podacima ili drugim resursima koji su rezervisani samo za određene korisnike.

Primer IDOR napada

Pretpostavimo da imate web aplikaciju koja omogućava korisnicima pristup svojim profilima na osnovu identifikatora. U sledećem primeru, korisnik može direktno promeniti identifikator u URL-u kako bi pristupio profilima drugih korisnika:

<?php
// Prikazivanje profila korisnika na osnovu identifikatora
$userId = $_GET['userId'];
$query = "SELECT * FROM users WHERE id = $userId";
$result = mysqli_query($connection, $query);
$user = mysqli_fetch_assoc($result);

// Prikazivanje podataka profila
echo "Ime: " . $user['name'];
echo "Email: " . $user['email'];
?>

U ovom primeru, korisnik može promeniti vrednost identifikatora `userId` u URL-u kako bi pristupio profilima drugih korisnika.

Prevencija IDOR napada

• Pravilna autorizacija i ovlašćenje: Aplikacija treba da sprovede adekvatne provere ovlašćenja kako bi osigurala da korisnik ima dozvolu za pristup određenom objektu ili resursu.
• Indirektno mapiranje: Koristite indirektno mapiranje identifikatora objekata na interne identifikatore koji se ne mogu lako pogoditi ili pretpostaviti. Na taj način, napadač će imati teže vreme pristupa drugim objektima.
• Dobar dizajn URL-ova: Izbegavajte otkrivanje internih identifikatora objekata u URL-ovima, posebno kada su osetljivi podaci u pitanju. Umesto toga, koristite pseudoslučajne ili nasumično generisane identifikatore objekata.
• Redovno testiranje: Redovno testirajte aplikaciju na IDOR ranjivosti kako biste identifikovali i ispravili potencijalne propuste.

Primer koda za zaštitu od IDOR napada

Zaštita od IDOR napada zahteva pravilnu autorizaciju i ovlašćenje prilikom pristupa objektima ili resursima. Evo jednog primerka koda koji ilustruje kako možete poboljšati sigurnost aplikacije:

<?php
session_start();

// Provera da li je korisnik autorizovan
if (!isset($_SESSION['userId'])) {
// Korisnik nije prijavljen, preusmeravanje na stranicu za prijavu
header("Location: login.php");
exit;
}

// Prikazivanje profila samo za prijavljenog korisnika
$userId = $_SESSION['userId'];
$query = "SELECT * FROM users WHERE id = $userId";
$result = mysqli_query($connection, $query);
$user = mysqli_fetch_assoc($result);

// Prikazivanje podataka profila
echo "Ime: " . $user['name'];
echo "Email: " . $user['email'];
?>

U ovom primeru, koristimo sesiju za čuvanje identifikatora prijavljenog korisnika (`$_SESSION['userId']`). Pre pristupa profilu, proveravamo da li je korisnik autorizovan tako što proveravamo postojanje identifikatora korisnika u sesiji. Ako korisnik nije prijavljen, preusmeravamo ga na stranicu za prijavu.

XML External Entity (XXE) Injection ranjivost

XML External Entity (XXE) Injection je sigurnosna ranjivost koja se javlja kada se napadač može iskoristiti za obradu eksternih entiteta u XML dokumentima. Ova ranjivost omogućava napadaču da izvršava udaljeni kod ili da pristupa osetljivim podacima na serveru.

Kako XXE Injection napad funkcioniše

XXE Injection se dešava kada napadač ubaci zlonamerni eksterni entitet u XML dokument, koji se zatim obrađuje od strane XML parsera. Eksterni entitet može biti referenca na spoljni resurs, kao što je datoteka, mrežni resurs ili sistemski resurs.Ako aplikacija ne pravilno konfiguriše XML parser, napadač može iskoristiti ove eksterne entitete za izvršavanje proizvoljnog koda na serveru ili za otkrivanje osetljivih podataka.

Primer XXE Injection napada

Pretpostavimo da imate web aplikaciju koja obrađuje XML podatke. U sledećem primeru, napadač ubacuje zlonamerni eksterni entitet koji omogućava pristup osetljivim datotekama:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<data>&xxe;</data>

U ovom primeru, napadač ubacuje eksterni entitet `&xxe;` koji referencira sistemsku datoteku `/etc/passwd`. Kada se ovaj XML dokument obradi, aplikacija može dozvoliti pristup sadržaju `/etc/passwd` datoteke i vratiti ga napadaču.

Prevencija XXE Injection napada

• Isključivanje ili ograničavanje eksternih entiteta: Konfigurišite XML parser tako da isključi ili ograniči upotrebu eksternih entiteta. Na taj način, napadač neće moći da ubaci zlonamerni kod putem eksternih entiteta.
• Upotreba bezbednih biblioteka ili funkcija: Koristite biblioteke ili funkcije za obradu XML-a koje su dizajnirane da budu sigurne protiv XXE Injection napada. Na primer, koristite SAX parser sa isključenom podrškom za eksterne entitete.
• Validacija korisničkog unosa: Pravilno validirajte korisnički unos kako biste sprečili ubacivanje zlonamernog XML koda koji sadrži eksterne entitete.
• Bezbedna konfiguracija parsera: Konfigurišite XML parser tako da bude siguran i isključite sve funkcionalnosti koje nisu potrebne za vašu aplikaciju.
• Sandboxing: Izolujte proces obrade XML-a u sigurnom okruženju kako biste ograničili potencijalne štete ako dođe do uspešnog XXE Injection napada.

Prevencija XXE Injection napada zahteva pažljivu konfiguraciju XML parsera, pravilnu validaciju korisničkog unosa i korišćenje bezbednih biblioteka ili funkcija za obradu XML-a.

Primer koda za zaštitu od XXE Injection napada

Zaštita od XXE Injection napada uključuje isključivanje ili ograničavanje upotrebe eksternih entiteta i pravilnu validaciju korisničkog unosa. Evo jednog primerka koda koji ilustruje kako možete poboljšati sigurnost aplikacije:

<?php
// Konfiguracija XML parsera
$dom = new DOMDocument();
$dom->loadXML($xml); // $xml predstavlja XML podatke od korisnika

// Isključivanje podrške za eksterne entitete
libxml_disable_entity_loader(true);

// Validacija korisničkog unosa i obrada XML podataka
// ...

// Daljnja obrada podataka
// ...
?>

U ovom primeru, koristimo `libxml_disable_entity_loader(true)` kako bismo isključili podršku za eksterne entitete u XML parseru. Ovo onemogućava napadaču da iskoristi eksterne entitete za izvršavanje zlonamernog koda ili pristup osetljivim podacima.

Za dodatne mere zaštite od XXE Injection-a potrebno je primeniti i sledeće metode:

• Validacija korisničkog unosa: Pravilno validirajte korisnički unesene XML podatke kako biste osigurali da ne sadrže zlonamerni kod ili reference na eksterne entitete.
• Korišćenje bezbednih XML parsera: Koristite biblioteke ili funkcije za obradu XML-a koje su dizajnirane da budu sigurne protiv XXE Injection napada, kao što je SimpleXML sa isključenom podrškom za eksterne entitete.
• Bezbedna konfiguracija parsera: Konfigurišite XML parser tako da bude siguran i isključite sve funkcionalnosti koje nisu potrebne za vašu aplikaciju.
• Sandboxing: Izolujte proces obrade XML-a u sigurnom okruženju kako biste ograničili potencijalne štete ako dođe do uspešnog XXE Injection napada.

Server-Side Request Forgery (SSRF) ranjivost

Server-Side Request Forgery (SSRF) je sigurnosna ranjivost koja se javlja kada napadač može izvršiti zahtev na drugi server putem ciljne web aplikacije. Ova ranjivost omogućava napadaču da izvršava zahteve unutar interne mreže ili drugim eksternim serverima na koje ima pristup.

Ovde možemo ukratko opisati kako SSRF napad funkcioniše:

• Korisnički unos: Napadač ili korisnik daje neki unos u obliku URL-a ili IP adrese putem web aplikacije.
• Server obrađuje korisnički unos: Web aplikacija na serverskoj strani prihvata korisnički unos i prosleđuje ga na dalju obradu.
• Manipulacija korisničkim unosom: Napadač manipuliše unosom kako bi izvršio zahtev na drugi ciljni server. Manipulacija može uključivati dodavanje specijalnih oznaka ili promenu URL-a kako bi se postigao željeni rezultat.
• Izvršavanje zahteva na ciljni server: Web aplikacija izvršava zahtev na ciljni server koristeći podatke iz korisničkog unosa. Zahtev može biti HTTP GET ili POST, FTP, DNS ili lokalni zahtev.
• Povratna informacija od ciljnog servera: Ciljni server obrađuje zahtev i vraća odgovor na veb aplikaciju.
• Rezultat obrade: Web aplikacija zatim obrađuje odgovor od ciljnog servera i može prikazati odgovarajuće informacije ili ih koristiti za daljnju obradu.

Primer SSRF napada

Pretpostavimo da imate web aplikaciju koja dozvoljava korisniku da unese URL za preuzimanje sadržaja i prikazuje ga na web stranici. U sledećem primeru, napadač može iskoristiti SSRF ranjivost kako bi izvršio zahtev na lokalnom serveru i dobio osetljive informacije:

<?php
// Unos URL-a od strane korisnika
$url = $_GET['url'];

// Izvršavanje zahteva
$content = file_get_contents($url);

// Prikazivanje sadržaja
echo $content;
?>

U ovom primeru, napadač može proslediti URL koji referencira lokalnu IP adresu ili interni server unutar mreže. Aplikacija će izvršiti zahtev na taj ciljni server i dobiti sadržaj koji će biti prikazan na web stranici.

Prevencija SSRF napada se može raditi pomoću sledećih metoda:

• Validacija korisničkog unosa: Pravilno validirajte i filtrirajte korisnički unos kako biste osigurali da sadrži samo dozvoljene URL-ove ili IP adrese. Ograničite dozvoljene domene ili IP opsege za zahteve.
• Bela lista (whitelist) dozvoljenih resursa: Ograničite dozvoljene URL-ove ili IP adrese na koje korisnik može izvršavati zahteve. Koristite belu listu resursa umesto crne liste (blacklist) kako biste bili sigurni da samo odabrani resursi mogu biti cilj zahteva.
• Izolacija mreže: Održavajte strogu mrežnu infrastrukturu koja minimizuje mogućnost pristupa internim resursima ili serverima iz spoljašnjeg okruženja.
• Ograničenje pristupa resursima: Konfigurišite vatrozid i mrežnu infrastrukturu kako biste ograničili pristup resursima unutar interne mreže samo na neophodne i pouzdane izvore.
• Kontrola dozvola i autorizacija: Primenite stroge kontrole dozvola i autorizacije na ciljnim serverima kako biste ograničili pristup osetljivim informacijama ili funkcionalnostima.

Prevencija SSRF napada uključuje pravilnu validaciju korisničkog unosa, ograničavanje dozvoljenih resursa, izolaciju mreže i primenu stroge kontrole dozvola i autorizacije.
Zaštita od Server-Side Request Forgery (SSRF) napada zahteva kombinaciju pravilne validacije korisničkog unosa i implementaciju sigurnosnih mera na serverskoj strani.

Evo jednog primera koda za zaštitu aplikacije od SSRF napada:

<?php
// Unos URL-a od strane korisnika
$url = $_GET['url'];

// Validacija korisničkog unosa
if (!filter_var($url, FILTER_VALIDATE_URL)) {
// Nevalidan URL, prekid obrade ili prikazivanje greške
die("Nevalidan URL");
}

// Provera dozvoljenih domena ili IP opsega
$allowedDomains = array("example.com", "trusteddomain.com");
$parsedUrl = parse_url($url);
if (!in_array($parsedUrl['host'], $allowedDomains)) {
// Nedozvoljen ciljni server, prekid obrade ili prikazivanje greške
die("Nedozvoljen ciljni server");
}

// Izvršavanje zahteva
$content = file_get_contents($url);

// Prikazivanje sadržaja
echo $content;
?>

U ovom primeru, koristimo `filter_var` funkciju sa `FILTER_VALIDATE_URL` filterom kako bismo validirali da li je korisnički unos ispravan URL. Ako URL nije validan, možete prekinuti dalju obradu ili prikazati odgovarajuću grešku.

Takođe, proveravamo da li ciljni server (host) pripada dozvoljenim domenima ili IP opsezima. Možete definisati listu dozvoljenih domena u `$allowedDomains` nizu. Ako ciljni server nije uključen u listu dozvoljenih domena, možete prekinuti obradu ili prikazati grešku.

Zaključak

Zaštita PHP aplikacija od potencijalnih sigurnosnih pretnji izuzetno je važna kako bi se osigurala bezbednost podataka i funkcionalnost aplikacije. U ovom tekstu smo prikazali nekoliko ključnih aspekata zaštite PHP aplikacija i pružili smernice za njihovu implementaciju.

Uz navedene smernice, važno je imati na umu da sigurnost PHP aplikacija nije statičan proces i zahteva stalnu pažnju i nadogradnju. Redovno ažuriranje i testiranje sigurnosti PHP aplikacija ključni su elementi zaštite od novih sigurnosnih pretnji.

Kombinacija svih ovih mera zaštite pomoći će u stvaranju sigurnih PHP aplikacija koje su otpornije na napade i štite osetljive podatke. Uz dosledno pridržavanje najboljih praksi sigurnosti, možete smanjiti rizik od sigurnosnih propusta i očuvati integritet svojih PHP aplikacija.