Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90951
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.177 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <56A80626.6080008@gmail.com>
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>
Date: Wed, 27 Jan 2016 09:21:58 +0900
Message-ID: <CAGa2bXYWO+0U0urbbUi-nJjKnACYXdRDsg0Jn6AcYus1VsrExQ@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: [RFC Discussion] Precise Session Management
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Stas,

On Wed, Jan 27, 2016 at 8:49 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>
>> 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.

It's a framework for secure programming.
Using it is up to users, but DbC is proven method for writing
sold(secure) code while maintaining the code execution performance in
production. Assert is a weak tool for it.

>
>> 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.

MHAC is also a proven method for message validation. Unvalidated
inputs for serialize are source of vulnerabilities for a long time. I
think it worth to provide it for all users. I see work in progress
phpt for serialize vulnerability, why not provide secure way out of
the box?

>
>> 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.

It related to secure programming. Validating inputs and use of proper
types is basic thing in secure programming. Type affinity helps this.

>
>> https://wiki.php.net/rfc/script_only_include
>
> This one we already discussed at length, and the vote result is clear.

It may be. However, easiness of code inclusion in PHP is one of the
weakest point that is unique to PHP. I'm not sure how it goes, but I
shall try.

>
>> 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?

I would like not to start discussions for these RFCs now. Fine for me.

>
>> 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.

I'm not saying stealing session cookie from HTTPS is trivial. It could
be trivial with certain environment, though.

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
themselves, and set it to victims cookie. Without session ID
regeneration with precise expiration, attacker may keep logged in
session forever.

> 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.

Described how easy to steal session permanently above.
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.

>
>> 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.

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.

Other than these, user should not have problems in their production
codes. If any, please let me know.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net