Rails - May 2007 - Protecting ActiveRecord Associations

I am working on a REST API and I''ve noticed mass assignment can really
be a huge security hole if you don''t take proactive measure.  For
example:

class User < ActiveRecord::Base
  has_many :categories
end
class Category < ActiveRecord::Base
  belongs_to :user
end

If you call @category.update_attributes in your controller, you leave
the door open for someone to pass in :user_id or :user parameters and
change the ownership of the category.

Of course Rails has the conventions to prevent this from happening with:

attr_protected :user_id, :user

But you don''t see much written about protecting attributes.  Some
models
will allow you to use validations to avoid security holes, but I''m
finding most of my belongs_to''s need to be protected.

In order to clean up my code and avoid stupid security holes, I''ve
thrown together a plugin to explore this problem.  You can check it out
at http://code.google.com/p/secure-associations/ So far I''ve only added
a belongs_to_protected method which will call the regular belongs_to and
protect the related attributes.

If there''s another way people are addressing this problem, let me know.
Otherwise if anyone else wants to use this plugin, I''ll add support for
the rest of the ActiveRecord associations.  I''m also thinking of making
an _immutable version which will allow you to only set an attribute
once.  Is there another convention in Rails for doing this?

Here''s my initial blog post on the topic:
http://tuples.us/2007/05/12/activerecord-associations-and-the-unfortunate-matter-of-security/

Jordan
http://jordan.mckible.com

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I saw your initial blog post on the subject and it got me wondering  
if it wouldn''t be better to make associations private by default.

-faisal


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi --

On Sun, 13 May 2007, Jordan McKible wrote:
> I am working on a REST API and I''ve noticed mass assignment can
really
> be a huge security hole if you don''t take proactive measure.  For
> example:
>
> class User < ActiveRecord::Base
>  has_many :categories
> end
> class Category < ActiveRecord::Base
>  belongs_to :user
> end
>
> If you call @category.update_attributes in your controller, you leave
> the door open for someone to pass in :user_id or :user parameters and
> change the ownership of the category.
>
> Of course Rails has the conventions to prevent this from happening with:
>
> attr_protected :user_id, :user
>
> But you don''t see much written about protecting attributes.  Some
models
> will allow you to use validations to avoid security holes, but I''m
> finding most of my belongs_to''s need to be protected.
Have you tried attr_accessible?  It''s sort of the mirror image of
attr_protected -- you provide a whitelist instead of a blacklist.


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

>> finding most of my belongs_to''s need to be protected.
> Have you tried attr_accessible?  It''s sort of the mirror image of
> attr_protected -- you provide a whitelist instead of a blacklist.
Good idea.  You''d just have to remember to maintain the whitelist if
the
model ever changed.  Probably not a big deal, but it would be one more 
thing to remember.  From an aesthetic prospective, I think I''d prefer 
the protection rolled up into the association.

Are you familiar with any pattern that only allows nil attributes to be 
updated? It seems like that''s a closer fit to what some association 
protection is trying to accomplish.

Jordan
http://jordan.mckible.com

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On May 14, 2007, at 12:28 AM, Jordan McKible wrote:
> Good idea.  You''d just have to remember to maintain the whitelist
> if the
> model ever changed.  Probably not a big deal, but it would be one more
> thing to remember.
One more thing for the automated tests to catch :)
> Are you familiar with any pattern that only allows nil attributes  
> to be
> updated? It seems like that''s a closer fit to what some
association
> protection is trying to accomplish.
You might be able to do something with faux accessors.

-faisal


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi --

