Relevant:

  What I want you to see in that thread I mentioned is the
  way the core team perceives this. You are not discovering
  anything unknown, we already know this stuff and we like
  attr protection to work the way it is.

Looks like this guy got really frustrated with the Rails devs basically saying that he didn't know what he was talking about. This reminds me of all of the unsafe defaults that PHP used to have. Same justification too, "it's a config setting, so it's up to the developer/sysadmin to read the docs and set them right."

This justification seems especially odd to me since Rails did so much in the first place to popularize the idea that the default behavior should be the one most likely to be "right". Don't they (or didn't they at one time) have a mantra "convention over configuration"?

I guess that doesn't apply to security.

This also makes it all the more serious. As the PHP developers found out the hard way:

When you make it really easy to get started, a lot of people won't learn the system in depth enough to understand all the issues because they don't need to in order to make it work "well enough" for most cases.

By making Rails so easy to get started, they pretty much guarantee that there's going to be a ton of developers that don't pick up on, or forget, that they need to deal with issues like this.

That even a site like Github was vulnerable to this demonstrates just how seriously wrong it is to pick a default like this..

This guy brought up the vulnerability and the maintainers didn't seem to take it seriously since he wasn't articulate enough or was not approaching them with enough respect maybe for their liking? I wish they would have kissed his ass a little to get the low-down on the vulnerability so I didn't have to worry about my company's private github repos. He deserves props for bring it up for discussion.

This has been discussed since the early days of Rails, and they have chosen to leave their defaults as such and encourage developers to implement model security as needed. Github (seemingly) did not implement model security. This is a vulnerability that is different from application to application, and if the team was following best practices, is not there.

And he's just demonstrated why this is not a responsible approach from the Rails team.

If it's a simple mass-assignment vulnerability, the Rails team has nothing to do with it given that mass-assignment is a feature and the vulnerability is well documented:

http://edgeguides.rubyonrails.org/security.html#mass-assignm...

Heck, I even learned this way back when I was learning Rails:

http://railscasts.com/episodes/26-hackers-love-mass-assignme...

The fact that this is even a discussion is sufficient for me to consider it a bug. It's irresponsible of the Rails team to leave this default the way it is given that it's long been a known risk.

That they like to consider it a "feature" doesn't make it any better - it just makes them look like idiots

I was going to say the same thing.

The Security guide does describe the issue, and even describes attr_accessible as a "Countermeasure". http://guides.rubyonrails.org/security.html#mass-assignment

Without any precautions Model.new(params[:model]) allows attackers to set any database column’s value.

Unbelieveable! PHP showed long ago that allowing a web request to auto-populate arbitrary members in app objects is just a spectacularly bad idea.

Even the canonical "Hello Rails" example code neglects to specify attr_accessible. http://guides.rubyonrails.org/getting_started.html#hello-rai...

The general attitude of Rails developers towards security here is really shocking. I don't think I could recommend anyone use Rails.

Er.. that's because there's nothing malicious an attacker can do with the mass-assignment vulnerability in the "Hello Rails" app?

Being able to change the :id or timestamps of the post isn't anywhere near the SQL injection vulnerabilities I've seen in many tutorials in other languages/frameworks.

I agree, though, I wouldn't recommend Rails to people who can't bother to read documentation.

Yeah I really feel for this guy. I don't blame his final solution, it was totally necessary. Issue #5228 is painful to read.