Why use sessions for CSRF Protection? That an be implemented with simple cookies.
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Double_Submit_Cookies Btw, not sure if this should be in php core though...it's more an application thing... On Tue, May 10, 2016 at 2:44 PM, Niklas Keller <m...@kelunik.com> wrote: > 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 > > > > >
