is it possible to hack PHP SESSION information?

[binxalot]

The subject line pretty much says it all.  I'm unsure of where this session information is stored, does it reside in the client's browser cache somewhere? or is it only on the server?  Is it possible to fake the session information or inject code into it from the client side?

[revraz]

It's server side, and yes, it's possible.  But is it likely since they have a small window to do it in?

[haku]

Sessions are NOT serverside, they are stored on the clients local machine (you can go in your cookies and look for a cookie called phpssid under your domain name). Yes they can be hacked, and this is in fact a very common method of hacking. Someone will hack into the session, then play around with the values of the session variables and try to find one that gives them administrator status or what not. You should program your code to protect you from this.

[jesushax]

how would you do this?

[haku]

Sorry, I think hackers suck. What legitimate reason could you have for wanting to hack a session variable?

[PFMaBiSmAd]

Session variables are stored on the server. The session ID that associates a visitors with the session variables stored on the server is what is stored in the cookie.

[jesushax]

i mean how would you protect your code?

[revraz]

What are the odds they will hack the 40 digit code in the time it's actually active?

[Psycho]

OK, from the manual:

 

A visitor accessing your web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.

That is JUST the session ID which is stored client-side!

 

 

Session data is stored in memory thus web server restart deletes it.

By default, all data related to a particular session will be stored in a file in the directory specified by the session.save_path INI option.

 

So, the data is stored server-side.

 

But to the point of this post I assume it would be possible to hack a user's session ID to then access data on a secured site, but I suppose there would only be a small window of opportunity. I've never worried about this, but I guess you could protect the session data by matching up the session data with the user's IP?

[haku]

My bad, you're correct about that. I always saw the phpssid in my cookie list and thought that the info was stored inside it.

 

Here is an article I just found on how to protect yourself:

 

http://www.net-security.org/article.php?id=925

[jesushax]

so how would i create a 24 digit user id?

 

so that a user id in my mysql table would be this id, is that the best way?

 

or maybe i ould MD5 the Userid

 

So

 

$_SESSION["UserID"] = (md5($row["UserID"]))

 

would that work in querystrings? or would i need to md5 it back before using it in script?

 

or is there a better way?

 

cheers

[tinker]

When I first started thinking about protecting against xss and practicing with the wget cookie features I considered things along this route.

1) Store a session cookie, but marry it with another id string which is passed in the link (not related to sess id) which is stored in the db along with the sess id, this pair then needs to marry to access.

2) Check the sess id to the browser agent, because even if the ip changes dynamically, the browser won't.

3) Use a cookie to store similar to 1, and if ip changes then challenge the cookie.

x) The extra string should probably be made up of the agent, sess id, user name (and maybe ip (if extra logout req)), and then either be a hash or (probably a waste of time) encrypted.

y) For non SSL login I converted some RSA code to JS and mixed with it's PHP counterpart works quite well for a simple public key system, see here (as you can see it is slightly limited)

 

[drewbee]

Personally, I dont use sessions, I use databases. But thats just me;

 

The session ID is what I use to link to the database information.

With this setup I can see who is online & what page they are on and force only 1 account to be logged in at a time (it forces other account to auto logout so no 2 people can be logged into the same user account at the same time).

It is always good idea to regenerate the session id every x often. On every page load is the most secure, but is a little redundant i think. I regenerate it every 5 minutes and update the database accordingly.

[tinker]

Personally, I don't use sessions, I use databases. But thats just me;

 

The session ID is what I use to link to the database information.

...

 

Do you mean that you don't use session variables? (or do you 'actually' put the sess_id in the link (bad))

 

But otherwise, yes that's how I do it...

[drewbee]

Do you mean that you don't use session variables? (or do you 'actually' put the sess_id in the link (bad))

 

But otherwise, yes that's how I do it...

 

No, I do not put it in the link (by link you mean url right?). The only part of the sessions I use is session_id() of which is used to know which row in the database i need to look at for x user.