Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90947
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.181 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>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <56A80626.6080008@gmail.com>
Date: Tue, 26 Jan 2016 15:49:58 -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: <CAGa2bXZ3gFegniSBCtfnnrrotbdCh+MjGufC11nYhd7kH31tuQ@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!

> I have
> https://wiki.php.net/rfc/dbc2

This doesn't seem to do anything with security. It's just a way of doing
asserts, which we already have.

> https://wiki.php.net/rfc/secure_serialization

This may be a viable extension of somebody really is going to use it. I
would suggest making a PECL extension.

> https://wiki.php.net/rfc/introduce-type-affinity

This also has nothing to do with security, and also looks unfinished,
not clear what is sought and what is the benefit.

> https://wiki.php.net/rfc/script_only_include

This one we already discussed at length, and the vote result is clear.

> Three RFCs for session is just too much for me already...

Maybe we should concentrate on doing one specific thing, bring it to
conclusion and then get to the next one?

> Anyway, we may be better to talk about how it should be.
> For this thread, how session management should be.
> It's just not good enough currently. Besides exploiting
> PHP session is too easy, random lost sessions is not

I am sorry, but I still see no base to this claim. You seem to be under
impression that stealing cookies from HTTPS connection is trivial, but I
do not see how it is. Moreover, since virtually all secure communication
over the web relies on this, if it were trivial, no secure communication
would be possible, and I don't see this happening.
If, however, HTTPS/cookies are secure, then I don't see how exploiting
PHP session in current state is easy. There may be some browser bugs
that make some scenarios not work sometimes, but so far I don't see any
problem that were bigger than light annoyance.

> acceptable. Weak defaults are not acceptable also. Let's

There are a lot of different use cases for PHP and session, and the same
requirements do not apply to all of them. So in my opinion, the defaults
should cover the most common cases, and avoid breaking applications as
much as possible.
-- 
Stas Malyshev
smalyshev@gmail.com