Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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?

like image 862
Sam Avatar asked Jun 10 '13 18:06

Sam


People also ask

How can session hijacking be prevented?

There are several ways to prevent session hijacking from happening: Use strong passwords and multifactor authentication. These techniques protect accounts from being accessed by hackers if they manage to steal a user's session ID (Alkove, 2021). Only share session IDs with trusted sources.

What is considered the best option against session hijacking?

The session cookie is already an arbitrary value, encrypting it will just generate another arbitrary value that can be sniffed. The only real solution is HTTPS.

How do I secure session cookies?

You can ensure that cookies are sent securely and aren't accessed by unintended parties or scripts in one of two ways: with the Secure attribute and the HttpOnly attribute. A cookie with the Secure attribute is only sent to the server with an encrypted request over the HTTPS protocol.


2 Answers

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.
like image 171
Celada Avatar answered Sep 21 '22 09:09

Celada


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).
like image 31
Michael Avatar answered Sep 22 '22 09:09

Michael