3 ms·

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 authlogi

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.

venus 14y ago
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.
- numbsafari 14y ago
  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_that_for_you/index.html 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 http://stackoverflow.com/a/2241740
  - deleted 14y ago
    [deleted]
    - deleted 14y ago
      [deleted]
up_and_up 14y ago
"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.
- paulgb 14y ago
  354 matches. https://github.com/search?utf8=%E2%9C%93&q=secret_token.rb&ref=searchcontext https://github.com/search?utf8=%E2%9C%93&q=secret_token....
  - SoftwareMaven 14y ago
    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!
    - graue 14y ago
      Incidentally, this is one reason why the 12-factor app methodology stores configuration in environment variables, not source files. http://www.12factor.net/config http://www.12factor.net/config
  - mikeryan 14y ago
    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.

venus 14y ago

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.

numbsafari 14y ago
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_that_for_you/index.html 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 http://stackoverflow.com/a/2241740
- deleted 14y ago
  [deleted]
  - deleted 14y ago
    [deleted]

up_and_up 14y ago

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

paulgb 14y ago
354 matches. https://github.com/search?utf8=%E2%9C%93&q=secret_token.rb&ref=searchcontext https://github.com/search?utf8=%E2%9C%93&q=secret_token....
- SoftwareMaven 14y ago
  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!
  - graue 14y ago
    Incidentally, this is one reason why the 12-factor app methodology stores configuration in environment variables, not source files. http://www.12factor.net/config http://www.12factor.net/config
- mikeryan 14y ago
  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.