Session::regenerateId – race condition

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
juzna.cz
Člen | 248
+
0
-

Nette Session se snazi zvysit bezpecnost session tim, ze jednou za cas pregeneruje session id. V tomto pripade ale muze nastat race condition, ktera prihlaseneho cloveka odhlasi, a to kdyz se sejdnou (alespon) dva spravne requesty ve spravnou dobu. Uvedu na prikladu…

Mejme 2 requesty A a B.

Mejme prikazy v prubehu zivota requestu
1 – browser odesila request
2 – volani Session::start()
3 – volani Session::regenerateId(), protoze ubehl timer
4 – prijeti odpovedi browserem.

Oznacme S1 (S2) puvodni (resp. nove) session id, ktere klient dostal. V session je ulozena promena user s id prihlaseneho uzivatele. Pomlcka znamena neexistujici session.

Kdyz nastane tato sekvence:

-- browser zacina s S1, ktere rika, ze je uzivatel prihlasen
 Akce       S1      S2        Komentar
  A 1     user=1    -         browser posila request s S1
  A 2     user=1    -         otevira se session
  A 3        -     user=1     regenerace, presun do noveho souboru
  B 1        -     user=1     browser posila druhy request s S1
  B 2     user=-   user=1     session neni, vytvori se; toto je error
  A 4     user=-   user=1     request konci se Set-Cookie: .. S2
  B 4     user=-   user=1     request konci se Set-Cookie: .. S1; toto je error
-- browser nyni pouziva S1, ktere rika, ze je uzivatel neprihlasen

Browseru to vyslo tak, ze request A prosel a akce se provedla. Request B neprosel a pravdepodobne zkoncil zobrazenim prihlasovaci stranky. Navic se uzivateli pod rukama smazala cela session.

juzna.cz
Člen | 248
+
0
-

Jeste prikladam paradoxni fun fact: protoze session se zahazuje po delsi necinnosti, mel jsem v aplikaci hlasku „Z duvodu delsi neaktivity jste byl odhlasen“. A tato situace paradoxne nastavala, kdyz byl uzivatel ve vhodnou chvili velmi aktivni a chrlil tedy hodne ajaxovych requestu :)

David Grudl
Nette Core | 8222
+
0
-

Možné řešení: regenerovat session po půl hodině pouze v případě, že se změní IP adresa.

juzna.cz
Člen | 248
+
0
-

Pomohlo by to? Kdyz mi utocnik na jine ip ukrade session, tak se mu to pregeneruje a zustane prihlaseny za mne, kdezdo me prihlaseni zmizi (protoze nedostanu nove session id)?

juzna.cz
Člen | 248
+
0
-

Pojdme po podstate problemu. Jaky problem (problemy) technika pregenerovani sessionId vubec resi?

Session hijacking – tedy ze ja pouzivam nejake sessionId a utocnik se ho nejak dozvi. Pak jej muze poslat na server a vydavat se za me. Diky zmene sessionId na to ma ale pul hodiny, po ktere to odhlasi bud jeho, nebo me – podle toho, kdo posle request ve spravnou chvili. Nevim jak vy, ale ja byt hackerem, tak mi pul hodinka staci ;)

Session fixation – nekdo vnuti memu prohlizeci jeho podstrcene sessionId (ktere zna a muze tedy provest session hijacking). Tomuto ale zabrani pregenerovani sessionId pri prihlaseni, u ktereho snad uzivatel jeste neposila tolik requestu najednou → race condition je mene pravdepodobna.

Jeste nejaky problem to resi?

Session hijacking je mozne provest napr. prectenim cookie z JS, coz ale nette osetruje pomoci http-only susenky. Pripadne pokud utocnik odchyti http traffic, ale ten si klidne odchyti i po pregenerovani.

Pregenerovani sessionId mi prijde jako reseni pseudo-bezpecnosti – resi to ve skutecnosti neco? Nebo na co jsem zapomnel? Diky

David Grudl
Nette Core | 8222
+
0
-

Regenerace ID snižuje šance na session hijacking, nic víc, nic míň. Protože to způsobuje komplikace, zrušil jsem to a session se automaticky zregeneruje jen při prvním otevření. (A pochopitelně při přihlášení a odhlášeni).

juzna.cz
Člen | 248
+
0
-

To dava lepsi smysl. Diky za rychle vyreseni :)

Editoval juzna.cz (22. 11. 2012 2:22)