Hacked: commit to rails master on GitHub

Indeed, github, Ruby and Rails are all different things. I do recommend approaching language/platform/tool choices form an engineering rather than a social point of view.

Don't get me wrong, though. I can see being turned off by rockstars, but you've found a language unencumbered by them?

More like:

"Dear Grabastic,

Today we had a demonstration by a user (xxx) of a security vulnerability on our site.

${VULNERABILITY_EXPLANATION}

We believe that it is possible that your application or records are covered in the scope of the exploit, because of the fact that ${VULNERABILITY_APPLICATION}.

In order to fix this issue, we have ${VULNERABILITY_PATCH}.

We have thanked this user for their vigilance in spotting bugs and security weaknesses in our site, and they have been added to our contributors-security page here (link).

We have a stance that security is something that can only be improved by lots of inquisitive eyes, and so if you have seen any issues that concern you, please do not hesitate to inform us and/or demonstrate the vulnerability--provided, of course, you do so without breaking anything permanently. :)

Our service is better today than it was yesterday, and we hope that with the patience and openness of our users it will be still better tommorrow!

Sincerely, angersock "

See, not so hard!

Not all security vulnerabilities can be protected automatically by a web framework. In many cases, frameworks provide features that developers can use themselves to secure their applications.

Example:

XSS is a common web security problem. In short, it means that putting user-originated data back on the page unescaped is unacceptable. Before Rails 3.0, the Rails approach to this problem was to provide a helper (h), which you could use to escape content that you knew to be vulnerable.

Unfortunately, many Rails users did not use this feature in all places they should have used it. As a result, many applications (Twitter included) suffered from whack-a-mole XSS vulnerabilities.

We were unable to solve this problem in the 2.x branch, because automatically escaping all text being put onto the page would be a massive breaking change and would break every app in existence.

Further, simply escaping all text would not really solve the problem. For example, the "" tag generated by Rails itself should not be escaped, while any of its contents or attributes provided by the application should. Asking the user to take on the responsibility to mark Rails-generated content as not needing escaping would reintroduce the same problem we had before: people would "unescape" things too eagerly, and apps would tend to have vulnerabilities.

The solution was to release a plugin for Rails 2.3 users (rails_xss) and change the default in Rails 3. It isn't perfect: there are still cases where applications have to mark strings as "safe", and applications that have to do so often might have the same problem, but I think we did a good job, all things considered.

This case is quite similar. Rails provides all the tools necessary to have a secure application (attr_accessible is the equivalent of h), but many apps don't use it correctly (or at all). In short, a Rails security default seems to be wrong, insofar as "wrong" means that many people fail to use the security feature, causing their applications to be vulnerable.

As with the XSS feature, fixing this problem requires some thought. Simply changing the default would break a lot of applications in the wild. Like XSS, it's probably correct to do so anyway here. However, like XSS, we should make sure that we have done everything we possibly can to mitigate the additional cost associated with complying with the new default. If it's too painful, many people will overeagerly bypass the feature, reintroducing the very issue we were trying to protect them from.

In this case, I have proposed a solution that I think will mitigate a lot of the problem (https://gist.github.com/1974187), and we will likely ship it as a Rails 3.2 plugin. This will allow us to gather feedback about unexpected consequences and ensure that when we change the default for Rails 4 (which has not even shipped a prerelease yet), it actually mitigates the security problem in the vast majority of Rails applications.

Nope, Diaspora also had this exact issue, which would let you use anything where a params hash updated a user model to e.g. overwrite their credentials or encryption keys. The specific exploitable example I found would have let you do it even if they had been checking authorization to update objects properly, because the attacker could reassign his own objects as the victim's objects with arbitrary attack payloads, one of which being sufficient to compromise the victim's account.

When I wrote a journal article about it my recommendation was that Rails ship with

ActiveRecord::Base.attr_accessible(nil)

by default, because otherwise vulnerabilities of that nature were virtually inevitable.