Re: Mass Assignment Vulnerability -- Another Suggestion

Gaspard Bucher
2009-03-02T08:21:41Z

I think we are touching a deeper problem here apart from the
accessible/protected issue. From the start we realized that we need to
store valid models in the database so we wrote validations. Strangely,
it did not occur to us that security issues are part of the validation
process. They are not some extra special thing that can happen in some
super firewall (controller). Now that AR gets more power, this thing
is creeping out.

What John is raising here is that our security layer is brittle
because it''s not DRY. We need to write code to remove disallowed
attributes in every controller that could potentially send offending
data to some model. And now that we have nested attributes, forgetting
a controller just became easier.

Authentication belongs to the controller. Securing models should
belong in the validation cycle, ensuring that *all* code hitting the
models goes through the same security validation process.

Gaspard


On Mon, Mar 2, 2009 at 6:55 AM, Michael Koziarski <michael@koziarski.com>
wrote:
>
>> With 2.3 being so close, I''d think we''d want to
consider a change like
>> this for 3.0.  What do you guys think?
>
> Definitely not keen on this for 2.3, but for 3.0 it''s definitely
an
> option.  My main concern with adding attr_accessible to every model is
> that it''ll just be seen as noise by most developers,
who''ll simply
> either remove the line, or not bother understanding why it''s
there.
> Defaulting to ''everything inaccessible'' would be far too
strong and
> would just lead users to paste in some ''enable
everything'' snippet
> they found on the internet.
>
> My gut feeling on this is that education is really the only option,
> and perhaps we need to emphasise these settings in an introductory
> tutorial, but I''m open to other ideas.
>
>
>
> --
> Cheers
>
> Koz
>
> >