Re: [RFC DRAFT] Automatic CSRF Protection

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 >