While I mostly agree that the Rails default should probably be changed, I think in fairness it's also worth pointing out that the Rails team does give fair warning about this issue. Specifically, anyone who reads the official Rails Security Guide back-to-back will know about this:
One might counter that nobody reads these guides back-to-back. I must admit I haven't read every word of every Rails guide. But I have read the security guide in its entirety, and I think every developer owes it to herself and her clients to do the same.
I'm not a big fan of the "this is documented" defense.
If Microsoft left a network accessible default passworded Admin account in Windows Server but documented it and told people to change it, would that be okay simply because it was documented? Documentation is no panacea for bad defaults.
Part of the OP's point (and he's absolutely right) is that this incident proves beyond a shadow of a doubt that just warning about the issue is clearly not enough. If the GitHub team screwed this up, what hope do the majority of the unwashed masses of Rails developers have, warning or no warning?
IIRC, something like that actually happened. Except it was a file server that threw your whole directory tree up on the net. oops! Why you ask? How could that even happen? It was just a few years before everyone had Internet, so it was assumed that your network was a LAN. (Source: http://www.grc.com/su-bondage.htm)
Of course, everyone should have really had a firewall anyway, so this was obviously cool right? After all, it's up to the user to secure their machine.
I think that every competent dev knows that something like update_attributes is inherently dangerous. So they probably keep it for backend import/maintenance tasks. At some point, someone copies the code/wrapper-function into the front-end.
The status quo of Rails is that everything is sanitized if you use the helpers. And validators on the models only look at data integrity. So all this protection, at least for me, kind of lulls you into feeling secure, because SQL inject is generally the typical, awful-case scenario.
update_attributes is not really a SQL inject attack vector (since the actual values are sanitized)...it's partially a social engineering scheme.
Actually, I do use update_attributes for public-facing interfaces. But only with attr_accessible. (I never use attr_protected, since blacklists are a disaster waiting to happen.)
http://guides.rubyonrails.org/security.html
One might counter that nobody reads these guides back-to-back. I must admit I haven't read every word of every Rails guide. But I have read the security guide in its entirety, and I think every developer owes it to herself and her clients to do the same.