Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93237
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: <4d97846f-81d6-6cad-91ad-5e513a709e91@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>
Date: Wed, 11 May 2016 09:07:15 -0400
Message-ID: <CAF+u_BxnVg+cpeitxR4Lo0Z938fcNGYEDBKLe6XPq8RU3KH9cQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=94eb2c08b1e8a69250053290b952
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: kinncj@gmail.com (=?UTF-8?B?S2lubiBKdWxpw6Nv?=)

--94eb2c08b1e8a69250053290b952
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So following your example then.
You could place an HTML page on a completelu different site... maybe this
page:
https://gist.github.com/kinncj/6ad5f5ef8d8c36eb5f844fb802a67b7a#file-attack=
er_example_net
:-)

As I mentioned in comments there:
/*
From this point, this attack will only work if:
1 - CORS is missconfigured
*/

The understanding is: the user must be responsible to configure it
properly, to secure it properly.
If the user must be responsible to secure it properly, why should be this
magic added to the core?

On Wed, May 11, 2016 at 8:48 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 11/05/2016 13:22, Kinn Juli=C3=A3o 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
>> 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 no=
t.
>>
>
> No, it's just "a request". I ask for a URL, I get some content. There is
> no "cross-site" involved, and no "forgery".
>
>
> About the pixel, what can prevent a mail pixel to point to
>> "attacker.com/img.jpg <http://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.
>>
>
> What you are saying there is "all CSRF tokens are pointless". The large
> number of articles recommending them and libraries implementing them shou=
ld
> be a pretty big clue that they are not.
>
> I think you are misunderstanding how the attack works; here is a simple
> example. If you are logged into a site called victim.example.com, I can
> place an HTML page on a completely different site (say,
> attacker.example.net) with the following code:
>
> <img src=3D"
> http://victim.example.com/change_password.php?new_password=3Dh4xx0r">
>
> Your browser will then send a request to the specified URL, and execute
> the command. At no point does the server at attacker.example.net receive
> any data from victim.example.com, but it can trick you into sending
> commands to it, with your authenticated privileges.
>
> With a CSRF token in place, the passive attack above will be rejected -
> "missing or invalid CSRF token". In the response, a fresh CSRF token may
> well be forwarded to your browser, but it is never forwarded to the
> attacker.
>
> Let's say we have an endpoint that simply checks the request cookies and
> generates a new CSRF token, as in Yasuo's example, the attacker could of
> course write this:
>
> <img src=3D"http://victim.example.com/generate_csrf_token.php">
>
> But this is no use - it tricks you into sending a command that generates =
a
> new token, but the attacker can't see what token was generated, so can't
> impersonate you.
>
>
> If you can read the value of that response, that is an XSS vulnerability.
> As the OWASP page linked to earlier says "any cross-site scripting
> vulnerability can be used to defeat token, Double-Submit cookie, referer
> and origin based CSRF defenses":
> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Pre=
vention_Cheat_Sheet#No_Cross-Site_Scripting_.28XSS.29_Vulnerabilities
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>



--=20
*--*
*Kinn Coelho Juli=C3=A3o*
*Toronto - ON/Canada*

--94eb2c08b1e8a69250053290b952--