Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69419
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXaH7B3vO=4Ap2hTfwUEp4Sw-PoK-omK6r=O71OUNksDxg@mail.gmail.com>
References: <CAGa2bXbh6dOf41nZ0r-RuRtkCuuiA=r=SnxS+A1+GgqFXPGOWQ@mail.gmail.com>
	<CABBJUpdNr6McK6Q4qtztiYYG9CKZF7AeUdvo3YM+W0S87f8nDg@mail.gmail.com>
	<CAPwsocEwM_A3YraxZmJEXjBxaGgTZhfv711801bwtHLfJfNh+Q@mail.gmail.com>
	<CAHMUw2EQuT-y2Ho85QXhDdtysTWC=4FyY4nK9i-yR7qGqk6M=Q@mail.gmail.com>
	<CAPwsocGh-e1xAmvxgBF6St++9TBdW6uzRy8Xu4Jhb4p-N4vFvQ@mail.gmail.com>
	<CAGa2bXaH7B3vO=4Ap2hTfwUEp4Sw-PoK-omK6r=O71OUNksDxg@mail.gmail.com>
Date: Mon, 30 Sep 2013 15:51:33 +0800
Message-ID: <CAHMUw2EU_cSv_OL=PDm3mK3hURp=X=n0P1TbjrHZfjaPcKZJqA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Leigh <leight@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b62249ae0f1fb04e7951a01
Subject: Re: [PHP-DEV] Regenerating session ID automatically when IP address
 has changed
From: tjerk.meesters@gmail.com (Tjerk Meesters)

--047d7b62249ae0f1fb04e7951a01
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Sep 28, 2013 at 6:47 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Leigh,
>
> On Fri, Sep 27, 2013 at 7:12 PM, Leigh <leight@gmail.com> wrote:
>
>> So on a successful session hijack (correct SID, new IP) the attacker
>> gets a new SID and keeps the valid session while the legitimate user
>> gets kicked out.
>>
>> Not seeing how that improves things at all.
>>
>
> There are 2 improvements
>
> 1. Generally speaking, more frequent session ID regeneration is more
> security.
>

This could make it more difficult for an attacker to take advantage, but
then I would like to see other changes as well, for instance:

a) Enable session.use_strict_mode by default.
b) Enable session.use_only_cookies by default
c) Enable session.cookie_httponly by default.
d) Use a stronger session.hash_function with more
session.hash_bits_per_character by default.
e) Enable session.cookie_secure on secure connections (I know this is not
going to be fool proof).

There are probably more settings we could change to more security aware
values.


> 2. Detection/indication of attacks is good for security.
>

This is an interesting aspect; when an old session identifier is presented,
from the end-user's perspective, either:
a) They get redirected to the site's login page; the user gets redirected
to the login page and unless they suspect their session was compromised (if
that's indeed what happened), they will sign in again (the browser may have
remembered the credentials, so it's a single click operation and they're
back), or

b) If the system uses a (naive) "remember me" feature, a new session gets
created automatically and they don't notice a thing.

From the server-side's perspective, the cookie value could simply not be
found, assuming that the regeneration also deletes the previous session
data; there's no discernible difference between an old session and a
compromised session afaict. This would be a different story if the session
engine would keep track of past values as well.

Btw, what I'm also missing from this proposal is the ability to hash
against other factors, i.e. user agent. ISP's may use a transparent HTTP(s)
proxy, most companies use an NAT, so being able to detect user agent
changes may improve detection further.

The bottom line is: if the system can make it easier to detect intrusion,
it should be in the system and it should be easy :)


>
> Showing active sessions and possible intrusion/source of intrusion is
> applications
> task, but session ID regeneration upon IP change is easy and simple task
> for
> session module. Why not have it as optional feature?
>
> It would be better than nothing if end user has chance to know the attack.
> IMHO.
>
> Many systems have notification mail when password or important information
> have changed. Damage has already done if it is an attack, but user could
> know
> there were attack. Session ID regeneration is the same kind of counter
> measure.
>
> If app supports number of active sessions, user could verify if they are
> under
> session hijack attack or not. It's up to app, though.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>



-- 
--
Tjerk

--047d7b62249ae0f1fb04e7951a01--