Mass assignment vulnerability - how to force dev. define attr_accesible?

[homakov]

Those who don't know methods attr_accesible / protected - check that article out http://enlightsolutions.com/articles/whats-new-in-edge-scoped-mass-assignment-in-rails-3-1

Let's view at typical situation - middle level rails developer builds website for customer, w/o any special protections in model(Yeah! they don't write it! I have asked few my friends - they dont!)
Next, people use this website but if any of them has an idea that developer didnt specify "attr_accesible" - hacker can just add an http field in params, e.g. we have pursue's name edition. POST request at pursues#update

id = 333 (target's pursues id)
pursue['name'] = 'my purses name'
pursue['user_id'] = 412(hacker id)

if code is scaffolded than likely we got Pursue.find(params[:id]).update_attributes(params[:pursue]) in the controller. And that is what I worry about.

After execution that POST we got hacker owning target's pursue!

I don't mean that it is Rails problem, of course not. But let's get it real(Getting Real ok) - most of developers are middle/junior level and most of them don't write important but not very neccessary things: tests, role checks etc including topic - attr_accesible

how to avoid injections ? What should Rails framework do to force people to keep their rails websites safe? Making attr_accesible necessary field in model? What do you think guys.

[drogus]

I was thinking about generating something like this, unless you pass some kind of option to generator (sometimes you just want to skip attr_accessible if you know what you're doing):

# You should always whitelist your accessible attributes for security
attr_accessible nil

[drogus]

@lest pointed me to #4062, there is a config setting that can do something like that config.active_record.whitelist_attributes. Although, based on that discussion I think that the consensus is that it should not be the default.

[homakov]

so, here is what i came up to.
My main concern - is relations.
I hate the idea that some people could rewrite object references by themselves. Nobody should be able to set task[user_id]=hacker_id or sort of
Vulnerable references are the main evil because

1. it totally ruins database and leaves no way to fix it back but backups
2. it works clearly. Hacked user won't be able to figure out "Where is my blog post" or "How come this spam post is in my timeline written by me" (if newpost[user_id]=target_user_to_hack)

I suggest to have foreign keys and primary keys protected by default(what are keys can be recognized by ActiveRecord easily).

IMO Rails should teach developers to set up so important and vulnerable keys by hands. It is not a handicap for prototyping, just +a few lines of code. But it is all about sane and safe rails apps.

@task = Task.new
@task.user = current_user
@task.update_attributes(params[:task]) #having params[:task][:user_id] should raise error

#or projects-tasks relations
@project = Project.find(params.delete(:project_id)) #we have project_id but it is protected. lets delete to avoid exception
if @project.user == current_user
  @task.project = @project
else
  #alarm!
end
@task.attributes = params[:task]

I've got a big picture in my head but the backbone is described above. I strongly believe that having keys(references, relations) will make ruby on rails a 20% more awesome. I mean robust

[homakov]

Oh, didn't mention. On my part - I wouldn't support setting all attrs protected. It will cause such big mess! You cannot force every body to read release notes. Stackoverflow will be down. :] + it is dirty solution.
What also we have in model but keys? E.g.
title: string - not vulnerable at all, user is able to edit his comment
rating: integer - pretty vulnerable but not dangerous
account: integer - developer who left user[account] open for mass assignment should suffer. Nevermind about him.
what else? Do we really need protected fields by default? No.

[homakov]

@dhh you dont like 'whitelist' idea - i dont too. But what is your opinion regards relation keys? They are obviously should be defined manually - in most cases. That is why having them protected by default is not a big deal.
And, surely, it should be opt-out-able, e.g.
config.active_record.protect_keys = true

[homakov]

Just imagine which power this vulnerability gives in my.. and now in your hands if you get what has happened.
@dhh @josevalim Y you no care

[sikachu]

There're too much trolling going on in this ticket and I'm not sure anymore if you mean anything serious. If you're going to do a bug report or feature request, just stop trolling and try not to be annoying, then the core team will come and check out by themselves.

Name calling while trolling doesn't help, trust me.

[homakov]

@sikachu bugs are serious.

This is not only bug report, because this problem is so wide spreaded. postereous, speakerdeck, scribd, github - and I only have started testing.

We need to introduce blacklist attributes. MOst of rails apps(from small to github) likely got mass-assignment bugs if they don't user attr_accessible.

I just want to attract more attention to reviewing this problem from scratch and calmly decide - what should we do with M As-ment problem.

And, if some of you support my idea I could provide fixing pull request. But you ignore this bug, like nothing has happened for a long time. SOrry for not called for trolling, I overplayed :) Everyone, again, express your point please, you are welcome.

[fxn]

There was a proposal about changing that flag in #4062 and the consensus is the pros of the default configuration outweigh the pros of the alternative.

Thanks!

[homakov]

@fxn have you read my post? Did you see vulnerabilities i pointed out in e.g. github?
It is not about the flag in configuration, I'm pretty certain. We need to have :created_at, :updated_at, and references to be protected by default. Whitelist issue has nothing to do with my point
Please read issues carefully, because I clearly emphysized that flag is not a panacea