10 Replies - 668 Views - Last Post: 26 April 2013 - 12:31 AM Rate Topic: -----

#1 adn258  Icon User is offline

  • D.I.C Addict

Reputation: 11
  • View blog
  • Posts: 762
  • Joined: 31-August 11

What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 23 April 2013 - 11:33 PM

So basically I'm going to outline in my mind my line of thinking for securing websites: I would love for you fine people here to tell me if my line of thinking is correct security wise.

So Using an SSL certificate for encryption and using simple server directives of the following

session.cookie_secure
session.cookie_httponly
session.use_only_cookies


Seems to prevent about 99% of the problems related to session hijacking since I started using this for sites I run etc. It seems like the only reliable way to stop session hijacking is TO KEEP ATTACKERS FROM EVERY GETTING THE SESSION ID OF ANOTHER USER TO START WITH.

MY LINE OF THINKING ____________________

It's impossible on my site for an attacker to edit a cookie or just simply "guess" a session ID as the session Id's on my server are configured to be over 30 random letters and numbers long i.e. nobody could ever guess that beyond ridiculous mathematical theory as even guessing thousands of ID's a second wouldn't work.

I notice on a lot of other forums and stuff users try to figure out ways to stop attackers once they have a session ID but this line of thinking is again wrong as they shouldn't be able if at all possible to get another users session id to start with. Let us say they do though?

Here are some of the methods I've heard of to keep the session from being hijacked

1. You could save the users IP in session and if the IP doesn't match the last IP you expire the session....this seems like a HORRIBLE IDEA though as some ISPS change IP addresses constantly. So this isn't an option.

2. Just like with the IP address you could save the USER_AGENT from server and if it doesn't match the last one the session again expires but this also seems like a stupid idea because this can be spoofed or an attacker could use the same browser.

3. The regenerate session ID on the start of every page. While in theory this could help it's a fundamentally stupid idea because this would only work if you visited another page BEFORE AN ATTACKER HIJACKED YOUR SESSION USING THE OLD ID. If an attacker took over your session with your old ID and went to another page the ID would change again thereby actually logging out THE VALID USER AND KEEPING THE HACKER IN SESSION which would do the opposite of what was intended.

So there you have it. It seems like the only good method of stopping session hijacking is using the directives I outlined up top to STOP an attacker from getting session ID's. This focus on exotic methods to stop attackers once they have a session ID are flawed.

IS my thinking correct?

Is This A Good Question/Topic? 0
  • +

Replies To: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

#2 Atli  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 3719
  • View blog
  • Posts: 5,991
  • Joined: 08-June 10

Re: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 24 April 2013 - 12:08 AM

I'd agree that none of those three points aren't reliable methods of stopping hijacked sessions from being used, but that doesn't mean some of them can't be used to reduce risk of session hijackers getting away with it.

There is another version of the first point that has proven pretty useful. The IP address alone is more or less useless, as you say, but it can be used to do a Geo Location search and pinpoint the rough location of the original user. You can save that location somewhere, and whenever the IP of the user changes, run another Geo Location search and compare them. If they aren't within the same City, for example, then that should be a red flag. It wouldn't stop a hijacker located close to the victim, but if, say, an American user is hijacked by someone in Europe, it would prevent it.

Using the user agent to spot hijackers is very easily overcome, but it doesn't hurt to use it. A session should only be per browser, so it will in no way hurt the original users, but there is always the possibility that the hijacker won't consider this a factor.

As for the third point, I share your opinion on that. It's potentially as damaging as it is useful, so as far as I'm concerned it's not a good idea.


Aside from all this, the damage a compromised session can do should also be minimized by adding additional layers of protection around sensitive info. Like not allowing even a logged in user to change a password or view complete financial info without, each time, entering the password. It may be a bit annoying, but much much safer.
Was This Post Helpful? 1
  • +
  • -

#3 adn258  Icon User is offline

  • D.I.C Addict

Reputation: 11
  • View blog
  • Posts: 762
  • Joined: 31-August 11

Re: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 24 April 2013 - 11:01 AM

Thanks Atli that makes sense and those additional precautions are indeed a good idea no doubt but correct me if I'm wrong the directives with SSL will solve about 99% of this problem correct? What do you personally do if you don't mind me asking? Especially if there's not serious financial issues involved.

