Hi Andrey, On Thu, May 12, 2016 at 7:24 AM, Andrey Andreev <n...@devilix.net> wrote: > On Thu, May 12, 2016 at 12:39 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> >> Hi Andrey, >> >> On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev <n...@devilix.net> wrote: >> > >> > It assumes, and thus also encourages, that users have an active session >> > at >> > all times - this is bad. You're not supposed to start a session for a >> > user >> > *until they have logged-in*. >> >> You don't have to use it if don't need it or has other complement such >> as double submit cookie. >> > > I am not concerned about using it myself. > > I am against it because it is (among other things) ineffective and > encourages a bad practice, which I've explained below ... v > >> >> > If you do, then unless you're not storing session data server-side >> > (which >> > is hard to do properly and is not supported by ext/session), you're >> > almost >> > certainly vulnerable to some form of DoS (e.g. inodes and/or >> > memory/storage >> > being filled-up), exhaustion of free IDs, entropy available for new >> > session >> > ID generation, pre-fetching of IDs to work around use_strict_mode >> > restrictions, etc. >> > > ^ ... and you misunderstood it: > >> >> None of these arguments make sense... >> It does not consume much resources. Moreover, this RFC's CSRF >> protection requires less resources than most web frameworks' >> implementation that use session for CSRF protections. >> > > Nowhere have I said that your CSRF implementation uses a lot of resources > (although it does use more server-side resources than the "double submit > cookie" method, simply because it stores the token on the server). > > I am talking about the implications of calling session_start() for > unauthenticated users. > Calling session_start() "blindly", before login is what opens the door for > the vulnerabilities that I've listed. Not because of heavy resource usage, > but because it allows an attacker to use-up as many single sessions as they > wish, until that results in some form of DoS.
User can call session_start() always regardless of this RFC. Needless session_start() could be a performance issue, but it does not relate to this RFC. How many of us thought "I have to call session_start() everywhere for this CSRF protection!"? I guess those who would like to use this CSRF protection will just enable POST protection and would not add any additional session_start(), would you? Even if this RFC encourages enabling session everywhere, it's not a strong reason that overwhelms reduced risk of CSRF vulnerability. >> >> > >> > Therefore, while the session store *after login* is suitable for token >> > storage, CSRF protection by default just doesn't belong in ext/session. >> >> Session task, by its definition, is to distinguish and manage state of >> requests. Session must distinguish requests, i.e. must keep >> authenticity. CSRF is obvious authenticity issue. Some of us see >> session manager as just a storage, but it's not a correct definition. > > > No, CSRF is an authorization issue. Authorization (authority) depends on > authenticity, but is not the same thing. Authenticity, authentication, authorization are different terms. Authenticity is "property that an entity is what it is claims to be" ISO 27000:2014 2.8 i.e. POST/GET request must be the intended request from the user access to web server. Authentication is "provision of assurance that a claimed characteristic of an entity is correct" ISO 27000:2014 2.7. Authorization is permission, in short. Request forgery (CSRF) is typical authenticity issue, not authorization. CSRF becomes security issue when non-authentic request could damage something. There is anonymous authenticity also. For example, anonymous BBS/comment system requires authenticity (CSRF protection). Otherwise, attacker would post "I'll detonate bomb!!" to the BBS/comment system on behalf of others. > This is a bad argument and ignores everything else that has been said so far > - you can't override a large amount of reasonable arguments by generalizing > on a single shared property. I don't understand this part... Anyway, main reason why other session managers do not cover CSRF attack protection is lack of required features. In order to implement CSRF protection, system must have output buffering and rewrite mechanism. PHP has both. There is no reason not to implement CSRF attack protection especially if it is a major security issue. There should be very good reasons to decline this RFC. I don't see convincing reasons, yet. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
