My app relied on the security vulnerability fixed in Rails 3.0.1.
While I did specify attributes such as name and email, my main goal
was to use an existing record by specifying the id. The 3.0.1 patch
does not make it possible to specify id in nested attributes. It now
raises a raise_nested_attributes_record_not_found whenever the id
attribute is present. The intention of the patch was to deny updates
to other attributes when the id is specified; i.e. {:id => 1, :name =>
''pedo bear'' }. That was off course a needed security
improvement but
was the intention also not to use nested_attributes for existing
objects?
The API docs
http://api.rubyonrails.org/classes/ActiveRecord/NestedAttributes/ClassMethods.html#method-i-accepts_nested_attributes_for
"It also allows you to update the avatar through the member:
params = { :member => { :avatar_attributes => { :id =>
''2'', :icon =>
''sad'' } } }
member.update_attributes params[:member]
member.avatar.icon # => ''sad''"
And
"If the hash contains an id key that matches an already associated
record, the matching record will be modified:"
Seems like this was not just a security vulnerability but intended and
documented behavior.
What should be done here?
1. Existing objects must be saved with child_id = # not
child_attributes = { :id => 3}
2. allow id in nested attributes but do not accept other attributes.
Either way the docs should be updated. (And so must my API docs...)
Patch:
http://rubyonrails-security.googlegroups.com/attach/e307ee2102f2e4be/3-0-nested_attributes.patch?view=1&part=4
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
> Seems like this was not just a security vulnerability but intended and > documented behavior.It was poorly considered intended behaviour because of the problems with :allow_destroy. That''s not to say we can''t come up with something nicer, but the original patch isn''t it> What should be done here? > > 1. Existing objects must be saved with child_id = # not > child_attributes = { :id => 3} > 2. allow id in nested attributes but do not accept other attributes.The problem with allowing id in the associations is how can we, a framework, scope it sensibly? In some cases assigning any record is fine. for example picking a category for a bug report, triggering category.find is fine. The other side of the coin is something like picking a bank account to assign a payment to. Unscoped finders there would be a huge problem.> Either way the docs should be updated. (And so must my API docs...)For now the docs should probably just be updated, and if someone wants to figure out a way to re-enable a sub-set of this functionality for 3.1, we can experiment and analyse here before we push any releases.> Patch: http://rubyonrails-security.googlegroups.com/attach/e307ee2102f2e4be/3-0-nested_attributes.patch?view=1&part=4 > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- Cheers Koz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
@koz Could you possibly supply some test cases for the exploiting scenario? It''s seems wrong to raise record not found everytime an :id is supplied. Looking into it. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.