Yasuo Ohgaki wrote on 10/05/2016 04:24:
Hi all,
It's not nice to work on the same code (i.e. session module) for
multiple RFCs, but time is limited.
I would like to hear from ideas/comments before I write patch for this.
https://wiki.php.net/rfc/automatic_csrf_protection
I think rewriting every URL, and erroring if the token on a URL has
expired, will not be useful for most people. What happens if I copy the
URL of a page into an e-mail or Twitter post? As soon as anybody clicks
that link, they're going to get an error raised; maybe it will recover
by clearing their session, causing them to log out unnecessarily; maybe
it will refuse to show the content claiming they're not authenticated.
In the worst case, someone might take my URL and use the CSRF token
against me - they have a time limit, but if the application author
relied on this protection, the same token will be valid for any action
on the site.
As described, the feature seems to assume that all pages are potential
CSRF targets, when even an authenticated user on a forum spends most of
their time on URLs which retrieve data and have no side effects. As Stas
pointed out, not all content is amenable to rewriting, either, which
could lead to a false sense of security - dare I compare the infamous
magic quotes? A good implementation of CSRF protection has to consider
when to generate a token, when to check it, and what to do on failure -
trying to submit a comment with an invalid CSRF token might re-display
the comment form with pre-filled content, for instance - and this
proposal doesn't seem to address that.
I think this is the kind of feature that can only really be addressed by
an application framework, which can have greater knowledge of when
actions are being triggered, link tokens to specific actions, and so on.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
