Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73160
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: <CAGAGxbaCq92+-jheNeRC033S8NUrYd_3cjiwOZcgGzbgt89QJQ@mail.gmail.com>
References: <CAGa2bXZT8w9=usaPcJzs8NaiGfCpqvw3NVOBvTuGmSAs3vwxEQ@mail.gmail.com>
 <20140314074112.GB26909@mail> <CAGa2bXYQXgJi2jxLxR4iCKb79LwQREUHLZ0z-+D5c-8fd6P1Kw@mail.gmail.com>
 <CAGAGxbaCq92+-jheNeRC033S8NUrYd_3cjiwOZcgGzbgt89QJQ@mail.gmail.com>
Date: Fri, 14 Mar 2014 19:57:40 +0900
Message-ID: <CAGa2bXa-NX3wO9XzMoa_yHK2RW9Y6qGWyW683OO+330udXHB8g@mail.gmail.com>
To: Chris Wright <daverandom@php.net>
Cc: Mateusz Kocielski <shm@digitalsun.pl>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1137e986ab84bb04f48ef2ed
Subject: Re: [PHP-DEV] Solution for session_regenerate_id() issues
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1137e986ab84bb04f48ef2ed
Content-Type: text/plain; charset=UTF-8

Hi Chris,

On Fri, Mar 14, 2014 at 7:37 PM, Chris Wright <daverandom@php.net> wrote:

> 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.
>

Indeed, there is no way to enforce serialized access to resources...

 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.
>

>

If session_regenerate_id(TRUE) is reliable, then it's not an issue.
However, session_regenerate_id(TRUE) is unreliable.

Apps that suddenly logout would not be an option for almost all developers.
Feasible solution is to allow some window of risks. I agree that there is
risk, but the risk is reduced a lot with this. The window is configurable,
too. Current risk enforced by default (i.e. session_regenerate_id(FALSE))
is too much to accept.

If session_regenerate_id(TRUE) could be used for an app, it's still
possible to delete old data immediately.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1137e986ab84bb04f48ef2ed--