Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93217
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbX_YhpJEr+9XjTb3xxgb2KTw=LEjC97A0vM4_WNiSvnA@mail.gmail.com>
References: <CAGa2bXZytbD1H-Rg5eWfiPwEM0p47JSQH-GC-ZayDSLbmbsGVA@mail.gmail.com>
 <c21d1d4b-a790-e1a9-7c93-2c5af4baf5d1@gmail.com> <CAGa2bXboop3KDFnYtcdO-K+hL0To5te_yeHeFEFO-kCVuzNOJQ@mail.gmail.com>
 <3b115b37-d399-0b69-24b4-de5c95c4a069@gmail.com> <CAGa2bXZwRK0GuXbT53B4w+h5ySiVJnJpo-d87Uiw-reYHi80zQ@mail.gmail.com>
 <CANUQDChxOeydBRLPrvuumf+edqJNKV+TOstGz66X_tg+Y7knPQ@mail.gmail.com>
 <CAGa2bXZC8Qp8-Ggyfj5+0X5aiktSX_AyfRdKAPXFZ=x4+A1XDQ@mail.gmail.com>
 <CANUQDCgi-P4=rWA5H+53_BcWyqeWaC_QOADUNMb_jV70KuhEPw@mail.gmail.com>
 <CAL0xaBFTF28h7ZTCkk=gn2=kepv0xe_Gk0+zjhmZzDmLJYU3-w@mail.gmail.com> <CAGa2bXbX_YhpJEr+9XjTb3xxgb2KTw=LEjC97A0vM4_WNiSvnA@mail.gmail.com>
Date: Wed, 11 May 2016 11:54:05 +0300
Message-ID: <CAL0xaBF8e7PhY_hqNYwNvxwRiha1=rUtLBfugUNC2FGf2FndzA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Niklas Keller <me@kelunik.com>, Stanislav Malyshev <smalyshev@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bb04d484ac89305328d302b
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--047d7bb04d484ac89305328d302b
Content-Type: text/plain; charset=UTF-8

Hi Yasuo!

2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki <yohgaki@ohgaki.net>:

> Hi Arvids,
>
> On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks
> <arvids.godjuks@gmail.com> wrote:
> > i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on
> by
> > default and having any INI settings that affect how engine processes
> data in
> > runtime.
> > People just don't learn until they shotgun themselves I guess.
>
> Override them if you don't like admins to set INI values. I've
> modified session_start() so that it can set INI values as function
> parameter.
> http://php.net/session_start


Admins can just forbid to change any settings. And there is an ini setting
"disable_functions" and alike. They will setup up session auto start and
forbid usage of the session_start. And force the CSRF. Been in similar
situations, done that, never want to deal with it again.
I'm not even talking about the fact, that I may have reasons to use a
different hashing algorithm in the first place.
Dealing with JS side, when you need to pass the CSRF token there is next
can of worms.
And then you get to the part, where you need to use a distributed session
management, that has it's own can of worms. And forcing CSRF handling into
the session module probably is going to make it hard to deal with it at all.

So no, sessions are sessions, they should have only one thing to be
responsible for - storing data. Nothing else. It's a module that already
has a lot of issues. What you are proposing, is to do what APC did - mixing
code opcache with shared memory storage. We all know how it ended.


>
>
> > What I personally would be for, is a CSRF aPI module that comes as
> default,
> > like the Password API one, that gives ability to generate good quality
> CSRF
> > tokens and manage it.
>
> Imagine number of CSRF vulnerabilities in PHP apps. It's countless.
>
> Letting users to choose right way is not an good options. It is
> proven. I've added session.use_strict_mode (disallows permanent
> session hijack, etc) many years ago, but fair number of users aren't
> enabling this option. I suspect most majority of users aren't enabled
> it. Even if we provide solution, it's hard to be adopted. If there is
> no solution, outcome is easy to imagine. IMHO.
>
> Users had access to good PRNG. Even if mt_rand() is used, it is hard
> enough for attackers to guess, yet there are countless CSRF
> vulnerabilities. What's the reason to ignore the fact, huge number of
> CSRF vulnerabilities exist in PHP apps?
>
> I cannot understand rationale behind you and others think it should be
> users task completely...
>

If user does not want to use CSRF, you can't force him. And realisticly
speaking, how are you going to force the tokents on the GET urls? Rewrite
them. In JSON? In XML? etc? C'mon, these days url's there are single page
apps with their own routing and stuff and you will never get a CSRF token
in any automated maner there. It needs to be done by developer of the app.


>
> Anyway, I fails to see the reason why PHP should not invalidate CSRF
> attacks against POST requests with 2 simple parameter or INI...
>

Because they may be out of your control and just forced on you by a 3rd
party. Not to mention that 3rd party libraries will do stuff that will not
take into account this setting or do some hack, and that will negate any
security.


>
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

--047d7bb04d484ac89305328d302b--