Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73229
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: <CAPhkiZxAc_88dt469JuiAXrkRoDLfJ=Mtcasqr6vLcj_iDg1ig@mail.gmail.com>
References: <CAPhkiZz4bN8XQOtkeyXMArgdngHVjHY+0gf-Qnb9RY8xrxOZTg@mail.gmail.com>
 <CAGa2bXbF5ip_rzt+P3vc1ReEU-RoP5vGOnrTTDpTLeMGSLDrAg@mail.gmail.com> <CAPhkiZxAc_88dt469JuiAXrkRoDLfJ=Mtcasqr6vLcj_iDg1ig@mail.gmail.com>
Date: Tue, 18 Mar 2014 05:03:44 +0900
Message-ID: <CAGa2bXb5inv+aw8Y1502E+iHQautNggJaHj8RvqsAdo4MAgCDw@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133e30817144104f4d2ed34
Subject: Re: [PHP-DEV] Solution for session_regenerate_id() issues
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1133e30817144104f4d2ed34
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Mon, Mar 17, 2014 at 9:02 PM, Andrey Andreev <narf@devilix.net> wrote:

>
> On Mon, Mar 17, 2014 at 1:47 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > Hi Andrey,
> >
> > On Mon, Mar 17, 2014 at 8:00 PM, Andrey Andreev <narf@devilix.net>
> wrote:
> >>
> >> I don't think delaying deletion is a good idea, it just brings more
> >> complexity to the whole process and I can't really imagine how it
> >> would be handled, since PHP is not run as a daemon - this is the
> >> reason why the session GC is triggered by chance instead of running as
> >> some type of a cron job.
> >>
> >> Applications usually handle this by not regenerating session ID during
> >> an ajax request. Most JS frameworks would send a 'X-Requested-With:
> >> XMLHttpRequest' header to provide a way for Ajax detection, and PHP
> >> frameworks have helper methods to look for that header. Even if they
> >> don't - anybody can implement a similar solution for their own
> >> application.
> >>
> >> With that said, I'd rather give a +1 for changing the
> >> session_regenerate_id() default action from "don't delete" to
> >> "delete", like you've previously suggested.
> >>
> >> Btw, I wouldn't worry about stolen session IDs ... if somebody steals
> >> it once, they'll do it after regeneration as well. Session ID
> >> regeneration is only effective against brute-force attacks.
> >
> >
> > Do you realize that stolen session could be used by attackers without
> > any indication currently? Unlike read_only, this is not about legitimate
> > user's
> > request. It's very easy to set up fake router by ARP spoofing. Stripping
> > HTTPS
> > is simple task and almost all users don't care about if HTTPS is used or
> > not.
> > Script kiddy is enough to steal session ID.
>
> You're making it sound easier than it is, but otherwise - yes, I
> realize that ... what makes you think that I don't? Why are you even
> bringing this up?
>

Because I wrote how to handle session regeneration securely in this thread.


> > To mitigate regeneration risk and keep session availability at the same
> > time,
> > delayed deletion is mandatory. It's also better than immediate deletion
> > because
> > it allows to detect possible attack. As you mentioned, if session ID
> could
> > be
> > stolen, session ID may be stolen as many times as attacker wants.
>
> How do you detect attacks by delaying deletion? And what do you do if
> you detect an attack to protect yourself from it? If it has to allow
> valid requests, it will also allow attackers because session ID is the
> only thing that you're looking for.
>

It was written in previous mail in this thread.

Users may set timeout flag in $_SESSION array and check the value if
session could be active or not. In order to do that in user land, one may do

session_start()
// ** check timeout flag **
if (!empty($_SESSION['VALID_UNTIL']) && $_SESSION['VALID_UNTIL'] < time()) {
   session_destroy();
   trigger_error('Possible session hijack attack detected');
   die('Possible session hijack attack detected');
}

// ** set timeout flag **
if ($_SESSION['LAST_REGENERATE'] < time() + 600) {
  $_SESSION['VALID_UNTIL'] = time() + 60; // Shorter is better, but rather
large value is set for lost radio/hand over/etc. Old session is allowed to
use as valid session for 60 seconds.
  session_commit(); // Need to save above data in old session.
  session_start();
  $_SESSION['LAST_REGENERATE'] = time(); // Update regenerate time here.
  session_regenerate_id(); // New session ID and old session data with old
session ID is left
  unset($_SESSION['VALID_UNTIL']; // This session should not be deleted
later.
}

Above example is allowing 60 seconds window for legitimate user and
attacker. If session is hijacked,
 - User could know attack if session ID is regenerated by attacker.
 - Attacker could know there is hijack protection if session ID is
regenerated by user.

LAST_REGENERATE is better to be NEXT_REGENERATE with 'lazy_write' to
prevent unneeded session writes as I wrote in different mail in this thread.

Exception is easier to handle error. I would like to implemented it with
exception.


> > Keeping session ID secure as much as possible is session manager's task.
>
> Nobody said it isn't.
>

Good.


>
> > Current mitigation that relies on GC is far from optimal and not
> acceptable.
>
> I haven't said that it is optimal. I only explained why the GC works
> the way it does currently.
>

OK.
It's not enough and it could be better.

 > 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.

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.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1133e30817144104f4d2ed34--