>From my Android phone on T-Mobile. The first nationwide 4G network.
-------- Original message --------
From: Prem Sichanugrist <[email protected]>
Date: 20/10/2014 18:07 (GMT-08:00)
To: [email protected]
Cc: [email protected]
Subject: Re: [Rails-core] strong parameters safety issue enables accidental
mass assignment
We already have plans to make Parameters not inherited from Hash before Rails
4.2, but we couldn't do it because it breaks backward compatibility. What we
did, instead, was to make sure we have test to cover those cases, and
reimplement those methods that leaked Hash object.
https://github.com/rails/rails/blob/v4.2.0.beta2/actionpack/test/controller/parameters/accessors_test.rb
https://github.com/rails/rails/blob/v4.2.0.beta2/actionpack/test/controller/parameters/mutators_test.rb
If we missed something, please let us know.
After 4-2-stable has been cut out, and master becomes 5.0, then we'll make
Parameters not inherited from Hash.
Thanks,
Prem
On Thu, Aug 7, 2014 at 3:19 AM, Matt Jones <[email protected]> wrote:
On Aug 6, 2014, at 12:51 PM, [email protected] wrote:
[snip]
Why does that matter?
It matters because it is possible for a developer to accidentally lose that
capability accidentally very easily on the way from the controller (where
permit happened and the capability gets created) to the model (where the
capability gets used). This loss does happen silently and effectively disables
mass assignment protection.
How does that happen?
The only class aware of the 'permitted?' capability is
ActiveController::Parameters, if we call a method that is not aware of the
capability it can get lost as a side effect:
class SomeModel < ActiveRecord::Base
#fields :name, :protected_secret_field
include ActiveModel::ForbiddenAttributesProtection
end
#imagine a request w/ params = {'name' => 1, 'protected_secret_field' => 2}:
params.reject!{|k,_|['controller', 'action'].include? k}
params.permit(:name)
SomeModel.new(params) #Exception, world is OK
SomeModel.new(params.symbolize_keys) #No Exception, secret overwritten
This is a bug in `symbolize_keys`. It appears to have been fixed (accidentally?
on purpose?) on master:
https://github.com/rails/rails/commit/f1bad130d0c9bd77c94e43b696adca56c46a66aa
by starting the loop with `self.class.new` instead of `{}`.
There’s some additional future changes coming up in Ruby 2.2.0 with methods
like `reject`:
https://www.ruby-lang.org/en/news/2014/03/10/regression-of-hash-reject-in-ruby-2-1-1/
that seem likely to further complicate the situation.
—Matt Jones
<signature.asc>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
