GW, That sounds like the right way to go. Is your code something that you can share? I'd be interested in a solution like you describe.
For my current app, I am using attr_protected, but as you mentioned, in the admin context and the public context, the list of attributes is different, so it would definitely be more appropriate to handle at the controller level. -- Ylan On Mar 5, 2012, at 9:38 PM, GW wrote: > 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 -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
