Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93211
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZ3k7banuhgH=VNiSuowmdfenMn5bY1jdQKiyYEq2LhHw@mail.gmail.com>
References: <CAGa2bXZytbD1H-Rg5eWfiPwEM0p47JSQH-GC-ZayDSLbmbsGVA@mail.gmail.com>
	<CAEZPtU7Wv1EQ_GsFSNwmzJnaACD91Dej_pWS_TUvjnj-wCRB5g@mail.gmail.com>
	<CAGa2bXZNtokRG8e73XCbhFsaqXZEfTM64zEdWGc25zYwYWTbWg@mail.gmail.com>
	<CAEZPtU7Lr+OA0Zn+qCc6h2ftpnRDE4t7YH=mUymXJu7XdR=79w@mail.gmail.com>
	<CAEZPtU6g-U5fbzcy=KD_OGH2BEukYnMPqrpDisTN5wbGkkbB2w@mail.gmail.com>
	<CAEZPtU7TeMxMnxBVA4BKdrsHba=4mxQCz_8VvEM528jadNyzVg@mail.gmail.com>
	<CAGa2bXZ3k7banuhgH=VNiSuowmdfenMn5bY1jdQKiyYEq2LhHw@mail.gmail.com>
Date: Wed, 11 May 2016 14:35:39 +0700
Message-ID: <CAEZPtU6bENDt2jUqOq9jWFi6c7ZjsUrxiHs3HASpRYQa+FEURw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1141bc5eabced805328c16f1
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: pierre.php@gmail.com (Pierre Joye)

--001a1141bc5eabced805328c16f1
Content-Type: text/plain; charset=UTF-8

On May 11, 2016 1:54 PM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:
>
> Hi Pierre,
>
> On Wed, May 11, 2016 at 2:19 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> > On May 11, 2016 11:46 AM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:
> >
> >> Thank you for your comments. I've updated the RFC. You might like this
> >> version.
> >>
> >
> > I still think we should not have that in core. If we do, it should be
> > controlled by the application implementation and not ini settings (some
> > routes may have it, other not, some route may have different ttl etc).
I am
> > not even sure it should be part of the session module.
> >
> > Sessions are per definiton easy. Implement them correctly (whatever that
> > means) is hard. Adding csrf to ext/session feels like adding auth
methods as
> > well. Both csrf ans auth may need sessions but they are not part of the
> > session features.
>
> Session, authenticity, authentication cannot divide into independent
> parts, but they are dependent by its nature. Whether we like it or
> not, session is a part of authenticity/authentication. (I'm not going
> to add authentication feature. Session's task is to store
> authentication "flag", but I think authenticity is part of session)
> Current session module provide authenticity partially and it could
> provide good authenticity check with relatively simple change. This is
> what I would like to change by this RFC.
>
> I fully agree that implementations of proper session, authenticity,
> authentication are hard. They are not simple tasks and could be
> implemented badly like many applications in the wild.

We have very good userland csrf implementation provided for almost all
leading tools out there. I think this is where it should stay, userland.

> If these tasks
> are easy and almost all developers/applications do them correctly, I
> would not bother. Unfortunately, it's not. PHP has to be provided
> basic utility to web developers for the task. IMO.

Fixing education issues by adding upcoming magic quotes like feature is not
very appealing to me. Csrf is not a bad thing as mq were but the idea
described in this rfc is leading us in a very similar direction.

> PHP is made for easy web application development. This RFC could
> provide easy, yet good enough, CSRF protection when only POST is used.
> It's just a matter of

Never been as simple for the cases I had. I see it as a rather simplistic
case used as a generic implementation system or site wise.

Csrf may need session like many other things.  It does not mean it should
be part of the session extension but use it if necessary.

>
> What is good about this RFC is applications that use only POST for
> data modifications could be protected w/o single line of code
> modification. And most importantly, it's easy to implement this :)
> So I don't see reasons let it developers burden.

About microservices. Totally agree. The session module should care about
session management and nothing else. And for this part only, except what
has landed in recently I have a strong feeling that it is band aiding
things instead of having something modern apps could use. In short, let
stop the band aid fixes and do something better to begin with, for each
"service". Userland (already there for most) and core (outside to begin
with).

Adding so many ini settings and unrelated features won't help here, in
countrary.  It will make even harder to replace it when we are so far (if
it happens ;).

--001a1141bc5eabced805328c16f1--