Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93254
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbX3_z3WsXTw=oA0Wca2vYkhV+wgAKxwvgGfhq1zGLtUw@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>
	<CAGa2bXbX3_z3WsXTw=oA0Wca2vYkhV+wgAKxwvgGfhq1zGLtUw@mail.gmail.com>
Date: Thu, 12 May 2016 01:24:55 +0300
Message-ID: <CAPhkiZw3-mz+Yg1iZwix5xKSO0hx+s0yOPBHqLyvHaA+Uwv0Cg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113b0c34db04b90532988260
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: narf@devilix.net (Andrey Andreev)

--001a113b0c34db04b90532988260
Content-Type: text/plain; charset=UTF-8

Hi,

On Thu, May 12, 2016 at 12:39 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Andrey,
>
> On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev <narf@devilix.net> wrote:
> >
> > 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.
>
>
I am not concerned about using it myself.

I am against it because it is (among other things) ineffective and
encourages a bad practice, which I've explained below ... v


> > 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.
>
>
^ ... and you misunderstood it:


> 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.
>
>
Nowhere have I said that your CSRF implementation uses a lot of resources
(although it does use more server-side resources than the "double submit
cookie" method, simply because it stores the token on the server).

I am talking about the implications of calling session_start() for
unauthenticated users.
Calling session_start() "blindly", before login is what opens the door for
the vulnerabilities that I've listed. Not because of heavy resource usage,
but because it allows an attacker to use-up as many single sessions as they
wish, until that results in some form of DoS.


>
> >
> > 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.
>

No, CSRF is an authorization issue. Authorization (authority) depends on
authenticity, but is not the same thing.

This is a bad argument and ignores everything else that has been said so
far - you can't override a large amount of reasonable arguments by
generalizing on a single shared property.

Cheers,
Andrey.

--001a113b0c34db04b90532988260--