I've always thought Rails had poor tools for this. Even attr_protected etc are poor solutions IMO (right idea, wrong place).
Borrowing from a framework I developed 2001-2006, I've added a layer to my controller-model conversation which requires an allowed_parameters for every form. On the GET side, it prevents search forms from including fields not intended for the context, and for POST it prevents any field from being updated out of context. IMO, that's correct place to do it: each form, in context, at the controller/model interface with the controller dictating what's allowed for the specifoc context--a list of submitted params, and a list of allowed params. The latter filters the former before the model does much else. Then these kind of exploits simply aren't possible. -- gw On Mar 5, 2012, at 5:40 PM, Chris McCann wrote: > A developer used the Rails mass assignment vulnerability to basically > give himself push access to any Github repo. He claims he made Github > aware of the problem before taking action to highlight it. > > Here's an article about it: > > http://www.h-online.com/open/news/item/GitHub-security-incident-highlights-Ruby-on-Rails-problem-1463207.html > > The take-away: make sure you're not leaving your Rails apps open to > exploit this way. Be sure to use attribute white-lists or black-lists > to protect assignment that could give users elevated privileges or > access to other users' stuff. > > See the Rails Security Guide > http://guides.rubyonrails.org/security.html#mass-assignment. -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