Also I notice for example my Bank somehow has something rigged up where if you refresh the page or back out the session automatically expires/gets terminated. How do you go about implementing that or does that matter do you think?
Was This Post Helpful? 0
  • +
  • -

#4 adn258  Icon User is offline

  • D.I.C Addict

Reputation: 11
  • View blog
  • Posts: 762
  • Joined: 31-August 11

Re: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 24 April 2013 - 08:04 PM

How does my bank know when you refresh the page do you think it automatically times out the session when you do that?
Was This Post Helpful? 0
  • +
  • -

#5 Atli  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 3719
  • View blog
  • Posts: 5,991
  • Joined: 08-June 10

Re: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 24 April 2013 - 08:55 PM

No, a session isn't affected by refreshes like that. My best guess is that they have some sort of rolling GET or cookie token that needs to be correct for the session to stay alive. So if you follow a normal link some JS code kicks in and updates the cookie/get value, so that when the request is issued the updated token is sent with it. If you just refresh or go back, an old token is included, and the session is invalidated. - But then, I don't really know what they are doing, so they may well have found some other cleaver way to achieve this.

About the SSL. All that does is encrypt the connection, effectively preventing so called "man in the middle" attacks where the session ID is stolen while on route to the client. What it doesn't protect you from are malicious programs on the user's computer. Once the session ID has been received by the browser, it's conceivable that a malicious program (virus) could steal it from there. There isn't anything you can do to protect from that; it's the client's responsibility. The flaky additional layers of security would be the only protection against that.
Was This Post Helpful? 0
  • +
  • -

#6 adn258  Icon User is offline

  • D.I.C Addict

Reputation: 11
  • View blog
  • Posts: 762
  • Joined: 31-August 11

Re: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 24 April 2013 - 11:51 PM

Atli that is a brilliant idea. There you have it. A Rolling GET. Wouldn't that be one way to stop session hijacking almost dead in its tracks? Hear me out. This wouldn't prevent a refresh but it might be more than enough security for most people. Tell me if this would work.

For example lets say when you log into a website it randomly assigns some 20 digit token and places it in your MYSQL database for that user FOR THAT SESSION ONLY I.E it will update when the user logs in again to a different token. Then all "protected page links" are dynamically assigned the GET to the links so the page MyAccount.php becomes
MyAccount.php?YourTokenStoredInTheDatabaseWhenYouLoggedIn=sd7dSSp980477Sdbbmq90

It would then query the database and if there isn't a match with that token and if there isn't the session is IMMEDIATELY LOGGED OUT and destroyed.

Wouldn't that make session hijacking almost impossible? If an attacker gets your session ID it would be worthless. The only way an attacker could hack you at this point is if he/she could grab your HTTP_REFERER which in some cases may be possible but even this would be impossible if AFTER A PAGE LOADS IT CHANGES AGAIN.

I believe this might be what my bank essentially does as I went to a page and went back to it WITHOUT refreshing and there was essentially some long ID code that was completely different.

Correct me if I'm wrong but using a new token like this combined with GET that changes with every login would be hard to hack, but if it changes with every page AFTER it loads it would be...and I don't say this lightly ALMOST IMPOSSIBLE.

Even if an attacker somehow got your SESSION ID AND YOUR HTTP_ REFERENCE it would still be worthless because he or she would ALWAYS be ONE GET token Behind. For example:

You're on a private page and your GET token was 889ii SET BY THE LAST PAGE AFTER IT LOADED (just using this for an example as it would obviously be longer) but after the page loads up and pulls information on the MyAccount.php Page from the MYSQL database, Your URL Link Is Still MyAccount.php?Id=889ii but Oops! It just changed in the database again lol to 554pp.

Unfortunately an attacker has put a malicious link somehow through XSS on Your MyAccount Page through some other Get Variable. The gullible user clicks it and the attacker is able to steal not only the SESSION ID but the HTTP_REFERRER which would show 889ii.

The attacker then uses that but oops remember it changed after the page loaded to 554pp the attacker loses lol the session is destroyed.


Basically this would make session hijacking almost impossible correct me if I'm wrong? This seems like excessive security for normal sites but for banking sites it would be worth the extra strain on the server for a constantly updating user token for each user in your DB that's stored in the DB. What do you think?


EDIT EDIT EDIT

