Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96163
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.45 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
References: <CAGa2bXaX1eZS=_Xg3JjCVZRBSruMy6yUk-PTrKoGOwW5Tg=0_Q@mail.gmail.com>
 <CAGa2bXaApCEziTVDB3PA_MpBJLuYvKHGmiSy8XuuD1uARfYhvA@mail.gmail.com>
 <36d925dc-f5a4-b6fb-1060-decf2c7f5271@gmail.com>
 <CAGa2bXakQAOumNdoh_jOcW+msuad5P5NbggLY6PsfPpROURN_w@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <950524ee-645a-e3ff-a034-16a2cdf74677@gmail.com>
Date: Mon, 26 Sep 2016 15:46:33 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAGa2bXakQAOumNdoh_jOcW+msuad5P5NbggLY6PsfPpROURN_w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Fixing halfway implemented session management -
 timestamp based session management OR remove session_regenerate_id()
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 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.

I think quite the opposite - user's shouldn't change stict_mode settings
in runtime.

> I realized that accessible magic values in $_SESSION were unpopular
> from discussions.  I proposed minimum change also and It was declined.

I know the RFC was declined, but RFC was huge and changed a lot of
things. I propose a very small and limited change on which we can build
incrementally.

> Differences are, it hides timestamp from $_SESSION, timestamp is only
> viewable via API.

I don't think we need to hide things, really. Why hide it?

> Unprecise
>   - Cannot make sure obsolete session removal.
>   - Accessibility to obsolete session is controlled by GC. (Attackers
> can keep it alive by simply accessing it)

Since that session is marked as deleted, you can easily reject it. So it
doesn't matter if it's kept alive or not.

> 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)

I think you are confusing here "insecure" (allows privilege escalation,
unauthorized access, etc.) and "does not allow detection for particular
attack". I'm not sure what this does with session hijack at all - if
somebody hijacked your session, how would you detect it with
session_regenerate_id()? I don't think this function has anything to do
with attack detection, and in general attack detection is not what
session mechanism is really for. If somebody got hold of your
authenticated session ID, it's pretty much game over for you, unless you
have protections like IP-control, etc. which are beyond the scope of
current discussion.

I think one of the reasons the previous RFC failed is that you tried to
do a lot of different and very tangentially related things at once.
Let's not do that again.

> Timestamp based management is mandatory for precise/secure session management.

You keep repeating this but just repeating this doesn't add much to the
discussion. I think everybody is aware of your opinion by now, and
simply repeating it again and again does not add much. Let's proceed to
more specific arguments.
-- 
Stas Malyshev
smalyshev@gmail.com