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>


Reply via email to