[lstamour]

Bit confused as to how this can't happen on iOS "just because," as iOS apps could be targeted in a similar way. Really the message here should be that SSL with certificate-pinning is a must for apps that inherently run in untrusted environments with an inability to easily inspect the security of the network traffic without MITMing it yourself. Wish this was a security feature on the app store -- if, in automated testing or in device logs, an app was entirely secure or insecure with its communication, just as we've padlock icons in browsers today.

[gress]

iOS apps cannot be targeted in this way because they don't have the JavaScript bridge.

[void-star]

Not exactly. iOS 7+ introduced Cocoa<->Javascript bridging capabilities in the public APIs. Before that, similar iOS APIs had existed as "private" ones (so, very uncommonly used outside of apple's own apps).

iOS doesn't bridge Javascript to _Java_ which is why this particular attack wouldn't work. But the JS<->Cocoa stuff is still pretty young, so wait and see ;)

[robterrell]

The JS-Cocoa bridge isn't young at all, it's the same bridge that has been on Mac OS X for years. And it's opt-in -- on the native side you have to specify which classes can be bridged and what methods can be called. It's not the case that any bridged webview exposes all of Cocoa for your JS injection pleasure. You could write an app that specifically exposed some dangerous API, but you'd know you had done so.

[lstamour]

> You could write an app that specifically exposed some dangerous API, but you'd know you had done so.

Few people write insecure code on purpose. Of course the same is true of Safari or networking/parsing code. I still maintain certificate pinning is the answer here, to try and defend as much as possible against MITM in the first place.