Page 3 of 4

Posted: Mon Aug 21, 2006 7:26 am
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).

Posted: Mon Aug 21, 2006 7:58 am
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');
}

Posted: Mon Aug 21, 2006 8:00 am
by Benjamin
I don't think that will work because of AOL users, who have changing IP's.

Posted: Mon Aug 21, 2006 8:13 am
by Jenk
indeed, as I said in previous post to that :)

Posted: Mon Aug 21, 2006 8:36 am
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.

Posted: Mon Aug 21, 2006 9:57 am
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.

Posted: Mon Aug 21, 2006 10:12 am
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.

Posted: Mon Aug 21, 2006 10:18 am
by Jenk
why can't people read all of one's post(s)? :s

Posted: Mon Aug 21, 2006 10:20 am
by Luke
Jenk wrote:why can't people read all of one's post(s)? :s
:lol: I read it Jenk.

Posted: Mon Aug 21, 2006 10:29 am
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:

Posted: Mon Aug 21, 2006 10:49 am
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.

Posted: Mon Aug 21, 2006 10:55 am
by Oren
I read all posts too.

Posted: Mon Aug 21, 2006 11:02 am
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.

Posted: Mon Aug 21, 2006 11:09 am
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.

Posted: Mon Aug 21, 2006 11:10 am
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. :)