On Mon, 14 May 2007, Jordan McKible wrote:
>
>>> finding most of my belongs_to''s need to be protected.
>> Have you tried attr_accessible?  It''s sort of the mirror image
of
>> attr_protected -- you provide a whitelist instead of a blacklist.
>
> Good idea.  You''d just have to remember to maintain the whitelist
if the
> model ever changed.  Probably not a big deal, but it would be one more
> thing to remember.  From an aesthetic prospective, I think I''d
prefer
> the protection rolled up into the association.
I agree about the remembering and aesthetics; it definitely means
you''re manually maintaining a kind of parallel configuration on top of
the basic business logic.  But keep in mind that it''s not just
associations that are vulnerable: someone could also maliciously
insert a change using, say, a class-variable accessor.  (Unless this
was tightened up in edge recently?  But I don''t think so.)
> Are you familiar with any pattern that only allows nil attributes to be
> updated? It seems like that''s a closer fit to what some
association
> protection is trying to accomplish.
I don''t think there''s any facility for that at the moment. 
Maybe one
could write an attr_gateway method, or something, with a block.


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 14/05/07, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
<dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> wrote:
> I agree about the remembering and aesthetics; it definitely means
> you''re manually maintaining a kind of parallel configuration on
top of
> the basic business logic.  But keep in mind that it''s not just
> associations that are vulnerable: someone could also maliciously
> insert a change using, say, a class-variable accessor.  (Unless this
> was tightened up in edge recently?  But I don''t think so.)
This was fixed with some release ago at least for class accessor
defined from within rails itself AFAIK

What I''ve done to make more strict the mass assignment methods is a
plugin (not published) that just compiles by default attr_accessible
with the actual db attributes of the object, stripping all the foreign
keys.
The plugin offers a facility to add/drop to/from attr_accessible
custom method that you want to make available in mass assignment.
This is quite easy to implement and gives a reasonably safe default to
start from.

Paolo
>
> > Are you familiar with any pattern that only allows nil attributes to
be
> > updated? It seems like that''s a closer fit to what some
association
> > protection is trying to accomplish.
>
> I don''t think there''s any facility for that at the
moment.  Maybe one
> could write an attr_gateway method, or something, with a block.
>
>
> David
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi --

On Mon, 14 May 2007, Paolo Negri wrote:
>
> On 14/05/07, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
<dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> wrote:
>
>> I agree about the remembering and aesthetics; it definitely means
>> you''re manually maintaining a kind of parallel configuration
on top of
>> the basic business logic.  But keep in mind that it''s not just
>> associations that are vulnerable: someone could also maliciously
>> insert a change using, say, a class-variable accessor.  (Unless this
>> was tightened up in edge recently?  But I don''t think so.)
>
> This was fixed with some release ago at least for class accessor
> defined from within rails itself AFAIK
Cool.
> What I''ve done to make more strict the mass assignment methods is
a
> plugin (not published) that just compiles by default attr_accessible
> with the actual db attributes of the object, stripping all the foreign
> keys.
> The plugin offers a facility to add/drop to/from attr_accessible
> custom method that you want to make available in mass assignment.
> This is quite easy to implement and gives a reasonably safe default to
> start from.
That sounds like a great solution.  Are you interested in publishing
the plugin?


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 14/05/07, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
<dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org>
wrote:
>
> Hi --
>
> On Mon, 14 May 2007, Paolo Negri wrote:
>
> >
> > On 14/05/07, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
<dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> wrote:
> >
> >> I agree about the remembering and aesthetics; it definitely means
> >> you''re manually maintaining a kind of parallel
configuration on top of
> >> the basic business logic.  But keep in mind that it''s not
just
> >> associations that are vulnerable: someone could also maliciously
> >> insert a change using, say, a class-variable accessor.  (Unless
this
> >> was tightened up in edge recently?  But I don''t think
so.)
> >
> > This was fixed with some release ago at least for class accessor
> > defined from within rails itself AFAIK
>
> Cool.
>
> > What I''ve done to make more strict the mass assignment
methods is a
> > plugin (not published) that just compiles by default attr_accessible
> > with the actual db attributes of the object, stripping all the foreign
> > keys.
> > The plugin offers a facility to add/drop to/from attr_accessible
> > custom method that you want to make available in mass assignment.
> > This is quite easy to implement and gives a reasonably safe default to
> > start from.
>
> That sounds like a great solution.  Are you interested in publishing
> the plugin?
If I can see there''s some interest around it, I might, if I have
permission from my employer and if I''ve time to arrange to actually
publish it on rubyforge.
But I have to warn it works well only if the app follows AR naming
convention of foreign keys.

