Hash operations not sufficient to protect data assignment in Active Record

199 views
Skip to first unread message

Michael Koziarski

unread,
Nov 26, 2009, 8:19:07 PM11/26/09
to rubyonrail...@googlegroups.com
Summary:

*This is not a code vulnerability but a documentation & best practice
advisory*

Rails' documentation and others have recommended hash operations to
interact with data. This is not sufficiently secure. Developers should
use the whitelist method of attr_accessible or at least the blacklist
based attr_protected.

Detail:

This is an advisory concerning risky practices common for some rails
applications, it does not concern a vulnerability in rails, there is
no patch or updated version to install.

Active Record's mass attribute assignment functionality gives
developers a simple method to update a number of model attributes in
a single call:

@user.attributes = incoming_changes # hash of new values

The typical use-case for this is to take all the parameters from a
form and update a model object. Alongside this functionality Active
Record provides a mechanism for programmers to specify which attributes
are permitted to be assigned in this manner.

attr_accessible lets you specify a whitelist of attributes which can
be assigned, and attr_protected lets you specify a blacklist of
forbidden attributes. For more information see the Mass Assignment
section of the Securing Rails Applications guide[1].

Some sources, including beta versions of Rails' own documentation,
have advised users to use some hash operations to remove
dangerous attributes. For example:

@user.attributes = params[:user].except(:admin)

These hash operations do not support all cases, and won't provide
sufficient protection. One area particularly difficult to secure in
this way is nested attributes[2].

Almost all models in almost all applications should be using
attr_accessible[3] to protect against this problem. Using
attr_protected provides some protection, however the whitelist-based
approach of attr_accessible is much less likely to introduce security
vulnerabilities as the codebase changes.

Thanks to Eric Chapweske for indicating the documentation problem to us,
and working with us on this advisory.

[1] http://guides.rubyonrails.org/security.html#mass-assignment
[2] http://guides.rubyonrails.org/2_3_release_notes.html#nested-attributes
[3] http://rails.rubyonrails.org/classes/ActiveRecord/Base.html#M002281
Reply all
Reply to author
Forward
0 new messages