News for hackers. Stuff that matters.
Re:SQL Injection Vulnerability in Ruby on Rails; affects all... by up_and_up on Wednesday January 02, 2013 @08:43PM (#5000612)
"This leaves persist_by_session open to sql attacks (such as logging in as any user), if a malicious user can write their own rails session cookie (if they have the rails secret_token)."

The key is: "if they have the rails secret_token"

The secret token is autogenerated when the application is initially bootstrapped. Here is more information about it from any config/initializers/secret_token.rb file:

# Your secret key for verifying the integrity of signed cookies.

# If you change this key, all old signed cookies will become invalid!

# Make sure the secret is at least 30 characters and all random,

# no regular words or you'll be exposed to dictionary attacks.

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