5 ms·

I think one of the common security issues strongly hinted at by this blog post is Rails' secret_token.rb security debacle[1]. Basically Rails has a file called

by h2s 14y ago

I think one of the common security issues strongly hinted at by this blog post is Rails' secret_token.rb security debacle[1]. Basically Rails has a file called secret_token.rb containing what should be a complete secret, but the default Rails .gitignore doesn't ignore it and as far as I've experienced, none of the main introductory Rails tutorials mention it. So a lot of people accidentally publicise it on GitHub, and this facilitates exploits of some of the recent Rails vulnerabilities. [1] http://biggestfool.tumblr.com/post/24049554541/reminder-secret-token-rb-is-named-so-for-a-reason http://biggestfool.tumblr.com/post/24049554541/reminder-secr...

josephlord 14y ago
I've made this mistake although fortunately with an unpublished app to a private repo but I'd still like to fix it. My ideal solution will probably be to: 1) Look for an environment variable 2) Look for a file in the project config or root named: secret-git-ignore-this-file (or something similar) 3) If it fails to find either of then generate a new secret with secure_rand 4) If running on Heroku write it to the environment variable (I think this can be done and should persist although I'll need to check the documentation). 5) Otherwise write it to the secret-git-ignore-this-file If/when I get round to this I'll probably try to put it on Github for others to use although if anyone knows of any good published solutions that do something like this that would be even better.
- Xion 14y ago
  Even if #4 is possible (I rather doubt it), you shouldn't really do that. It breaks the barrier between code and configuration by making the former influence the latter. Such approach is simply not scalable. I don't know what secret_token.rb is (I do Python) but if it's anything like an HMAC key for encrypting your session cookies, your app will break once deployed to more than one frontend because the cookies will suddenly become tied to specific dyno.
  - deleted 14y ago
    [deleted]
  - thisone 14y ago
    4 is possible. You run the app locally using foreman, store your local variables in a .env file, and add that to your gitignore. For your heroku running app, you use the toolbelt to add env variables. https://devcenter.heroku.com/articles/config-vars#local-setup https://devcenter.heroku.com/articles/config-vars#local-setu... https://devcenter.heroku.com/articles/config-vars#setting-up-config-vars-for-a-deployed-application https://devcenter.heroku.com/articles/config-vars#setting-up...
  - josephlord 14y ago
    Yes it is for the session cookies. You are right that it won't work well for multiple frontend servers but that isn't going to be an issue for this current app. If it is written to the Heroku environment it should be available to all dynes I think. I can rethink the solution if I need scale. I don't really think of it as config as I don't care what the value is just that it is consistent on any given host.
- ryannielson 14y ago
  I wrote a gem that I've used to help with the secret key problem in the past. It's called Envious: https://github.com/RyanNielson/envious https://github.com/RyanNielson/envious Basically it adds a yml file, that is added to .gitignore, with configuration settings that get added to ENV. It can even send your environment variables to Heroku using a Rake task. There are some examples on the page. You can use it to have different secret keys depending on your Rails environment as well.

by h2s 14y ago

josephlord 14y ago

I've made this mistake although fortunately with an unpublished app to a private repo but I'd still like to fix it. My ideal solution will probably be to: 1) Look for an environment variable 2) Look for a file in the project config or root named: secret-git-ignore-this-file (or something similar) 3) If it fails to find either of then generate a new secret with secure_rand 4) If running on Heroku write it to the environment variable (I think this can be done and should persist although I'll need to check the documentation). 5) Otherwise write it to the secret-git-ignore-this-file If/when I get round to this I'll probably try to put it on Github for others to use although if anyone knows of any good published solutions that do something like this that would be even better.

Xion 14y ago
Even if #4 is possible (I rather doubt it), you shouldn't really do that. It breaks the barrier between code and configuration by making the former influence the latter. Such approach is simply not scalable. I don't know what secret_token.rb is (I do Python) but if it's anything like an HMAC key for encrypting your session cookies, your app will break once deployed to more than one frontend because the cookies will suddenly become tied to specific dyno.
- deleted 14y ago
  [deleted]
- thisone 14y ago
  4 is possible. You run the app locally using foreman, store your local variables in a .env file, and add that to your gitignore. For your heroku running app, you use the toolbelt to add env variables. https://devcenter.heroku.com/articles/config-vars#local-setup https://devcenter.heroku.com/articles/config-vars#local-setu... https://devcenter.heroku.com/articles/config-vars#setting-up-config-vars-for-a-deployed-application https://devcenter.heroku.com/articles/config-vars#setting-up...
- josephlord 14y ago
  Yes it is for the session cookies. You are right that it won't work well for multiple frontend servers but that isn't going to be an issue for this current app. If it is written to the Heroku environment it should be available to all dynes I think. I can rethink the solution if I need scale. I don't really think of it as config as I don't care what the value is just that it is consistent on any given host.
ryannielson 14y ago
I wrote a gem that I've used to help with the secret key problem in the past. It's called Envious: https://github.com/RyanNielson/envious https://github.com/RyanNielson/envious Basically it adds a yml file, that is added to .gitignore, with configuration settings that get added to ENV. It can even send your environment variables to Heroku using a Rake task. There are some examples on the page. You can use it to have different secret keys depending on your Rails environment as well.