I know that with Rails 3.2 all attributes are 'black-listed' in essence, that forces you to whitelist each attribute via attr_accessible.

However, if I make every column in my table attr_accessible doesn't that leave me vulnerable to mass assignment attacks?

If not, why not?

If so, what's the point of forcing whitelisting?

This is a real question, because one of my production apps I am forced to have something like this, just to get Devise to work:

attr_accessible :email, :password, :password_confirmation, :remember_me, :name, :confirmed_at, :confirmation_token

Thoughts?

有帮助吗?

解决方案

Columns listed are vulnerable in the sense that if you let users update those records via mass assignment then they will be able to update those columns. Remember that you don't need to make a field accessible if you'll just be doing user.foo = 'blah' - only calls to update_attributes, create an so on are concerned.

The point of this change of defaults is to make it pretty much impossible for you to forget about this: because you have to whitelist the attributes you have to think about whether access to those fields is ok. Ask yourself what an attack could accomplish if they could change those fields on records they are allowed to update.

The attr_accessible model is creaking at the seams - there was a post on the rails blog not too long ago about a new controller level approach they are trying.

其他提示

In your example there r only two fields which can be used to exploit auth process, confirmed_at and confirmation_token. But they can't be changed by user before he confirms his email, so no problem here before u change default behaviour of devise. Also i don't understand why u have to make them accessible.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top