1


To prevent session hijacking, i tried to assign a specific cookie name to each user based on these variables: User-agent and IP Address.

I have used following function to generate session cookie name which holds session ID.

static function getSessionName(){
    $id= @md5(base64_encode(self::$secretToken.$_SERVER["HTTP_USER_AGENT"].$_SERVER["REMOTE_ADDR"]));
    while(is_numeric($id{0})){
        $id = substr($id, 1).$id{0};
    }
    return $id;
}

It means that every user which visits my website, will have a different session cookie name. It will block hijacker from using cookies of somebody else, unless he/she changes his/her user agent to victim's user-agent; and tries to appear online using victim's IP address somehow, like using user's internet modem, router, NAT, etc.

Let me explain it using a example. So, if two users use same browser and connect from same IP address, they get same cookie names (assume f5e30acc605e938b097dee73c0272470).

Now, the script will look for session ID inside a cookie named f5e30acc605e938b097dee73c0272470 on these two clients. In this condition, one of the clients can hijack other's cookie. Same IP, same User-Agent and then same cookie name!

This method is good but not quite secure. Changing user-agent is not so difficult to do, and victim and hijacker may have equal IP addresses if they connect from public networks like Coffenets, Public hotspots, etc.

It's important to deny the attacker from doing so, especially if we use a "Remember Me?" option to generate long-lasting session cookies.

Does anybody have a suggestion about this problem?

As i researched, one of the solutions was using SSL and secure cookies. But, i'm looking for a solution without SSL usage.

zxcmehran
  • 1,435
  • 14
  • 24
  • As i said, in this situation, cookie name is dependent to two factors, **User-Agent** and **IP Address**. May adding another dependency solves the problem... – zxcmehran Sep 22 '12 at 12:20
  • 2
    Look at this article: http://jaspan.com/improved_persistent_login_cookie_best_practice – JvdBerg Sep 22 '12 at 12:34
  • 1
    And something else, don't forget to use htmlentities() or strip_tags() when you output data from the database, this will prevent xss attacks (cross site scripting). The most common technique to hijack a session cookie, is to inject some javascript that grabs the cookie for you. Now, if you need the users to been able to use html (a comment system for example) then you can use a whitelist for the allowed tags. – Manolis Agkopian Sep 22 '12 at 13:08
  • Manolis, Thanks for your advice. I already have paid enough attention to this problem. I'm using this method on a public extensible project and cannot guarantee that every developer who wants to extend it, follows the instructions you said. So, decided to assume that my cookies will be stolen in near future! That's what made me be a such strict programmer and ask this question! :) – zxcmehran Sep 22 '12 at 13:38
  • 1
    If user browser is upgraded (new version in UserAgent) or user has dynamic IP, he will have to login again. Is that ok solution for you? – Glavić Sep 22 '12 at 14:39
  • Glavic, you're right! My solution is not suitable for "Remember me" functionality. – zxcmehran Sep 22 '12 at 14:55

1 Answers1

1

If you are basing your senario on the assumption that

1) The attacker can have the same ip address and 2) The attacker can pretend to have the same user agent as they have access to any information transmitted over the net

Then there is no possible way for you to verify the identity of this cookie. This is because you have assumed in your assumptions that all this information is available.

You have two solutions: a) use SSL b) Trust that your users won't be in the same coffee shop as an attacker, that the IP address is valid, and that your site is not yet important enough to deserve a large scale attack. What can they do yet - make offensive posts and spam? They could do that anyway with their own accounts.

From my experience and from what I have read, I agree with the statement that "premature optimization is [one of the greatest evils of programming]". Focus your time on building a site that works and is useful for people and then, if something start to go wrong, think about getting an SSL certificate. You just don't have the money for the certificate and you don't have the money because your site has not yet been successful (so do that first).

"Premature Optimization" and paranoid security measures are temptations for programmers because we like to think of ourselves as working on large-scale, very important projects when we are not [yet].

user1122069
  • 1,767
  • 1
  • 24
  • 52
  • So, you are saying that there is no way to make it secure without using SSL? – zxcmehran Sep 27 '12 at 15:40
  • By the way, in my case, it's important to make it secure. Because its going to be used on a real large-scale project. I completely agree with you about "Premature Optimization", but this working on this project is not an example of that. – zxcmehran Sep 27 '12 at 15:45
  • Yes. If you can understand the reasoning - you are assuming that all traffic to and from the server is compromised, right? So every function that you write for the user will be known - how else will you send it to the user - and its inputs will be know... so its outputs will be known. Public key crypography is a solution to this problem... but why do you say that this project will go to a large scale when you don't have funds for ssl? What needs to be so secure and who are these attackers in the coffee shop? – user1122069 Sep 28 '12 at 20:08
  • The Project may not be enough large as you said, but, it will be used on many servers and hosts, and all users may not be able to pay for SSL certification. You can look at something like Joomla as it's example. – zxcmehran Oct 05 '12 at 20:14