Nemas bas neki veliki izbor u nekim situacijama, sem da pravis POST forme, ali ti, iskreno, dodje na isto sa stanovista sigurnosti.
Poenta je da handlujes svaku promenjivu, svaki request. Jer ti uvek znas kakve podatke ocekujes, i ti onda samo odradis proveru da li dobijas takve podatke i eventualno odradis neke konverzije.

Na primer. Imas ID koji saljes preko url-a. On je integer tipa.


Ovako ces se osiguras da je to uvek integer, bez obzira sta neko poslao. Naravno, ovde mozes da napravis daleko komplikovanije provere po potrebi.

Ali, opet da napomenem, jako je bitno da handlujes svaku promenjivu.
Ja, na primer, ne koristim nikad $_GET, $_POST ili $_REQUEST. Imam svoju klasu TRequest, koja ima funkcije getGet, getPost i getRequest. I onda u okviru tih funkcija radim handlovanje, ali na osnovu prefixa. Meni sve promenjive iz requesta imaju prefix, na primer: int_ str_ txt_ dec_
Naravno, ovde moze se naprave jos bolji sistemi preko prefixa, Da proveravas da duzinu stringa, da li je obavezna promenjiva ili ne. Dosta toga.

Drugi nacin je da napravis fitter na ulazu u celu aplikaciju, koja pre nego sto pocnes da bilo sta radis i koristis request, automatski obradi kompletan request, po odgovarajucim pravilima.




_{[Ovu poruku je menjao flylord dana 17.11.2006. u 17:57 GMT+1]}

A zasto mislis da je to lose i nesigurno resenje ???

Pa lose "Nesigurno" je onda i samo onda kad to programer odradi traljavo...

Poz
sale

Apsulutno.
Moze samo da postoji bar bugova koji se nalaze u samom phpu medjutim, bugovi u skripti su propusti developera.
Sad, ne kazem ja da skripta moze biti 100% bez bugova ali se to moze smanjiti na sto manji broj ...

To sa stranom je loše ako (na primer) napraviš ovako nešto:


Pogledaj sajt www.phpsec.org, a posebno obrati pažnju na http://phpsec.org/projects/guide/

p0z

I ako aplikacija radi sa bazom obavezno provera za ulazne podatke preko forme (injection).
addslashes, mysql_real_escape_string ...