Yasuo Ohgaki <yohg...@ohgaki.net> schrieb am Di., 10. Mai 2016 12:57:
> Hi Rowan, > > On Tue, May 10, 2016 at 6:38 PM, Rowan Collins <rowan.coll...@gmail.com> > wrote: > > 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. > > To protect all of URLs automatically, all URLs need to have token. > That's the reason why all URLs have token. The risk is the same as > Trans SID session management. > > > 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. > > Because of likelihood of the vulnerability, it's better provide basic > infrastructure. IMO. It's possible to give more control to users. > > - Specify protected method GET/POST or both. > GET should never require automatic CSRF protection. If you need this, you're doing something fundamentally wrong. The only exception are things like OAuth, but these have to be handled manually anyway. - Add session_csrf_validate() for manual validation > > Implementation is simple enough even with these addition. (Added to RFC) > > I considered to protect whole application while I was writing this RFC > draft. Thank you for point this out! > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
