Another Android WebView Vulnerability

android.gifAnother day, another Android WebView vulnerability. This time it’s related to users that have enabled accessibility on their phones. This exposes two Javascript objects allowing remote code execution.

You might think this problem has low risk as not many people would enable accessibility features that are intended to assist users with disabilities. However, even I have had this enabled as it’s used by a password store app I use that auto-fills login forms for me.

There’s some new useful advice for developers to invoke removeJavascriptInterface("accessibility") and removeJavascriptInterface("accessibilityTraversal") that I have added to my WebView security guidelines.

Same Origin Bypass and Android Apps

trendmicro.pngThere has recently been a high profile ‘Same Origin Bypass’ security issue regarding the Android browser, prior to Android 4.4 KitKat, that allows a client session on one site to affect a client session on another. TrendLabs have just posted some information that shows that this vulnerability has wider reach than first thought. Like me, you might have thought it was only a web browser problem in that visiting one infected site can then cause problems when you visit further sites. However, as TrendLabs state… 

"A more significant problem right now might be apps that show a website within their own user interface. Messaging apps, or other apps where users can view an arbitrary URL, are a particular problem if the site is opened within the app and not sent to the user’s default browser."

I guess what they are getting at is that opening one infected URL followed by other uninfected URLs can compromise the security (data and behaviour) of the later sites. I urge you to think about if your Android app opens arbitrary URLs or even defined URLs, the content of which, you have no control over. Opening them into a WebView can cause unintended Javascript to be run. I have some further guidelines for using Android WebViews where I already advise not to use WebViews if your app involves processing any data that needs to remain secure.

The Web vs Apps Outcome

android.gifThere was time when some people thought the future of mobile development was the web. That thinking was based on the fact that the web was a common platform across all types of device and that would be the only way to solve fragmentation. If you look at the ‘Web Technologies’ section at the bottom of this site you will see I was sceptical.

In practice, we all know apps have dominated. While Apple and Google have improved their web browsers, they haven’t put in as much effort to allow the browser access to APIs nor improve the user experience for web-based apps. However, I believe the situation has become even worse than this.

The lack of browser-based access to native APIs has caused workarounds to be devised that are used in hybrid apps that contain WebViews and code included by most 3rd party ‘easy’ app creation tools. On Android these involve use of Javascript access to the Android native Context to call into native code. Unfortunately, as these are workarounds, they are very insecure. My article on ‘Use WebViews Carefully’ gives more details. Anyone using app creating tools based on WebViews or using WebViews in their app needs to be aware of these vulnerabilities. In fact, as of last week, outside of embedding in apps, even using the browser on its own has been the subject of a security scare.

A second problem is that there’s now no one ‘Android Browser’ upon which the WebViews are based. Niels Leenheer has a great set of slides that explains how browsers vary across Android versions, devices and phone manufacturers. The consequence of this is that getting any non-trivial WebView-based app to work across many device types is very difficult. The many 3rd party companies creating app creation tools based on web technologies face an uphill battle – as do people using their tools.

It’s ironic that the (web) platform that some people thought might solve the fragmentation problem has, arguably due to under-investment and lack of innovation by Google and Apple, become one that has security and fragmentation headaches.

Listening in on Android Apps

fireeye.pngFireEye has a new post on Android man in the middle (MITM) vulnerabilities on Android. While it covers Android, the coding flaws are just as applicable to iOS. FireEye found that 68% of 1000 most downloaded apps had one of three SSL vulnerabilities. For the avoidance of doubt, these are vulnerabilities introduced through app coding, not vulnerabilities in the Android OS. FireEye also found that of a random sample of 10,000 free apps, 40% used trust managers that didn’t check server certificates.

androidsslvulnerabilities.png

Even if you have coded your own app correctly, there’s the possibility that an included library has a vulnerability. For example, Flurry, up to v3.4, had such a vulnerability.

If you need further guidance, take a look at my security site:

There’s also a follow up FireEye article on why these issues are also applicable to enterprises, even when they are using a mobile device management (MDM) solution that silos apps.

What You Ought To Know About Android WebViews

