Hi, 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. > > > > > 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. 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. Cheers, Andrey.
