Blad jest od zawsze ten sam i to bez wzgledu czy to php czy c czy inny jezyk.
Mianowicie najwieksze zlo pochodzi od uzytkownika tak wiec kazda wartosc
na ktora moze miec wplyw, czyli pochodzi od niego.. i nie mowie tu tylko o tak
oczywistych sprawach jak zmienne z GET, POST ale rowniez ciasteczek i wszystkiego
innego co przy odrobinie checi mozna ustawic samodzielnie MUSI BYC SPRAWDZONE.
Czy wartosc OCZEKIWANA jest wartoscia WPROWADZONA. Czy &id= strony to liczba
czy moze zapytanie SQLa, czy includowany plik z &file= to faktycznie plik znajdujacy sie
w okreslonym z gory katalogu, bez %00, http://, ../ i tego typu ciagow w nazwie.
Najlepiej ustalic jedno miejsce z ktorego bedziemy pobierac wszystko od uzytkownika.
Jakas warstwa posredniczaca - bardzo latwo napisac taka klase.
Z liczbami nie ma wiekszego klopotu, zzazwyczaj wystarczy rzutowanie $id = (int) $_GET['id'].
Warto sprawdzic jeszcze logike np. czy > 0 itd ale to juz takie grozne nie jest. W przypadku stringow
warto uzywac mysql_real_escape, testowac pod wzgledem niebezpiecznych sekwencji ktore mogly by
zaszkodzic z perspektywy skrypty.
ps. dobrym nawykiem IMHO w zapytaniach SQLa jest stosowanie " " do liczb. Czasem spotykam kod
gdzie programista wyszedl z zalozenia, ze skoro poruwnuje liczbe w zapytaniu np. SELECT * FROM tabela
WHERE id = $zmienna nie musi pisac WHERE id = "$zmienna". Jest to prawda, zapytanie bedzie dzialac ale
ryzyko jest takie, ze jesli nie sprawdza czy liczba faktycznie jest liczba pomimo zastepowania " na rzecz \"
wciaz jest narazony poniewaz hax04 nie musi uciekac z " " poniewaz ich tam wcale nie ma

poprostu wykonuje
zastrzyk z wlasnego kodu wprost w serce aplikacji

Ogolnie mowiac - nie wierzyc uzytkownikowi bo to najwieksze zlo i dno