Atli because this security stuff is so interesting and I love talking to you about it I got thinking about it even more!! You could use the token idea with cookies but no matter how the cookie crumbles (pun intended) it would never be as secure as changing a token in the MYSQL database. Why? If you think about it doing that idea with a cookie wouldn't work. Going back to my example lets say you update a token BOTH IN SESSION and in a another cookie using SETCOOKIE and everytime a page loads it changes.

So the user loads the MyAccount.php page and again there's that malicious link but the as soon as the page loads but setcookie is called and it changes the ID/token in the other cookie. This should go into our list of useless methods BECAUSE if the user clicks that malicious link all the attacker has to do is steal both cookies and HE OR SHE WOULD have the current Token/ID since it updates it in something the ATTACKER POTENTIALLY HAS ACCESS TOO.

By updating it in a MYSQL database and using GET excluding rarities you would always be one step ahead and an attacker would always have one access ID that was left behind where it should be. Do you see what I mean? I'm right aren't I?

This post has been edited by adn258: 25 April 2013 - 12:07 AM

Was This Post Helpful? 0
  • +
  • -

#7 Atli  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 3719
  • View blog
  • Posts: 5,991
  • Joined: 08-June 10

Re: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 25 April 2013 - 12:30 AM

Keep in mind that a GET value, a POST value and a Cookie are all essentially equal when it comes to security. They can all be picked out of the request fairly easily. The only real difference is the access Javascript has to them, and there the GET protocol is the weakest link, followed by non-HTTP cookies.

So, in essence, what you described is a variation on the third point of your original post: a rolling token (which the session ID is) that is updated on every request. If a hijacker were to somehow get a hold of your cookie, then it is also fair to assume the hijacker could also get a hold of the raw HTTP request, either by sniffing it out of the air or through malicious code on the client machine. A rolling GET/Cookie token, in addition to the session ID, would add a complication, but it would still not prevent hijacking.

Then the same downside you described in your original post exists here: If a hijacker intercepts the request and gets a hold of the session ID and the rolling token, the hijacker could step in an effectively replace the user as the owner of the session.
Was This Post Helpful? 0
  • +
  • -

#8 adn258  Icon User is offline

  • D.I.C Addict

Reputation: 11
  • View blog
  • Posts: 762
  • Joined: 31-August 11

Re: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 25 April 2013 - 02:36 AM

This is true it's not impossible but I don't see how a remote attacker could do that? IF the token changes every single time a user goes to another page but is STORED IN THE MYSQL database and the LINKS ON THE PAGE ALSO DYNAMICALLY CHANGE meaning that the GET variable is NEVER the same then the attacker would have to have access to the new MYSQL token correct?

What I mean is as soon as a user loads a page you'd have something like so


function CreateRandomStr()
{
   //code to create a random letter number string
}

function GetStoredTokenInSqlDatabase()
{
 //Code That Retrieves the Current Token For This Logged In User From The Database
}

function SetNewTokenInSqlDatabase($NewDatabaseToken)
{
 //Code That Stores A New Token To Compare To Our Session In Our SQL Database
}

if ($_SESSION['CurrentToken'] != GetStoredTokenInSqlDatabase())
{
session_destroy();
exit();
}

//safely stored on our server session variable
$NewToken = CreateRandomStr();
$_SESSION['CurrentToken'] = $NewToken;
SetNewTokenInSqlDatabase($NewToken);




IF this was on every single protected page the best an attacker could do is get HTTP_REFER and the last $_GET Token but that would ALWAYS SHOW THE LAST TOKEN NOT THE NEWLY SET TOKEN meaning they would never have the right token by just stealing the GET. Do you see my point? Where am I wrong in my logic on this Atli? Thanks for your help.

This post has been edited by adn258: 25 April 2013 - 02:40 AM

Was This Post Helpful? 0
  • +
  • -

#9 Atli  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 3719
  • View blog
  • Posts: 5,991
  • Joined: 08-June 10

Re: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 25 April 2013 - 05:16 AM

The problem with what you are doing there is that it's all server side. It would be enough for an attacker to hijack the session ID to bypass that code. The only thing a user needs to pass the validation you are doing there is to have a valid session ID. Any valid session ID will do. - Even if you were to replace the SESSION in that code with a GET or Cookie based system, where the token is passed to the client and updated on every request, you are still just creating variations of the third point in your original post.

