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 [email protected] to get a copy of this message
Hi Stas,

On Fri, Mar 21, 2014 at 4:57 AM, Stas Malyshev <[email protected]>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
[email protected]


Thread (23 messages)

« previous php.internals (#73347) next »