How do I prevent session hijacking by simply copy a cookie from machine to another?

Question

Most Web Applications use cookies to manage the session for a user and allow you to stay logged in even if the browser was closed.

Let's assume we did everything by the book to make sure the cookie itself is safe.

• encrypt the content
• set http only
• set secure
• ssl is used for the connection
• we check for tampering with the content of the cookie

Is it possible to prevent someone with physical access to the machine to copy the cookie and reuse it on another machine and thus stealing the session?

Perfidy

None of your proposed checks would in any way stop someone from physically copying an unmodified cookie to a new location. – Rafaellle

You can tie a session to an IP address, but it's not really a good idea by itself as it breaks for legitimate users in a variety of circumstances. (Although IP checking can certainly be useful as part of a wider risk rating strategy.) – Rigid

@bobince: IP adress is not an option since you would invalidate your cookie everytime you change the network. – Perfidy

@deadron: These measurements have nothing to do with copying the cookie. This demonstrate what can be done to make the value safe. – Perfidy

None of this makes the value safe. They only protect the connection. You seem to be making an assumption here that major applications have some sort of protection in place for this. If you actually use the applications you will find that the protection generally comes in the form of short activity based timeouts in addition to an IP to cookie association. This is just how browsers work. If you need a more secure solution consider writing your own Browser in something like QT. – Rafaellle

Answer 1

This risk is inherent in using cookies to authenticate sessions: the cookie is a bearer token, anyone who can present the cookie is authenticated.

This is why you see further protections such as:

• automatic log out after a certain amount of time, or period of inactivity;
• device fingerprinting;
• requiring re-authentication for critical actions (e.g. making a bank transfer or changing your password).

Demirep

Honestly never thought of why re-authentication was needed esp changing password till you start using JMeter and not able to make auth work in one go (ViewState) - so copy Cookie and voila!!! – Esculent

Answer 2

It doesn't make sense to "protect" against this. If this kind of copying happens, then either:

• The end user did it on purpose because they wanted to change computers. This is, of course, not something you should care about or be concerned about.
• An attacker has already compromised the user's browser and gotten access to the cookies stored inside. By definition this cookie is a secret that proves that the identity of the HTTP client. If the attacker already has access to it, they can already use it in any number of ways of their choosing that you won't be able to prevent or distinguish from the real user accessing the server legitimately.

Thomas

Why is it already game over? Please elaborate your answer.All large apps like Gmail, Facebook, Github, etc use cookies. What are they doing to avoid trojan horses just checking for a working cookie? – Perfidy

I tried to clarify a little bit. Basically it comes down to the fact that if a secret is exposed to an attacker, who can't prevent the attacker from knowing the secret. That's a tautology. – Thomas

See I don't know if I agree with that - even if you do compromise a cookie, you should be able to prevent usage on another, completely different machine. Its not easy to do that, but I think "don't care about it" isn't a good way to go. – Niobous

@KarthikRangarajan I see what you're saying, but trying to prevent a small piece of (secret) data from being copied is like trying to write software that prevents you from writing a password on a piece of paper: how could you possibly, even in principle, prevent it? – Thomas

I agree with that - you cannot really prevent them from copying it; but you can prevent them from using it. How about locking the cookie to that machine, and if used on any other machine, just expiring the cookie? That could potentially work. – Niobous

@KarthikRangarajan: Well, it would have to be enforced by the server. Short of OS fingerprinting, I suppose you could restrict the cookie to be valid only for clients coming from a certain IP address, but you'd block legitimate access if the true client happened to change IP addresses. Everything else, such as for example, User-Agent string, is under the control of the client. – Thomas

Yup, that's exactly what I am talking about @Celada. – Niobous

I don't agree with "It doesn't make sense to \"protect\" against this" neither. First of all, it doesn't answer the question - the answer could be a "yes" because it might be possible using @KarthikRangarajan's suggestion, though may not be user-friendly. Secondly, security is often enforced in different layers, and it's weird to me that one shouldn't enforce it in their own application layer and instead just rely on other layers of security. If the application is really critical and needs that level of security, then it should. – Musculature