PHP sessions

Imam eno vprašanje. Na katere stvari se je varno zanašati pri preverjanju session-ov (preprečevanju zlorab)? Sam trenutno uporabljam samo preverjanje user-agent-a...

Pri IP-ju pride do problemov pri raznih proxy-ih. Pa koliko sem bral o tem, so si dokaj enotni, da naj se ip nebi uporabljal.

publikum: ko smo ravno pri tem - a mogoče veš za kakšen dober tutorial ki bi to opisoval? Lahko je tudi kakšna knjiga, vendar ker se s tem zaenkrat ne nameravam ukvarjati profesionalno bi rad da je to opisano na čimkrajši način, ljudsko in razumljivo.
hvala,
matej

1) Za IP sem napisal, kako je
2) User-agent preverjam
3) Session ID itak
4) Zakaj pa bi generiral še en ID? (Če napadalec dobi enega, bo tudi drugega dobil z lahkoto.?) Kopiranje same vsebine v cookie pa se mi ne zdi smiselno.

Sem kje zgrešil kako bistvo?

publikum, mislim da sva se slabo razumela - rabil sem nekaj o preverjanju vseh teh stvari ki si omenil, tisti tutorial pa je le o sessionih splošno in sem ga tudi že prej videl (edini tak tutorial ki sem ga takoj razumel!).
Ali je to le tako enostavno da na začetku vsake skripte (za session_start()) pač pregledaš user-agent, ip in sid ter jih primerjaš s tistimi ki sem jih prej takoj po prijavi spravil v določene spremenljivke?
No pa tudi mene potem zanima tisto o generiranju lastnega sida...
hvala še enkrat,
matej

sleepy_net: obstaja razlika med "require" in "include", še posebej pa med preverjanjem, ali datoteka sploh obstaja (file_exists). Glede samega "zaupanja uporabniku" pa si poglej en star xbiteov članek: Varnost v PHPju

Če se ceniš, sprožiš error sam. Zakaj?

a) Ker PHP errorji niso namenjeni uporabniku-obiskovalcu, ampak developerju: "Dragi uporabnik, članek žal ni na voljo; preverite bla bla bla ..." je nekako bolj zgovoren kot "_prepareobject(common/news/catalog.class.php): failed to open stream: No such file or directory".
b) "Nepredvidljivost": kaj se bo zgodilo s stranjo oz. njenim izgledom? Require ti bo prekinil izvajanje skripte, include ne; ti je vseeno?
c) Prikazovanje PHP errorjev: je odvisno od nastavitve strežnika: se sploh prikaže ali ne? Izgled? Plain text, ali morda html? Celo z linkom na dokumentacijo? (Zopet: beri točko A.)

Lej,

PHP errorji so namenjeni napakam, do katerih pride ob izvajanju skripte; ne pa napakam, ki so posledica neke "normalne" uporabe spletne strani. In PHP errorji ti ne omogočajo zadostnega nadzora in vplivanja na vsebino sporočila, ki ga boš prikazal uporabniku.

(Primer: nekje v skripti izvedeš $a/$b, kjer je uporabnik za $b vnesel 0. Zdej, "Division by zero" ne bo dobro sporočilo; lahko ga spremeniš v "Deljenje z ničlo", morda celo "Prosim, vnesite pozitivno vrednost" [ampak to je generično sporočilo, ki bi ga bilo dobro uporabniku prilagodit -- omenit polje, kontekst ...]; kako boš dalje kontroliral izvajanje skripte? Ne moreš. Če gre za notice, se nadaljne računske operacije še kar izvajajo, kot da ni nič, če za fatal error, se prekine z nedokončanim izpisovanjem. Razen, če prej pogledaš [if(intval($b) === 0)] in uporabnika opozoriš, mu poveš točno kje in kaj je zajebal, prekineš izvajanje izračuna, a dokončaš izpis strani.)

Če gre za datoteko, za katero sem prepričan, da obstaja ("config.php" mi že deluje kot temeljni pogoj za kakršnokoli pametno delovanje same aplikacije), potem [v praksi] še nikoli nisem preverjal njenega obstoja. Morda bi bilo pametno, ampak se s tem še nisem ukvarjal :-). [Je pa verjetno res, da ti brez te datoteke stran sploh ne bo delala, ne? V okviru tega presodi, kakšno sporočilo (če sploh) boš prikazal. Causa cognita.]

(Nasprotno pa bi redno preveril obstoj datoteke, kadar na to lahko vpliva uporabnik: npr. article?id=bla vstavi datoteko bla.html. Jaz sem v prejšnjih postih odgovarjal s tega vidika, da.)

(Vsekakor bi blo lepše, če bi se ob neobstoju ključne datoteke izpisalo nekaj v stilu "Dragi obiskovalec, stran ima trenutno tehnične težave, se vidimo kasneje", kot pa nek portal s polno mysql errorji :).)