Hi all, On Wed, May 11, 2016 at 5:05 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks > <arvids.godj...@gmail.com> wrote: >> i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on by >> default and having any INI settings that affect how engine processes data in >> runtime. >> People just don't learn until they shotgun themselves I guess. > > Override them if you don't like admins to set INI values. I've > modified session_start() so that it can set INI values as function > parameter. > http://php.net/session_start > >> What I personally would be for, is a CSRF aPI module that comes as default, >> like the Password API one, that gives ability to generate good quality CSRF >> tokens and manage it. > > Imagine number of CSRF vulnerabilities in PHP apps. It's countless. > > Letting users to choose right way is not an good options. It is > proven. I've added session.use_strict_mode (disallows permanent > session hijack, etc) many years ago, but fair number of users aren't > enabling this option. I suspect most majority of users aren't enabled > it. Even if we provide solution, it's hard to be adopted. If there is > no solution, outcome is easy to imagine. IMHO. > > Users had access to good PRNG. Even if mt_rand() is used, it is hard > enough for attackers to guess, yet there are countless CSRF > vulnerabilities. What's the reason to ignore the fact, huge number of > CSRF vulnerabilities exist in PHP apps? > > I cannot understand rationale behind you and others think it should be > users task completely...
BTW, I'm not asking PHP developers to implement this feature, but I'm willing to implement/maintain the feature. Why <?php session_start(['csrf_rewrite'=>SESSION_CSRF_POST, 'csrf_validate'=>SESSION_CSRF_POST]); ?> and protect CSRF attacks against POST requests are bad for PHP and its users? Thanks. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
