[charliesome]

> Knowing the secret token allows an attacker to trivially impersonate any user in the application.

Worse. Knowing the secret token allows an attacker to trivially execute code in your application.

Don't ever let your secret token become public knowledge, and if it does, you need to change it straight away.

[olalonde]

Doesn't Rails use randomly generated session IDs? Also, how does it allow an attacker to trivially execute code?

[danielfone]

> 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-ma...

[olalonde]

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]

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]

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]

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.

[lucian1900]

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.

[duaneb]

Ruby (and rails) has atrociously insecure deserialization that you need to explicitly disable.