ugrás a tartalomhoz

saját php session engine

ErdosJ · 2007. Júl. 23. (H), 09.38
sziaisztok
nekialltam egy portalos-bejelentkezos oldalnak, a kulcsin tobbnyire mar keszen is van, most allnek neki a bejelentkezes resznek. az alap otlet a php beepitett session fuctionjainak a hasznalata volt, de azt nem tartom ebben az esetben tul gyorsnak/biztonsagosnak, es kulonben is csak arra kellene, hogy a bejelentkezest leellenorizzem..
az en otletem az volt, hogy egy adatbazisban a felhasznalok tablajaban csinalok egy sessionId mezot, ami egy szamot tartalmaz. amikor a felhasznalo bejelentkezik, vagy egy uj oldalra lep, ez a szam mindig ujrageneralodik (random), visszaadodik az oldalnak, az pedig a tovabbi oldalak betoltesenel (ajax) postolja a sessionId-t, amit a betoltott oldal leellenoriz, ujrageneral, es minden kezdodik elorol. esetleg uj oldal betoltesenel nezhetne a legregebbi oldalbetoltes idopontjat... igy talan a tobbszoros bejelentkezest is ki lehetne szurni, sot, azt is, hogy az adatforgalmat figyelve valaki sessionId-t lophasson.
mit gondoltok, erdemes igy csinalni, vagy nagy hulyeseg az egesz?
‹ DB fejlesztés csapatban Táblák száma egy adatbázisban ›
 ■
1

Bejelentkezés vs session

janoszen · 2007. Júl. 23. (H), 10.10
Asszem itt kavarod egy kicsit a dolgokat. A session != bejelentkezés. A bejelentkezés a sessionre épül.

Ami a sessionlopást illeti, nem csak ilyen veszélyek vannak, hanem egészen mások is. Csinálhatsz pl IP azonosítást, felhasználószám-figyelést, stb de végeredményben mégis csak oda fogsz kilyukadni, hogy a felhasználóidat is képezni kell.
4

...

ErdosJ · 2007. Júl. 23. (H), 10.32
nem kavarom, hasznaltam mar sessiont, alap szinten tudom, mi az. viszont nem szeretnek agyuval verebre loni. es eppen ebben kertem a segitsegeteket.
az ip azonositas dolog nem teljesen vilagos... ugy tudom, hogy ip-t lehet valtoztatni, engem pedig baromira zavarna, ha az oldal tiz percenkent kidobna..
a felhasznaloszam-figyeles meg micsoda? hogyan jon a bejelentkezeshez?
8

Felhasználószám

janoszen · 2007. Júl. 23. (H), 11.28
Tfh. egy felhasználó bejelentkezik egy munkamenetben, letárolod a munkamenet azonosítót, majd ha máshol bejelentkezik automatikusan kidobod a másik munkamenetben és ezt közlöd vele...

Ami az IP-t illeti, ezért van ott a pipa sok helyen, hogy IP cím ellenőrzés nélkül.
2

feltaláljuk újra a kereket?

zila · 2007. Júl. 23. (H), 10.27
Szerinted érdemes újra feltalálni a kereket? Hogyan mérted ki a php session kezelésének lassúságát? Mitől nem biztonságos a php session kezelése?

Abban látok rációt, hogy a session-t adatbázisban tárolod. Ettől még persze a php session kezelését fogod használni... A sessionid újragenerálása sem rossz ötlet, de ha nem https-en viszed a forgalmat, akkor az adatforgalomat figyelő gonosz az új sessionid-t is megszerzi... sőt, már a usernév és jelszó is birtokába kerül, így teljesen felesleges neki session-t lopni, hiszen megvan a login...
5

nnademegismiert?

ErdosJ · 2007. Júl. 23. (H), 10.36
>sőt, már a usernév és jelszó is birtokába kerül, így teljesen felesleges neki session-t lopni, hiszen megvan a
>login...
mar megis miert? hiszen en mindig csak az ujrageneralt sessionId-t es a felhasznalonevet kuldenem tovabb a lehivott oldalaknak, a jelszo az adatbazisban fog csucsulni, termeszetesen md5-ben.
6

forgalom figyelés

zila · 2007. Júl. 23. (H), 10.41
Ha valaki figyeli a forgalmat akkor elkapja a bejelentkezést amikor a user az űrlapot elküldi a szervernek. Ezt valamikor meg kell tennie nem?
Mivel http kapcsolat nem titkosított a jelszó sima szövegként megy a szervernek.
10

..

