Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73292
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.178 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZxOV4GzjHOvaC7wTnnyhWuiG7w6VU0um19pAUnGDp=SxA@mail.gmail.com>
References: <CAPhkiZz4bN8XQOtkeyXMArgdngHVjHY+0gf-Qnb9RY8xrxOZTg@mail.gmail.com>
 <CAGa2bXbF5ip_rzt+P3vc1ReEU-RoP5vGOnrTTDpTLeMGSLDrAg@mail.gmail.com>
 <CAPhkiZxAc_88dt469JuiAXrkRoDLfJ=Mtcasqr6vLcj_iDg1ig@mail.gmail.com>
 <CAGa2bXb5inv+aw8Y1502E+iHQautNggJaHj8RvqsAdo4MAgCDw@mail.gmail.com>
 <CAPhkiZxiXdHYo90cm=uZ+t2+DOuh9OWmkVNnnAGXC=TfznCvXw@mail.gmail.com>
 <CAGa2bXaU8g6eApd+u4G5LZCkBhR=Qt3NmL0gyGxxQztZr4gxvA@mail.gmail.com> <CAPhkiZxOV4GzjHOvaC7wTnnyhWuiG7w6VU0um19pAUnGDp=SxA@mail.gmail.com>
Date: Wed, 19 Mar 2014 11:10:25 +0900
Message-ID: <CAGa2bXbAQuhMASwCbsCrfQ0caYBcD7M-xZV2+n2Dj2RfPstYYA@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133e30842755104f4ec2ae6
Subject: Re: [PHP-DEV] Solution for session_regenerate_id() issues
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1133e30842755104f4ec2ae6
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Tue, Mar 18, 2014 at 7:23 PM, Andrey Andreev <narf@devilix.net> wrote:

> On Tue, Mar 18, 2014 at 1:07 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> >> I don't get it ... I thought you were proposing a solution in PHP
> >> itself, not userland code. Am I missing something?
> >
> >
> > I would like to fix this by PHP. i.e. session module.
> > Therefore, I'm trying to change session module behavior.
> >
> > It's an example of proper/reliable session ID regeneration and session
> > expiration
> > handling in user land.
>
> The userland solution works because it emulates a certain state of the
> session between requests. I don't see how you'd do that in PHP itself
> and even if you could, it might not be what everybody wants. I for one
> would expect if I tell PHP to delete something, that thing to get
> deleted immediately.
>

Better security is what user wants.
Besides, if session manager does its jobs, then user can concentrate
what is important for them. i.e. Making a good apps.


>
> >> >> > Immediate deletion is worse than delayed deletion.
> >> >>
> >> >> I don't agree with this, but I guess we'll have to agree to disagree
> on
> >> >> it.
> >> >
> >> >
> >> > Letting user and/or attacker to know there is protection against
> session
> >> > hijack
> >> > is good for better security. It wouldn't prevent attack, but it
> >> > mitigates
> >> > risk.
> >> > It's the same as having surveillance camera for security.
> >>
> >> Surveillance cameras may scare off a random criminal in real life, but
> >> this is because it would film them and they'd be easily identified.
> >> We're on the internet here and everybody can hide themselves, alerts
> >> don't scare the kiddies.
> >>
> >>  - Letting the _application developer_ about an alleged attack is good.
> >>  - Letting the user (as in an end user, just somebody using the site)
> >> know about is irrelevant to security and bad from a usability point of
> >> view, nobody likes to see errors in websites, to say the least.
> >
> >
> > User is the only one that can identify which connection is legitimate or
> > not.
> > Therefore, app developers are advised to implement list/history of active
> > sessions.
>
> Advised !=  required.
>

I would say it's required for security sensitive sites.


> User-accessible history != throwing errors in people's faces
>

Letting user know that there might be possible attack is something user
needs.

If you really don't want to let users know possible attack, you may ignore
it.
i.e. Just ignore errors by your code.


>
> >>  - Letting the attacker know about it is not just not good, it's
> >> really bad. It further exposes details about the application to the
> >> attacker; details that can be used to aid them in a more sophisticated
> >> attack. They now know that there's something stopping them at some
> >> point and so they learn how to avoid it.
> >
> >
> > Consider which is good for attackers.
> > Even dummy surveillance camera is good for security. It is good alarm
> > attackers that they have been watched to prevent further attacks.
>
> I already said this: we're on the internet, alarms are tools that can
> aid attackers, you don't scare them off with it. Anyway ... I already
> said that we'll have to agree to disagree on this, you obviously have
> a completely different opinion.
>

I'm sure that ignoring possible attack is what attacker appreciated.


>
> >> > I'm proposing session manager does its task to make session management
> >> > as secure as possible. I may agree with you if could explain why
> >> > immediate
> >> > deletion is better than delayed.
> >>
> >> It's simple - immediate deletion doesn't leave a time window for
> >> attackers to exploit.
> >
> >
> > As you and I point it out. Attackers may steal session ID as many times
> as
> > they want.
> > Immediate deletion would not provide surveillance, hence no mitigation.
> It
> > also brings
> > lost session issue for legitimate users.
>
> It's up to application developers to decide if and how to implement
> "surveilance", mitigation. I already explained previously how the
> "lost session" issue is solved currently by many applications and I
>

AJAX request is not the only request to web servers.
Besides, many modern applications are made with AJAX only and
using the same session ID is increasing the risk of hijack.


> see nothing wrong with it, you just can't make it a part of PHP
> because any similar solution is unreliable (it assumes
> JavaScript-triggered processes, PHP doesn't talk with JS) and
> ultimately the app designer's choice (what if my application doesn't
> use ajax?).
>

Making HTTP session management as secure as possible is session manager's
task.

 - Reliable session ID regeneration
 - Possible attack detection (if it's feasible)
 - Reliable session expiration

I think all of these are session manager's task, not other code/module.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1133e30842755104f4ec2ae6--