Stopping session hijacking

9three · 12-04-2008, 06:30 PM

Would this work?

PHP Code:


			
session_start();

session_regenerate_id();

if (session_regenerate_id() != $_SERVER['HTTP_USER_AGENT'])

{

$_SESSION = array(); 

session_unset();

session_destroy();

header('Location: index.php');

}

Wildhoney · 12-04-2008, 10:58 PM

One thing I used to do back in the days when I didn't use a framework, was to store items in the session data. I would create a fingerprint and then check that fingerprint was valid on every page load.

You could store the IP address, but some ISPs -- I think AOL, to name one, changed the user's IP address randomly so you can't rely on that, because an AOL user would be continually logged out. One thing I used was the browser data -- such as browser identifier, language, etcetera. Whilst these are not always present, what I assumed when I did it was that if they didn't exist, it wasn't a valid user -- perhaps a bot or something like that.

So whilst HTTP_USER_AGENT doesn't always exist, you could do the same as me and assume if there isn't a HTTP_USER_AGENT then it's not a user, and therefore throw an error instead. If there is a HTTP_USER_AGENT then create a fingerprint (perhaps with MD5() or SHA1()) and then check to ensure they match on every page load. Although this is not absolute hack-proof, it makes it even harder than it already is in requiring the hacker to know the user's browser details as well when attempting to hijack a session.

There are, of course, plenty of other ways to ensure your session layer isn't compromised, which are well documented. However, at least in my opinion, your approach is certainly correct in theory.

Further reading:

TalkPHP: Why you shouldn't rely on an IP;

TalkPHP: Understanding the life of a session;

Sitepoint: Notes on PHP Session Security;

9three · 12-04-2008, 11:12 PM

Thanks for the info.

Yes I figured in theory that the method was a good way to go. But, sometimes you miss out something so it's always good to a 2nd opinion.