ErdosJ · 2007. Júl. 23. (H), 11.57
jo, jo, de ez normal sessionozgatassal is megtortenhet, es nem kapcsolatos a kerdesemmel...
7

új session id

Hodicska Gergely · 2007. Júl. 23. (H), 10.51
Mitől nem biztonságos a php session kezelése?
Erről a második cikkben lehet olvasni, az egyik legnagyobb hibáját pont említetted is (belépéskor nincs új session id), illetve ez nyilván nem a PHP hibája, de erre szinte senki nem szokott figyelni. De a menet közbeni session lopás ellen sincs semmilyen védelem, ezt is Neked kell megoldani.

Az meg hogy DB-ben tárolod a session adatokat, annak biztonság szemszögéből viszonylag kevés jelentősége van (webhosting esetén el tudom képzelni, hogy jelentősebb), inkább skálázhatóság miatt lehet érdekes.

A sessionid újragenerálása sem rossz ötlet, de ha nem https-en viszed a forgalmat, akkor az adatforgalomat figyelő gonosz az új sessionid-t is megszerzi.
Azért ahogy én tudom nem olyan egyszerű hálózati forgalamt figyelni, hacsak nem vagy egy hálózati szegmensben az illetővel, szóval új session id mindenféleképpen kell, különben nagyon megkönnyíted a session lopást.


Üdv,
Felhő
9

biztonság

zila · 2007. Júl. 23. (H), 11.53
A hálózat figyeléséhez vagy a szerverrel, vagy a klienssel kell egy hálózatban lenned, ez evidens volt nekem is.
Ha nyílt protokollon megy a beszélgetés, akkor a sessionid váltás is lekövethető, sőt, nem is kell sessiont lopni, hiszen a teljes forgalmat tudja naplózni a rosszarc...

De ez csak amelett szól, hogy érdemes saját kézbe venni a session kezelést, de teljesen más alapokra tenni (kihagyni teljesen a php session kezelését) szvsz nem érdemes.

üdv,
Zila
11

lehallgatás

Hodicska Gergely · 2007. Júl. 23. (H), 21.12
A hálózat figyeléséhez vagy a szerverrel, vagy a klienssel kell egy hálózatban lenned, ez evidens volt nekem is.
Ha nyílt protokollon megy a beszélgetés, akkor a sessionid váltás is lekövethető, sőt, nem is kell sessiont lopni, hiszen a teljes forgalmat tudja naplózni a rosszarc...
Nyilván ha képes lehallgatni a forgalmat, akkor HTTPS nélkül nem sok esélyed van. Viszont egyrészt azok száma, akik képesek lehallgatni a forgalmad, eltörpül a lehetséges támadók számától, plusz nem túl valós forgatókönyv. Nemrég én is felvetettem ezt a kérdést nálunk a hálózatosok fejének (itthon a legjobb pár ember között van ezen a területen), és ő mondta, hogy annak az esélye, hogy valaki a szolgáltatónál nekiáll a forgalmad lehallgatni, az nagyjából nulla. A "session csapda" jellegű támadás viszont teljesen valós veszélyforrás, ezért muszáj ellene védekezni.

De ez csak amelett szól, hogy érdemes saját kézbe venni a session kezelést, de teljesen más alapokra tenni (kihagyni teljesen a php session kezelését) szvsz nem érdemes.
Ezzel teljesen egzet értek.


Üdv,
Felhő
12

biztonság

Balogh Tibor · 2007. Júl. 24. (K), 11.38
Aki foglalkozott session kezeléssel, tudja, hogy érdemes biztonságosabbá vagy jobban kezelhetővé tenni a beéptett folyamatot.

Tk. a php semmi mást nem csinál, hogy ellenőrzi, hogy létezik-e a session sütiben elküldött azonosítónak megfelelő fájl vagy sem. Arról nem is beszélve, hogy a transparent - a címben elküldött - süti nem kis veszélyt rejt, messze el kellene kerülni. - Volt egy fórum, ahol az egyik kedves ember elküldte valakinek a fórum címét egy ismerősnek, csak be volt jelentkezve. Ezután meg az a valaki az ő nevében írt hozzászólásokat.

Szóval, egyáltalán nem a kerék feltalálása, ha biztonságosabb sessionkezelést kpróbálunk készíteni.
3

cikkek a témában

Hodicska Gergely · 2007. Júl. 23. (H), 10.31
http://weblabor.hu/cikkek/munkamenetkezeles1
http://weblabor.hu/cikkek/munkamenetkezeles2


Üdv,
Felhő