Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96162
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <36d925dc-f5a4-b6fb-1060-decf2c7f5271@gmail.com>
References: <CAGa2bXaX1eZS=_Xg3JjCVZRBSruMy6yUk-PTrKoGOwW5Tg=0_Q@mail.gmail.com>
 <CAGa2bXaApCEziTVDB3PA_MpBJLuYvKHGmiSy8XuuD1uARfYhvA@mail.gmail.com> <36d925dc-f5a4-b6fb-1060-decf2c7f5271@gmail.com>
Date: Tue, 27 Sep 2016 07:09:11 +0900
Message-ID: <CAGa2bXakQAOumNdoh_jOcW+msuad5P5NbggLY6PsfPpROURN_w@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: Fixing halfway implemented session management -
 timestamp based session management OR remove session_regenerate_id()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Stas,

On Mon, Sep 26, 2016 at 3:18 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> Please read session_regenerate_id() example #2.
>>
>> Example #2 Avoiding lost session by session_regenerate_id()
>
> In this example, why you do session_commit() in my_session_start()?
> There's no point in writing stale session.
>
> I also see no code that actually removes old sessions - is it by design?

Yes. It's by design.
In general, users should not delete session data manually, but should
let GC do the job. It's described in new Session Security manaul page.

>
> I am also not sure why this code messes with session.use_strict_mode -
> which user code is not supposed to do, this should be possible to do
> without doing that.

Because current session module cannot distinguish if session ID come
from outside, i.e. session cookie/trans sid, or script. This could be
improved, but user should control session.use_strice_mode currently.

>
> In fact, thinking about it, I think the following can be done relatively
> easily: make session_regenerate_id(), if called with false, to put magic
> entries into old session that specify a) when it was regenerated and b)
> what was the new session ID.

I realized that accessible magic values in $_SESSION were unpopular
from discussions.  I proposed minimum change also and It was declined.

My last proposal was rather complex, but it does what you're suggesting.

Differences are, it hides timestamp from $_SESSION, timestamp is only
viewable via API.

>
> This would allow to implement example #2 in userspace much cleaner, and
> if we want to implement it further in session, we could add option to
> session_start to do so. But one could also use this data in your own
> session system if one wants to do it slightly differently.
>
> This still leaves the question of old sessions, but it's not new as
> session_regenerate_id(false) already exists and in general we have GC.

I guarantee it works.
However, it's not precise/secure.

Unprecise
  - Cannot make sure obsolete session removal.
  - Accessibility to obsolete session is controlled by GC. (Attackers
can keep it alive by simply accessing it)

Unsecure
  - No way to detect possible session hijack. (My last proposal omit
raising error because people seem to care about BC too much rather
than security. Adding error/exception is matter of few lines)

Timestamp based management is mandatory for precise/secure session management.
Question is who will be responsible? Session module or User?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net