Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93239
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
To: =?UTF-8?Q?Kinn_Juli=c3=a3o?= <kinncj@gmail.com>
References: <CAGa2bXZytbD1H-Rg5eWfiPwEM0p47JSQH-GC-ZayDSLbmbsGVA@mail.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>
 <CAF+u_BxnVg+cpeitxR4Lo0Z938fcNGYEDBKLe6XPq8RU3KH9cQ@mail.gmail.com>
Cc: internals@lists.php.net
Message-ID: <67a20f52-962a-acb5-6d71-4a5995928d87@gmail.com>
Date: Wed, 11 May 2016 14:40:30 +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_BxnVg+cpeitxR4Lo0Z938fcNGYEDBKLe6XPq8RU3KH9cQ@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 14:07, Kinn Julião wrote:
> 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-attacker_example_net
> :-)

Neither of the files in that gist are demonstrating CSRF as such.

attacker_example_net is bypassing the Same Origin Policy; it 
hand-wavingly pre-supposes a misconfiguration which allows this, 
including sending the user's cookies with the cross-domain request. Note 
that if the first XHR can successfully generate a CSRF token, then you 
don't need an <img> tag, since a second XHR to the rewritten URL will 
succeed. At this point, you have a far stronger attack footprint than 
normal CSRF anyway, because you can access privileged data and 
arbitrarily impersonate the user in a 2-way conversation with the server.

supersafe.com_img.jpg is simply a spam script. The request to 
http://example.com/contact.php is coming from the server hosting the 
site, and doesn't impersonate anybody. If the form requires the user to 
have previously authenticated, this will simply fail, because it never 
authenticates as anybody. If your implication is that you've tricked 
somebody else's *server* into executing this code, that's yet another 
type of attack, and there are much worse things you could do with the 
ability to run arbitrary code on their server.


> As I mentioned in comments there:
> /*
> From this point, this attack will only work if:
> 1 - CORS is missconfigured
> */

Yes. As OWASP says, to protect against CSRF, one must first protect 
against XSS. However, protecting against XSS does not protect against 
CSRF, so token-checking or similar countermeasures are still necessary.


> If the user must be responsible to secure it properly, why should be this magic added to the core?

I'm not convinced it should be in the core, but "some users will have 
XSS vulnerabilities" is not a good reason for it not to be.


Regards,
-- 
Rowan Collins
[IMSoP]