Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73320
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <532A43C5.309@sugarcrm.com>
References: <CAGa2bXYJqGqegGy=rYcDBXd8RmFFR9j=p2m63ZVSADoga+vwhg@mail.gmail.com>
 <5329E37C.5000106@sugarcrm.com> <CAGa2bXaDA=EhqgxZLqkBjTJqPyeogma1oC8L8NiTKx3WKp-rUg@mail.gmail.com>
 <532A43C5.309@sugarcrm.com>
Date: Thu, 20 Mar 2014 12:07:53 +0900
Message-ID: <CAGa2bXb74KKizUbN_CuEVJwOFDUBUBYe_6deWLk1A9CBhGHZbg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113437fcab97ab04f50115db
Subject: Re: [PHP-DEV] [RFC] [Discussion] Secure session_regenerate_id()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113437fcab97ab04f50115db
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Thu, Mar 20, 2014 at 10:26 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > I'm recognizing reliability/availability as a part of security.
> > ISO 27000 defines it's a part of security.
>
> Let's not parse semantics here. Declaring something that is not security
> issue - i.e. would not lead to unauthorized access, data disclosure,
> etc. - as security issue only makes real security issues drown in the
> noise and not get proper priority. And mislead people into thinking that
> existing ways - which are fine - are somehow insecure and make them not
> use them.
>

I'm OK with different name.
Lines between security issue or not is vague.
Session management is closely related to authentication/authorization.
Therefore,
I'm recognizing it as security issue, but it's not important. I agree that
discussion
wouldn't worth it.


>
> > Secure behavior by default is the way to go. IMO.
> > There are too many pitfalls in web application. We should try to
> > mitigate them
> > as many as possible where it could be done.
>
> We're not implementing web application in the engine. It's the task for
> the developers and libraries. Implementing something that can easily be
> implemented in userspace in the core only makes it less flexible and
> makes core more heavy to maintain. We're not really saving much code
> there - in fact, we're adding more code as now the developer has to deal
> with exceptions. If the session would be silently deleted, it would
> probably be ok, even though still a narrow use case whcih I don't think
> should be in the engine, but throwing hard errors doesn't look useful at
> all.


I'm looking for proper HTTP session management for session module.
Regenerating session ID is basic task of HTTP session management.
(I would like to discuss proper expiration also, but I'll leave it for now)

I'm proposing time stamp in $_SESSION because it does not require
overhead, complexity nor BC. If compatibility/availability would be an
issue, it can be implemented by another serializer and hide all time
stamps needed. Session module should support time stamps,
though.

I may propose serializer based solution also. It encapsulates time
stamps. There are number of implementations. Generic one that I
think of now is "serializer wrapper". It wraps current serializers to
have both user and system(session module) data. e.g. You can think
of this as array of serialized data.

What do  you think about this?

Session manager should manage session properly rather than leaving
its tasks to users. IMHO.

I also use PHP for convenience and would like to concentrate what
is important for the objectives. I would rather rely on PHP feature for
basic things like session management/escaping/etc.

Let's make PHP do the basic job for web developers/applications.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113437fcab97ab04f50115db--