Home > Mobile >  What's stopping someone from force logging into cookie authentication with 'document.cooki
What's stopping someone from force logging into cookie authentication with 'document.cooki

Time:02-19

Let's say you're using express sessions to provide a session cookie & storage. How would you authenticate that a user is actually that user? Can any random person get an "authenticated" cookie and import it into their browser via the developer console document.cookie='cookie=IAMACOOKIE'? At this point they have all access to the account(unless session has expired).

Sorry if this is a dumb question! I'm only recently starting to get into web stuf.

CodePudding user response:

Session cookies are generally protected in a several ways:

  1. They must be cryptographically hard to "guess" or attack with a brute-force attack. This will typically also include encryption based on a server-side "secret".

  2. They should be protected with an https transport so that there is no way for any man-in-the-middle to grab the cookie and then use it. Note a very vulnerable situation is a cookie used of http on a public WiFi network. At that point the owner of the WiFi network or someone who hacked into the WiFi network could easily be collecting cookies. But, if the cookie is always under https and marked as secure (such that the browser will never send the cookie over http), then it's not subject to the hacked public WiFi. End-users can also use VPNs to protect themselves on public WiFi, but really any web-site that wants or needs to protect their user's auth credentials must run on https such that the credentials are automatically protected, even on public WiFi.

  3. Session cookies should be given the options Secure and HttpOnly. This prevents them from ever being sent over http and prevents client-side Javascript in a web page from accessing them.

  4. Session cookies should have a relatively short lifetime (time period on the server where they are valid), limiting the number of them that are still alive and subject to guessing attacks. One has to find a compromise point between security and user experience as you don't want to be forcing the user to log back in every 5 minutes either.

  5. Rate limiting (and perhaps even IP blocking) is deployed to detect and prohibit scripted guessing of cookie values.

The point of these protections are that it would be very difficult for a session cookie to be guessed by an attacker or stolen while in transit.

Let's say you're using express sessions to provide a session cookie & storage. How would you authenticate that a user is actually that user?

The id in the session cookie is a temporary authentication credential. It is assumes that if you have that cookie, then you are the same user as the one who originally logged in when the session cookie was created (or were given permission by the original user to use the session).

If a user were to show/send the cookie info to another person; could they import that data onto their own machine/browser, allowing them to "be" that user until the session expires?

Yes, one could do that if you really wanted to. Some web-sites may use some sort of "browser fingerprinting" to attempt to detect the case where a cookie is now being used by a different browser. But, at that point, the original owner could just lend their username and password to someone else too. It's just a fact that any legit user has the ability to "lend" their login credentials to anyone they want to (whether that is or isn't a wise thing for them to do).

  • Related