Hi Niklas, On Wed, May 11, 2016 at 1:40 PM, Niklas Keller <m...@kelunik.com> wrote: > Yasuo Ohgaki <yohg...@ohgaki.net> schrieb am Mi., 11. Mai 2016 00:05: >> >> Hi Stas, >> >> On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev >> <smalys...@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. So I didn't ignore GET usage. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
