Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93204
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.220 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZC8Qp8-Ggyfj5+0X5aiktSX_AyfRdKAPXFZ=x4+A1XDQ@mail.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>
Date: Wed, 11 May 2016 08:37:39 +0200
Message-ID: <CANUQDCgi-P4=rWA5H+53_BcWyqeWaC_QOADUNMb_jV70KuhEPw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bf10b54273b9205328b474d
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: me@kelunik.com (Niklas Keller)

--047d7bf10b54273b9205328b474d
Content-Type: text/plain; charset=UTF-8

2016-05-11 6:50 GMT+02:00 Yasuo Ohgaki <yohgaki@ohgaki.net>:

> Hi Niklas,
>
> On Wed, May 11, 2016 at 1:40 PM, Niklas Keller <me@kelunik.com> wrote:
> > Yasuo Ohgaki <yohgaki@ohgaki.net> schrieb am Mi., 11. Mai 2016 00:05:
> >>
> >> Hi Stas,
> >>
> >> On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev
> >> <smalyshev@gmail.com> wrote:
> >> >> What happens with applications that do not produce HTML at all, such
> as
> >> >> REST,
> >> >>  - These apps may add SESSCSRF value manually.
> >> >
> >> > Add where? And where that value would come from? RFC says nothing
> about
> >> > that.
> >>
> >> As usual. Query parameter when GET is used. Additional input when POST
> >> is used. All users have to do is adding CSRF token to JS program.
> >
> >
> > Again: GET doesn't need any protection, it must be idempotent.
> >
> > Query parameter is a very bad idea, just like session IDs in the query
> > parameter are a bad idea. Maybe we should think about removing support
> for
> > it.
>
> I agree users should use POST rather than GET.
> However, there many codes use GET and it could be used safely.
> e.g. Many web API uses AUTH key in query strings. It's not security
> issue because of its usage.
>

It is, because it will be leaked to other sites without having special
headers. Older browsers not supporting those headers will still expose
those tokens in referer headers.

APIs are a different topic. They're not visited by the user directly, so
the URL is never exposed to other sites (may they be via clicked links or
embedded images).


> So I didn't ignore GET usage.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

--047d7bf10b54273b9205328b474d--