Surely you should be using attr_accessible with config.active_record.whitelist_attributes = true anyway? I can't imagine a situation where you'd want to have to manually blacklist attributes over whitelisting them.
That's made learning Rails a bit interesting. Seems that a number of these vulnerabilities are practically moot if you're following best practices brought about within the last year or so (for example, attr_accessible on all models as a result of the Github snafu). Of course, all vulnerabilities are worth paying attention to, but it'd be nice to know which ones are relevant to greenfield development.
How about when you want the majority of your attributes whitelisted? I understand the urge to whitelist, but lets be reasonable here.
If i have a table with 20 columns, 19 of which i want accessible (lets exclude a private UK). I also expect the schema for the table to be volatile. Why should i even consider while listing 19+ over blacklisting 1?
The idea is to fail in the direction of being safer than unsafe, if for example someone adds a database column and forgets to write "attr_protected" in the Rails code.
I have 170 tables in an app and a similar amount of controllers. 3 of those refer to the logged in user and in no place except the admin controller itself can you modify an object, or what an object refer to, in such a way where an administrator can access anything he or she shouldn't. Admins have different accounts not to restrict what they can do but to (automatically outside what can be modified by posting params to models) keep track of who has made what changes and to keep them for making incompatible changes at the same time.
So no, I'd rather not start whitelisting my models.
Yes, however it's also worth noting that Rails core has acknowledged the awkwardness of relying solely on model-level protection for vulnerabilities that should be nipped in the bud at the controller level. Rails 4 will include DHH's new strong_parameters gem that allows params to be filtered proactively on every controller. This will of course help prevent a much broader class of vulnerabilities than ActiveRecord bugs.
