Thursday, November 24, 2016

Testing the security of Cordova applications

Native vs. Hybrid:

Hybrid frameworks like Cordova offers the advantage of building one app for multiple platform (support for Android, iOS, Windows Phone, FireOS, FirefoxOS ...) . The framework is easy and fast to develop with and offers generally a single API for all platforms.

Hybrid apps suffer however from performance issues, even if the latest versions have made great enhances to the speed of the framework and the speed delay is unnoticeable on modern phones.

Cordova:

Cordova is platform to develop hybrid mobile apps using HTML5, CSS3 and Javascript, it is open-source and licensed under Apache Licence version 2.0, the core components offer a rich set of functionality in JavaScript, which can be extended using native languages.

Internals:

To review the security of a Cordova mobile application, it is important to have an initial understanding of the internals of the framework to know what to look for and where.

config.xml:

config.xml is the main configuration file that defines several aspects of the mobile application, like enabled plugins, platform specific settings and list of custom hooks. For more information on the options of config.xml file, please check the following URL: https://cordova.apache.org/docs/en/latest/config_ref/

For a security audit, it is the first thing to check to have an initial understanding of the application capabilities.

<?xml version='1.0' encoding='utf-8'?>
<widget id="io.cordova.hellocordova" version="0.0.1" xmlns="http://www.w3.org/ns/widgets" xmlns:cdv="http://cordova.apache.org/ns/1.0">
  <name>HelloCordova</name>
  <description>
      A sample Apache Cordova application that responds to the deviceready event.
  </description>
  <author email="dev@cordova.apache.org" href="http://cordova.io">
      Apache Cordova Team
  </author>
  <content src="index.html" />
  <plugin name="cordova-plugin-whitelist" spec="1" />
  <access origin="*" />
  <allow-intent href="http://*/*" />
  <allow-intent href="https://*/*" />
  <allow-intent href="tel:*" />
  <allow-intent href="sms:*" />
  <allow-intent href="mailto:*" />
  <allow-intent href="geo:*" />
  <platform name="android">
      <allow-intent href="market:*" />
  </platform>
  <platform name="ios">
      <allow-intent href="itms:*" />
      <allow-intent href="itms-apps:*" />
  </platform>
</widget>

The config.xml file resides at the root of the Cordova project folder which as the following structure:
  • hooks: allows to modify how the Cordova CLI works
  • platforms: hosts the native code for each platform. It is possible for developers to modify it to extend or alter the Cordova framework, although the recommended way is to add plugins.
  • plugins: plugins extend the JavaScript API and are stored in the current folder
  • www: this is the main folder storing the HTML, JavaScript and CSS code.

Whitelist

The whitelist plugin is an important security plugins that defines authorized URI for navigation, intent and network access. The plugins also allows the definition of a CSP (content-security-policy), a very important protection against cross-site scripting (XSS) vulnerabilities, highly dangerous for Cordova application.

For more information on CSP, I highly recommand the following links https://content-security-policy.com/ and this presentation by 2 Google folks on the new nonce-based protection https://www.youtube.com/watch?v=zlH_bBQMgkc.

<!-- Good default declaration:
    * gap: is required only on iOS (when using UIWebView) and is needed for JS->native communication
    * https://ssl.gstatic.com is required only on Android and is needed for TalkBack to function properly
    * Disables use of eval() and inline scripts in order to mitigate risk of XSS vulnerabilities. To change this:
        * Enable inline JS: add 'unsafe-inline' to default-src
        * Enable eval(): add 'unsafe-eval' to default-src
-->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com; style-src 'self' 'unsafe-inline'; media-src *">

<!-- Allow everything but only from the same origin and foo.com -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' foo.com">

<!-- This policy allows everything (eg CSS, AJAX, object, frame, media, etc) except that 
    * CSS only from the same origin and inline styles,
    * scripts only from the same origin and inline styles, and eval()
-->
<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'">

