Hacker News Reader

Hacker News

Comment by charliesome | Hacker News Reader

Full thread

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.

View on HN

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

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

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.

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

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.

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.

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?

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

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.

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

Reply on news.ycombinator.com