GET típusú lekérdezések és a biztonság

Internet: PHP, CGI, stb.

Hello! Hogyan lehetne rávenni a böngészőt, hogy kipucolja a history-t vagy hogy ne is rögzítse? GET-es módszerrel adom át a felhasználónevet+jelszóhasht az oldalakon belül, de az a baj, hogy ha valaki visszamegy a historyban akkor be tud lépni.
Illetve, ha a kép már törölve van, de az adatlapját kiválasztja, akkor az is egy szép kis PHP hibát csinál... (mondjuk az ellen véd egy sima if is)

  • 2030 megtekintés

( Ajnasz v | 2006. 02. 19., v – 22:57 )

Gettel nem küldünk felhasználónevet és jelszót.
Ha a scriptben valami miatt hiba keletkezik, akkor azt meg lekezeljük.

( wlaszi | 2006. 02. 19., v – 23:33 )

erre (is) találták ki a session-t, és a session változót...

( skynetpro | 2006. 02. 20., h – 09:00 )

OK, de sessiont hogyan???

A GET egyszerű, mert az url végére rábiggyesztem és kész. POST-tal ugyanezt nem lehet... csak az kellene, hogy ne tárolja a historyt... vagy csak egy lapot tároljon. azt meg iframe-mel lehetne, de ez necces...

POST-al is lehet változót utaztatni (pl:

input type="hidden" name="news_date" value="1997"

), de jelszót sosem szoktak!

amúgy meg lásd php.net: session_start(); blabla session_unset(); session_destroy();

Ám még ezzel sem jó a jelszót küldözgetni! Én pl úgy csinálom, hogy a loginnál létrehozok egy sessiont, belerakom változóként a usernevet meg a hozzátartozó jogosultságot + egy hash-t ami plusszban azonosítja a klienst. Tehát a sessionön belül már csak a jogosultságot vizsgálom, és a user is csak arra kell, hogy ha gebasz van, akkor tudjam kinek a nevét postolni az error logba.
De a net tele van php login howto-kkal...

ahogy mondod...de asszem írtam, hogy nem szokás :)
Nyílván csak olyat POST-ol, amit épeszű ember nem haxol meg (pl saját mailcím megadása) arról nem is beszélve, hogy a POST-ot fogadó php úgyse fut le ha nincs meg a sessionváltozóban a megfelelő jogosultság... legalábbis jobbelyeken :)

Saját session irása valami sql vagy egyszerű dbm backenddel vagy a beépített $_SESSION, ami elég jól le van vezetve a php manualban. Az minden esetre alapvető, hogy a kliensed csak valami hash-t tároljon, amivel azonositja magát és mást ne. Ha nagyon ki akarja valaki kerülni, akkor valahogy úgyis szerez egy megfelelő sessionid-t szóval az ilyentől alapvetően fölösleges pánikolni. Ha annyira fontos oldalak, akkor egy HTTPS kell, az segit valamennyire.

A historyval nemtom mi a bajod, egyébként szerintem javascripttel ki lehet radirozni, de baromira sikideg lennék, ha egy megnézett site variálna.

( gsimon | 2006. 02. 20., h – 09:52 )

És a POST is csak akkor jó valamire, ha https-en át megy, különben kétféle ember is lesniffelheti a drótról: boldog és boldogtalan :)...

( 1aca | 2006. 02. 20., h – 14:09 )

Egy par otlet:
- login HTTPS-en, session id-t generalsz, majd atiranyitod HTTP-re (ezt csak akkor, ha nagy a forgalmad, egyebkent hagyd HTTPS-en), vegen logout
- leszedsz valahonnan egy javascript md5/sha implementaciot, es mikor valaki lekeri a "login oldal"-t, generalsz egy random valamit, amit a kliens osszehash-el a passworddal es ugy kuldi el (igy nem lehet megismetelni)