Beefed up mass assignment coverage (section 6) in the security guide. Now includes nested mass assignment (and nested object forms) and adds another (paranoid) countermeasure.

1 files changed, 26 insertions, 2 deletions

diff --git a/railties/guides/source/security.textile b/railties/guides/source/security.textile
index 5797eb888b..98a42f1223 100644
--- a/railties/guides/source/security.textile
+++ b/railties/guides/source/security.textile
@@ -392,15 +392,31 @@ params[:user] #=> {:name => “ow3ned”, :admin => true}
 
 So if you create a new user using mass-assignment, it may be too easy to become an administrator.
 
+Note that this vulnerability is not restricted to database columns.  Any setter method, unless explicitly protected, is accessible via the <tt>attributes=</tt> method.  In fact, this vulnerability is extended even further with the introduction of nested mass assignment (and nested object forms) in rails 2.3.  The +accepts_nested_attributes_for+ declaration provides us the ability to extend mass assignment to model associations (+has_many+, +has_one+, +has_and_belongs_to_many+).  For example:
+
+<ruby>
+  class Person < ActiveRecord::Base
+    has_many :credits
+
+    accepts_nested_attributes_for :children
+  end
+
+  class Child < ActiveRecord::Base
+    belongs_to :person
+  end  
+</ruby>
+
+As a result, the vulnerability is extended beyond simply exposing column assignment, allowing attackers the ability to create entirely new records in referenced tables (children in this case).
+
 h4. Countermeasures
 
-To avoid this, Rails provides two class methods in your ActiveRecord class to control access to your attributes. The attr_protected method takes a list of attributes that will not be accessible for mass-assignment. For example:
+To avoid this, Rails provides two class methods in your Active Record class to control access to your attributes. The +attr_protected+ method takes a list of attributes that will not be accessible for mass-assignment. For example:
 
 <ruby>
 attr_protected :admin
 </ruby>
 
-A much better way, because it follows the whitelist-principle, is the +attr_accessible+ method. It is the exact opposite of attr_protected, because _(highlight)it takes a list of attributes that will be accessible_. All other attributes will be protected. This way you won't forget to protect attributes when adding new ones in the course of development. Here is an example:
+A much better way, because it follows the whitelist-principle, is the +attr_accessible+ method. It is the exact opposite of +attr_protected+, because _(highlight)it takes a list of attributes that will be accessible_. All other attributes will be protected. This way you won't forget to protect attributes when adding new ones in the course of development. Here is an example:
 
 <ruby>
 attr_accessible :name
@@ -416,6 +432,14 @@ params[:user] #=> {:name => "ow3ned", :admin => true}
 @user.admin #=> true
 </ruby>
 
+A more paranoid technique to protect your whole project would be to enforce that all models whitelist their accessible attributes.  This can be easily achieved with a very simple initializer:
+
+<ruby>
+ActiveRecord::Base.send(:attr_accessible, nil)
+</ruby>
+
+This will create an empty whitelist of attributes available for mass assignment for all models in your app.  As such, your models will need to explicitly whitelist accessible parameters by using an +attr_accessible+ declaration.  This technique is best applied at the start of a new project.  However, for an existing project with a thorough set of functional tests, it should be straightforward and relatively quick to insert this initializer, run your tests, and expose each attribute (via +attr_accessible+) as dictated by your failing tests.
+
 h3. User management
 
 -- _Almost every web application has to deal with authorization and authentication. Instead of rolling your own, it is advisable to use common plug-ins. But keep them up-to-date, too. A few additional precautions can make your application even more secure._