Session hijacking can occur on standard HTTP pages through various means including packet sniffing. It can also occur when SSL isn’t implemented correctly. There are measures you can take to make session hijacking difficult, if not impossible, for all but the most experienced hackers.
I’ll go over these briefly and let you make up your mind how much security you need.
Probably the most important thing is to make sure PHP is using only cookies for sessions. If a session ID is included in a URL, simply posting the complete URL somewhere could invite session hijacking attempts. Also, using session regeneration techniques would break the back button – the URL would be different each time.
Session cookies are not immune to interception, but they can be made worthless to anyone but the users who’re tied to them. Human beings can’t move as fast as sessions can be changed, even if they gain access to the session files on the server. Speaking of session files, they need to be stored in a place only accessible by one server user and one website at a time.
When checking the PHP runtime settings, this flag should always be set to “1” (without the quotes). You shouldn’t rely on it and you should make sure you set it while setting the session cookie when configuring your application. One thing to be aware of is that you have to set the session cookie name before you can set the session cookie parameters. You also have to use the session name when destroying the session.
While this is disputed as effective against XSS among developers, any extra protection measure (regardless of how insignificant it may seem) against session hijacking is worth implementing.
When using the cookie-only approach to sessions, the web browser’s back button will function normally. While it may seem like overkill, you can regenerate the session ID on every page load. An attacker would have to be able to duplicate it from the outside, using HTTP headers, in a small window of opportunity each time.
The proper way to do it is to set the flag to true (wiping out session data) upon a successful login and setting it to false on every occasion after that.
It can’t be done using PHP only and it requires storing certain HTTP environment variables and comparing them with what’s being received with every page load. IP addresses and user agents aren’t reliable because both can change from one page load to the next.
If you have a membership site of some kind, your members have to log on or log in, right? They obviously know what their credentials are.
If you have a secure login form of some kind, it makes sense that you can create pages that need the same parameters when adding anything at all to the website. By doing so, you can make session hijacking useless.
The key here is that the member should have a password manager. Most of the major web browsers have add-ons like LastPass that will store the data securely. There are also specific programs for various operating systems as well, like KeePass Password Safe. These things are free!
If nothing else, most modern web browsers will let you store your data within the web browsers themselves, something I can only recommend as well as one of the other methods and only if your web browser isn’t being used by others.
Let’s say, for instance, that you’ve designed a forum of some kind from scratch. It doesn’t matter what an attacker can read on the forum. What matters is that you don’t want the attacker to be able to post anything, either as another member or as a member that doesn’t exist.
You can let attackers read all they want but if they need credentials to actually post something, they can’t do it unless they already have those credentials. Something like this would probably cause a typical attacker to give up on this kind of attack.
You’re going to get a percentage of people who won’t read the instructions and another percentage who won’t read them well enough to understand what they mean. You need to be ready and offer other avenues like contact forms, sticky posts or whatever else you can think of to minimize support requests.
Using SSL is the only way to insure against session hijacking and even then it can still be done. The SSL secure flag must be set with the session cookie or the session cookie won’t be encrypted by the SSL handshake.
Regardless of what method you use, with or without SSL, you should always store confidential information in an encrypted state. This way, even if an attacker should break in, minimal damage can occur and the rest of the private data stays private.
Previous and Next Articles (if any):