4 ms·
> Knowing the secret token allows an attacker to trivially impersonate any user in the application. Worse. Knowing the secret token allows an attacker to trivi
by charliesome 13y ago
> 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 13y agoDoesn't Rails use randomly generated session IDs? Also, how does it allow an attacker to trivially execute code?
- danielfone 13y ago> 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 agoThat'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 agoRails' 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 agoalso, 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 agoSince 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 agojust 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 agoI 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 agoIt 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 13y agoRuby (and rails) has atrociously insecure deserialization that you need to explicitly disable.