2

When used as a session store, I noticed that redis-rails saves the session id in unencrypted format in the cookie. Shouldn't session id be treated as secure information and not be exposed in a cookie unencrypted to thwart session-hijacking attempts?

RajeshT
  • 417
  • 4
  • 9
  • No, they shouldn't, as long as they're protected in transit which https tends to cover. – pvg Sep 10 '17 at 18:50
  • 1
    The site uses https, but still someone can keep trying random strings as session id to grab someone else's session. Can't they? P.S May I know why the question is downvoted? – RajeshT Sep 10 '17 at 18:53
  • No, they can't unless the sessions are predictable or they have more time than the age of the universe. Session id's merely have to be random, unpredictable and sufficiently large. – pvg Sep 10 '17 at 19:04
  • You could theoretically say that using memcached/redis is more secure than cookiestore as aliens with super-unobtainium based quantum supercomputers could brute force the encryption. These very same aliens might also be able to guess a session identifier provided that your application stays online and the sun does not swallow earth first. – max Sep 10 '17 at 22:56
  • You might want to explore devise gem as well. – Ketan Doshi Sep 11 '17 at 07:54

1 Answers1

2

No.

The session identifier cookie is the only (decent) way to link a client to a session. The client must have some sort of claim which they can pass along with the request so that we can identify them.

This applies whether you are using CookieStore, Redis, ActiveRecord or memcached.

Encrypting the session identifier with a fixed salt or no salt would do absolutely nothing but waste time since the attacker has access to the cookie anyways in a man-in-the-middle or XSS attack.

If you used a salt you would have to link that to the user as well. Now you have two problems instead of one.

While you could use a bunch of novel approaches like salting with the user agent, ip or anything else that you think you know about the client the security benefits are few.

As @pvg said:

Session id's merely have to be random, unpredictable and sufficiently large.

Meaningful ways to protect the session are:

  • Use https to thwart man-in-the-middle attacks.
  • Call reset_session when logging users in and out to avoid session fixation.
  • Sanitize user input to avoid XSS.
max
  • 96,212
  • 14
  • 104
  • 165