Why Slicing The Params Hash Poses a Security Issue on Mass-Assignment

Why slicing the params hash poses a security issue on mass-assignment?

The problem with slice and except in controller might occur in combination with accept_nested_attributes_for in your model. If you use nested attributes, you would need to slice parameters on all places, where you update them in controller, which isn't always the easiest task, especially with deeply nested scenarios. With using attr_accesible you don't have this problem.

Mass Assignment Vulnerability

First and foremost, this line num_users = A.where(:name => "NEW").count works fine with or without using mass-assignment. This is because where method do not assign data to a model record.

On the other hand, it is rare to see a question with ruby-on-rails-4 and mass-assignment tags (there are only 7 with both).

This is because Rails 4 remove mass_assignment and replace it with strong_parameters, you can find it at rails guides upgrade to 4.0.

If the line attr_accessible :name is working fine on your rails 4 app. Then you must have the protected_attributes gem at your Gemfile.

There must be a good reason for add the protected_attributes gem to a Rails 4 app. If not, you can remove from the Gemfile do bundle install and remove all the attr_accessible ... lines from your model. And also remove the :without_protection => true parameter from the model's actions (new, create, create!, update_attributes and update_attributes!, assign_attributes).

If you keep the gem protected_attributes at the Gemfile. Then when you need to update some field which is not attr_accessible you must add a parameter without_protection: true to the action. This way:

A.create({name: 'NEW'}, without_protection: true)

And the record will be stored at the db. Otherwise it will not work.

Does the Rails Console Bypass Mass-Assignment Protection?

user.update_attribute("role", "admin")

it has got nothing to do with strong parameters..
That just generates an sql query as you see in the console which updates the record.

strong parameters are used to restrict unpermitted params coming from the view/client and modify your record.

As in your case,

your user_params does not include role because you are assigning it yourself. in case you had not done that and in the request body I had sent role: 'admin',

User.new(params)

would make the user admin, if verify_recaptcha(model: @user) condition fails..

False Warning for mass assignment is thrown by Brakeman Gem in model.new and model.update_attibutes and model.create

It is possible to have mass assignment issues with values due to accepts_nested_attributes_for. However, if you are not using accepts_nested_attributes_for then this is probably a false positive.

Notice Brakeman returns a "weak" confidence warning for this code. Like most of Brakeman's "weak" confidence warnings, it is code you should take a look at but probably isn't an issue.

You can use Brakeman's ignore configuration to ignore false positives. You can also ignore weak confidence warnings by running Brakeman with -w 2. It's also possible to turn off mass assignment warnings with -x MassAssignment but I would not recommend that since you are running an ancient (and probably very vulnerable) version of Rails.

Changing Stripe param keys for mass assignment in Rails

There are multiple ways you can do this, but I like to do the mapping like so:

def order_params
  {
    shipping_zip: params[:stripeShippingAddressZip],
    # more here
  }
end

After this you can just do:

Orders.create(order_params)

I hope this helps!

Risks of Mass Assignment in Laravel

The "risk" is that developers often pass Input::all() into the model. Without the protection that the new system with $fillable and $guarded provides, unexpected user input can produce an error (to be exact an SQL error like: column foo not in field list) and it possibly allows the user to insert attributes you didn't want him to set by manipulating the request.

How can I suppress the assignment of one or more fields in a Ruby-On-Rails mass-assignment?

Watch this railscasts http://railscasts.com/episodes/26-hackers-love-mass-assignment/

You are thinking about mass assignment security the wrong way. attr_accessbile does not make the password value open to the public (you will use filter_parameter to hide that value).

Think of it this way, you have a user form. You want the user to be able to create an account with a password but you do not want them to be able to add themselves as an admin (they could do this through sql injection or manipulating the POST parameters). To protect against this, you would add :name, :password, :email to attr_accessible and leave out the admin field.

---

Related Topics