Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90956
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.52 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
References: <CAGa2bXbg_kebBVg3tSh4uFHZ6nQXRbjUXNQa0JZx9sezQqb5kg@mail.gmail.com>
 <CAGa2bXYZXkCJwFKVwaNfV+OEw0FzeFFbtxLm0zRmFVE_b4xsMw@mail.gmail.com>
 <CAGa2bXbRJMZFcXfZc9o7YnAhkDRfYKPjO+10k-eKXdoGNTREbg@mail.gmail.com>
 <CAGa2bXYGpV=P-680ig1LOkYWsSRS-Ya2rYVa3wo3vrxdT=zwiw@mail.gmail.com>
 <56A727C3.9070505@gmail.com>
 <CAGa2bXYj6iCvKqcpf_p6Dm_TNOxtVozry=AONKWu9-VKzb_FHw@mail.gmail.com>
 <CAGa2bXZ3gFegniSBCtfnnrrotbdCh+MjGufC11nYhd7kH31tuQ@mail.gmail.com>
 <56A80626.6080008@gmail.com>
 <CAGa2bXYWO+0U0urbbUi-nJjKnACYXdRDsg0Jn6AcYus1VsrExQ@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <56A81CA5.2050106@gmail.com>
Date: Tue, 26 Jan 2016 17:25:57 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <CAGa2bXYWO+0U0urbbUi-nJjKnACYXdRDsg0Jn6AcYus1VsrExQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC Discussion] Precise Session Management
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Other than HTTPS, setting unremovable cookies is easy with JavaScript
> vulnerability. Currently, we only has session.use_strict_mode=1. This
> is not good enough because attacker can generate valid session ID by

That sound unlikely, given how much space needs to be searched. By the
same vein, you could say one could defeat encryption by just guessing
the key. Which, if you are unbelievably lucky, can be true, but nobody
is that lucky. I don't see how guessing session ID is easier than
guessing encryption key.

> themselves, and set it to victims cookie. Without session ID
> regeneration with precise expiration, attacker may keep logged in
> session forever.

That's not true, as many application provide session expiration in
userspace.

> Described how easy to steal session permanently above.

It was claimed, but not described how that could actually happen.

> Without this proposal, user/web site owner will never know possible
> security breach. With this proposal, user/web site owner can detect it
> by raised errors for access to expired sessions.

I'm not sure what would be the use of it. Suppose you detected somebody
is trying to use old sessions to breach your security. Then what?
I am also not sure which proposal you refer to that helps with access to
expired sessions - aren't they just deleted? If so, you can't
distinguish access to expired session from access to one that never
existed.

> Other than restricting chars for session_id(), this proposal will not
> break application. Other possible minor BC happens when apps rely on
> constant session ID. Relying on constant session ID is _bad_ practice,
> but the patch allows to disable automatic session ID regeneration for
> better compatibility. Tests for session behavior may be affected, but
> it will not affect production code.

Still do not see how restricting chars is beneficial (handlers already
restrict what is unacceptable for them).
Also, as I said, as a particular implementation detail, I don't think
specific session regeneration pattern belongs in core - not all
applications would want it, and not all in the same way. Some
applications would rather prefer to drop the session and force the user
to re-login, for example.

> Other than these, user should not have problems in their production
> codes. If any, please let me know.

Changing defaults and functionality always brings possibility for
breakage, and the fact that so many tests needed to be changed also
suggests that the applications that would use the same code unmodified
would be broken.

-- 
Stas Malyshev
smalyshev@gmail.com