Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93213
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.46 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAL0xaBFTF28h7ZTCkk=gn2=kepv0xe_Gk0+zjhmZzDmLJYU3-w@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>
Date: Wed, 11 May 2016 17:05:05 +0900
Message-ID: <CAGa2bXbX_YhpJEr+9XjTb3xxgb2KTw=LEjC97A0vM4_WNiSvnA@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Niklas Keller <me@kelunik.com>, Stanislav Malyshev <smalyshev@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

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

> 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...

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net