0

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?

marcamillion
  • 32,933
  • 55
  • 189
  • 380

2 Answers2

1

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.

Frederick Cheung
  • 83,189
  • 8
  • 152
  • 174
0

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.

Yuri Barbashov
  • 5,407
  • 1
  • 24
  • 20
  • Because of the particular Devise module I am using `:confirmable`...it needs to set those fields. – marcamillion Jun 10 '12 at 19:58
  • If u don't know how to monkeypatch devise module to remove this behaviour, u can use attr_accesible with role, as: user, for example, and then use assign_attributes with as: user. http://api.rubyonrails.org/classes/ActiveModel/MassAssignmentSecurity/ClassMethods.html – Yuri Barbashov Jun 10 '12 at 20:26
  • Well I was asking specifically as a theoretical question...am I still exposed to mass assignment attacks if I have many columns in my `attr_accessible`? – marcamillion Jun 10 '12 at 21:44