Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93189
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZytbD1H-Rg5eWfiPwEM0p47JSQH-GC-ZayDSLbmbsGVA@mail.gmail.com>
References: <CAGa2bXZytbD1H-Rg5eWfiPwEM0p47JSQH-GC-ZayDSLbmbsGVA@mail.gmail.com>
Date: Wed, 11 May 2016 11:12:07 +0700
Message-ID: <CAEZPtU7Wv1EQ_GsFSNwmzJnaACD91Dej_pWS_TUvjnj-wCRB5g@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134f38ec1e8690532893eae
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: pierre.php@gmail.com (Pierre Joye)

--001a1134f38ec1e8690532893eae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

On May 10, 2016 10:25 AM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:
>
> Hi all,
>
> It's not nice to work on the same code (i.e. session module) for
> multiple RFCs, but time is limited.
>
> I would like to hear from ideas/comments before I write patch for this.
> https://wiki.php.net/rfc/automatic_csrf_protection
>
> Thank you for your comments.

I will try to explain a bit my view on all the current efforts (welcome) to
secure session managements and related areas.

For the last one, I do not think php should take of it. If we still want to
do it, I won't do it all using what it is proposed. It should provide APIs,
easy to use and being used on demand (think of the password APIs for csrf
protection). INI settings are unflexible, hard to custom or fix later. The
pl=C3=A9thore of packages (and some very good ones like in slim fe) lead th=
e
way.

This RFC also makes many assumptions about erroneous  common cases as many
other said in this thread.

About all other RFCs to secure or improve sessions. My feeling is simple:

The current session code and designs is old, very old. It does not match
today ways to do things. Every time we fix it, I see a band aid fix.

In other words, rewrite the damned thing. Make clear, simple APIs, enable
secure behavior by default and limit the ini options to the very strict
minimum.

We all already used custom extensions for management anyway (serialization,
different backends, etc). It may not help shared hosting but these are kind
of hopeless in many regards.

> Regards,
>
> P.S. Precise session ID management is important, but this one is also
> important. I'll finish and start voting 2 active session RFCs soon. I
> may finish all of them hopefully.

--001a1134f38ec1e8690532893eae--