Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72585
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52FDD23F.9010808@sugarcrm.com>
References: <CAGa2bXYXuQ6hhbzTMne7SgErFfKfJ01w5RquAgA4GBAAzN7hAA@mail.gmail.com>
 <CAGa2bXauh+PoSNvFf38eqQkvQ6y_9cgga2DENmV35a9Ncs2Dtw@mail.gmail.com> <52FDD23F.9010808@sugarcrm.com>
Date: Fri, 14 Feb 2014 18:38:35 +0900
Message-ID: <CAGa2bXb4T47_T3N4J0b5+Pp+kwqJO64mO3AuRm7bqT4S75dTaA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3352842d17104f25a9467
Subject: Re: [VOTE] RFC: Introduce session_start() options - read_only,
 unsafe_lock, lazy_write and lazy_destroy
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3352842d17104f25a9467
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Fri, Feb 14, 2014 at 5:22 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > When browser accesses to the personal page, application checks
> > authentication status and returns HTML page for it if user's session is
> > authenticated. Browser tries to load images which require authenticated
> > session. If session_regenerate_id() is called (timeout, etc) while
> > loading images, what happens? If old session data is deleted, other
> > images cannot be loaded because requests are done by old session ID.
> > This scenario valid since current browser uses multiple connections to
> > load resources of a web page.
>
> If anything was called that makes old session invalid, any further
> access to this session should result in failure. How the app does it,
> does not matter really. Doing otherwise would be a huge security problem
> - you removed the session, but you still can access it. Timing does not
> matter - milliseconds of unauthorized access may be enough to compromise
> an account. So I don't see any use in "delete, but only with delay"
> option - if the data still valid, no reason to delete, if not valid -
> should be deleted immediately.


Ideally, it is better to be deleted immediately.
Due to the limitation of web technology, it is not possible without
unwanted behaviors.

 - Limitation: It is impossible to force browsers access resources one by
one.
 - Unwanted behaviors: Some accesses may be denied, image/iframe/js
content/etc not accessible by vanished session.

As I explained, current work round for the limitation (keep "must be
deleted" session) allows access to attackers indefinite period of time. It
will be reduced from indefinite to seconds with this RFC.

When ideal solution cannot be chosen, we should choose better.
Allow attackers seconds or indefinite attack time?
Users may set as short as 1 second with this RFC.

Implementation/setting of delayed deletion is debatable, but choice is
obvious to me...

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3352842d17104f25a9467--