Is it possible to fake session variables?


I was just wondering if malicious users are able to fake session variables? When a user logs on, I assign a session var loggedin as true. Is this a security issue, could a user fake the session var loggedin, even if he has not logged in?


It depends how you assign the session value to the user

check username password from the database and if they match you set it to true

mrwooster - thats an interesting question…I also wondereed if it is possible for a malicious user to fake session vars by creating their own form that posts to a secure (ie password protected using sessions) page of your site with the required session vars set. (assuming they know the session var names)…Similar to posting to a form with post vars to send spam etc…

Anyone got thoughts on this?

That is why every page which you want secure should have some sort of login in it to secure against that possibility.

For example:

if ( $_SESSION['loggedin'] ) {

// Do logged-in required actions

Even your EditProfile.php which normally a logged-in user can only see, it needs to check that the request came from a logged in user.

Now for faking session variables? It’s generally not possible, not without some sort of phishing scheme to retrieve the session ID. Session variables are not stored on the client’s computer, they are only stored on the server. All that the client’s machine gets is the sessionID which is usually stored in a cookie. Now websites that have ?SESSID=AD1212BC956871 in the URL… they are far more vulnerable as anyone can very quickly attempt different session ID’s.

ZareMedia - so a malicious user couldnt simply post a form to a secure page with the session var logged in set? Am I correct in assumng that the session var needs to have been set on the same server?


Thanks for the replies - cronsrcs, as far as I know - as far as I know, that can’t be done. The session has to have been registered on the server to be valid.

No. They have zero control over what session variables are set. Session variables are not stored on the client’s machine

Now if they knew the session ID of a currently logged in user, yes they could technically “fake” in that method by creating a cookie which is handed to your website like a real one

Thanks - that makes complete sense…I didnt think that it would be that easy ;)…


Unless someone manages to get access to your server (in which case you’re screwed anyway) there’s no way they could change the session variables. However, early versions of 5.0 had a bug which allowed users to set $_SESSION variables if register_globals was enabled, but it’s been fixed.

in which case you’re screwed… or you are just on a shared hosting. :wink:

On a shared machine always point session.save_path to a subdir under your home. When using /tmp or similar (which is by default), you’re vulnerable to your neighbors’ tricks and even bugs in their software.

I am using cakePHP on a shared webhost and so have set the session handling to use the database - I am hoping this will solve some of the session security issues.

I think that someone else could set session variables using a different form.

For example, if you are creating session variables for a pagination or something like that, and you are turning your $_POST variables into $_SESSION variables then it would be possible.

$_SESSION['SessExample'] = $_POST['Example'];

As for Session variables created by you specifically where you set the variable either through a database field (assuming that your data is secure) or just giving the session a specific variable then you are safe.

But with the form you should never trust user input so you should be verifying what the user has put in and escaping characters.

Well, not really. They could hijack the session if they knew the session-id of another user. But they can’t directly change what’s stored in the session.
Session hijacking is almost impossible in practice, but session-fixation is quite possible. That’s why you should always use [fphp]session_regenerate_id[/fphp] when a user logs in/changes privileges.

Read more on the subject at:

You can also check this thread for more info on session security. It has some good info, and helped me out a ton.

Did you just reiterate what I already stated to up your post count? Or did you really not comprehend the SAME statement?