3 ms·

> Session data is marshal-ed Ruby data, deserializing it has the same risks as YAML.load. http://daniel.fone.net.nz/blog/2013/05/20/a-better-way-to-manage-the-

> Session data is marshal-ed Ruby data, deserializing it has the same risks as YAML.load. http://daniel.fone.net.nz/blog/2013/05/20/a-better-way-to-manage-the-rails-secret-token/#comment-902646816 http://daniel.fone.net.nz/blog/2013/05/20/a-better-way-to-ma...

olalonde 13y ago
That's a bit surprising. I'd be interested to read the reasoning behind this design decision as most frameworks I have used store session data in a database rather than directly in the cookie. Well I guess there is a pretty damn good reason given Rails' reputation.
- davesims 13y ago
  Rails' default session is cookie store, highly recommended is DB. It's a config issue that depends on your app's particular DB setup, so default isn't DB. But in session_store.rb you'll see this comment recommending against the default: # Use the database for sessions instead of the cookie-based default, # which shouldn't be used to store highly confidential information # (create the session table with "rails generate session_migration") # ShopMobile::Application.config.session_store :active_record_store
  - gingerlime 13y ago
    also, in config/initializers/secret_token.rb: # Your secret key for verifying the integrity of signed cookies. Does this mean that if you use redis/db-backed sessions you can safely ignore this secret_token parameter completely or even delete this initializer? UPDATE: I just tried to remove it from our environment, and everything seems fine. Unless I'm missing something out, I'd say that's a far better and easier solution overall. It gives you much better control over you session + you don't have to worry about this configuration variable.
    - davesims 13y ago
      Since it's not only used for session cookies, I'd keep it around, on the off chance I ever wanted a signed cookie, like: cookies.signed['some-id'] = model.id Rails will use the secret here too.
      - gingerlime 13y ago
        just curious: when would you need a signed cookie though? i.e. What need does it fulfil that neither the session store nor your database do?
        davesims 13y ago
        I dunno, good question. Maybe something like this: there's some cases where I'll prefer cookies to session data, esp if it's non-volatile data that I can take or leave, like convenience values for the user on the js side, "last selected item" or the like. I don't necessarily want that data in my session, or as a user attribute that I have to migrate the DB for. If it's a pkid or something that isn't necessarily sensitive, but I also don't want it to be too easy to get at, I might use a signed cookie. Now, I've never actually done this... ;p
- lucian1900 13y ago
  It is often useful to not have to store anything server-side and just round-trip signed data in the cookie. Of course, using a format that can execute code on deserialisation is still a bad idea: a successful attack on the signature should at most let someone impersonate a user, not do anything to an app.

olalonde 13y ago

That's a bit surprising. I'd be interested to read the reasoning behind this design decision as most frameworks I have used store session data in a database rather than directly in the cookie. Well I guess there is a pretty damn good reason given Rails' reputation.

davesims 13y ago
Rails' default session is cookie store, highly recommended is DB. It's a config issue that depends on your app's particular DB setup, so default isn't DB. But in session_store.rb you'll see this comment recommending against the default: # Use the database for sessions instead of the cookie-based default, # which shouldn't be used to store highly confidential information # (create the session table with "rails generate session_migration") # ShopMobile::Application.config.session_store :active_record_store
- gingerlime 13y ago
  also, in config/initializers/secret_token.rb: # Your secret key for verifying the integrity of signed cookies. Does this mean that if you use redis/db-backed sessions you can safely ignore this secret_token parameter completely or even delete this initializer? UPDATE: I just tried to remove it from our environment, and everything seems fine. Unless I'm missing something out, I'd say that's a far better and easier solution overall. It gives you much better control over you session + you don't have to worry about this configuration variable.
  - davesims 13y ago
    Since it's not only used for session cookies, I'd keep it around, on the off chance I ever wanted a signed cookie, like: cookies.signed['some-id'] = model.id Rails will use the secret here too.
    - gingerlime 13y ago
      just curious: when would you need a signed cookie though? i.e. What need does it fulfil that neither the session store nor your database do?
      - davesims 13y ago
        I dunno, good question. Maybe something like this: there's some cases where I'll prefer cookies to session data, esp if it's non-volatile data that I can take or leave, like convenience values for the user on the js side, "last selected item" or the like. I don't necessarily want that data in my session, or as a user attribute that I have to migrate the DB for. If it's a pkid or something that isn't necessarily sensitive, but I also don't want it to be too easy to get at, I might use a signed cookie. Now, I've never actually done this... ;p
lucian1900 13y ago
It is often useful to not have to store anything server-side and just round-trip signed data in the cookie. Of course, using a format that can execute code on deserialisation is still a bad idea: a successful attack on the signature should at most let someone impersonate a user, not do anything to an app.