Vazno je da ne prenosis neke vazne podatek tipa password ili slicno i da dobijene get podatke ne koristis direktno u upitima jer tako najcesce dolazi do hakovanja

Get podaci se mogu naci u linkovima, pa time i u server logovima i rezultatima pretrage. Sigurnost je, znaci, nikakva. Sto se provere tih podataka tice budi pazljiv da potpuno iskljucis mogucnost SQL injectiona. U principu, najlakse je sve cemu ne odgovaras u skripti odgovoriti 404 stranicom bez konektovanja na bazu.

A čekaj, u ovom slučaju kada svi $GET podaci prođu kroz petlju, oni su provereni, i ja ih mogu koristiti dalje(direktno u upitima) jer bi se u suprotnom zaustavilo izvršavanje skripte sa komandom die().
Znači prvi kod u php-u je:

i ako su svi $GET podaci tačni odnosno u ovom mom slučaju 0-9.a-z,A-Z,_,- onda ja bez problema mogu napisati

Znači koristio sam direktno $GET ali sam ga pre toga proverio. Ako bilo koji $GET sadrži karakter koji nisam dozvolio skripta će se završiti pre nego što dođe do echo-a. To sam hteo da pitam, da li sam se tako u potpunosti zaštitio od hakovanja preko get-a. Naravno pod uslovom da ne šaljem šifre preko $GET-a.


Pa zar je moguće doći do SQL injectiona ako $GET podaci prođu ovu moju prvu proveru? Kontam da treba da obratim pažnju na proveru podataka koji se šalju preko nekog INPUT-a ali to neće biti slučaj u ovom mom primeru. Znači šaljem samo neke promenljive koje nemaju veze sa nekim formama. Ako znači neko pošalje nešto što sadrži ',? ili < to neće proći prvu proveru u foreach-u i neće moći doći do moguće konekcije na bazu itd.

Taj preg_match te nikako ne zasticuje. Od toga jos moze da se uradi nesto sto ne bi zeleo.

Koristi stvari kao sto su: http://www.php.net/manual/en/book.filter.php http://www.php.net/manual/en/function.strip-tags.php http://www.php.net/manual/en/function.addslashes.php http://www.php.net/manual/en/function.stripslashes.php

Hm, a ja mislio da koristim ovaj preg umesto ovih silnih f-ja. Jel znaš možda neki primer gde preg_match neće valjati kako bih skontao u čemu je problem kod njega?

Pa dobro, ako ti nekim regularnim izrazom nekome zabraniš da unosi znake navoda, npr. neki reg exp za email, nikad neće proći ta tvoja server side validacija, ako neko pokuša da u to polje za email upiše znak navoda.

Ali npr. u polje za neki tekst, recimo za neki guestbook ili tako nešto, glupo je da nekome zabraniš da unosi znake navoda, i tu već moraš da escape-uješ unos. Takođe, tu moraš da misliš i na to da u tekstulano polje neko može da unese neke HTML tag-ove, koji, kad budeš prikazivao sadržaj toga što je korisnik uneo, mogu da ti poremete izgled sajta (npr. neko unese zatvoren div tag, itd.). Za te svrhe se obično koristi f-ja htmlspecialchars.

Ili, kod neke autentifikacije korisnika, dobro poznata stvar je SQL Injection, a od toga se obično "štitiš" tako što vrednosti iz polja za username i password escape-uješ f-jom mysql_real_escape_string.

E pa super onda. Svestan sam ja da sa ovim reg. izrazom ne bi trebao da štitim podatke koje su poslate preko forme. Ovo će mi služiti za posebne podatke koji moraju biti striktno zadani onako kako ja želim i njih neće unositi korisnik već ja odnosno url će ih sam koristiti za prepoznavanje onoga šta treba da prikaže na toj stranici. Ja ću sam određivati imena u akcijama, pa mi je dovoljno da imam samo brojeve, slova, - i _. Pa sam pomislio ako neko pokuša taj link da promeni, pa zato da pitam da li će ovo biti dovoljno da mu ne dozvoli pristup ako link nije po defaultu kako sam ga napisao.
Ako url prođe proveru biće znači nešto ovako:

Pa dobro, ja sam izgleda pogrešno protumačio poruke na ovoj temi, jer sam mislio da ti hoćeš da "braniš" od nekih korisnikovih unosa, koji bi se upisivali u bazu.

Ovo što ti hoćeš nema veze s tim, već samo sa prikazom sadržaja na strani u zavisnosti od akcije. I tu nema potrebe da radiš neke posebne provere, jer ako korisnik sam ukuca neku akciju koja ne postoji, ništa mu se neće ni prikazati.

Npr. ako imaš ovakvu situaciju:

... sad kad korisnik unese neku akciju koja nije definisana, ništa mu neće biti prikazano, odnosno, u ovom mom primeru, izvršiće se ovaj default slučaj...

Da, da... U pravu si. Za include mi ne trebaju ovakve provere. Ja sam nešto umoran danas pa mi stao mozak..:)
Hvala na pomoći!