Solution for session_regenerate_id() issues View as Markdown

Hi Mateusz,

On Fri, Mar 14, 2014 at 4:41 PM, Mateusz Kocielski shm@digitalsun.plwrote:

I'm not sure if we should handle that in PHP, application usually
regenerates
session on important events (i.e. on user login/logout etc.), so any
requests
with old session should be denied, and this can be achieved using
session_regenerate_id(TRUE). Wouldn't it be better to write a security
note in the documentation rather than making whole thing more complex?

The issue is that session_regenerate_id(TRUE) is unreliable. It could cause
race condition since requests from client are not synchronized. There is no
way to force synchronized access resources to clients. Out of sync issue
would be more noticeable under mobile environment, networks with poor
congestion control and/or the same web app in multiple tabs.

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.
}

Something like this should be done for reliable session_regenerate_id(). I
think not many apps do this.

Above example is allowing 60 seconds window for legitimate user and
attacker. 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.

Without code like above, both attacker and user may use the session as long
as web app allows. User has no chance to know if he/she is under session
hijack attack or not. Attacker feels safe to enjoy stolen session.

This should be session manager task and calling session_regenerate_id()
should be enough for PHP users, IMO.

I didn't include automatic session ID regeneration in the RFC, but it could
be handled by session manager also. It's just a matter of storing/checking
last regenerate time. If users are following security best practices, they
should renew session ID periodically even when HTTPS is used.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

For me, an arbitrary delay time is not a solution to this. The point
of this (unless I misunderstand) is to prevent session hijacking with
the old session ID, and simply reducing the the time window where this
can happen doesn't really solve anything, as I see it.

The only flow that makes sense to me (aside from simply nuking the old
session data immediately when the ID is regenerated) goes as follows:

• A request regenerates the session ID
• The old session data is somehow marked as read-only.
• All outstanding requests that the server has already received that
  are blocked waiting for a lock on the session are able to access the
  old data on a read-only basis.
• When the last one of these requests has been processed, destroy the
  old session data.

I realise this is likely impractical to implement in such a way that
it works reliably (or even at all) with every SAPI.

Hence I believe the only practical solution here is simply to
educate users and encourage the use of session_regenerate_id(TRUE) in
the documentation.

Hello,

On Fri, Mar 14, 2014 at 4:41 PM, Mateusz Kocielski shm@digitalsun.plwrote:

I'm not sure if we should handle that in PHP, application usually
regenerates
session on important events (i.e. on user login/logout etc.), so any
requests
with old session should be denied, and this can be achieved using
session_regenerate_id(TRUE). Wouldn't it be better to write a security
note in the documentation rather than making whole thing more complex?

The issue is that session_regenerate_id(TRUE) is unreliable. It could cause
race condition since requests from client are not synchronized. There is no
way to force synchronized access resources to clients. Out of sync issue
would be more noticeable under mobile environment, networks with poor
congestion control and/or the same web app in multiple tabs.

I don't see why we should be so worried about it. Answer from server could not
be delivered, thousand things can simply go wrong, all those "exceptions"
should be handled by the application.

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.
}

Something like this should be done for reliable session_regenerate_id(). I
think not many apps do this.

Above example is allowing 60 seconds window for legitimate user and
attacker. 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.

Without code like above, both attacker and user may use the session as long
as web app allows. User has no chance to know if he/she is under session
hijack attack or not. Attacker feels safe to enjoy stolen session.

Every pot has two handles, user has no chance to know is he/she is under
session attack, but also server doesn't know who's the attacker and who's the
victim. What if we'll regenerate session upon attacker's request?

This should be session manager task and calling session_regenerate_id()
should be enough for PHP users, IMO.

I see your arguments valid, but I feel that it's sweeping under the rug the
real problem, which is handling async requests properly.

I didn't include automatic session ID regeneration in the RFC, but it could
be handled by session manager also. It's just a matter of storing/checking
last regenerate time. If users are following security best practices, they
should renew session ID periodically even when HTTPS is used.

Is periodically renewing session ID really a big benefit? If an attacker can
obtain session id from victim once, then with probability ~1 session can be
stolen again.

BTW, don't get me wrong, I'm not against making PHP more secure, I just want
to keep things as simple as possible (which is usually good for security too).

Regards,
Mateusz Kocielski