Session::regenerateId – race condition
- juzna.cz
- Člen | 248
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 request2
– volani Session::start()3
– volani Session::regenerateId(), protoze ubehl timer4
– 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
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
Možné řešení: regenerovat session po půl hodině pouze v případě, že se změní IP adresa.
- juzna.cz
- Člen | 248
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
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).