News for hackers. Stuff that matters.
Re:SQL Injection Vulnerability in Ruby on Rails; affects all... by paulgb on Wednesday January 02, 2013 @09:15PM (#5000713)
Re:SQL Injection Vulnerability in Ruby on Rails; affects all... by mikeryan on Wednesday January 02, 2013 @09:36PM (#5000773)
did you even look at what was matched?

Change the cookie secret token at config/initializers/secret_token.rb

Create a config/initializers/secret_token.rb file:

That will rename your app in the following files: ... config/initializers/secret_token.rb

Change your Application’s Secret Token ...

Change the secret token at /config/initializers/secret_token.rb

Those are the first six items in order and the trend continues at least through the first page of results.

Re:SQL Injection Vulnerability in Ruby on Rails; affects all... by paulgb on Thursday January 03, 2013 @06:45AM (#5001931)
Good catch, I'm glad that it's a best practice. I wasn't trying to shame those projects, I'm not a rubiest so I was just trying to figure out how someone might gain access to a secret token.
Re:SQL Injection Vulnerability in Ruby on Rails; affects all... by SoftwareMaven on Wednesday January 02, 2013 @09:26PM (#5000747)
That's an interesting issue (Django has the same issue with its SECRET_KEY). If you have an open-source project that utilizes these kinds of technologies, you need to keep your secret key secret.

As it says in the Django settings:

"Make this unique, and don't share it with anybody."

Your web application's security depends on it!

Re:SQL Injection Vulnerability in Ruby on Rails; affects all... by graue on Wednesday January 02, 2013 @10:50PM (#5000946)
Incidentally, this is one reason why the 12-factor app methodology stores configuration in environment variables, not source files. http://www.12factor.net/config