-2

I was thinking about a situation to avoid session sharing or hijacking, validating the IP the user logged in against the ip that is accessing any page after log in. It was working until I figured it's possible when the user are coming from other network and someone from inside the same network copied (or hijacked) the cookie to another machine. After you copy a cookie from a logged session to another machine, the other machine can access the application without login because the session id is ok and the IP (when comes out to the internet) is the same.

Is there any way we can avoid it?

I was thinking having the cookie encrypted using SSL by the server sharing the key as it does for SSL connection. In this way only the right client would have the right cookie value. (Here I'm not talking about connection with SSL but encrypt the cookie. The SSL will be used encrypting the content as usual). I didn't find anything about this yet.

I would say the question is more like "How can I create a encrypted cookie based on each client and the server is the only one who can decrypt the cookie". If I just encrypt it on server, based on my encryption key, it will be the same encryption to every user and it will keep being copied.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
user3551863
  • 101
  • 1
  • 1
    You can try to use [browser fingerprinting techniques](https://panopticlick.eff.org), but in the end you're trying to achieve something that isn't possible. You cannot protect against users voluntarily sharing the same cookie in the same network. All of your identifying information are client-supplied. – Adi Apr 23 '14 at 08:03
  • What problem are you trying to solve? This sounds like something that is poorly motivated and where your ultimate goals are probably not solvable through technology. (If the user of the machine is malicious, he can always proxy requests from the other machine, and you can't prevent that.) – D.W. Jun 24 '14 at 00:56

2 Answers2

1

Is there any way we can avoid it?

Yes, you could have a rolling session key. i.e. the server will generate a new Session ID to store in the cookie every n number of requests. The Set-Cookie header will only be sent once, so if there are two browsers logged into the same session, one of them will be using the old, invalid session. You could have a small overlap where both sessions are valid to avoid problems with requests for resources that the browser has yet to request (e.g. an AJAX request that has just been sent awaiting a connection, while the server has responded with a new ID to the main page request). This gives a good balance of usability whilst fulfilling your single session requirement as the browser that does not receive the new cookie will be logged out.

Another way to do this is to go for a stricter method, as employed by some banks. Rather than store the Session ID in a cookie, it is stored in the page itself. This also ensures that the user follows a set route through your site and cannot jump to pages out of sequence. The way this works is that there is a hidden field within the page and each navigation action is a HTTP POST to the next page. e.g. you could have a single handler at https://www.example.com/loggedInAction and each form POSTs to that:-

<form method="post" action="https://www.example.com/loggedInAction">
  <input type="hidden" name="requestId" value="123456" />
  <input type="hidden" name="action" value="navigateToMyAccountPage" />
</form>

The idea here is that the Request ID is regenerated after each navigation action, and the server uses this Request ID to keep track of each session. Session sharing is not possible as the ID is stored in the form rather than the cookie, although it can be combined with a cookie if you wish to keep session ID and the request ID separate. If another user did copy the request ID and edit their request, only the first user could continue as each Request ID is expired once used. This approach will also prevent use of the back button on the site, and it is really an approach that needs to be designed into the system from the start.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
0

Cookies have an option to force encryption. Simply add secure; to the cookie header:

Set-Cookie: mycookie=somevalue; path=/securesite/; Expires=12/12/2010; secure; httpOnly;

httpOnly; protectes the cookie from JavaScript.

See How can I check that my cookies are only sent over encrypted https and not http?

Also keep in mind that users IP might change during session could be normal. Mobile Device switching to WLAN or after a 24 hour disconnect.

Community
  • 1
PiTheNumber
  • 5,394
  • 4
  • 19
  • 36
  • 1
    This protects from malicious hijacking of the cookie in-the-wire. It doesn't address issues of hijacking from the machine itself, or (as per OP's question) normal copying of the cookie value from one browser to another. – Adi Apr 23 '14 at 07:57
  • @Adnan If the attacker has access to the computer there is nothing left to secure. – PiTheNumber Apr 23 '14 at 08:01
  • 1
    Duh! Which is what you should tell the OP in your answer. Regardless of it being a good advice or not, your answer does **not** address the question. In this site, we answer questions. – Adi Apr 23 '14 at 08:03
  • @Adnan I don't think OP is talking about access to the computer. The attacker has only hijacked the cookie. He could have got it from LAN traffic. Anyway it is better to protect the cookie from getting stolen in the first place. – PiTheNumber Apr 23 '14 at 08:08
  • _"I was thinking about a situation to avoid session **sharing** or hijacking"_ ... _"someone from inside the same network **copied** (or hijacked) the cookie to another machine."_ – Adi Apr 23 '14 at 08:12