Storing Session Data in MySQL - Need Help

[bill bratske]

I'm trying store my session data in a database to improve security.  I have followed http://www.devshed.com/c/a/PHP/Storing-PHP-Sessions-in-a-Database/ to set it up.

 

What is happening is that the session data gets stored in the database table properly, but after the user is redirected to another page I cannot seem to access that session data because the $_SESSION variable is empty. Right now my login page just checks the users PW and username in the database, sets up a few session variables, and redirects them to their personal member page.

 

To troubleshoot, I did a var_dump of the $_SESSION array right after the $_SESSION variables are set on the login page, which yielded the expected results.  Then, I did a var_dump of the $_SESSION array after the page had been redirected to the member page -- and the array was empty.  What could be going on that the array would be empty?  I am using a different member page right now to troubleshoot this, so I will post the code for that...

 

Here is my code:

 

member page:

<?php
//Start session
session_start();
require_once("sessions.php");
    $sess = new SessionManager();	
var_dump($_SESSION);
	exit();
?>

 

login page:

<?php
//Connect to database
require_once('db.php');
dbconn();
//Start session
require_once("sessions.php");
$sess = new SessionManager();
session_start();

//Filter form data
switch ($_POST['form'])
{
    case 'login':
        $allowed = array();
        $allowed[] = 'form';
        $allowed[] = 'email';
        $allowed[] = 'password';

        $sent = array_keys($_POST);

        if ($allowed == $sent)
        {
//Sanitize the value received from login field
//to prevent SQL Injection
if(!get_magic_quotes_gpc()) {
	$email=mysql_real_escape_string($_POST['email']);
}else {
	$email=$_POST['email'];
}
$pw=md5($_POST['password']);
//Create query 
$qry="SELECT m_id FROM members WHERE email='$email' AND passwd='$pw'";
$result=mysql_query($qry);
//Check whether the query was successful or not
if($result) {
	if(mysql_num_rows($result)>0) {
		//Login Successful
		session_regenerate_id();
		$member=mysql_fetch_assoc($result);
		$_SESSION['SESS_MEMBER_ID']=$member['m_id'];
		$_SESSION['email']=$email;
		$_SESSION['test']='TEST';
		session_write_close();
		header("location: auth.php");
		exit();
	}else {
		//Login failed
		header("location: login-failed.php");
		exit();
	}
}else {
	die("Query failed");
}
        }
else{
//Extra Form Data Detected.
}
        break;
}
?>

[PFMaBiSmAd]

Doing a session_start() before your custom session manager has been setup, like you are doing in the member's page, will result in php using the built in session save handler.

 

There are only a couple of good reasons for using a custom session save handler and on a shared web host, security is not among the top reasons. On a shared web host the database server can be seen by all accounts and since databases don't have failed login retry lockout code, it is fairly easy for someone with an account to do a brute force username/password attack and break into your database. It is much more secure to use the built in session file save handler and set the session save path to be to a private folder within your account's folder tree.

[bill bratske]

Doing a session_start() before your custom session manager has been setup, like you are doing in the member's page, will result in php using the built in session save handler.

 

There are only a couple of good reasons for using a custom session save handler and on a shared web host, security is not among the top reasons. On a shared web host the database server can be seen by all accounts and since databases don't have failed login retry lockout code, it is fairly easy for someone with an account to do a brute force username/password attack and break into your database. It is much more secure to use the built in session file save handler and set the session save path to be to a private folder within your account's folder tree.

 

So somebody would have to have a hosting account on the same server as me to brute-force my database password?  If I use a very strong password, this risk is mitigated quite a bit, right? 

 

I was building for expandability, but I could always add this later if there were a need for multiple web servers...

 

Thanks for pointing out that I was calling session_start too early, I also forgot to put my DB connection string on the top of the new members page (duhhh).

 

 

[PFMaBiSmAd]

So somebody would have to have a hosting account on the same server as me to brute-force my database password?

They would only need to have an account within the same host company. One database server is often shared between multiple web servers.