» »

PHP sessions

PHP sessions

rokpok ::

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...
Rad bi bil pingvin.

MasterBlaster ::

IP se tudi ne sme spremeniti.
Tk je pa pika .

rokpok ::

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.
Rad bi bil pingvin.

SFfreak ::

Preverjaj vse, kar lahko: IP, User-agent, SID, generiraj še svoj SID in ga zakodiraj s crypt(), priporočljivo pa je, da še vsebino sessiona (malce spremenjeno) skopiraš v cookie in potem primerjaš...

mte ::

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

SFfreak ::

Zgodovina sprememb…

  • spremenil: SFfreak ()

rokpok ::

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?
Rad bi bil pingvin.

MasterBlaster ::

Dodatni cookie pride v poštev le pri SSL povezavi. Tu lahko označiš cookie kot secure, kar pomeni, da ga bo browser poslal le preko SSL povezave. S tem preprečiš, da bi ga morebitni napadalec prestregel.
Tk je pa pika .

mte ::

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

rokpok ::

(da ne bom odpiral nove teme). Navada je, da nikoli ne zaupaš podatkom, ki ti jih poda uporabnik. Kakšna pa je meja, do katere moraš zaupati vase? Primer: imamo datoteko, v kateri so naštete datoteke, ki jih kasneje vključimo v php skripto.

config datoteka:

nekaj.php
nekaj2.php
...

Kako zdaj vključiš te datoteke?

1) require_once (...)
2) if datoteka obstaja potem require_once (...)

Moje mnenje je, da lahko narediš tako, kot je napisano pod 1), zato ker se v obeh primerih mora sprožiti error. Pri prvem primeru, ga sproži PHP, v drugem primeru pa ga sproži programer pod else stavkom.

Lp
Rad bi bil pingvin.

Ziga Dolhar ::

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
https://dolhar.si/

rokpok ::

Ziggga: falil bistvo vprašanja. Vem, kaj je razlika med require in include. Podal sem samo primer, da bi lažje razumeli kaj želim povedati. Pustiti PHP-ju da sproži error ali pa ga sprožiti sam?

Glede zaupanja uporabniko pa so mi stvari jasne. Vseeno hvala za link. (še vedno čakam kakšen odgovor na prvo vprašanje).

Lp
Rad bi bil pingvin.

Ziga Dolhar ::

Č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.)
https://dolhar.si/

rokpok ::

To je res, vendar vse 3 točke se da odpraviti z error-handlerjem (razen če gre za fatal/core error). Uporabniku se prikaže prijazno sporočilo, error pa se zabeleži v loge in pošlje na mail.
Rad bi bil pingvin.

Ziga Dolhar ::

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.)
https://dolhar.si/

rokpok ::

Se opravičujem. Sploh nisem opazil, da se je debata oddaljevala od postavljenega vprašanja. V takšnih primerih, kot si ga podal (Ziggga), mi je jasno, da je preverjanje nujno.

Bom pa še enkrat razložil vprašanje. Imaš dve datoteki: index.php in config.php. Za obe datoteki, si prepričan da obstajata, saj si ju ustvaril sam. Sedaj pa moraš datoteko config.php vključiti v datoteko index.php. Kako boš to naredil?

1) Boš vseeno preveril, če datoteka config.php obstaja in upošteval minimalne možnosti, da je kdo izbrisal datoteko?
2) Boš samo vključil datoteko?

Podobnih situacij je še veliko.
Rad bi bil pingvin.

Ziga Dolhar ::

Č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.)
https://dolhar.si/

rokpok ::

Pa sva se našla. :D Tudi jaz v takih primerih ne preverjam, če datoteka obstaja ali ne. Razmišljam pa o tem, če bi ali ne, zato me zanimajo mnenja drugih o tem. Saj vem, da je verjetno še kar nekaj drugih bolj pomembnih stvari (ki sem jih mogoče kje spregledal), ampak vseeno.

Se še enkrat opravičujem, ker sem tudi jaz debato potegnil v napačno smer.
Rad bi bil pingvin.

Ziga Dolhar ::

(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 :).)
https://dolhar.si/

rokpok ::

Velikokrat videno >:D . Nevem no. Možnosti, da ta datoteka ne obstaja so zelo zelo majhne in če se enkrat odločim, da grem preverjat vse najmanjše stvari (tudi druge podobne), potem je to kar precej več kode. Je pa res, da pa možnost vedno obstaja, samo do kakšne meje jo upoštevati.?
Rad bi bil pingvin.


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Blokiranje piškotkov v wp-config.php

Oddelek: Izdelava spletišč
6709 (509) Manager
»

PHP include(); problem

Oddelek: Programiranje
10916 (705) DuleKrtola
»

php skripta za registracijo uporabnikov

Oddelek: Izdelava spletišč
161990 (1571) skorpio
»

[PHP] napake, napake...

Oddelek: Izdelava spletišč
7998 (847) medobear
»

Podatkovne baze in PHP

Oddelek: Izdelava spletišč
6987 (863) Iztirjenec

Več podobnih tem