The problem with this whole situation is that HTTP is stateless. There is no way for you to maintain a session without the user having to have a token of some sorts that identifies him/her as the same user that started the session. As such, any session based system is at risk of hijacking. The best you can do is complicate the process; make it trickier for hijackers to get their hands on valid credentials. But you can never completely protect against it. It's just not possible.

HTML5 does offer a way to get past this though. The WebSockets protocol bypasses the normal HTTP nature of the web, allowing Javascript applications to maintain a connection to the server for long periods. - If you created, say, a banking system that relied solely on a socket connection to pass data, instead of a series of HTTP requests, that could in theory be made 100% safe from hijacking. If the socket connection is established through SSL, a hijacker would never get the chance to hijack or eavesdrop on the connection. Once the connection is made, it can serve as the session, and as the socket connection terminates, so does the session. The only way for a hijacker to hijack that kind of session would be to inject code into the page to mess with the Javascript controlling all this, and that can easily be prevented.

Unfortunately WebSockets are not supported widely enough yet for that to be viable as the only choice. Perhaps as a more secure progressive enhancement for browsers that support it.
Was This Post Helpful? 0
  • +
  • -

#10 adn258  Icon User is offline

  • D.I.C Addict

Reputation: 11
  • View blog
  • Posts: 762
  • Joined: 31-August 11

Re: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 25 April 2013 - 11:42 PM

View PostAtli, on 25 April 2013 - 05:16 AM, said:

The problem with what you are doing there is that it's all server side. It would be enough for an attacker to hijack the session ID to bypass that code. The only thing a user needs to pass the validation you are doing there is to have a valid session ID. Any valid session ID will do. - Even if you were to replace the SESSION in that code with a GET or Cookie based system, where the token is passed to the client and updated on every request, you are still just creating variations of the third point in your original post.

The problem with this whole situation is that HTTP is stateless. There is no way for you to maintain a session without the user having to have a token of some sorts that identifies him/her as the same user that started the session. As such, any session based system is at risk of hijacking. The best you can do is complicate the process; make it trickier for hijackers to get their hands on valid credentials. But you can never completely protect against it. It's just not possible.

HTML5 does offer a way to get past this though. The WebSockets protocol bypasses the normal HTTP nature of the web, allowing Javascript applications to maintain a connection to the server for long periods. - If you created, say, a banking system that relied solely on a socket connection to pass data, instead of a series of HTTP requests, that could in theory be made 100% safe from hijacking. If the socket connection is established through SSL, a hijacker would never get the chance to hijack or eavesdrop on the connection. Once the connection is made, it can serve as the session, and as the socket connection terminates, so does the session. The only way for a hijacker to hijack that kind of session would be to inject code into the page to mess with the Javascript controlling all this, and that can easily be prevented.

Unfortunately WebSockets are not supported widely enough yet for that to be viable as the only choice. Perhaps as a more secure progressive enhancement for browsers that support it.



I challenge that. I don't think having a session ID would help with a regenerating token within a MYSQL database. We should test this theory Atli. I'm thinking of creating a demo site as a test that uses this.

I'll give you a login and myself a login too. I'll give you my session ID once I'm logged in but I will make the site uses this method and we'll see if by me just giving you my session ID once I'm logged in through a cookie editor is enough. Are you down? OF course I'm not disagreeing with you on your point that anything that uses a session can potentially be compromised but you can make it so ridiculously hard to impossible that 99.9999% of attackers wouldn't have a chance or they'll go attack something else.

You don't have to make something 100% secure which isn't possible, you just have to make it so ridiculously hard that it isn't worth someone's time.

This post has been edited by adn258: 25 April 2013 - 11:50 PM

Was This Post Helpful? 0
  • +
  • -

#11 Atli  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 3719
  • View blog
  • Posts: 5,991
  • Joined: 08-June 10

Re: What Is An Isn't A Waste Of Time For Mitigating Session Hijacking?

Posted 26 April 2013 - 12:31 AM

Sure, I'll help you test it, but there really isn't much point. What you do there won't overcome normal session hijacking because it is all happening based on session data that PHP obtains after resuming the session using the client provided session ID. You are comparing entries in two server-side data storage mechanisms based on a normal session ID cookie. The client is never aware of the token, and it is never linked to the client through anything other than the session ID.

The only way to verify that a client is valid is by using data coming from the client. If the token is stored only on the server side, how is it supposed to be verifying the client?
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1