2

For example, Rails Restful Authentication uses

User.find_by_id(session[:user_id])

to find the user as the first try. So

  1. If the session is stored only by the use of cookies (isn't this a Rails option of storing session info all by using just cookies?), then can't user with user id 12345 changes his cookie's value from 12345 to 12346 and pretend to be another user?

as a side note

I. If the session is by a session_id as a cookie, and looked up session info in the DB, then can't another person steal the cookie and pretend to be that user? (steal the cookie by interception internet traffic)

II. Or, since the 3rd choice is to use the cookie auth_token to check against the users table for the field remember_token, can another person steal this auth_token cookie and pretend to be that user?

nonopolarity
  • 146,324
  • 131
  • 460
  • 740

3 Answers3

3

Cookie security, session hijacking and much more are all covered in the Ruby on Rails Security Guide. It's a must-read.

jdl
  • 17,702
  • 4
  • 51
  • 54
1

From jdl's answer, there are some paragraphs there:

The client can see everything you store in a session, because it is stored in clear-text (actually Base64-encoded, so not encrypted). So, of course, you don’t want to store any secrets here. To prevent session hash tampering, a digest is calculated from the session with a server-side secret and inserted into the end of the cookie.

That means the security of this storage depends on this secret (and on the digest algorithm, which defaults to SHA512, which has not been compromised, yet). So don’t use a trivial secret, i.e. a word from a dictionary, or one which is shorter than 30 characters. Put the secret in your environment.rb:

 config.action_dispatch.session = {
  :key    => '_app_session',
  :secret => '0x0dkfj3927dkc7djdh36rkckdfzsg...'
}

note: I am not sure it is config.action_dispatch.session or config.action_controller.session, or Rails 3.0.1 is suggesting: DEPRECATION WARNING: config.action_controller.session has been deprecated. Please use Rails.application.config.session_store instead.

Community
  • 1
  • 1
nonopolarity
  • 146,324
  • 131
  • 460
  • 740
0

This cannot happen because sessions just reference a cookie stored on the server. The only thing that is stored on the users browser is an id that is then used to get the session off of the server. So unless they are able to get the encryption for a session, users will not be able to systematically guess id's for the reason I just explained.

Update

change the default to store the session on the server instead of in the cookie

Community
  • 1
  • 1
thenengah
  • 42,557
  • 33
  • 113
  • 157
  • 1
    Default behavior in Rails is to store the entire session in a cookie. You may optionally store it on the server. – jdl Feb 25 '11 at 00:12
  • but even so the cookie is encrypted by the secret key generated when the rails app is generated, AFAIK – Gareth Feb 25 '11 at 00:27
  • @Gareth so you mean it is hard to fake `session[:user_id]` to be something else because it is encrypted or is encrypted with encrypted checksum? – nonopolarity Feb 25 '11 at 02:26