Session hijacking can occur on standard HTTP pages (pages not protected by SSL) through various means including packet sniffing. 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 would invite an attack on the session. Also, using session regeneration techniques will break the back button — the URL would be different each time.
Session cookies are not immune to interception, but they can be made worthless except to the user who’s tied to the session. Human beings can’t move as fast as sessions can be changed, even if they have access to the session files on the server.
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 ensure you set it in 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.
While this is disputed as effective against XSS amongst developers, any additional protection measure (regardless of how insignificant it may seem) 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 appear to be 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 — while the user is paused on a particular page.
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, while logged in, after that.
Using a Web Browser Fingerprint
It can be done using PHP only and it requires storing certain HTTP environment variables in session variables and comparing them with what is being received with every page load. IP addresses and web browser user agents aren’t worth using because both can change from one page load to the next, depending on the operating system in use at the time.
Using SSL (TLS) is the only way to insure against session hijacking and even then it can still be done. The SSL secure flag must be set or the session cookie won’t be encrypted by the SSL handshake. Regenerating the session ID on a regular basis is still a good idea.
Regardless of what method you use, with or without SSL, you should always store confidential information in an encrypted state (hashed with a salt of some kind). If an attacker should break in, minimal damage can occur and private data stays private.