You need a way to inject symbols as hash keys. Normal parameter handling does not allow this, so you need a different way to exploit the bug. As venus says, session forging is one way. Regular parameter handling is not.

I will defer to the rails core dev here :)

The linked vuln report gives the impression that regular parameter handling is vulnerable.

Sure. Here is the exploit: https://github.com/binarylogic/authlogic/pull/341

That's a bug/exploit in Authlogic, a third party library for rails, not rails.

However, that bug/exploit is based on the rails vuln and was patched in authlogic exactly how the Rails report instructed people to work around it (casting the parameter to a string).

Reading the actual report linked in the OP you'll see that generic and boilerplate code (e.g. the extremely common pattern: "Post.find_by_id(params[:id])") is going to be vulnerable to this bug.

"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.

354 matches.

https://github.com/search?utf8=%E2%9C%93&q=secret_token....

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.

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.

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!

Incidentally, this is one reason why the 12-factor app methodology stores configuration in environment variables, not source files. http://www.12factor.net/config

The linked pull request described a method for getting unescaped code into the application so the issue with find_by_id might be exploited.

Have you got another way of getting unescaped code into the application such that this issue might be exploited? If so, the core team will be very, very interested to hear from you.

I've been going through the code for ActiveRecord and now AuthLogic. I'm admittedly not well versed in Ruby.

However from the description of the vulnerability found at [1], it would appear as though the cookie value can be set to a Ruby string value that is then parsed by server to produce a Ruby Hash value (rather than the AuthLogic plugin's assumed string value).

Is the eval() of the cookie value done by Rails or is it done by AuthLogic? Is that a potential security vulnerability in itself?

[1]http://phenoelit.org/blog/archives/2012/12/21/let_me_github_...

edit: forgot the URL

edit2: nvm ... apparently it's using the Ruby Marshal API, not an eval()-type call.

http://stackoverflow.com/a/2241740