Új hozzászólás Aktív témák

• #11255 CSorBA őstag mobal #11254

  Új Válasz 2012-09-19 10:45:00 #11255

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  CSorBA

  őstag

  válasz mobal #11254 üzenetére

  Ezzel nem teljesen értek egyet, bár az is lehet, hogy én gondolom rosszul.

  Szerintem a SESSION biztonságosabb, mint az adatbázis, de csak abban az esetben, ha védjük a SESSION id lopásától. (most tételezzük fel, hogy a szerveren teljesen védve van a sessiont tároló fájlrendszer)

  Itt eleve pont ettől védem. Nézzük mi van a sessionunkban:

  - ugye alapból van neki egy id-je
  - userid (ha ez létezik, akkor be van lépve, illetve tudom, hogy kiről van szó)
  - security_token - md5(IP-USERAGENT)

  Minden oldalletöltésnél legenerálom a felhasználóm (vagy támadóm) md5(IP-USERAGENT) hashét, és összehasonlítom a jelenlegi SESSION-ban security_tokenjével. Ha nem egyeznek, kidobom.

  Ha ellopja a session id-t, akkor jó esetben el fog térni ez a security_token. És kidobom.

  Emellett csinálhatom azt, amit Brown Ügynöknek írtam, hogy folyamatosan változtatom a SESSION id-t.

  Most nem értem, miért kellene adatbázisban tárolnom? Ha ellopja az id-t, és még sikerült ugyanazon ip-t, user agentet is előállítania, akkor már olyan mindegy, hogy db-ből nézem, vagy sessionból. (de pont ezt fogom megakadályozni a folyamatos id váltással) Feleslegesnek érzem a táblás tárolást.

  Az már más kérdés, hogy mi van akkor, ha folyamatosan váltom az id-t, és a támadom ÉPPEN elkapja a jót, épp belép, épp oldalt tölt le, és Ő fogja megkapni onnantól a valid id-t, és a felhasználómat vágja ki... Bár valljuk be, ennek nagyon kevés esélye van. Az alábbiaknak kellene teljesülni:

  - Hálózati forgalom figyelésével, két oldalletöltés között elkapni a session id-t.
  - Egy ip-ről lenni.
  - Eltalálni a User agentet.

Új hozzászólás Aktív témák