Mmm, yes & no. I have a standardized model editing layer that handles many
typical CRUD behaviors expressed in typical web UIs. That layer builds all its
own SQL or AR calls and handles a lot of common user interaction -- lind of
like an automated back end for most sites. So, the params filtering is buried
in that with a number of other integral features which in turn integrates into
AR.
Essentially, though it's just a simple comparison of the actual input
parameters and a list of allowed inputs.
Define allowed inputs as a simple array of params names, pass along the
controller params:
def distill_params(allowed_inputs, input_params)
return if input_params.nil?
input_params.delete_if do |input_name, input_value|
!(allowed_inputs.include?(input_name.to_sym))
end
end
I extend that with follow-up call to merge "implied" inputs (those which don't
appear in the form, but which are included in the final CRUD query).
So, I have 3 lists: params hash from the submtted form, array of allowed param
names, and a hash which defines additional n-v params to pass to AR which are
not in the form.
So, the technique itself is very simple, it's just that I do that with every
form -- not as an assumed universal set of rules at the model or even the
controller level. It's at the form level. That concept is more important than
the technique IMO.
The amount of coding is limited to defining the allowed and implicit lists.
Everything else is automated so I don't have to write the workflow and AR calls
for each form.
I've been doing this for over 10 years now across a couple of languages, and
implemented this in Rails a long time ago.
If MassAssignmentSecurity can be used to do that, then eventually I'll have a
look at that so my system morphs into a more idiomatic one for future apps, but
for now, existing projects may as well stay as they are.
-- gw
On Mar 6, 2012, at 8:56 AM, Ylan Segal wrote:
> GW,
>
> That sounds like the right way to go. Is your code something that you can
> share? I'd be interested in a solution like you describe.
>
> For my current app, I am using attr_protected, but as you mentioned, in the
> admin context and the public context, the list of attributes is different, so
> it would definitely be more appropriate to handle at the controller level.
>
> --
> Ylan
>
> On Mar 5, 2012, at 9:38 PM, GW wrote:
>
>> I've always thought Rails had poor tools for this. Even attr_protected etc
>> are poor solutions IMO (right idea, wrong place).
>>
>> Borrowing from a framework I developed 2001-2006, I've added a layer to my
>> controller-model conversation which requires an allowed_parameters for every
>> form. On the GET side, it prevents search forms from including fields not
>> intended for the context, and for POST it prevents any field from being
>> updated out of context.
>>
>> IMO, that's correct place to do it: each form, in context, at the
>> controller/model interface with the controller dictating what's allowed for
>> the specifoc context--a list of submitted params, and a list of allowed
>> params. The latter filters the former before the model does much else. Then
>> these kind of exploits simply aren't possible.
>>
>> -- gw
>>
>>
>>
>> On Mar 5, 2012, at 5:40 PM, Chris McCann wrote:
>>
>>> A developer used the Rails mass assignment vulnerability to basically
>>> give himself push access to any Github repo. He claims he made Github
>>> aware of the problem before taking action to highlight it.
>>>
>>> Here's an article about it:
>>>
>>> http://www.h-online.com/open/news/item/GitHub-security-incident-highlights-Ruby-on-Rails-problem-1463207.html
>>>
>>> The take-away: make sure you're not leaving your Rails apps open to
>>> exploit this way. Be sure to use attribute white-lists or black-lists
>>> to protect assignment that could give users elevated privileges or
>>> access to other users' stuff.
>>>
>>> See the Rails Security Guide
>>> http://guides.rubyonrails.org/security.html#mass-assignment.
>>
>> --
>> SD Ruby mailing list
>> [email protected]
>> http://groups.google.com/group/sdruby
>
> --
> SD Ruby mailing list
> [email protected]
> http://groups.google.com/group/sdruby
>
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
