Re: [RFC] [Discussion] Secure session_regenerate_id()

From: Date: Thu, 20 Mar 2014 22:28:57 +0000
Subject: Re: [RFC] [Discussion] Secure session_regenerate_id()
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-73347@lists.php.net to get a copy of this message
Hi Stas, On Fri, Mar 21, 2014 at 4:57 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote: > > Anyway, I don't want to write code that wouldn't be accepted. > > I think "serializer wrapper" might be alternative choice. It works as > > follows. > > As a PECL extension that provides configurable serializer option - sure, > why not. As the part of the core - I don't see common enough use case. > If this extension proves popular and everybody would be using it, we can > merge it into core then. It requires session module modification. Session module should have flag to enable/disable serializer wrapper, should pass additional parameters, should maintain internal state. I guess you mean PECL session manager extension. It may be a good start. This way, I don't have write number of RFCs and care about misunderstandings like "Trying to solve that is unsolvable", "Excluding XHR is solution", etc. For precise/secure session management, not only session_regenerate_id() but also expiration handling, etc should be handled more strictly to be secure than now. Current session module does not manage session precisely/securely. This is true since users _must_ write number of codes to manage session precisely. All of them cannot be performed by session manager. Example is how to handle exceptions. However, most of them can be done in session manager. I choose session_regenerate_id() to discuss, since it is mandatory for session security and it is easy to understand what's wrong with it now. i.e. Which one is secure "Leave obsolete session indefinite period vs. Invalidate obsolete session with certain period" is clear to me. I think this is clear for you, too. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net

« previous php.internals (#73347) next »