开发者

Is this vulnerable to mass assignment?

开发者 https://www.devze.com 2023-02-07 16:07 出处:网络
I use this to allow users to vote on an Entry: <% form_tag url_for(entry_votes_path(@entry)), :id => \'voting_form\', :remote => true do %>

I use this to allow users to vote on an Entry:

 <% form_tag url_for(entry_votes_path(@entry)), :id => 'voting_form', :remote => true do %>
      <%= hidden_field_tag 'vote[user_id]', current_user.id  %>
      <%= submit_tag 'Vote for this entry', :id => 'voting_button' %>
 <% end %>

This is my controller code:

def create
    @entry = Entry.find(params[:entry_id])
    @vote = @entry.votes.build(params[:vote])

    respond_to do |format|
    if @vote.save
        format.html { redirect_to @entry }
        format.js
      end
 开发者_如何学运维   end
  end

I have two questions

  1. How can I assign current_user.id without using a hidden field?

  2. Also, I'm not using attr_accessible or attr_protected on the Vote model right now. How should I secure the model to make sure someone can't create a lot of votes? Right now, all the fields in the Vote model are set by the params hash -- should I use attr_protected on say, the entry_id foreign key and then set it separately in the controller?


I'm not using attr_accessible or attr_protected on the Vote model right now...

Then, by definition, mass assignment is possible from the query string.

Should I use attr_protected on say, the entry_id foreign key and then set it separately in the controller?

In general, it's better to use attr_accessible than attr_protected. This is because attr_accessible establishes a default of deny-all to mass assignment and lets you define whitelisted exceptions. On the other hand, attr_protected forces you to blacklist specific attributes. When you modify the program and add a new attribute with attr_accessible set, the program will fail if you need to whitelist the attribute and forget. In other words, it fails safely. Alternatively, if you add a new attribute with attr_protected set, the program will work even if the new attribute should have been included in the blacklist. On other words, it fails insecurely.

The rule here is to protect any attribute which it would be dangerous to allow to be set from the query string. Protecting the key helps prevent injection of new rows but it may be necessary to protect other fields if you want to prevent the ability to change the contents of existing rows.

A good reference on this may be found at guides.rubyonrails.org.

0

精彩评论

暂无评论...
验证码 换一张
取 消