Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73330
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXavdsU8LMoA9f2CDgTGzKsMhFdB6aVU2pO5WAXqjtBJKg@mail.gmail.com>
References: <CAGa2bXYJqGqegGy=rYcDBXd8RmFFR9j=p2m63ZVSADoga+vwhg@mail.gmail.com>
 <20140319080229.GA83863@mail> <CAGa2bXZiGJO+ioJ1qV3YUQVpU9-5TbmdH0WaXmWHxZ_6umYoOQ@mail.gmail.com>
 <20140319111131.GB83863@mail> <CAGa2bXa=ib0nrTRzXYtvXos=_mn9jBH4Q+UqipK5P4bLYzXuVA@mail.gmail.com>
 <20140320082346.GA61204@mail> <CAGa2bXaf+5_Zo+JGz9GnunJC0qoLESaHowr2VSKxJxbKhHPM+A@mail.gmail.com>
 <20140320091326.GA65574@mail> <CAGa2bXavdsU8LMoA9f2CDgTGzKsMhFdB6aVU2pO5WAXqjtBJKg@mail.gmail.com>
Date: Thu, 20 Mar 2014 18:26:31 +0900
Message-ID: <CAGa2bXax-jqicPo-dK2yfd1objqwR4Lsk7YaDDGYYfLbJOc33Q@mail.gmail.com>
To: Mateusz Kocielski <shm@digitalsun.pl>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113393c8b76d1d04f5065f4b
Subject: Re: [PHP-DEV] [RFC] [Discussion] Secure session_regenerate_id()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113393c8b76d1d04f5065f4b
Content-Type: text/plain; charset=UTF-8

Hi Mateusz,

On Thu, Mar 20, 2014 at 6:19 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

>
> On Thu, Mar 20, 2014 at 6:13 PM, Mateusz Kocielski <shm@digitalsun.pl>wrote:
>
>> On Thu, Mar 20, 2014 at 05:30:36PM +0900, Yasuo Ohgaki wrote:
>> > Hi Mateusz,
>> >
>> > On Thu, Mar 20, 2014 at 5:23 PM, Mateusz Kocielski <shm@digitalsun.pl
>> >wrote:
>> >
>> > > > > I agree. But we've got more factors here, it's not a simple tool
>> for
>> > > > > detection
>> > > > > of crimes. If we let "old session" live for x secs, what will
>> happen to
>> > > > > changes done to the old session? How do you want to resolve that?
>> We
>> > > should
>> > > > > find a balance between complexity and security.
>> > > > >
>> > > > >
>> > > > Currently we have poor mitigation. My proposal provides better
>> > > mitigation.
>> > >
>> > > I still don't see how you want to handle inconsistency between
>> sessions. It
>> > > seems that your RFC silently ignores that issue.
>> >
>> >
>> > I'm not sure which inconsistency. Could you specify/describe it?
>>
>> Consider following scenario:
>>
>> 1. session_regenerate_id(..) is called
>> 2. request to /update_session with old session id is done (some key-value
>> in
>> session is changed) - with your change this request will succeed
>> --- from here user uses only new session -
>> 3. updated key-value is missing in new session
>>
>> (same scenario can be triggered now if old session is not deleted)
>
>
> This race condition will not change with or without my proposal.


I should be more precise.
This race condition will be problem with future RFC not written yet.
Problem is a little differ, though. It's addressed and there is solution
for it.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113393c8b76d1d04f5065f4b--