Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93232
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
To: internals@lists.php.net
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>
Message-ID: <4667bb84-4401-4dd6-6193-fcf3aa6b3d48@gmail.com>
Date: Wed, 11 May 2016 13:13:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <CAF+u_ByFOKd+CyCO5yO_2aSYf2GhLrqb6oLHcvKuNF6W7E+YGg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: rowan.collins@gmail.com (Rowan Collins)

On 11/05/2016 12:36, Kinn Julião wrote:
> You're making confusion between CSRF and Session Hijacking... In any moment
> I mentioned about hijacking someone else's session, but to still being able
> to CSRF (Cross Site Request Forgery).

CSRF generally implies tricking an authenticated user into making a 
request using their own session. Without any form of token check, an 
identical request will be sent from any user, so you don't need to know 
anything about the user or their session to perform the attack - it can 
in fact be entirely passive, e.g. the src of an <img> embedded in 
another page.

With a CSRF token bound to each session, you can't perform a passive 
attack, because you need to first discover some information from their 
session, and target the attack.

Without tricking the user into submitting the request with their own 
authentication, there is no forgery, and no attack.


> Any other remote source would still be able to use your "example".

A remote source would only be able to read their own CSRF token, not 
that of another user. If they are not authorised to submit the content, 
it is not the CSRF token's job to enforce that.


> "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".

All CSRF tokens are "remotely requested", in that they are sent from the 
server to the client's browser during a legitimate request. There is no 
difference in exposure between an HTML hidden input in the response to 
"GET /display_comment_form.php" and a JSON value in the response to "GET 
/generate_form_token.php".


> "B is spamming your site's contact form, with a csrf token remotely
> requested, and the same stored in its session".

CSRF is not related to spam or rate limiting, it is related to 
impersonation. A spam bot can simply repeatedly request new HTML forms 
and scrape out the hidden input.

Regards,
-- 
Rowan Collins
[IMSoP]