Re: [RFC DRAFT] Automatic CSRF Protection

Hi Rowan, On Tue, May 10, 2016 at 9:36 PM, Rowan Collins <rowan.collins@gmail.com> wrote: > Yasuo Ohgaki wrote on 10/05/2016 11:57: >> >> To protect all of URLs automatically, all URLs need to have token. >> That's the reason why all URLs have token. > > > In my opinion, that fails on both counts: not all URLs need protection (I > would say for most applications, the majority of URLs do not need it), and > not all URLs will be protected automatically (because rewriting HTML is a > hard problem, and because some submissions that need protecting are not > generated as HTML). > > Interestingly, the OWASP page has a whole section on the dangers of exposing > CSRF tokens in URLs: > > https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL > It backs up my gut feeling that exposing the CSRF token too widely can > severely diminish its usefulness; for instance, by exposing tokens in > Referer headers sent to external sites. > > There may be types of application that would benefit from every page having > a "CSRF or die" policy - e.g. online banking - but I don't think they > represent a large proportion of the PHP user space, or benefit significantly > from having the functionality built into the language. For everyone else, > all that's needed is functions to manually generate, save, and validate > tokens, and those can trivially be written as a userland library. Indeed > there are plenty: https://packagist.org/search/?q=csrf Exposure of CSRF token is obvious security risk. As I wrote, the risk is the same as trans sid. In addition, it does not add CSRF token to URLs by default now. (i.e. Protect POST automatically when it is enabled) Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net