session_regenerate_id

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

feyd wrote:or future reference this sort of "attack" is called session hijacking.
No its not. This is session fixation. Session hijacking it getting the details of an existing session created by the victim and using it. This is almost the opposite, giving a session which you have access, to the victim.
Jenk wrote:you could probably add a bit of obscurity to it, though it's probably so weak it's not even worth the millisecond or two it will add to processing time..
I don't see how that helps at all. You can avoid session fixation by regenerating the session id when permissions change and changing the session name from phpsessid (not as good on its own).
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

ole wrote:
Jenk wrote:you could probably add a bit of obscurity to it, though it's probably so weak it's not even worth the millisecond or two it will add to processing time..
I don't see how that helps at all. You can avoid session fixation by regenerating the session id when permissions change and changing the session name from phpsessid (not as good on its own).
Because it uses the users IP address as well, in pseudo:

Code: Select all

Login();

$_SESSION['id'] = md5(session_id() . $_SERVER['REMOTE_ADDR']);


<session hijacked>

if ($_SESSION['id'] !== md5(session_id() . $_SERVER['REMOTE_ADDR'])) {
  session_destroy();
  Logout();
  die('be gone hijacker');
}
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

I don't think that will work because of AOL users, who have changing IP's.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

indeed, as I said in previous post to that :)
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

Ah missed that part :oops:

I think Orens idea of forcing session cookies isn't bad. Saves search engines from picking them up too.

The way I use sessions is by storing them in the database and sending a key to the client. If I wanted more security I could change the key on every page request, but that doubles the number of db queries. ie 1 to verify and pull info about the key, and another to update the key.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

If I wanted more security I could change the key on every page request, but that doubles the number of db queries
Which is why you should only do it when permissions change.
because it uses the users IP address as well
Ah yes, not amazingly strong but an extra level of protection nonetheless :).
I don't think that will work because of AOL users, who have changing IP's.
Yeah that's true if any user has to disconnect and reconnect it will break their session (if they have dynamic ips), not a problem for boardbanders but might be for 56kers.

I think that is what astions means by changing IPs. As far as I know IPs can't change whilst a connection is active. Also this problem is by no means exclusive to AOL, I use Pipex for instance and have a dynamic IP, and I like it that way.
User avatar
Oren
DevNet Resident
Posts: 1640
Joined: Fri Apr 07, 2006 5:13 am
Location: Israel

Post by Oren »

astions I'm not sure as to what key you are talking about, maybe like a token - a fingerprint, is that what you meant?
Anyways, I believe that +1 query is not that bad when this adds some more security to the application.
Jenk wrote:

Code: Select all

Login();

$_SESSION['id'] = md5(session_id() . $_SERVER['REMOTE_ADDR']);


<session hijacked>

if ($_SESSION['id'] !== md5(session_id() . $_SERVER['REMOTE_ADDR'])) {
  session_destroy();
  Logout();
  die('be gone hijacker');
}
astions made a very good point why it should be avoided, and I would like to add that relaying on most of the $_SERVER variables is not a good idea since they may change and they are also easy fake.

This code would be a good idea though:

Code: Select all

$fingerprint = md5($_SERVER['HTTP_USER_AGENT'] . $some_keyword);
The point behind this: As I said before, the $_SERVER variables can be easily faked, and $_SERVER['HTTP_USER_AGENT'] is no exception, but it still adds some security since it's not very likely that good_guy would switch browsers all of a sudden. If good_guy does switch browsers after all, then we simply ask him to re-login. If the $_SERVER['HTTP_USER_AGENT'] has changed because it's bad_guy who is trying to gain access, he simply wouldn't know the password.

Read http://phpsec.org/projects/guide/4.html#4.2 to understand this better and if you want to know what $some_keyword is for.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

why can't people read all of one's post(s)? :s
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

Jenk wrote:why can't people read all of one's post(s)? :s
:lol: I read it Jenk.
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

I don't know what your all talking about when you say changing permissions. My members are either logged in or they aren't. Their permission levels are stored server side in the database.

As far as the key is concerned, I generate a random 25 digit string which consists of upper, lower and numeric characters.
Jenk wrote:why can't people read all of one's post(s)? :s
I only read what was quoted :roll:
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

not logged in -> logged in counts as a permissions change.

EDIT: Also if entering admin/private area of a site, it's a good idea to revalidate login and regen' id.
User avatar
Oren
DevNet Resident
Posts: 1640
Joined: Fri Apr 07, 2006 5:13 am
Location: Israel

Post by Oren »

I read all posts too.
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

I think I'm going to go ahead and change the key on every page request. I understand it's impossible to prevent session hijacking, but I can at least make it harder.
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

If you are lead to somesite.com/login.php?PHPSESSID=I_NOW_HAVE_ACCESS_TO_YOUR_SESSION obviously no real threat is yet posed yet since more than likely no information about the user is readily available just by visiting login.php whether the session is set or not.

Now, though, the user may log in with that session id, and all of his session data will be retreived from the database (or other source) and made available in his session. Now the attacker has access to that information because the user logged in with his supplied session id.

Now let's say the user is already logged in and is sent a session_id. Where is the security risk here? or is there one? I just tried this approach on my system and it didn't seem to create the session file. Didn't seem to compromise the session in any way. I tried a few different approaches and none of them worked. I will keep trying it, but if anybody knows a couple precise ways I could demonstrate this on myself, so I can see just how this attack is done, please let me know.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

If you're looking to increase the security of it, I'd also consider switching up to the sha1 method and telling php to use different encoding than standard hex, or randomly choose different settings for each of the settings.

http://php.net/ref.session#ini.session.hash-function
http://php.net/ref.session#ini.session. ... -character

These are of course, for PHP 5. If need be, you could build your own session class that does everything for PHP that way it's more transparent. :)
Post Reply