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.
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 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
please check the following URL.
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="firstname.lastname@example.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>
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.
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.
<!-- 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 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 or include one of the hundreds of open-source plugins available here.
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.
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 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:
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.
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
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.