Besides AWS, so many SDKs are used client oriented design, like Dropbox and Facebook. The consequence of leaking those keys may not critical as the AWS though.
Correct. Even for the not rooted phones, attackers can send SMS, record audio or access SD card due to the permissions the target app applied. Also you may exploit some privilege escalation vulnerability on Android after you got a shell. It's phone-specific and app-specific though.
It's a vulnerability on Android Webview component, which supports a "addJavascriptInterface" method. This method allows you to call the Java native method by using a Javascript object inside the webpage. And, there is a trick that can bypass the restriction on classes that JSInterface object could access. You can call any method in any Java class. Such as Java.lang.Runtime.exec. You can google "addJavascriptInterface vulnerability". It's not a new vulnerability, but lots of app haven't fix it yet.
You would never be able to install an app without user click "install" etc.
This one uses Javascript Bridge vulnerability to execute high privilege code in your Android. The attack code is javascript to be interpreted to Java calls in Android.
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.
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 ;)
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.
> 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.
