Re: Re: Fixing halfway implemented session management - timestamp based session management OR remove session_regenerate_id()

Hi Stas, On Mon, Sep 26, 2016 at 3:18 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote: >> Please read session_regenerate_id() example #2. >> >> Example #2 Avoiding lost session by session_regenerate_id() > > In this example, why you do session_commit() in my_session_start()? > There's no point in writing stale session. > > I also see no code that actually removes old sessions - is it by design? Yes. It's by design. In general, users should not delete session data manually, but should let GC do the job. It's described in new Session Security manaul page. > > I am also not sure why this code messes with session.use_strict_mode - > which user code is not supposed to do, this should be possible to do > without doing that. Because current session module cannot distinguish if session ID come from outside, i.e. session cookie/trans sid, or script. This could be improved, but user should control session.use_strice_mode currently. > > In fact, thinking about it, I think the following can be done relatively > easily: make session_regenerate_id(), if called with false, to put magic > entries into old session that specify a) when it was regenerated and b) > what was the new session ID. I realized that accessible magic values in $_SESSION were unpopular from discussions. I proposed minimum change also and It was declined. My last proposal was rather complex, but it does what you're suggesting. Differences are, it hides timestamp from $_SESSION, timestamp is only viewable via API. > > This would allow to implement example #2 in userspace much cleaner, and > if we want to implement it further in session, we could add option to > session_start to do so. But one could also use this data in your own > session system if one wants to do it slightly differently. > > This still leaves the question of old sessions, but it's not new as > session_regenerate_id(false) already exists and in general we have GC. I guarantee it works. However, it's not precise/secure. Unprecise - Cannot make sure obsolete session removal. - Accessibility to obsolete session is controlled by GC. (Attackers can keep it alive by simply accessing it) Unsecure - No way to detect possible session hijack. (My last proposal omit raising error because people seem to care about BC too much rather than security. Adding error/exception is matter of few lines) Timestamp based management is mandatory for precise/secure session management. Question is who will be responsible? Session module or User? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net