Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93236
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
To: =?UTF-8?Q?Kinn_Juli=c3=a3o?= <kinncj@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>
Cc: internals@lists.php.net
Message-ID: <4d97846f-81d6-6cad-91ad-5e513a709e91@gmail.com>
Date: Wed, 11 May 2016 13:48:14 +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_BxxZ-xG2cS-C97qx+WNccryd_0xvhgPbvdqfe7F_8mL0g@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 13:22, Kinn Julião 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 not.

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 
should 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="http://victim.example.com/change_password.php?new_password=h4xx0r">

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="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_Prevention_Cheat_Sheet#No_Cross-Site_Scripting_.28XSS.29_Vulnerabilities

Regards,
-- 
Rowan Collins
[IMSoP]