

IOS 6 injecting should_group_accessibility_children to POST requests - philnash
http://logicalfriday.com/2012/10/03/ios-6-injecting-should_group_accessibility_children-to-post-requests/

======
ubernostrum
So... the story here is

1\. They were blindly throwing the entire set of POST data into a Rails model.

2\. This started throwing errors when they got an unexpected key in POST.

3\. They "solved" the problem by writing a middleware to filter out that
specific key from POST.

I don't even know where to begin.

~~~
tomjen3
Begin by reading up on Rails.

Mass assignment is a fairly normal thing to do, any parameters you want the
model to ignore can be marked as so in the model and then mass assignment will
work anywhere. Rails loves DRY.

Since the only way in which one can get wrong arguments is if somebody is
hacking you (or attempting to do so) in which case just throwing an error at
them is a fair thing to do.

~~~
untog
I'm not a Rails guy, so you'll have to forgive ignorance here. Are you telling
me that Rails only lets you blacklist parameters, not whitelist?

Because that seems entirely the wrong way around.

EDIT: looked at the link posted elsewhere here[1] and ound that it is possible
to whitelist using "attr_accessible". Please tell me people know about and use
this.

[1] <http://guides.rubyonrails.org/security.html#mass-assignment>

~~~
bryanlarsen
You can do either. The default used to be blacklist, but that was changed to
whitelist recently.

------
mobwill
Most likely, their native client is blindly adding the objective c properties
to the POST request, by using introspection. Apple is not adding anything to
the POST request. This is similar to the problems people used to run into when
the javascript object prototype was overridden and everyone's code would break
because they were just doing

for (var prop in object)

~~~
jcromartie
Indeed. Why in the world would Apple inject this into POST requests?

[http://developer.apple.com/library/ios/documentation/uikit/r...](http://developer.apple.com/library/ios/documentation/uikit/reference/UIAccessibility_Protocol/Introduction/Introduction.html#//apple_ref/occ/instp/NSObject/shouldGroupAccessibilityChildren)

~~~
coob
Willing to bet it's a bug.

------
ejs
This should not be an issue if you avoid mass-assignment with dumping all
params, which is a security vulnerability anyway.

If you do something like:

@user = User.new(params[:user].slice(:name))

It will be safer, and avoid the problem.

------
eli
Does this parameter serve a documented purpose?

It's weird that iOS is doing that... but (at the risk of piling on) browsers
do all sorts of weird stuff. Your app needs to deal with it.

~~~
brown9-2
Yeah, the discussion here seems to be missing the forest for the trees.

For non-Rails programmers an idea such as mass assignment sounds very strange,
but if you ignore that, it still sounds odd at first request than an OS would
inject parameters into a HTTP post request.

------
jcromartie
These folks are claiming that this is an issue without creating a minimal
program that reproduces the issue. If it were a real issue it would be trivial
to make an app that POSTs to an API and inspect the traffic.

I have inspected several POST requests from iOS 6 apps and have not seen
anything like this yet.

------
tilsammans
This has been solved already and will be part of Rails 4. Use strong
parameters: <https://github.com/rails/strong_parameters>

~~~
jcromartie
Will this be a default in Rails 4? I feel like people should need to go
through a lot of work to do something as dangerous as Rails/AR mass
assignment...

~~~
Legion
> Will this be a default in Rails 4?

Yes.

------
asg
I'm amazed at how the discussion here has devolved into the merits of mass
assignment. While that is a worthwhile topic in itself, specially given the
recent github issues, any suggestion that the this issue would have been
mitigated by the OP not using mass assignment is flawed.

Any webapp that I would consider secure MUST validate all input from clients.
This includes white listing any and all parameters names, preferably in
middleware, but at least in the controller. Allowing random keys in your input
seems recipe for disaster, when you consider a multi layer app security
policy. While this may seem like an overkill to some, this is best practice
I've seen implemented in any project that deals with real money.

Hence, such a change in iOS WILL break any such application. Irrespective of
your views on the sanity of mass assignment.

I would like to see a discussion on why apple thought it would be a good idea
to introduce a new parameter to every request. Any ideas?

~~~
masklinn
"Validating input" can yield a number of results, and ignoring incorrect data
(keys) altogether is not only a valid reaction, it's a perfectly safe one and
it's how the vast majority of systems work. Indeed, a number of usual patterns
would break if that didn't work.

Mass-assignment and similar patterns (of shoving all request parameters into
your trusted content, see also `extract` and `register_globals`) "allow random
keys into your input", ignoring said keys doesn't.

