Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73305
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <20140319111131.GB83863@mail>
References: <CAGa2bXYJqGqegGy=rYcDBXd8RmFFR9j=p2m63ZVSADoga+vwhg@mail.gmail.com>
 <20140319080229.GA83863@mail> <CAGa2bXZiGJO+ioJ1qV3YUQVpU9-5TbmdH0WaXmWHxZ_6umYoOQ@mail.gmail.com>
 <20140319111131.GB83863@mail>
Date: Thu, 20 Mar 2014 03:33:09 +0900
Message-ID: <CAGa2bXa=ib0nrTRzXYtvXos=_mn9jBH4Q+UqipK5P4bLYzXuVA@mail.gmail.com>
To: Mateusz Kocielski <shm@digitalsun.pl>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1136c856cfff9804f4f9e4de
Subject: Re: [PHP-DEV] [RFC] [Discussion] Secure session_regenerate_id()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1136c856cfff9804f4f9e4de
Content-Type: text/plain; charset=UTF-8

Hi Meteusz,

On Wed, Mar 19, 2014 at 8:11 PM, Mateusz Kocielski <shm@digitalsun.pl>wrote:

> > > login and operates as user without HTTPS, then it's not our problem.
> > >
> >
> > Secure attribute does not matter if attacker is stripping HTTPS.
>
> You're right. But if user runs over transparent stripping proxy, then
> managing
> session by an attacker is easy (attacker replaces set-cookie from server
> to victim with own value, and sends proper session on every user request).
> User won't have an idea that something is wrong. Simply, running without
> https
> in insecure environment is asking for trouble and what you prospose won't
> help
> in this case.
>

Security measures are mitigation. HTTPS could be useless. It's the same.

 > I'm having hard time to explain why "detection" is better for security.
> > Surveillance camera does not "prevent" crime, but "identify" who did.
> > Surveillance cameras are good for security.
>
> 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.


 > BTW, almost all security measures are "mitigation".
> > Security measure does not have to "remove risk", but mitigates risk like
> > HTTPS.
> > Do you agree that HTTPS is security measure, right?
>
> Yes.
>
> >
> >  [...]
> > >  Problem of immediate old session deletion:
> > >
> > >     Make session ID regeneration unreliable. (Unacceptable)
> > > [...]
> > >
> > > I haven't found single issue in
> > > bugs.php.net that session_regenerate_id(TRUE) is a problem to any
> user.
> > >
> >
> > Of course, there aren't. session_regenerate_id(FALSE) is the default now
> and
> > random logout by race condition is hard to be noticed by developers.
>
> You might be right, I just found [1]. Note the shadowhand's post:
>
> [...]
> I think developers should be aware of the fact that HTTP is a stateless
> protocol and work around that fact, not try to "fix" it with hacks that
> will,
> with all due respect, end up causing more issues than they solve.
> [...]
>

I agree with his/her opinion. HTTP is stateless and we cannot force client
to
synchronize session ID. I'm proposing better/stricter work around than now.

http://forum.kohanaframework.org/discussion/1870/race-conditions-in-session-handling/p1

Thank you for the link.

Regards.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1136c856cfff9804f4f9e4de--