#mass assignment

I found this article helpful when I was trying to better understand mass assignment, attr_accessible AKA whitelist, and attr_protected AKA blacklist. 

After studying a little further, I found that this security concept is called "Strong Parameters."

TX to @joegiralt, @hackerella & @maxjacobson (@flatironschool grads)!

Sup y'all! On the off chance that you follow my blog for coding tips (though that is a big part of my long-term goal for this collection of posts), listen up:

If you intend to push your Rails 4.0 app to Heroku, tread carefully if you plan to use the 'protected_attributes' gem. It appears that this gem prevents Heroku from precompiling your codebase... needless to say, this was a headache that took me quite a while to get to the bottom of.

Basically, this gem is designed to preserve the mass assignment feature that Rails 4 left in the dust in case some of your other gems had attr_accessor (Here's an awesome explanation of exactly what the heck mass assignment is, and why the Rails community decided to get rid of mass assignment: the infamous Homakov Incident - those damn Russian hackers!)

In my rails project, application.rb has the following line by default:

config.active_record.whitelist_attributes = true

This means that all attributes are protected from mass-assignment unless opened up in the model by doing something like:

attr_accessible :xyz, :abc

Now active admin does mass assgignments all over the place when updating stuff from its admin portal.

So i guess we can:

add all attributes to attr_accessible, which would be stupid or

we can update each model under the admin directory and list out the things its going to show, update etc.

The 2nd solution somewhat works but the whole point of using active admin is so i can open up the whole thing for my co-founder and he can go nuts, tweaking things. Writing every models accessible fields will drive me nuts which is not cool.

So this is what i ended up doing:

First, to each model under app/models I added the following line:

attr_accessible *column_names, :as => :admin

Then In the active admins initializer file active_admin.rb i added the following:

module ActiveAdmin class BaseController with_role :admin end end

Thats it! Now all columns are accessible as long as the role making the udpate is admin and I have instrcuted active admin's base controller to make all updates using role admin

Refernces:

http://apidock.com/rails/v3.1.0/ActiveRecord/Persistence/update_attributes

The following is a guest post by Jennifer Eisenberg and originally appeared on her blog. Jennifer is currently a student at The Flatiron School. You can follow her on Twitter here.

This past weekend I dove head first into Rails. I quite literally created over seven applications just to familiarize myself with the commands and the generated file system with a clear goal of debunking some of the magic of Rails.I frequently came across the same error regarding “mass assignment.” The simple hassle-free fix was to add the attribute to attr_accessible and poof no more error. Although that temporarily fixed my error, this mass assignment concept was still fuzzy. Even the ruby guides surprisingly appeared to be unhelpful to a mere beginner — as most of the issues surrounding mass assignment have to do with security breaches, a topic I will go into at a later date.

The definition Mass Assignment is the convention Rails assigns the act of constructing your object with a parameters hash while you are assigning many values to attributes with one single assignment operator. Lacking mass assignment would mean a lot of manual labor drawing assignment statements for each and every attribute.

Attr_accessible The keyword attr_accessible allows developers to assign specific attributes open to mass assignment.

Under the hood of the attr_accessible we have a method that looks like

This code takes in an arbitrary amount of key value pairs. Mass assignment permits us to set a bunch of attributes at once. For each k/v pair sent in above, the name of the key becomes the name of an attribute setter method and the value associated with the key is the name of the value you want to pass to that method. The ruby send method then permits you to call the method name that is the key’s name as well as call the associated value as a param in the key’s method. This is a solid underlying method because we can easily alter the number of attributes in the class and need not worry about editing the initialize method.

Thus without attr_accessible, all attribute fields would be open to mass assignment leading to a potentially perilous situation.

Security Issue Not going to go super indepth here yet, but essentially because rails conventions are so, well – conventional – it’s not too tough to merely guess attribute names like :user or worse, :admin. Funny story, actually in order for a developer named Egor Homakov to prove his point that mass assignment is insecure and dangerous, he actually gave himself access to commit to the rails repo on github. (read more about his awesome hack or lapse in judgement or what he calls “The commit that changed my life” here. Anyway there are two main ways to get around this.

Whitelisting This is what’s safe and we assume everything else is dangerous. Thus we can assume this is super secure because we are being explicit in what we give access. You tell your application what is allowed. Similarly, attr_accessible makes the attributes accessible while the others are protected aka we are being explicit in what we give global access.

These attributes are unprotected and can be mass assigned and if we add more we need to add them to this list assuming we want them to be accessible.

Blacklisting Just the opposite. Consider all attributes “good” unless they come from explicit source x. Similarly, the attr_protected method says that the written attributes are protected while everything else IS accessible.

Above we are protecting the is_admin attribute and all other attributes added at a later time will not be automatically protected like :is_admin.

The following is a guest post by Jennifer Eisenberg and originally appeared on her blog. Jennifer is currently a student at The Flatiron School. You can follow her on Twitter here.

  This past weekend I dove head first into Rails. I quite literally created over seven applications just to familiarize myself with the commands and the generated file system with a clear goal of debunking some of the magic of Rails.I frequently came across the same error regarding “mass assignment.” The simple hassle-free fix was to add the attribute to attr_accessible and poof no more error. Although that temporarily fixed my error, this mass assignment concept was still fuzzy. Even the ruby guides surprisingly appeared to be unhelpful to a mere beginner — as most of the issues surrounding mass assignment have to do with security breaches, a topic I will go into at a later date.

The definition Mass Assignment is the convention Rails assigns the act of constructing your object with a parameters hash while you are assigning many values to attributes with one single assignment operator. Lacking mass assignment would mean a lot of manual labor drawing assignment statements for each and every attribute.

Attr_accessible The keyword attr_accessible allows developers to assign specific attributes open to mass assignment.

Under the hood of the attr_accessible we have a method that looks like

This code takes in an arbitrary amount of key value pairs. Mass assignment permits us to set a bunch of attributes at once. For each k/v pair sent in above, the name of the key becomes the name of an attribute setter method and the value associated with the key is the name of the value you want to pass to that method. The ruby send method then permits you to call the method name that is the key’s name as well as call the associated value as a param in the key’s method. This is a solid underlying method because we can easily alter the number of attributes in the class and need not worry about editing the initialize method.

Thus without attr_accessible, all attribute fields would be open to mass assignment leading to a potentially perilous situation.

Security Issue Not going to go super indepth here yet, but essentially because rails conventions are so, well – conventional – it’s not too tough to merely guess attribute names like :user or worse, :admin. Funny story, actually in order for a developer named Egor Homakov to prove his point that mass assignment is insecure and dangerous, he actually gave himself access to commmit to the rails repo on github. (read more about his awesome hack or lapse in judgement or what he calls “The commit that changed my life” here. Anyway there are two main ways to get around this.

Whitelisting This is what’s safe and we assume everything else is dangerous. Thus we can assume this is super secure because we are being explicit in what we give access. You tell your application what is allowed. Similarly, attr_accessible makes the attributes accessible while the others are protected aka we are being explicit in what we give global access.

These attributes are unprotected and can be mass assigned and if we add more we need to add them to this list assuming we want them to be accessible.

Blacklisting Just the opposite. Consider all attributes “good” unless they come from explicit source x. Similarly, the attr_protected method says that the written attributes are protected while everything else IS accessible.

Above we are protecting the is_admin attribute and all other attributes added at a later time will not be automatically protected like :is_admin.

A slew of github gists. I don't understand why people don't make these blog posts, I can only imagine the traffic they're getting. Embedding gists is easy.

Homakov shows us how he was able to compromise Github.com

Jbarnette shows us how to make your Rails app warn on ActiveRecord::Base#update_attributes

Wycats creates a Proposal for Improving Mass Assignment

 안녕하세요. 반갑습니다! 

 오늘부터 루비 온 레일즈에 관한 팁과 테크닉을 다루는 블로그 레일즈 매니악을 운영하게 된 강성희(paranoiase)입니다.

 잘 부탁드립니다. _(__)_

def signup @user = User.new(params[:user]) end

 위의 코드는 대량 할당(Mass Assignment)의 간단한 예입니다. 이렇게 하면 params[:user]에 들어가 있는 값을 사용자 레코드에 한 번에 대입할 수 있죠.

 이는 폼 처리 등을 간편하게 해결할 수 있어 매우 편리합니다만, 과도하게 사용할 경우 해킹의 소지가 될 수 있습니다.

# POST: "http://www.example.com/user/signup?user[name]=ow3ned&user[admin]=1" def signup params[:user] # name: "ow3ned", admin: true # 이제 이 사용자는 관리자 권한을 갖게 됩니다. @user = User.new(params[:user]) end

 위와 같은 방법을 대량 할당 해킹이라고 합니다.

 대량 할당 해킹을 막는 가장 좋은 방법은 속성에 접근할 수 있는 권한을 지정해 주는 것입니다.

class User < ActiveRecord::Base # 이제 admin은 대량 할당으로 값을 넣을 수 없습니다. attr_protected :admin end

 또는 attr_protected의 정 반대의 역할을 하는 attr_accessible을 추천합니다.

class User < ActiveRecord::Base # 이제 email, password만 대량 할당으로 값을 넣을 수 있습니다. attr_accessible :email, :password end

 attr_accessible을 이용하면 지정한 속성을 제외한 모든 속성은 대량 할당을 할 수 없게 됩니다. 좀 더 방어적이지만, 그만큼 안전하죠.

 이제 다음 달에 추가한 새로운 레코드가 대량 할당 해킹의 소지가 될 경우는 없을 겁니다.

# POST: "http://www.example.com/user/signup?user[name]=ow3ned&user[admin]=1" def signup params[:user] # name: "ow3ned", admin: true @user = User.new(params[:user]) @user.admin # => false # not mass-assigned @user.admin = true @user.admin # => true end

좀 더 완벽한 방법을 원하는 사람들은 다음과 같은 코드를 이용합니다.

# 이제 속성을 명시적으로 지정하지 않으면 대량 할당을 할 수 없습니다. ActiveRecord::Base.send(:attr_accessible, nil)