31

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?

user5532169
  • 719
  • 1
  • 7
  • 24
Sam
  • 443
  • 1
  • 4
  • 7
  • None of your proposed checks would in any way stop someone from physically copying an unmodified cookie to a new location. – Deadron Jun 10 '13 at 18:12
  • 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.) – bobince Jun 10 '13 at 21:11
  • @bobince: IP adress is not an option since you would invalidate your cookie everytime you change the network. – Sam Jun 10 '13 at 22:28
  • @deadron: These measurements have nothing to do with copying the cookie. This demonstrate what can be done to make the value safe. – Sam Jun 10 '13 at 22:30
  • 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. – Deadron Jun 11 '13 at 13:28

2 Answers2

27

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.
Celada
  • 20,176
  • 3
  • 55
  • 70
  • 3
    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? – Sam Jun 10 '13 at 22:27
  • 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. – Celada Jun 11 '13 at 00:02
  • 7
    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. – Karthik Rangarajan Jun 11 '13 at 14:29
  • 2
    @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? – Celada Jun 11 '13 at 14:45
  • 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. – Karthik Rangarajan Jun 11 '13 at 20:23
  • 6
    @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. – Celada Jun 11 '13 at 20:38
  • Yup, that's exactly what I am talking about @Celada. – Karthik Rangarajan Jun 11 '13 at 21:09
  • 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. – Leo Lei Nov 30 '15 at 00:42
15

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).
Community
  • 1
  • 1
Michael
  • 879
  • 4
  • 12