Menu

RTCXpression

Close

Preventing Session Hijacking when using PHP

- August 3, 2013

session hijacking 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.

PHP Sessions

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.

The httpOnly Flag

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.

Regenerating the Session ID

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.

Using a Web Browser Fingerprint to Prevent Session Hijacking

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.

You can use certain JavaScript environment variables to help prevent session hijacking, but this will only work if your users have JavaScript turned on (the default in every major web browser). It also requires running JavaScript code on every page to fetch the variables.




Re-Authentication to make Session Hijacking Worthless

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.

[Update 2014-05-24: Using a JavaScript utility like store.js to store credentials would make re-authentication a breeze.]

When you begin something like this, you have to make sure each person who registers is aware of what’s required. If your website requires JavaScript and cookies, make it clear. The best place is the registration and login screens themselves. If they’re going to be required to re-enter their login credentials to post, make that clear as well.

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 to Prevent Session Hijacking

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.

Share:

Categories: Technology

Previous and Next Articles (if any):

« »

Comments:

Your comment will appear below the form when it's approved. When the page redisplays after hitting the send button (it takes a few seconds), your comment has been sent.

When replying to someone else's comment, please start the comment with "@" and the name so I can put it in the right place.

More

Please read some of my more important pages if you have the time:

Comments Policy           Privacy Policy

RTCXpression established Feb 28, 2011
Copyright © 2013-2017 RT Cunningham
Hosted at Digital Ocean