Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93194
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.50 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAEZPtU7Wv1EQ_GsFSNwmzJnaACD91Dej_pWS_TUvjnj-wCRB5g@mail.gmail.com>
References: <CAGa2bXZytbD1H-Rg5eWfiPwEM0p47JSQH-GC-ZayDSLbmbsGVA@mail.gmail.com>
 <CAEZPtU7Wv1EQ_GsFSNwmzJnaACD91Dej_pWS_TUvjnj-wCRB5g@mail.gmail.com>
Date: Wed, 11 May 2016 13:45:45 +0900
Message-ID: <CAGa2bXZNtokRG8e73XCbhFsaqXZEfTM64zEdWGc25zYwYWTbWg@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

On Wed, May 11, 2016 at 1:12 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> 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 API=
s,
> 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. Th=
e
> pl=C3=A9thore of packages (and some very good ones like in slim fe) lead =
the way.
>
> This RFC also makes many assumptions about erroneous  common cases as man=
y
> 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.

I agree partly.
The way session ID is managed is obsolete and insecure. Therefore, I propos=
ed
precise session management.

> 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.

I have different point of view.
Current session manager is like UDP. Users has to do lot of work to
maintain state properly. Session manager should be like TCP. IMO.
Users shouldn't have to care about details how session/state is
maintained.

Thank you for your comments. I've updated the RFC. You might like this vers=
ion.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net