Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29888
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain powertrip.co.za designates 72.21.46.202 as permitted sender)
In-Reply-To: <465C6002.5080209@lerdorf.com>
References: <465C5D1D.7040206@gmail.com> <465C6002.5080209@lerdorf.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/alternative; boundary=Apple-Mail-3-297288992
Message-ID: <2D27B2C2-76D1-4A04-B414-53A6E24AF950@powertrip.co.za>
Cc: Stut <stuttle@gmail.com>,
 internals@lists.php.net
Date: Tue, 29 May 2007 21:45:51 +0200
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Subject: Re: [PHP-DEV] Session security
From: jacques@powertrip.co.za (Jacques Marneweck)

--Apple-Mail-3-297288992
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


On 29 May 2007, at 7:16 PM, Rasmus Lerdorf wrote:

> Stut wrote:
>> Hi all,
>>
>> Just wanted to get your opinion on a discussion currently going on on
>> the general list.
>>
>> Why does the PHP session extension not use something like the user  
>> agent
>> to validate that a session ID has not been hijacked? Or is this
>> something that just hasn't been implemented yet?
>
> The user agent is trivial to spoof.  If you are going to hijack
> someone's session, it is very easy to also hijack their user agent
> string, so I don't see how that solves anything.
>
I think he's trying to figure out how to do something similar to using a
'browser fingerprint' as part of his session.  One thing I noticed with
doing creating and checking a 'browser fingerprint' a few years back
was depending on what you were doing / using it would change things
between requests.

With web requests, a lot of things are easy to spoof from the client  
side.
Locking a session to an IP address has it uses provided the user does
not make their requests from various IP addresses like the AOL proxy
farms used to do afaik.

If you are really paranoid, use SSL and regenerate the session  
identifier
on the first request from the user.  That way it's not known.  It's  
generally
advised to regenerate the session identifier on privilege change.

There is no real way of detecting if a session has been hijacked  
given for
example for .za users we tend to be transparently proxied for  
requests to
international sites, so forcing locking a session to a IP will lock  
that session
to an ISP's netcache.

Something along the lines of:

if (!isset($_SESSION['initiated'])) {
     session_regenerate_id();
     $_SESSION['initiated'] = true;
}

When you change privilege do something along the lines of

     session_regenerate_id(true);

Which will delete the previous session and keep the current session  
information.

YMMV.

Regards
--jm

> -Rasmus

--
Jacques Marneweck
http://www.powertrip.co.za/
http://www.powertrip.co.za/blog/
http://www.ataris.co.za/

#include <std/disclaimer.h>



--Apple-Mail-3-297288992--