Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73150
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.51 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <20140314074112.GB26909@mail>
References: <CAGa2bXZT8w9=usaPcJzs8NaiGfCpqvw3NVOBvTuGmSAs3vwxEQ@mail.gmail.com>
 <20140314074112.GB26909@mail>
Date: Fri, 14 Mar 2014 18:37:35 +0900
Message-ID: <CAGa2bXYQXgJi2jxLxR4iCKb79LwQREUHLZ0z-+D5c-8fd6P1Kw@mail.gmail.com>
To: Mateusz Kocielski <shm@digitalsun.pl>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2681844ac1904f48dd462
Subject: Re: [PHP-DEV] Solution for session_regenerate_id() issues
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c2681844ac1904f48dd462
Content-Type: text/plain; charset=UTF-8

Hi Mateusz,

On Fri, Mar 14, 2014 at 4:41 PM, Mateusz Kocielski <shm@digitalsun.pl>wrote:

> 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

--001a11c2681844ac1904f48dd462--