Session Hijacking Protection

[Zero-Affect]

Firstly i'd like to thank Zeddicus of mcaddons for his post on his website about this also thanks to phpsec for information on this.

In header.php

find (this is normally located in the userdata section):

$IP = $_SERVER['REMOTE_ADDR'];

or if it looks like this replace with above:

$IP = ($_SERVER['HTTP_X_FORWARDED_FOR'])
  ?  $_SERVER['HTTP_X_FORWARDED_FOR']
  :  $_SERVER['REMOTE_ADDR'];

then add below:

if ( isset($_SESSION['HTTP_USER_AGENT']) ) {
   if ( $_SESSION['HTTP_USER_AGENT'] != sha1( $_SERVER['HTTP_USER_AGENT'] )) {
  session_unset();
  session_destroy();
  header("Location: login.php");
   }
} else {
   $_SESSION['HTTP_USER_AGENT'] = sha1( $_SERVER['HTTP_USER_AGENT'] );
}

 

In authenticate.php

find:

$_SESSION['userid']=$mem['userid'];

Add below:

     $_SESSION['HTTP_USER_AGENT'] = sha1( $_SERVER['HTTP_USER_AGENT'] );

Tested and works perfectly (thanks BogFx for the help testing).

I am not sure on what encryption is possible but im assuming any is allowed.

see hash() for further information on hashes.

Any issues don't hesitate to contact me via PM or post here.

[Tyr]

Thanks!

[iSOS]

This is a good prevention technique, but in no way *solves* the problem, other precautions need to be taken, A good way is password validate important game functions like selling items/sending cash ect.

Being on a shared host doesn't help the problem either as all sessions are stored on a certain folder, but if you're on a VPS you can change the session path and that makes the 'hijackers' life a lot harder.

[Zero-Affect]

There are afew people which say it's flawed i'm one of the people, somewhere it will be flawed but if it works against the MCC "hackers" then why not let the people have it.

[iSOS]

Yeah, It's obviously flawed since the more experienced 'hackers/hijackers' can 'spoof' the user-agent, or simply may have the same user-agent, But it's an extra layer to get through rather than just 'walking in'.

[Djkanna]

Safari has a way of spoofing your user agent so you can use any in theory :)

[Zero-Affect]

Firefox also lol i have it which is why i keep stating it's flawed.

[Zeggy]

As well as doing this for user agent, you can also do the same with the player's IP address.

The hashing isn't really necessary since this is all server-side data, the player will never be able to see any of it.

Some more tips:

Look into regenrating session tokens - http://php.net/manual/en/function.session-regenerate-id.php

Set a time-out on old sessions.

Destroy the session if there is no referer. This way a player can only visit your site through your login box, they can't just type a url and enter the player area of your game (or admin area).

[Zero-Affect]

Thanks for the feedback Zeggy, You do have a point the hashing isn't really needed since it's server side, I believe the original by Zedd uses ip's but you then would have issues with AOL users would you not?

[Zeggy]

Yep, using IPs always gives some kind of trouble with silly ISPs :P

I don't really have any ideas on how to solve that.

[iSOS]

I suppose with the IP side of things you could have a 'log' of any the users IP's that change during game play, If there user-agent is AOL you can disregard, but if not maybe look into a little more, see if it's the same a another user. (potential hijacker).

[Zero-Affect]

Zeddicus IP's can be changed i simply would change my IP to a AOL one to prevent the IP check, then change user agent and imply a little js to get session's. Mac Address is possible solution but that can be changed, something unique which can't be gathered maybe.

If you're like me and on shared hosting you can't access most things so maybe MySQL table with a hashed session involved?

Formula: login_name+userid+8 rand chars

hashed into whirlpool then imputed in Sessions table column session and have a column for users id

Then simply check if the login_name+userid+8 rand chars (stored somewhere in users table) hashed into whirlpool equals the stored one for their ID.

Simple really lol

remember you'd obviously change the formula around abit so that it's not easy to guess and maybe change the name of the column in users don't call it "rand_chars_for_session" lol

a simple edit in authenticate, register and header really.

If no one finds a issue with that ill code it up.

[iSOS]

The 'hijacker' would have to get the exact 'user-agent,IP' of the user involved, now that's going to be hard for anyone without access to you DB or there PC.

With the 'log' I meant all IP's would be logged but you could disregard AOL IP's, but if you change IP, you'd need to get the exact user IP anyway, same with user-agent.

