How to hack a Rails app using its secret_token
robertheaton.com
robertheaton.com
Course none of that makes it acceptable (it's atrocious!). This is a perfect example of why code and config need to be kept separate[2]. If you have that as a mantra from the beginning then you don't have issues like this.
[1]: In reality you should change your secret token regularly. The best approach is to accept a rolling window of old ones so you can age them out. Then you can pick how far back you want to support (eg. how stale a client's cookie can be).
http://guides.rubyonrails.org/security.html
[edit] should be widely known. I would say it took me a couple hours to read the majority of the security doc at a shallow level) and I wouldn't have known about this unless i had just started upgrading a 2.3 app.
(tho i can't find a .gitignore for it
https://github.com/fortuity/rails3-gitignore
https://github.com/github/gitignore/blob/master/Rails.gitign...
The guides do not underline that you can do RCE, either!
There is a metasploit module available now.
https://twitter.com/unixmonkey/status/360859127620182017
https://github.com/joernchen/metasploit-framework/blob/7f3ec...
http://blog.codeclimate.com/blog/2013/01/10/rails-remote-cod...
https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...
(patched in 3.2.11)
https://github.com/joernchen/metasploit-framework/commit/7f3...
https://github.com/search?p=7&q=secret_token+extension%3Arb+...
The data stored in the cookie is cryptographically signed with the secret token so the server can verify if its been tampered with. It's a very solid approach but like anything involving crypto it's important to keep the secrets secret!
To clarify, the secret token should only be known to the server. The client doesn't have it. The client only has their own signed cookie data.
At the very least cookie storage should be an opt-in for apps that need it, not a default with apparently not enough warnings about the security aspects