Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93233
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4667bb84-4401-4dd6-6193-fcf3aa6b3d48@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>
Date: Wed, 11 May 2016 08:22:57 -0400
Message-ID: <CAF+u_BxxZ-xG2cS-C97qx+WNccryd_0xvhgPbvdqfe7F_8mL0g@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a114f03e4142e880532901a5a
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: kinncj@gmail.com (=?UTF-8?B?S2lubiBKdWxpw6Nv?=)

--001a114f03e4142e880532901a5a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> 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.

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 forward
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 i=
n
> fact be entirely passive, e.g. the src of an <img> embedded in another pa=
ge.
>
> 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 "G=
ET
> /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 an=
d
> 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
>
>

--001a114f03e4142e880532901a5a--