Re:IOS 6 injecting should_group_accessibility_children to PO...
by ef4 on Wednesday October 03, 2012 @11:06AM
(#4607750)
But even if they're using attr_accessible to whitelist parameters, the failure mode here would have been exactly the same.
The real culprit is Apple. It's just not ok to add unexpected parameters to people's POSTs. If anything, they should have put it in an HTTP header instead.
Re:IOS 6 injecting should_group_accessibility_children to PO...
by Pewpewarrows on Wednesday October 03, 2012 @11:27AM
(#4607878)
I'm a Python/Django guy so I'm not intimately familiar, but is that really the case? I was under the assumption that the handler wouldn't pass any POST vars not in attr_accessible to the model. In which case additional, unexpected ones would become silently dropped.
Re:IOS 6 injecting should_group_accessibility_children to PO...
by masklinn on Wednesday October 03, 2012 @01:34PM
(#4608591)
According to http://guides.rubyonrails.org/security.html#countermeasures you're entirely correct that it won't raise any error, although the keys won't be dropped: attr_accessible drops the attributes when mass-assigned to a model, they're still available in the params hash.
Rails gives you attr_accessible and attr_protected to alleviate this problem. Protip: the one from those two that you suggested to use is just as terrible an idea as allowing blind POST into your database. Blacklisting is always the wrong approach to security. I don't care if you have to repeat yourself and type more characters: use the whitelisting of attr_accessible.