4 ms·

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

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.

aaronbrethorst 14y ago
Legacy codebases, etc etc
tptacek 14y ago
We definitely think you should be using attr_accessible and not attr_protected.
bdcravens 14y ago
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.
liquidise 14y ago
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?
- jey 14y ago
  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.
yxhuvud 14y ago
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.
- tptacek 14y ago
  This is ostensibly why attr_accessible has a "role" parameter.
  - dasil003 14y ago
    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. http://rubysource.com/rails-4-quick-look-strong-parameters/ http://rubysource.com/rails-4-quick-look-strong-parameters/

aaronbrethorst 14y ago

Legacy codebases, etc etc

tptacek 14y ago

We definitely think you should be using attr_accessible and not attr_protected.

bdcravens 14y ago

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.

liquidise 14y ago

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?

jey 14y ago
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.

yxhuvud 14y ago

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.

tptacek 14y ago
This is ostensibly why attr_accessible has a "role" parameter.
- dasil003 14y ago
  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. http://rubysource.com/rails-4-quick-look-strong-parameters/ http://rubysource.com/rails-4-quick-look-strong-parameters/