Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93251
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.53 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAF+u_ByFOKd+CyCO5yO_2aSYf2GhLrqb6oLHcvKuNF6W7E+YGg@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>
Date: Thu, 12 May 2016 05:12:48 +0900
Message-ID: <CAGa2bXYaaz7eX5OZ4y4B+3NZo7KF8HSzU+qKh-6omXMWKGJXAQ@mail.gmail.com>
To: =?UTF-8?B?S2lubiBKdWxpw6Nv?= <kinncj@gmail.com>
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>, Niklas Keller <me@kelunik.com>, 
	Stanislav Malyshev <smalyshev@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Kinn,

On Wed, May 11, 2016 at 8:36 PM, Kinn Juli=C3=A3o <kinncj@gmail.com> wrote:
> You're making confusion between CSRF and Session Hijacking... In any mome=
nt
> I mentioned about hijacking someone else's session, but to still being ab=
le
> to CSRF (Cross Site Request Forgery).
>
> Any other remote source would still be able to use your "example".
>
> "A is using your own site's contact form, with a plotted csrf token as a
> hidden field in the form, and the same stored in the session".
> With your token solution for asynchronous requests:
> "A is using your own site's contact form, with a csrf token remotely
> requested, and the same stored in its session".
> "B is spamming your site's contact form, with a csrf token remotely
> requested, and the same stored in its session".
>
> Which means: B still being able to CSRF. Which is tottaly different from
> Session Hijacking.

You've said

> The cross site can request the "get_csrf_token.php", store on its session
> (even curl can save the session id cookie or whatever), get the token and
> request the endpoint with the retrieved token and session id.

I probably understand the reason why you misunderstood now.

This CSRF protection is works like Trans SID as RFC introduction
states. It is as secure as Trans SID. If you are curious, study Trans
SID and why it is adequately safe.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net