TalkPHP - View Single Post

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;

12-04-2008, 10:58 PM	#2 (permalink)
Wildhoney La Vida es Sueño Join Date: Sep 2007 Location: Oldham Posts: 2,280 Thanks: 90	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; __________________ The man who comes back through the Door in the Wall will never be quite the same as the man who went out.