Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73141
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXZT8w9=usaPcJzs8NaiGfCpqvw3NVOBvTuGmSAs3vwxEQ@mail.gmail.com>
References: <CAGa2bXZT8w9=usaPcJzs8NaiGfCpqvw3NVOBvTuGmSAs3vwxEQ@mail.gmail.com>
Date: Fri, 14 Mar 2014 12:10:10 +0900
Message-ID: <CAGa2bXZr9SFFOxh5ju6hCkDoJaOd0GTA9sorm1bE-TKRbxdKaw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3275cbf3b3104f4886afb
Subject: Re: Solution for session_regenerate_id() issues
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3275cbf3b3104f4886afb
Content-Type: text/plain; charset=UTF-8

Hi all,

Before I start working on revised session module improvement patch, I would
like to address session_regenerate_id() issue.

On Thu, Mar 13, 2014 at 1:03 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Current session_regenerate_id() has issues. I'll try to explain what these
> are.
>
> Issue 1: Old session data is not deleted.
>
> session_regenerate_id() does not delete old session by default. It leaves
> old session available. When attacker could steal session ID via
> XSS/sniffing/etc, attacker can use session ID as valid ID as long as
> application allows. No detection/prevention of security breach is possible
> at session module level. This behavior is unacceptable for security reason.
>
> Issue 2: Old session data cannot be deleted.
>
> session_regenerate_id(TRUE) deletes old session data immediately. It's
> good for security, but if there are multiple connections from a client to
> server (e.g. AJAX/iframe/tabs/etc),  valid connection may fail since it
> could be using old session ID. Therefore, session_regenerate_id() does not
> delete old session data. Immediate session data deletion is unacceptable
> for reliable operation.
>
> To solve these 2 issues, we need to delay old session data deletion.
> Delete old session data 60 seconds later, for example.
>
> If there is any other feasible solutions are welcome. I cannot think of
> any.
>

Current behavior (leaving active session that attackers may be abusing) is
far from optimal. I can only think of delayed deletion as the solution for
this.

Delayed session deletion implementation has 2 options. (Introducing
separate API has severe overheads. Thus, it's not an option)
 - set and check time stamp in $_SESSION. (Keep save handler/serializer
compatibility)
 - set and check time stamp in raw session data. (Need save
handler/serializer modification)

This is "must be fixed" design problem for new release. IMHO.
I don't mind which new release, but this should be fixed someday.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3275cbf3b3104f4886afb--