Question

I currently have the following code for EVERY page on my website. Please could anyone confirm if this is a good practice to start and continue a PHP session?

//************************************************************
//Session Settings
//************************************************************

$session_name = 'PHPSESSID'; 
$session_exp_time = 10000; 

$previous_name = session_name($session_name);

//Set garbage collection parameters
ini_set('session.gc_maxlifetime',   $session_exp_time);
ini_set('session.gc_probability', '1');
ini_set('session.gc_divisor', '100');

ini_set('session.name', $session_name);
ini_set('session.cookie_domain', ''); //Session set to not be available to subdomains
ini_set('session.cookie_lifetime', 0);

//Set the session cookie parameters
session_set_cookie_params($session_exp_time, '/', '');

//Start or continue a session...
@session_start();

if (isset($_COOKIE[$session_name]))
setcookie($session_name, $_COOKIE[$session_name], 2147483647, '');

Please note that this script is included in EVERY page.

Another related question:

Should I set a custom session save path or should I just use the server’s default session save path? What are the pros and cons? From what I understand, if you don’t set a custom session save path, then chances are you might have some kind of conflict on a shared hosting? Please help enlighten.

Thanks in advance!

Answer 1

Many of your statements involve session configuration settings; those can usually be moved in either the server’s php.ini or a top-level .htaccess (Apache).

session.name = PHPSESSID
session.gc_maxlifetime = 10000

session.gc_probability = 1
session.gc_divisor = 1000

session.cookie_domain =
session.cookie_path = /
session.cookie_httponly = 1
session.cookie_lifetime = 0

You shouldn’t make sessions last as long as you do (expiry in 2038); sessions are normally perpetuated with session cookies (which last until the browser is closed, technically). If you want to implement a “remember me” feature, I suggest you add that on top of your sessions, like explained here: http://jaspan.com/improved_persistent_login_cookie_best_practice

I find it important to distinguish between starting a new session and resuming an existing one, especially in cases whereby sessions are only created as part of a sign in process. When a session can’t be resumed, something went wrong and the user should be redirected back to the login page (or homepage).

PHP doesn’t understand that difference, session_start will automatically create a session if it’s not there, and worse, if an arbitrary session ID is given; the latter allows for session adoption attacks as outlined here: http://gihyo.jp/dev/serial/01/php-security/0025 – it’s in Japanese, you will have to translate it with your browser.

To find out whether a session can be resumed, you need to prime every new session by adding a special key (e.g. $_SESSION['_id'] = session_id()). If that key is found, the session already exists and you can resume it; if not, the session either didn’t exist or someone is trying to feed you a wrong ID.

To start a new session, you first see whether it can be resumed; if not, you use session_regenerate_id(true) to change the session ID (this makes it harder for an attacker to hijack a session).

Lastly, session save paths on a shared server can be written under your own home folder, but this only makes sense if your shared host runs with a dedicated user per virtual host (i.e. suexec). Otherwise, to protect your session from snooping attacks you will have to encode the session data (and maybe the keys too). Check out the mcrypt extension: http://sg.php.net/mcrypt – you should be able to find examples online.

I hope this more or less answers your question. Let me know if you think anything’s amiss.