Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93253
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZxWNtGhD_R=TO4sJF5ToinRxFK+5VhsjeUXsSDK-ts8Xg@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>
 <CAL0xaBF8e7PhY_hqNYwNvxwRiha1=rUtLBfugUNC2FGf2FndzA@mail.gmail.com>
 <CAF+u_ByFOKd+CyCO5yO_2aSYf2GhLrqb6oLHcvKuNF6W7E+YGg@mail.gmail.com>
 <4667bb84-4401-4dd6-6193-fcf3aa6b3d48@gmail.com> <CAF+u_BxxZ-xG2cS-C97qx+WNccryd_0xvhgPbvdqfe7F_8mL0g@mail.gmail.com>
 <4d97846f-81d6-6cad-91ad-5e513a709e91@gmail.com> <CAF+u_BxnVg+cpeitxR4Lo0Z938fcNGYEDBKLe6XPq8RU3KH9cQ@mail.gmail.com>
 <CAPhkiZxWNtGhD_R=TO4sJF5ToinRxFK+5VhsjeUXsSDK-ts8Xg@mail.gmail.com>
Date: Thu, 12 May 2016 06:39:32 +0900
Message-ID: <CAGa2bXbX3_z3WsXTw=oA0Wca2vYkhV+wgAKxwvgGfhq1zGLtUw@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "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 Andrey,

On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev <narf@devilix.net> wrote:
> Hi,
> This gets a -1 from me as well.
>
> Much has been said already about why this is a bad idea, to the point where
> I don't know why there's still discussion around it. But here's one more
> reason ...
>
> It assumes, and thus also encourages, that users have an active session at
> all times - this is bad. You're not supposed to start a session for a user
> *until they have logged-in*.

You don't have to use it if don't need it or has other complement such
as double submit cookie.

> If you do, then unless you're not storing session data server-side (which
> is hard to do properly and is not supported by ext/session), you're almost
> certainly vulnerable to some form of DoS (e.g. inodes and/or memory/storage
> being filled-up), exhaustion of free IDs, entropy available for new session
> ID generation, pre-fetching of IDs to work around use_strict_mode
> restrictions, etc.

None of these arguments make sense...
It does not consume much resources. Moreover, this RFC's CSRF
protection requires less resources than most web frameworks'
implementation that use session for CSRF protections.

BTW, use_strict_mode is not a "restriction", but a mandatory
requirement for proper session management. What current session
manager is broken is other parts like inadequate session data lifetime
management.

>
> Therefore, while the session store *after login* is suitable for token
> storage, CSRF protection by default just doesn't belong in ext/session.

Session task, by its definition, is to distinguish and manage state of
requests. Session must distinguish requests, i.e. must keep
authenticity. CSRF is obvious authenticity issue. Some of us see
session manager as just a storage, but it's not a correct definition.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net