Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73323
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.182 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAEZPtU4TaWSxnYqvceVKPgZJivheRK_M3ynpvasnh+a6+1ps0w@mail.gmail.com>
References: <CAGa2bXYJqGqegGy=rYcDBXd8RmFFR9j=p2m63ZVSADoga+vwhg@mail.gmail.com>
 <5329E37C.5000106@sugarcrm.com> <CAGa2bXaDA=EhqgxZLqkBjTJqPyeogma1oC8L8NiTKx3WKp-rUg@mail.gmail.com>
 <532A43C5.309@sugarcrm.com> <CAGa2bXb74KKizUbN_CuEVJwOFDUBUBYe_6deWLk1A9CBhGHZbg@mail.gmail.com>
 <CAEZPtU4TaWSxnYqvceVKPgZJivheRK_M3ynpvasnh+a6+1ps0w@mail.gmail.com>
Date: Thu, 20 Mar 2014 17:28:03 +0900
Message-ID: <CAGa2bXbJNu0TxAD8FHuVs9nguwj1X=o4khV6FkqebMhU4y=QVg@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11380016a8961e04f5058e55
Subject: Re: [PHP-DEV] [RFC] [Discussion] Secure session_regenerate_id()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11380016a8961e04f5058e55
Content-Type: text/plain; charset=UTF-8

Hi Pieere,

On Thu, Mar 20, 2014 at 1:02 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> On Thu, Mar 20, 2014 at 4:07 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > 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.
>
> I agree with Stas here. I have been asking for past CVEs related to
> the possible issues you described here, I did not find any and sadly
> did not get any information which could change my mind.
>
> Most of what is described here should be covered by the application
> layer as it really depends on what developers need. Per se, the
> current session module is safe. It may not cover all edges cases but
> this is why we have the necessary API to allow developers to add
> behaviors, as desired (not necessary required, which is the point I
> agree with Stas here).


I think most PHP users are using session module as complete tool for their
web applications.
They rely on it for proper session management even if the manual explains
HTTP session
management cannot be trusted.

Since HTTP session management cannot be trusted, ID regeneration is
required to mitigate
risks. However, current session_regenerate_id() behavior can be called
optimum hardly.
It does not make sure obsolete session is deleted nor does not raise alarm
for possible
abuse. When it deletes old session, it is unreliable.

Attack methods/patterns for password clacking are evolving. Therefore,
password authentication
is evolving to multi-factor authentication due to raising risks. Password
hashing methods
are evolving due to technology/technique evolution. Session management
should evolve also.
There are tools like BackTrack and risk of session hijack is raising.
e.g.  MITM is casual attack and real risk for web developers.

I would say current behavior was acceptable 10 years ago, but it would not
be
acceptable 10 years later for sure. I think we are in the middle of it.
HTTP session
management is center of web security and it would be the same next 10
years.
Hardening session management where it is possible worth the effort. IMHO.

I don't mind write document to help users to do proper HTTP session
management with
current session module. However, I would like to spend my time to make
session module
to manage session properly rather than spending time for document. It makes
sure
that all PHP users do precise session management unlike documentation.

Leaving active session behind is unacceptable risk to me.
I fail to understand why some of us do not see the risk of current HTTP
session
management and/or it should be part of user code.

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.

For serialization, serializer wrapper is called instead of serializer.
The wrapper accepts 2 hashes, 1 serializer as parameter. Hashes are
$_SESSION and internal data contains time stamps. It serializes both hashes
and return strings like

[HEADER: contains size of serialized data]+[serialized
$_SESSION]+[serialized internal data]

This returned string is passed to save handler.
When serializer wrapper is enabled, the wrapper is used instead of
serializer. Unserilize
does reverse operation of serialize. No internal data is exposed to users.

How about serializer wrapper?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11380016a8961e04f5058e55--