Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93234
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+u_BxxZ-xG2cS-C97qx+WNccryd_0xvhgPbvdqfe7F_8mL0g@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>
Date: Wed, 11 May 2016 08:28:10 -0400
Message-ID: <CAF+u_ByYLBfyTM88xT6m5tdta7=yz6Tzuo8vZPnRO7sp7CvkPQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a114f4172c5bff90532902c16
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: kinncj@gmail.com (=?UTF-8?B?S2lubiBKdWxpw6Nv?=)

--001a114f4172c5bff90532902c16
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

And again, I'm bashing against/based in his poor example for asynchronous
requests...
On May 11, 2016 8:22 AM, "Kinn Juli=C3=A3o" <kinncj@gmail.com> wrote:

> > CSRF is not related to spam or rate limiting, it is related to
> impersonation. A spam bot can simply repeatedly request new HTML forms an=
d
> scrape out the hidden input.
>
> The Spam bot was just an example, contering his own example.
>
> And it still a cross site request... Either if it comes from a bot or not=
.
>
> About the pixel, what can prevent a mail pixel to point to "
> attacker.com/img.jpg" which fetches the
> "whatever_his_enpoint_to_return_the_token.php", grab the token and forwar=
d
> to the form? The same as what prevets it from scraping the html? Nothing.=
..
> So in the end, this RFC improves nothing as mentioned above.
> On May 11, 2016 8:16 AM, "Rowan Collins" <rowan.collins@gmail.com> wrote:
>
>> On 11/05/2016 12:36, Kinn Juli=C3=A3o 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 p=
age.
>>
>> 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 tha=
t
>> 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 a=
nd
>> scrape out the hidden input.
>>
>> Regards,
>> --
>> Rowan Collins
>> [IMSoP]
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

--001a114f4172c5bff90532902c16--