Paolo
>
>
> David
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi --

On Mon, 14 May 2007, Paolo Negri wrote:
>
> On 14/05/07, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
<dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> wrote:
>>
>> Hi --
>>
>> On Mon, 14 May 2007, Paolo Negri wrote:
>>
>>>
>>> On 14/05/07, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
<dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> wrote:
>>>
>>>> I agree about the remembering and aesthetics; it definitely
means
>>>> you''re manually maintaining a kind of parallel
configuration on top of
>>>> the basic business logic.  But keep in mind that it''s
not just
>>>> associations that are vulnerable: someone could also
maliciously
>>>> insert a change using, say, a class-variable accessor.  (Unless
this
>>>> was tightened up in edge recently?  But I don''t think
so.)
>>>
>>> This was fixed with some release ago at least for class accessor
>>> defined from within rails itself AFAIK
>>
>> Cool.
>>
>>> What I''ve done to make more strict the mass assignment
methods is a
>>> plugin (not published) that just compiles by default
attr_accessible
>>> with the actual db attributes of the object, stripping all the
foreign
>>> keys.
>>> The plugin offers a facility to add/drop to/from attr_accessible
>>> custom method that you want to make available in mass assignment.
>>> This is quite easy to implement and gives a reasonably safe default
to
>>> start from.
>>
>> That sounds like a great solution.  Are you interested in publishing
>> the plugin?
>
> If I can see there''s some interest around it, I might, if I have
> permission from my employer and if I''ve time to arrange to
actually
> publish it on rubyforge.
> But I have to warn it works well only if the app follows AR naming
> convention of foreign keys.
You could grab the keys dynamically with reflections or
reflect_on_all_assocations.  That might even be easier than
calculating them yourself from table names (if that''s what
you''re
doing).


David

> Paolo
>
>>
>>
>> David
>
> >
-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

dear sender,
i´m out of the office until may 29th.
your email will not be forwarded.
for urgent stuff please contact joern-0M91wEDH++c@public.gmane.org
kind regards,
alexander





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Paolo Negri wrote:
> What I''ve done to make more strict the mass assignment methods is
a
> plugin (not published) that just compiles by default attr_accessible
> with the actual db attributes of the object, stripping all the foreign
> keys.
The converse would also be helpful: an update_attributes_unsafe method
that allowed unrestricted mass assignment for internal processing,
allowing several separate assignment lines to be compressed into one,
avoiding the puzzlement that can occur when use of update_attributes
for such a multiple assignment fails to work.

-- 
We develop, watch us RoR, in numbers too big to ignore.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Ok, next week I''ll be trying to publicly release another project of
mine, but after that I''ll seriously look into publishing the plugin so
we can look more in detail on how to improve it.

Paolo

On 16/05/07, Mark Reginald James
<mrj-bzGI/hKkdgQnC9Muvcwxkw@public.gmane.org>
wrote:
>
> Paolo Negri wrote:
>
> > What I''ve done to make more strict the mass assignment
methods is a
> > plugin (not published) that just compiles by default attr_accessible
> > with the actual db attributes of the object, stripping all the foreign
> > keys.
>
> The converse would also be helpful: an update_attributes_unsafe method
> that allowed unrestricted mass assignment for internal processing,
> allowing several separate assignment lines to be compressed into one,
> avoiding the puzzlement that can occur when use of update_attributes
> for such a multiple assignment fails to work.
>
> --
> We develop, watch us RoR, in numbers too big to ignore.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---