Apache Cordova is a widely used framework for writing mobile apps that follows the “hybrid app” paradigm. A hybrid app is a mobile app that is partly implemented in platform-neutral HTML5/JavaScript and partly in platform specific languages (e.g., Java or Objective C).

As part of our work on developing static analysis techniques for Cordova apps [1], we analyzed Cordova apps from Google play: we took the Top 1000 apps (as ranked by Google in spring 2015) from Google Play and checked if these apps contain a config.xml file that belongs to the Cordova framework. Using this criterion, we could identify 50 Cordova apps. Thus, according to our analysis, only 5% of the Top 1000 apps are using Cordova.

How apps use the Cordova plugins

This actually differs significantly. Many apps do, in fact, use Cordova as intended: The app is written in JavaScript, the Java part is unmodified and simply loads the entry-point HTML file which is set in the Cordova configuration file. Some apps, however, significantly change the Java part. The most extreme apps do not ship any HTML or JavaScript code in the APK and simply specify one hard coded URL in Java to be loaded, which is often just the mobile version of their website, hosted in a remote location.

Some apps chose a middle ground: They may first load Activities like regular Android apps, and may embed HTML and JavaScript code only into some parts of the app, where Cordova Plugins may be used to communicate back and forth. Such irregular Cordova apps are the exception and are significantly harder to statically analyze, as they change the way Cordova is integrated into the app.

How developers use the Cordova plugins

Many plugins take callback functions and pass them through to their exec call. Especially for plugins which do not simply yield a result which can be passed to the success callback, e.g, when the plugin is just supposed to execute a command, there are often no fail callbacks being provided, either. Some of these actions could indeed fail, which would not get propagated through to the app code itself, though, because no fail callback has been passed.

How Cordova plugins are written

Plugins generally have the character of libraries, where the JavaScript part rarely does more than encapsulate the exec calls. There are also no other mechanism used to conduct cross-language calls. The official Cordova plugins adhere to these guidelines. Our work is intended for this kind of plugins.

Anyone can write Cordova plugins, and not all developers adhere to these guidelines. One found plugin, apparently written just for this specific app, does not contain any JavaScript code; instead, the exec calls are done right in the app code itself. Other plugins represent the other extreme and implement quite a bit of the plugin logic on the JavaScript side, which could have been as well written in Java. Again some other plugins do not even use exec to communicate with their Java side, but use methods which are also used internally in the Cordova framework. The reason for these unnecessary uses of workarounds remains unclear.

One plugin found in those Cordova apps is special in a different way: Combining Java and JavaScript was apparently not enough, as the APK contained some native libraries accessed via JNI to do some basic arithmetic calculations. As JSON strings get passed from the JavaScript part via Java to the C part, the attack surface gets even larger.

Key Take Aways

• Cordova is used for writing security critical apps
• A lot of apps ship Cordova components that they not use (but still might expose a security risk)
• There is a need for tools that help developers to write high quality Cordova apps

References