Rails 2.0 cookies - Security Concern
rorsecurity.info
rorsecurity.info
--------------------------
* Introduce a cookie-based session store as the Rails default. Sessions typically contain at most a user_id and flash message; both fit within the 4K cookie size limit. A secure hash is included with the cookie to ensure data integrity (a user cannot alter his user_id without knowing the secret key included in the hash). If you have more than 4K of session data or don't want your data to be visible to the user, pick another session store. Cookie-based sessions are dramatically faster than the alternatives.
restful_authentication, for instance, puts only the user_id in the session. If a user were to crack the cookie and change the user_id to, say, 1 (which is often an admin account), it could be a HUGE security vulnerability.
I'm not even sure using a "really good" secret password would be a good enough security measure, since the user can do the brute forcing locally. And what about open source projects, where their environment.rb might be public?
All in all, I don't like it.
I don't know enough about the relative merits of HMAC vs. SHA512 hashing. I do know it still depends on the developer remembering to change the secret key into something harder to crack.
This isn't exactly a Rails 2.0 thing, though. Cookie-based session store was merged in in Rails 1.2.x, but enabled by default in Rails 2.0. You can still use memcached or "ActiveStore".
This security vulnerability is probably going to be one of the biggest gotcha for a newbie developer, as there is a wave of inexperienced or irresponsible Rails developers getting in on the action. Newcomers are still looking at the old, "write a blog in 15 minute" video made during the Rails 0.3 days, or the O'Reilly "Write a cookbook Rails app, parts one of three". Or Agile Web Development with Rails, 2nd Ed., which does not mention this gotcha.
One solution to this problem is not to depend on the developer to think up or generate a password. Rails 2.0 allows you to write "initializer" snippets that automatically load when placed in the appropriate directory. It would be almost trivially easy to write such a snippet that loads the secret key from an configuration file, and if one does not exist, automatically generate it. Such a setup would not depend on saving the secret key into the version control system, and can be refreshed every time the app gets deployed using an automation tool such as Capistrano. Though it would (should) invalidate all the current user sessions once redeployed.
Under this setup, you definitely don't want to serialize objects into the session. That's a surprisingly popular practice among a small minority of Rails developers.