androidsecuritylogo.pngDo you use WebViews in your Android app? If you say ‘no’, are you sure? What about 3rd party libraries/SDKs that you have included? Many such as ad libraries, Facebook and LinkedIn use WebViews.

In researching references for AndroidSecurity.guru I realised the use of WebViews is probably the area most overlooked when it comes to security. They are usually used to simplify development in that changes can be made at the server without an app re-install. They are also used by the majority of app creation tools because HTML and Javascript are very easy to dynamically create and run (in WebViews).

The problem is that WebViews come with lots of security holes. There’s generally two areas of concern. The first is classic cross site scripting where, for whatever reason (e.g. WiFi man in the middle attack or server side breach), the app ends up using rogue HTML/Javascript. The second problem area is the bridge from Javascript to app Java code which allows all your app programming interfaces to become visible.

I have some suggestions for tightening up WebView security. However, some of the suggestions might limit the functionality required of your WebViews. Also, it’s difficult to apply these suggestions to 3rd party SDKs, especially when you don’t have the source code.

For apps, for example banking and payment apps, that deal with sensitive data and really have to be secure, I’d think deeply if you really need to be using WebViews or 3rd party SDKs incorporating WebViews.

Banking Apps Leaking Information

ioactive.pngThere’s a new informative article at IOActive on how personal banking apps leak information. While the article concentrates on banking apps and iOS, the information is just as applicable to other types of apps and other mobile operating systems such as Android.

Ariel Sanchez of IOActive Labs took a look at 40 banking apps from the top banks in the world. Tests included SSL (session handling, valid certs), compiler protection, use of webviews, use of SQLite as well as anti-tampering analysis.

ioactivebankingvulnerabilities.png

The analysis is very alarming. Put simply, banking apps, that should be more secure than most other apps, can’t be trusted.

However, security isn’t just for banking apps. Snapchat is a very recent example of an app exposing 4.6 million users’ usernames and phone numbers. Poor security can damage your reputation. So what can you do? IOActive gives some pointers…

  • Ensure that all connections are performed using secure transfer protocols
  • Enforce SSL certificate checks by the client application
  • Protect sensitive data stored on the client-side by encrypting it using the iOS data protection API
  • Improve additional checks to detect jailbroken devices
  • Obfuscate the assembly code and use anti-debugging tricks to slow the progress of attackers when they try to reverse engineer the binary
  • Remove all debugging statements and symbols
  • Remove all development information from the production application
I have covered many of these areas in previous posts…

WebView Apps and LWUIT

java.gifIn 2007, I observed that most of the few non-game Java ME applications that had become successful, performed most of their processing at the server. Last year I wrote about WebView applications and commented on how useful these are for some types of application.

WebView applications are just a web site embedded inside an application. It’s easy to create these on most platforms:

With Java ME, up until now, you have had to hand-craft your own mini HTML rendering engine. However, LWUIT now supports a new HTMLComponent. This makes it much easier to create cross-platform WebView applications that include Java ME.

WebView Applications

Around two years ago I asked why there weren’t that many successful Java ME consumer applications that weren’t games. I went on to conclude that the few that were successful were just a window on more open, capable and consistent processing somewhere else.

It’s interesting to see that a number of development frameworks for several development platforms have evolved around this model of having a view on what’s essentially mainly happening at a server somewhere. In fact, even without these frameworks most platforms (except Java ME) have some kind of webView that can be embedded within an application.

WebView apps give many of the advantages of full native applications (use of phone APIs/features and discoverability via app stores) with the main disadvantage that the application itself needs a data connection at the time the user uses the application. Also, using a web oriented interface sometimes isn’t as usable as an equivalent interface made up of the phone’s native controls.

Sometimes it’s possible to use a webview instead of a plain text view to show application information. This allows information such as help or troubleshooting to actually reside online somewhere where it can be changed easily. Alternatively, it allows advertisements to be easily embedded in applications results because most ad systems are oriented towards embedding code in web pages.

I have done a few feasibility studies recently where a webView type application made a lot of sense. They tend to be applications that people will use for the specific unique content as opposed to those that need to compete with other applications on features or user experience.