And with the JS and sessions, I'm pretty sure you could only get your own session ID, the easiest way to get them is just going to the 'tmp' folder as that's where all sessions are stored.(unless you've changed the session.save.path)

I think I see an issue with your idea, when the user actually hijacks the session they will then be on there account, so there ID.(maybe I just haven't got the idea correctly.)

But I feel as long as everything *important* is validated, (item sell,cash send,crystal send) ect ect, that will limit the damage that could be done, and atleast reassure yourself that even if someone did find a way round your defences that your players are relativity safe.

[Zeggy]

As well as preventing hijacked sessions from being used, something else to consider is to prevent sessions from being hijacked in the first place:

Prevent xss, don't allow your site to be iframed, no hotlinking, no off-site images on your game, etc.

CrimGame: I don't understand your idea very well, could you explain it more? (or example code)

[Zero-Affect]

Ah Zeggy sadly i just thought about it and noticed it's flawed.

 

I think I see an issue with your idea, when the user actually hijacks the session they will then be on there account, so there ID.(maybe I just haven't got the idea correctly.)

Yeah that's what i noticed, bugger ain't it lol

From a users point of view if they have to put in a password or something every time they want to do something they will be annoyed, filtering inputs and outputs is probably the best solution really.

user agent can be stolen Zeddicus think maybe CSRF.

[iSOS]

filtering inputs and outputs is probably the best solution really.

Agreed, But it's also about damage limitation,if for some reason an account was compromised there has to be way's in order to prevent complete 'destruction' of there account & game play experience.

Obviously both ways posted have there flaws but in all seriousness who is going to spend the time finding a users user-agent & IP just to access an RPG account, I think they'd be after there bank details if they got that far lol.

[Zero-Affect]

We don't store bank details... Paypal doesn't share information so no such possibility really, unless they edit the donation script to load a fake PP script and then simply grab the information when they login (i don't think this would work).

Grabbing user agent is simple, load a external file via a little js or basically redirect them to another site which then logs their ip, reference link, session and user_agent not so difficult.

[iSOS]

No, what I mean is if the hijacker got as far as getting there IP & user-agent then that's alot of work just to get into an RPG account, they would be better off trying to get your bank details.

Yes a simple script can do that, but your site has to be penetrated in order to redirect your site there. -- What I'm trying to say is, why would someone take all that trouble just to enter an account?

But *if* they did there has to be some kind of damage limitation in place, I see it every where when user's accounts have been 'hacked' and all there stuff is gone and they have no cash ect ect.

[Zero-Affect]

Yes it's simple and some people are just basic tossers and hack RPG accounts for a laugh, im sure a high ranking TC account would be worth afew quid...

Restricting functions is a bad solution in my eyes due to the obvious draw backs when users get bored with having to input data to be validated all the time. Think if it's the password they input i would basically setup a fake validation which prompts they input the data and it goes to my external link then it simply goes to "gym.php validation" they will assume it was a wrong password.

Auto submit the data into a validator on a script then opening the script and them believing nothing is wrong. Then i just bypassed your validation and stole a users password which then no session hacking is needed.

[CrazyT]

if ( isset($_SESSION['HTTP_USER_AGENT']) ) {
   if ( $_SESSION['HTTP_USER_AGENT'] != sha1( $_SERVER['HTTP_USER_AGENT'] )) {
  session_unset();
  session_destroy();
  header("Location: login.php");
   }
} else {
   $_SESSION['HTTP_USER_AGENT'] = sha1( $_SERVER['HTTP_USER_AGENT'] );
}

Why two if's when you can use one?

if (isset($_SESSION['HTTP_USER_AGENT']) && ($_SESSION['HTTP_USER_AGENT'] !== sha1($_SERVER['HTTP_USER_AGENT']))) {
session_write_close();
header('Location: login.php'); die;
} else {
   $_SESSION['HTTP_USER_AGENT'] = sha1($_SERVER['HTTP_USER_AGENT']);
}

[Drizzah]

Another way to use it could be like this (I THINK)!:

 

$IP = $_SERVER['REMOTE_ADDR'];
$IP = mysql_real_escape_string($IP);
if
(isset($_SESSION['HTTP_USER_AGENT']) && 
($_SESSION['HTTP_USER_AGENT'] !== sha1($_SERVER['HTTP_USER_AGENT']))) {
session_write_close();
header('Location:
login.php'); die;
} else {
$_SESSION['HTTP_USER_AGENT'] = 
sha1($_SERVER['HTTP_USER_AGENT']);
}

[Guest Drizzle]

I believe someone told me that mres isn't needed, but im not really sure. Umm yea i searched firefox last night (I search time to time), I found one of those spoof user agents add-ons, the spoofer for the IP, One of the proxy add-ons (There are more, but then again on any proxy, the IP spoofer for HTTP-FORWARDED-FOR doesn't work on most proxys because your in a frame. ), and a few other things. I just listed them down, didnt download them though. And i will not be sharing as people dont really need to know them, best for me to say i said nothing and let them search or something

[CrazyT]

Another way to use it could be like this (I THINK)!:

 

$IP = $_SERVER['REMOTE_ADDR'];
$IP = mysql_real_escape_string($IP);
if
(isset($_SESSION['HTTP_USER_AGENT']) && 
($_SESSION['HTTP_USER_AGENT'] !== sha1($_SERVER['HTTP_USER_AGENT']))) {
session_write_close();
header('Location:
login.php'); die;
} else {
$_SESSION['HTTP_USER_AGENT'] = 
sha1($_SERVER['HTTP_USER_AGENT']);
}

Wow you got that out of another topic i commented on = (MINE)

[bluegman991]

crime game i have something similar to what u suggested about hashing the users username but i dont know whether i should look at it as a good thing or a bad thing...

or a better way to do it

you see i have it so when they log in it sets there session sec id to there id+some random numbers+a little more info that wont change throught there session. and while testing i see that they can only be logged in on 1 browser at a time. but if the log into their account on another browser/computer it will log them out on the other browser and start a new session in the 1 they just logged into. so im wondering if there account was to get hacked while they were either away from their computer for a short amount of time or while they were playing would it be good to let them be hack while there logged out, or find some way to keep them logged in so they can see everything

[Zero-Affect]

I am custom building my engine so i see no reason any more for this but i will add precautions. Alan yes well Drizzle or whatever he wants to call himself does like to copy and paste...