Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93173
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.193 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <b7bf68fd-bef5-7c25-90c8-d5c40cd055b3@gmail.com>
References: <CAGa2bXZytbD1H-Rg5eWfiPwEM0p47JSQH-GC-ZayDSLbmbsGVA@mail.gmail.com>
 <e9b34da1-a6c7-261e-1a83-9bf34d2ed8ac@gmail.com> <CAGa2bXZp5HavxNw6ZFk0RnOc2HvAtukLz2mnT8FC_UE8O9PNmw@mail.gmail.com>
 <b7bf68fd-bef5-7c25-90c8-d5c40cd055b3@gmail.com>
Date: Wed, 11 May 2016 07:03:46 +0900
Message-ID: <CAGa2bXaZ4Js_gGYT4cA3iJ92TQyEZSHYmue91JZ+R8Tu9QGizA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Rowan,

On Tue, May 10, 2016 at 9:36 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> Yasuo Ohgaki wrote on 10/05/2016 11:57:
>>
>> To protect all of URLs automatically, all URLs need to have token.
>> That's the reason why all URLs have token.
>
>
> In my opinion, that fails on both counts: not all URLs need protection (I
> would say for most applications, the majority of URLs do not need it), and
> not all URLs will be protected automatically (because rewriting HTML is a
> hard problem, and because some submissions that need protecting are not
> generated as HTML).
>
> Interestingly, the OWASP page has a whole section on the dangers of exposing
> CSRF tokens in URLs:
> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL
> It backs up my gut feeling that exposing the CSRF token too widely can
> severely diminish its usefulness; for instance, by exposing tokens in
> Referer headers sent to external sites.
>
> There may be types of application that would benefit from every page having
> a "CSRF or die" policy - e.g. online banking - but I don't think they
> represent a large proportion of the PHP user space, or benefit significantly
> from having the functionality built into the language. For everyone else,
> all that's needed is functions to manually generate, save, and validate
> tokens, and those can trivially be written as a userland library. Indeed
> there are plenty: https://packagist.org/search/?q=csrf

Exposure of CSRF token is obvious security risk.
As I wrote, the risk is the same as trans sid. In addition, it does not
add CSRF token to URLs by default now. (i.e. Protect POST automatically when
it is enabled)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net