5 ms·

People are reading this as a vulnerability in rails when it is actually a vulnerability in GH's code. Your comment unfortunately is going to add to it :(. What

People are reading this as a vulnerability in rails when it is actually a vulnerability in GH's code. Your comment unfortunately is going to add to it :(. What should he have reported to rails security team? Shouldn't he have been contacting GH security team instead? Edit: Rails guides discusses the root cause and counter measures against these type of vulnerabilities http://guides.rubyonrails.org/security.html#mass-assignment http://guides.rubyonrails.org/security.html#mass-assignment

nirvdrum 15y ago
Serious question: how is that any different than leaving SQL injection points in place and then just documenting it?
- vijaydev 15y ago
  If an app makes it possible to do SQL injections, whose fault is it? What Rails have done is to have a particular default (whose correctness can be debated) and document how it can be exploited and how to safeguard from it.
  - nirvdrum 15y ago
    You didn't really answer my question. Rails has all the helpers in place to sanitize input for SQL injection. Why in that case do they apply the defaults and not do so in this case? They both amount to making unwanted DB modifications.
bnegreve 15y ago
This is clearly what the author of the blog post suggests, why do you assume the vulnerability is in GH's code ?
dhconnelly 15y ago
When I read "this vulnerability affects tons of Rails apps," I read that as a security vulnerability in Rails. I'm not a user of the framework, but I've heard "convention over configuration" often enough to think that if this was brought up in the Rails issues tracker, it should be prevented by convention.
- marshray 15y ago
  If it affects "Hello Rails" the canonical example Rails application, then maybe it is arguably a vulnerability in Rails. http://guides.rubyonrails.org/getting_started.html#say-hello-rails http://guides.rubyonrails.org/getting_started.html#say-hello...
FuzzyDunlop 15y ago
The problem with this is that the getting started guide[0] uses this 'mass assignment' method in one of the examples (under section 6.8) without any mention of a caveat. The scaffolding does likewise. You'd be forgiven for thinking there was no vulnerability, given the lack of warning over that sort of code, and the fact that Rails does a lot of 'magic' behind the scenes (especially since you're using their own helper classes to handle form input and such like). [0] http://guides.rubyonrails.org/getting_started.html http://guides.rubyonrails.org/getting_started.html
javascriptlol 15y ago
Wrong. The system should not fail open.
generalk 15y ago
The Rails Guides may discuss it, but this does not excuse the fact that for years the Rails core team knowingly shipped code (and generators that created) insecure by default code. No, this isn't a "Rails vulnerability" in the traditional sense, but the level of immaturity and groupthink in the response to these issues being reported is staggering and somewhat shameful.

nirvdrum 15y ago

Serious question: how is that any different than leaving SQL injection points in place and then just documenting it?

vijaydev 15y ago
If an app makes it possible to do SQL injections, whose fault is it? What Rails have done is to have a particular default (whose correctness can be debated) and document how it can be exploited and how to safeguard from it.
- nirvdrum 15y ago
  You didn't really answer my question. Rails has all the helpers in place to sanitize input for SQL injection. Why in that case do they apply the defaults and not do so in this case? They both amount to making unwanted DB modifications.

bnegreve 15y ago

This is clearly what the author of the blog post suggests, why do you assume the vulnerability is in GH's code ?

dhconnelly 15y ago

When I read "this vulnerability affects tons of Rails apps," I read that as a security vulnerability in Rails. I'm not a user of the framework, but I've heard "convention over configuration" often enough to think that if this was brought up in the Rails issues tracker, it should be prevented by convention.

marshray 15y ago
If it affects "Hello Rails" the canonical example Rails application, then maybe it is arguably a vulnerability in Rails. http://guides.rubyonrails.org/getting_started.html#say-hello-rails http://guides.rubyonrails.org/getting_started.html#say-hello...

FuzzyDunlop 15y ago

The problem with this is that the getting started guide[0] uses this 'mass assignment' method in one of the examples (under section 6.8) without any mention of a caveat. The scaffolding does likewise. You'd be forgiven for thinking there was no vulnerability, given the lack of warning over that sort of code, and the fact that Rails does a lot of 'magic' behind the scenes (especially since you're using their own helper classes to handle form input and such like). [0] http://guides.rubyonrails.org/getting_started.html http://guides.rubyonrails.org/getting_started.html

javascriptlol 15y ago

Wrong. The system should not fail open.

generalk 15y ago

The Rails Guides may discuss it, but this does not excuse the fact that for years the Rails core team knowingly shipped code (and generators that created) insecure by default code. No, this isn't a "Rails vulnerability" in the traditional sense, but the level of immaturity and groupthink in the response to these issues being reported is staggering and somewhat shameful.