PHP | is validating session property necessary and why?

Question

Is there a reason to fill session property with values from database?

1

$_SESSION['hash']  = query_row['hash']; //hash from database; unique to each user

and then on each page, check if session exist

if(isset($_SESSION['hash'])) && $db->checkLogin()
{
//user session is still valid
}

whereby:

function checkLogin($session_hash)
{
if($_SESSION['hash']) 
{
 //check if $session_hash is found in database
}
    }

instead of using

2

$_SESSION['islogged_in']  = true;

and only check if session is set

if(isset($_SESSION['islogged_in']))
{
//user session is still valid
}

Does using the first method give you any more protection? Is it wise to set the session value with something unique instead of 'true'? Is it wise to validate the $_SESSION[] value with databank data? And WHY would it be safer?

EDIT: I know which are the standard methods to protect sessions against fixation and Hijacking. This is not my question :)

I can't find a reason to use method 1 at all (so validating with databank or even setting session property with unique data like username, ..) As far as I know, session properties are being saved server side, so users/hackers can't modify them. Session protection (hijacking and fixation) only protects the session id since this is the only thing that's being save on client in cookie (so can be modified). I see lots of programmers on the internet do this anyway, so that's why I'm asking.

YES. Session_cookies are stored in a cookie on the cleint side, and in the tmp folder of the server (sometimes) (witch is world readable). Yes it's safer to use the DB as well. — Louis Loudog Trottier, Nov 16 '12 at 22:19
@Louis. Session data is stored on the server. The session id is stored on the client as a cookie. — aziz punjani, Nov 16 '12 at 22:20
Good question. It is hover good to know which user you are dealing with. I usually save a user object in the session var with information I need to be readily available. And set up sessions to save to DB. But as long as you don't need to know whoes logged in I would go with option 2. — fimas, Nov 16 '12 at 22:22
If you have session fixation and hijacking covered I don't see a reason to check the db on every request. — jeroen, Nov 16 '12 at 22:35

score 0 · Answer 1 · edited May 23 '17 at 12:34

I think you are better off with method 2. Sessions can only be set by the server, so if it is set, you know your user was validated. The first method needlessly checks the database again each time, and is not any more safe. Neither of these methods protects against session hijacking.

If you want to protect against session hijacking, you couldalso store the user's IP in the session, and check each time to make sure it has not changed. This is a fairly simple and easy way to check. If you want some other more robust alternatives, I suggest you look at this page.

score 0 · Answer 2 · answered Nov 16 '12 at 23:46

if you don't want to know anything about the user except that he has logged in successfully there is no reason to store the id and check if the id exists (or something like this). you and you alone can write to the session. if your server gets hacked (example: some can upload code or sessions to your server) than you have much more problems than checking if the session data (that you write into the session) is valid :)

PHP | is validating session property necessary and why?

1

2

2 Answers2