0

Possible Duplicate:
PHP Session Fixation / Hijacking

I've been using $_SESSION superglobal a lot and heavily.

However the situation is like this:

Once the user is logged I want to keep track of his ID(MySQL table). I can easily insert the id into $_SESSION['id'] = $user_id;

After all I can use that variable across the pages on my site. What's on my mind is - user can trick the ID into another. If I would see that there's a simple number then I can change it a bit and see what happens - I want to prevent this as it can cause a lot of problems as user ID would be used for adding, deleting, editing entries inside the database.

Is session_regenerate_id() just enough to keep my session safe from hijack ?

Conclusion: Cookie only stores session identificator - all the values are on the server and never get passed to the client side. Read about session fixation/hijacking on StackOverflow

Community
  • 1
  • 1
lukas.pukenis
  • 13,057
  • 12
  • 47
  • 81
  • What makes you think that variables stored in `$_SESSION` are sent to the client? – Chris Eberle Oct 17 '11 at 05:32
  • Nothing. I believe there's only some kind of hash on a client side inside a cookie which works in cooperation with a $_SESSION. I may have written my question out incorrectly - I will update. – lukas.pukenis Oct 17 '11 at 05:37

3 Answers3

1

If I were you I'd have a table in your database that stored a user_id and a session_hash. Possibly a date_expires as well. Then when a user logs in you create a hash based on their id and maybe a random salt, store that in the database as well as the session variable. That way if they change that value on their side, the chances of them matching some other stored value in your database is very unlikely. Along with this if the user performs any operations on their account you just check the database table for their hash to get their real id and then follow through with the operation like you normally would.

Tyler Ferraro
  • 3,753
  • 1
  • 21
  • 28
1

One option would be to hash it and then use that same hash in your database.

Example:

$_SESSION['id'] = md5($user_id);

$query = "SELECT * from database_table where md5(database_table.user_id) = " . $_SESSION['id'];
Atticus
  • 6,585
  • 10
  • 35
  • 57
1

The user has no acccess to $_SESSION['id']. He can not modify a variable that's kept on your server (see session doc).

session_regenerate_id() has a different purpose. It resets the cookie SID. That's the handle that differentiates users and sessions. It only makes sense to use if you have a secondary identifier (IP or user agent string) to verify. It's main purpose is preventing stale or intersecting sessions. Again, see the manual.

mario
  • 144,265
  • 20
  • 237
  • 291
  • Sorry.. I understand $_SESSION is on a server side, but sessions work with cookies on client side - somehow data needs to be passed from browser to the server for the session. It's called session hijacking I think? – lukas.pukenis Oct 17 '11 at 05:34
  • Only the SID cookie is passed by the browser. The contained `["id"]` variable is kept on the server. – mario Oct 17 '11 at 05:36
  • 1
    Please read [PHP Session Fixation / Hijacking](http://stackoverflow.com/questions/5081025/php-session-fixation-hijacking) – mario Oct 17 '11 at 05:37
  • Thanks - appears to be a perfect URL I was looking for – lukas.pukenis Oct 17 '11 at 05:40
  • "It only makes sense to use..." - nonsense - it should **always** be used at authentication or where you can detect an expired session to prevent fixation attacks – symcbean Oct 17 '11 at 09:14