Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81465
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.44 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
Date: Sat, 31 Jan 2015 11:44:57 +0900
Message-ID: <CAGa2bXb1xnOkYtiwonDU+HxUR0JKxi05TANRcgLh9-6ALR97tg@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c11a98678eda050de9b730
Subject: Session: More strict session data management
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c11a98678eda050de9b730
Content-Type: text/plain; charset=UTF-8

Hi all,

Current session module manages session data lazy manner.

session_regenerate_id() does not delete old session data and leave it
accessible undefined period. i.e. It survives as long as it's accessed
before expiration time.

This is security threat when attacker steal session ID.

session_regenerate_id() has option to delete old session data.
session_regenerate_id(TRUE) deletes old session data, but this option
is disabled by default since it causes race condition. i.e. User may get
empty session.

I would like to propose more strict session data management when
session.use_strict_mode=On or enabled always. (BTW, I'm willing to remove
use_strict_mode, enable it always)

1. Enable old session data deletion for session_regenerate_id().
2. When session data is deleted, add "hidden" deletion timestamp
   to $_SESSION.
3. When to be deleted session data is loaded, session module checks
  if it is accessible by comparing "hidden" timestamp in $_SESSION.
  If it is accessible, session module initializes session without "hidden"
  timestamp. If it is not accessible, session module actually deletes
  the session data and create new session.

The "hidden" session deletion timestamp may be implemented as
$_SESSION['__SESSION__DESTROY__'.session_id()] = time() + 60;
Session module creates "'__SESSION__DESTROY__'.session_id()" automatically
upon session_regenerate_id() call.

With this behavior, session module *always* deletes obsolete session data.

The reason that rather long delay is needed is wireless networks. Wireless
network is unstable and may have very long delay. e.g. Imagine you're in a
elevator. 60 seconds may be too short for some applications. Therefore,
there
will be "session.destroy = 60" INI setting.

It is also good to have means to notify obsolete session data access to
script.
session_status() will have new destroyed status.

As I described already, current session management is lazy to delete
obsolete
session data. New behavior is much stricter than now and there is no exposed
internal data to users(script). The "hidden" timestamp only exists in
obsolete
session data. New behavior requires less GC also.

Comments are appreciated.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c11a98678eda050de9b730--