Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91892
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKws9z1ihtDyyDQORzs_gJVcOA7Z=A5QzgBf6w1UoP3pd2Ab6A@mail.gmail.com>
References: <CAGa2bXauwspEZ4HYSHgVOyd+VEvKxoymWYFPG6NaOdCa+APfKQ@mail.gmail.com>
	<CABHuAWzwxRQxohRca8MvChs4ZdHNk-xc9P5HW93dzkq1TRztoQ@mail.gmail.com>
	<CAKws9z1ihtDyyDQORzs_gJVcOA7Z=A5QzgBf6w1UoP3pd2Ab6A@mail.gmail.com>
Date: Thu, 24 Mar 2016 14:59:02 +0000
Message-ID: <CABHuAWzaDhP2YN+Gik0vwWmaa9b7m9xjUrNejhLSvosBiv_0CA@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11401ab2e8720b052eccaf1f
Subject: Re: [PHP-DEV] [RFC][Discussion] Precise session data management
From: t.carnage@gmail.com (Chris Riley)

--001a11401ab2e8720b052eccaf1f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 March 2016 at 14:43, Scott Arciszewski <scott@paragonie.com> wrote:

> On Thu, Mar 24, 2016 at 9:55 AM, Chris Riley <t.carnage@gmail.com> wrote:
>
>> On 24 March 2016 at 02:34, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>> > Hi all,
>> >
>> > Since the vote for
>> > https://wiki.php.net/rfc/precise_session_management
>> > is declined 15 vs 11.
>> > https://wiki.php.net/rfc/precise_session_management#vote
>> >
>> > We have to come up with other solutions for
>> >
>> >  - Session loss by race conditions
>> >  - Method to make session abuse harder
>> >
>> > I'm open to implement better solution than proposed RFC.
>> >
>> > These issues are serious issues that cannot be ignored.
>> > Looking forward alternative implementation ideas!
>> >
>> > Thank you.
>> >
>> > --
>> > Yasuo Ohgaki
>> > yohgaki@ohgaki.net
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>> I'm disappointed this RFC failed as improving session security should be=
 a
>> high priority. I'd propose that we focus on items which will improve
>> session security overall. This jumped out at me to start with: "This RFC
>> also
>> includes minor security improvements like httponly cookie, better hash
>> function."
>>
>> Perhaps a first RFC for improving session security can start with those
>> items: Set the session cookie to be httponly (or provide an ini setting =
to
>> do so, defaulting to on) instead of using a better hash function for the
>> session id, why not generate it from random_bytes()? Then the id is cryp=
to
>> secure.
>>
>> I'd then consider a second RFC setting out the extra internal data that
>> would be required to kill off old sessions correctly. That would require
>> to
>> keys under ['__PHP__SESSION__'] (could the key name be an ini setting to
>> preserve BC?) 'destroyed' and 'expires', the latter would be a bool flag
>> stating if the session had been explicitly destroyed. (A destroyed sessi=
on
>> could no longer be used, could throw an exception or just have no data i=
n
>> it) the expires key would be used in a similar manner, being set to
>> Time+cookie expiry time on each read/write to the session. (again an
>> expired session would not be accessible and would function like a
>> destroyed
>> one)
>>
>> The combination of the two would resolve most of the security issues and
>> establish the __PHP__SESSION__ key which could later be used to handle t=
he
>> race condition issue.
>>
>
> Could we also add HTTPS detection and enable the secure flag by default
> when a session is established on an HTTPS endpoint?
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com/>
> =E2=80=8B
>
>
I had considered this suggestion myself, but I wasn't sure if it would be
easy to implement. It could also cause some very strange (to a novice
developer) behaviour which would be hard to debug (Think sites which have
part http part https, session behaviour would be dependant on the entry
page the user hits) I'd support this, but it should probably be opt-in to
start with (alternatively we could come up with a different way to allow
the developer to specify sessions being ssl only)

--001a11401ab2e8720b052eccaf1f--