Hacker News Reader

Comment by boundlessdreamz | Hacker News Reader

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

View on HN

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

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.

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

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

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.

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.

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.

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

Wrong. The system should not fail open.

Reply on news.ycombinator.com