>It was recently discovered that applications do not even need to have a Javascript Interface in their code to be vulnerable to this attack. This is because a Javascript Interface is implemented core webview code in Android versions before 4.2. Meaning that every single application that loads a webview over cleartext is vulnerable to this attack.
Maybe its because I haven't properly had coffee yet or because I've never used WebView in android but I'm having trouble parsing this. From the small code snippet they provided it shows them enabling javascript and adding an interface. Is this just a general comment for other apps that are working on HTTP or broken HTTPS or does it relate to this exploit?
There is a CVE (CVE-2012-6636) [1,2] related to the general issue they are mentioning. Basically one could use reflection to call any public function on any class in the app. Since Android 4.2 one now needs to add the @JavascriptInterface decorator to explicitly expose methods. At least this is my current understanding of this.
If the app then uses HTTP or HTTPS without certificate validation, it is easily possible to inject JavaScrpipt code even when no Cross-Site Scripting vulnerability exists in the app.
Someone unknown added a phone number and a new mobile pin to my paypal account recently. I called paypal support and they walked me through changing the pin. Few minutes later, the pin was changed once again by the unknown person. I call paypal again and they walk me through a similar process again. Finally it stopped but it left me feeling very vulnerable especially because I'd enabled two factory auth and it did little to prevent it.
Weird enough no funds from my account disappeared. Not sure if me acting so far(within minutes of compromise) had to do with it.
This also caught my eye... But then again there are many examples where Paypal has handled issues badly, so I'd guess this just the way they want their brand to be perceived.
I'm guessing an engineer added the 'proceed' call during development because the dev servers had invalid certs, and they forgot to change it back before committing.
What kind of code can be executed through the Javascript interface? They seem to claim it's not specific to Paypal's implementation and these seem fairly common. I was under the impression they only expose various methods and variables. How can they be exploited?
An attacker can show the user a page identical to PayPal's and convincingly ask them for their credentials. The submission would send the credentials to the attacker.
Maybe its because I haven't properly had coffee yet or because I've never used WebView in android but I'm having trouble parsing this. From the small code snippet they provided it shows them enabling javascript and adding an interface. Is this just a general comment for other apps that are working on HTTP or broken HTTPS or does it relate to this exploit?