Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73217
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.213.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbF5ip_rzt+P3vc1ReEU-RoP5vGOnrTTDpTLeMGSLDrAg@mail.gmail.com>
References: <CAPhkiZz4bN8XQOtkeyXMArgdngHVjHY+0gf-Qnb9RY8xrxOZTg@mail.gmail.com>
	<CAGa2bXbF5ip_rzt+P3vc1ReEU-RoP5vGOnrTTDpTLeMGSLDrAg@mail.gmail.com>
Date: Mon, 17 Mar 2014 14:02:24 +0200
Message-ID: <CAPhkiZxAc_88dt469JuiAXrkRoDLfJ=Mtcasqr6vLcj_iDg1ig@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Solution for session_regenerate_id() issues
From: narf@devilix.net (Andrey Andreev)

Hi,

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?

> 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.

> Keeping session ID secure as much as possible is session manager's task.

Nobody said it isn't.

> 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.

> 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.

Cheers,
Andrey.