Re: Solution for session_regenerate_id() issues

Hi Mateusz, On Sun, Mar 16, 2014 at 5:53 PM, Mateusz Kocielski <shm@digitalsun.pl>wrote: > On Sat, Mar 15, 2014 at 08:46:29AM +0900, Yasuo Ohgaki wrote: > > > Application means client side application? > > > > Suppose you have gallery application that only shows user's photo. Every > > request > > for photo should use authenticated session. If > session_regenerate_id(TRUE) > > is called > > during page rendering, what happens? > > By application I meant client side application. I don't believe that > periodically regenerating session introduces better security. Regarding the > Stealing session ID is easy even with HTTPS. Therefore, changing session ID is the security best practice to mitigate risk. > case you provide, if session_regenerate_id(TRUE) is used in the page which > contains photos, then all requests for images will contain new session > cookie. (If browser requests for photos, then body of the document was > received, thus also headers with new cookie was received). If > session_regenerate_id() is used elsewhere, then I think that it's not our > problem. It's session manager problem. Currently, session module allows to exploit stolen session as long as app allows even when user follows security best practice. i.e. call session_regenerate_id() periodically. I think almost all apps do not have proper mitigation. There must be mitigation and it could be done with deletion time stamp by session manager. It's a session manager design issue. Session manager should provide mitigation rather than leaving it to users. IMO. I copied following lines from previous my mail just in case you missed it. Users may set timeout flag in $_SESSION array and check the value if session could be active or not. In order to do that in user land, one may do session_start() // ** check timeout flag ** if (!empty($_SESSION['VALID_UNTIL']) && $_SESSION['VALID_UNTIL'] < time()) { session_destroy(); trigger_error('Possible session hijack attack detected'); die('Possible session hijack attack detected'); } // ** set timeout flag ** if ($_SESSION['LAST_REGENERATE'] < time() + 600) { $_SESSION['VALID_UNTIL'] = time() + 60; // Shorter is better, but rather large value is set for lost radio/hand over/etc. Old session is allowed to use as valid session for 60 seconds. session_commit(); // Need to save above data in old session. session_start(); $_SESSION['LAST_REGENERATE'] = time(); // Update regenerate time here. session_regenerate_id(); // New session ID and old session data with old session ID is left unset($_SESSION['VALID_UNTIL']; // This session should not be deleted later. } > However, we should update our documentation to note the problem. > > BTW, > > fiºéQ0ÔîÃÇ
> 5™https://bugs.php.net/search.php?cmd=display&search_for=session_regenerate_id > - it seems that users also don't see this issue as a problem. > Two of them are mine ;) > > > Of course attacker may, but > > > > If session is hijacked, > > - User could know attack if session ID is regenerated by attacker. > > - Attacker could know there is hijack protection if session ID is > > regenerated by user. > > > > This is much better than current. Risk is mitigated rather than left > open. > > BTW, almost all security measures are mitigation. > > > > I don't see how risk is mitigated in that case. User will lose session (if > it > was regenerated by attacker) which probably result in logout, I don't > believe > that typical user will be alarmed. Session manager can raise error for invalid access. Programmer may catch the error and warn user/attacker if users are cautious. > As a result we'll get an attacker and user > using distinct sessions - how many applications already deny using two > distinct sessions for one account? This one is user (PHP developer) issue since session manager does not know about users. Web apps may allow or disallow multiple sessions. It's developer's choice. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net