Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73252
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.174 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZxiXdHYo90cm=uZ+t2+DOuh9OWmkVNnnAGXC=TfznCvXw@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>
Date: Tue, 18 Mar 2014 08:07:21 +0900
Message-ID: <CAGa2bXaU8g6eApd+u4G5LZCkBhR=Qt3NmL0gyGxxQztZr4gxvA@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3dba8c1448e04f4d57d1a
Subject: Re: [PHP-DEV] Solution for session_regenerate_id() issues
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3dba8c1448e04f4d57d1a
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Tue, Mar 18, 2014 at 6:01 AM, Andrey Andreev <narf@devilix.net> wrote:

> >> 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.
>
> 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.


>
> >> > 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.


>  - 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.


>
> The first can also be implemented in userland with something like this:
>
> $_SESSION['last_regenerate'] = time();
> session_regenerate_id(FALSE);
>
> // Later, detection:
>
> if (isset($_SESSION['last_regenerate']) &&
> $_SESSION['last_regenerate'] > time() + 60)
> {
>     session_destroy();
>     // send email to webmaster
> }
>

For the regeneration, this is enough.
The code is made to illustrate for both session expire and session
regeneration by session module.
I should have written code for destroying VALID_UNTIL, too. I'll add it in
new RFC.

> 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.


>
> But speaking of sessions and security, I'll mail you privately about
> something because I didn't see an option in the bug reporting form to
> mark it as a private one.
>

If you choose "security" bug type, it's hidden.
Or if it's related to session module, you might want to send mail directly
to me to discuss.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3dba8c1448e04f4d57d1a--