<!-- Allows XHRs only over HTTPS on the same domain. -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' https:">

<!-- Allow iframe to https://cordova.apache.org/ -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; frame-src 'self' https://cordova.apache.org">

Plugins

Plugins defines the set of functionalities supported by the application, Cordova has a rich list of existing plugins that allows access to common functionalities like Camera, GPS, Networking and Battery. Developers can develop their own plugins (https://cordova.apache.org/docs/en/latest/guide/hybrid/plugins/index.html) or include one of the hundreds of open-source plugins available here (https://cordova.apache.org/docs/en/latest/guide/hybrid/plugins/index.html).

Cordova plugins are easy to develop,  for Android for instance, they are implemented by simply extending the class CordovaPlugin and overriding one of the execute methods.

Additional frameworks

Applications developed using Cordova usually use complementary frameworks like Sencha, Angular or use extended version of Cordova like PhonGap and Ionic. These frameworks extends Cordova functionality to make application development a lot more easier, for instance Ionic provides services such as push notifications, A/B testing, analytics, code deploys, and automated builds.
These frameworks have their own logic and configuration files.

Debugging

Debugging code either for development or for security testing is very helpful to identify bugs and vulnerabilities or to ease understanding of the application. The tools available for debugging depend on the target platform. For Android, it is possible to use Chrome remote debugging, this provides access to all the developer tools inside Cordova. For iOS, it is possible to use the Safari Web Inspector which offers a very similar set of functionality.

Cordova has become a real alternative to build mobile application. From a security perspective, Cordova introduces new challenges and an extended attack surface, here are some of the common security weaknesses and attention points:

Common security weaknesses:

Insecure Whitelist: the whitelist Cordova plugin is an important cornerstone in the security of Cordova apps. As stated earlier, the plugins allows to define authorized URIs the WebView can navigate to, authorized intents the application can request for the case of Android and the authorized networks accesses.

Another important feature of the plugin is the support of CSP policies to protect against XSS vulnerabilities. CSP is necessary as the whitelist filters do not apply to Websockets and <video> HTML5 tag.

Permissive policies like:

<!-- Don't block any requests -->
<access origin="*" />
are insecure and unfortunately common and facilities the exploitation of XSS vulnerabilities in the application. This vulnerability is checked by the our openly available security scanner.

Cross Site Scripting (XSS): From the OWASP definition, Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

XSS vulnerabilities do apply to Cordova applications and are highly dangerous as they are equivalent to full code execution in the context of the mobile application. The range of possibilities depends on the list of loaded plugins.

To illustrate the vulnerability, let's take the following example of a vulnerable application that lists all contacts with an image (the code is inspired from https://github.com/cfjedimaster/Cordova-Examples/tree/master/stealcontacts):

The application basically retrieves contacts with a photo (line 20) and display the photo and the displayName attribute. The application includes the displayName insecurely, thus introducing an XSS vulnerability.

To exploit the vulnerability, we can simply create a contact with the following displayName:



Once, we launch the application, we are greeted with the alert(1) box.


The payload is in this case harmless, but it is easily possible to replace it with a malicious one to access sensitive information for instance.

Unused plugins: Reducing the attack surface of the application is important to reduce the impact of vulnerabilities like XSS, particularly plugins with dangerous functionality, like file, camera and contact access.

Plugins could also suffer from their own class of vulnerabilities, like SQL injection, insecure filesystem access or XXE injection.

Unpatched Cordova versions: Cordova has suffered in the past from several vulnerabilities bypassing the whitelist restrictions, allowing to load arbitrary resources. Fixing the vulnerability usually requires building and publishing a new version of the application.

For a list of known vulnerabilities, check the following URL: https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-27153/Apache-Cordova.html

Android is still Android  and iOS is still iOS: Beside the new class vulnerabilities introduced by Cordova, particularly XSS, a Cordova mobile application is still a mobile application, and classical mobile application vulnerabilities are still applicable.

Popular Posts