A multi-party,fine-grained permission and policy enforcement framework for hybrid mobile applications

Abstract

In hybrid mobile applications (apps), the core code of an app is in JavaScript. Any JavaScript code in a hybrid app, local or remote, can access available APIs, including JavaScript bridges provided by a hybrid development framework, to access device resources. This JavaScript inclusion capability is dangerous since there is no mechanism to determine the origin (party) of the code to control access. Moreover, any JavaScript code running in a mobile app can access the device resources through the exposed APIs. Previous solutions are either limited to a particular platform (e.g., Android) or a specific hybrid framework (e.g., Cordova) or only protect the device resources and disregard the sensitive elements in the web environment. Furthermore, most solutions require modification of the base platform.

In this article, we propose a novel policy enforcement framework to enforce useful fine-grained security and privacy policies based on permission for each party in hybrid mobile apps. In contrast to the conventional permission model in mobile apps, our permission specification is platform-agnostic and context-aware. This new permission specification allows app developers to customize for different parties over single permission. We integrate our permission specification into an app at the development phase; however, by design, it allows end-users to adjust parameters at runtime to protect their privacy. Together with multi-party permission patterns, we introduce comprehensive classes of expensive fine-grained, stateful policies that developers can deploy in practice. These policy patterns can help to protect the privacy of users and can also mitigate significant types of potential attacks in hybrid apps, evidenced by our real-world evaluation. Our experimental results also demonstrate that the framework is compatible with various hybrid development frameworks over two major mobile platforms, with lightweight overhead.

Keywords

Security permission privacy hybrid mobile apps

1. Introduction

Hybrid mobile application (app) development is a technology for developing mobile apps using web technologies (i.e., HTML, CSS, and JavaScript), thanks to the portability of the web [20,65]. In hybrid mobile apps, developers write the core business code in webpages using JavaScript, HTML, and CSS, instead of a platform-specific language such as Java for Android. Typically, developers use a middle-tier development framework such as Cordova (https://cordova.apache.org/) to integrate this web code into a native mobile app for a specific platform, e.g., Android or iOS, automatically. These types of mobile apps are known as hybrid mobile apps, as they contain both web code (written by developers) and platform-specific code (typically generated by a hybrid development framework) [29,31].

Hybrid frameworks typically provide JavaScript “bridge” APIs to allow hybrid mobile apps, i.e., the business JavaScript code, to interact with the native code to access device resources such as geolocation, contact lists, SMS, and others. While this execution model provides advantages for developers, it, however, exacerbates the security issues of hybrid mobile apps compared to native apps. One security challenge is that the permission model in mobile platforms (i.e., grant all or nothing) is too coarse-grained to prevent the misuse of these JavaScript bridges. In addition, while built-in security mechanisms such as same-origin policy, content security policy, or domain whitelisting can prevent web-based vulnerabilities such as cross-siting scripting attacks, these mechanisms fail to prevent potential malicious behaviors from whitelisted third-party code (cf. Section 2.3 for detailed discussions). For example, third-party advertisement JavaScript code embedded in a hybrid mobile app can access granted resources through available JavaScript bridges without any limitations [83].

There have been several efforts in the literature to provide security solutions for hybrid mobile apps, these proposals, however, face one or several limitations. For example, some solutions, e.g., [26,83], focus on a specific platform (e.g., WebView in Android), therefore they do not work on other platforms. A few other works, e.g., [25,37], provide platform-independent solutions, but they only focus on a specific hybrid framework, such as PhoneGap, by modifying them. Thus, these might not be compatible with other hybrid frameworks. In [26], Georgiev et al. introduce an access control mechanism that can mediate device resources for web-based system applications for multiple parties. However, the solution does not protect users’ sensitive information stored in the web environment. PhoneWrap [24] can protect both device resources and users’ information but does not support different policies for multiple parties within a hybrid app.

Motivated by the above limitations, our work aims to provide a robust and extensible policy enforcement framework for hybrid mobile apps that can fill the gaps in the state-of-the-art as previously discussed. In preliminary work [67], we propose HybridGuard, a framework that allows developers to define flexible permissions and fine-grained policies for different parties within a hybrid app. As a reference monitor implemented in the web environment, our framework can enforce policies at runtime to control the behavior of the code so that it can prevent potential attacks and resource abuses. The multi-party permission and fine-grained policy enforcement mechanism advance the current “all-or-nothing” permission model in mobile platforms and complement basic security features provided by the hybrid framework and the embedded web browser. We leverage JSON (JavaScript Object Notation), a textual structural specification, to design our multi-party and usage control permissions. We implement the enforcement code in JavaScript, independently and separately from the policy specification. The policy specification and enforcement code are embedded into an app at the web layer with minimal instrumentation of the original index HTML page to load and execute external JavaScript code. Our approach requires developers to mark JavaScript code from each party under a label (we define as “principal”). By doing so, the code from each party can be precisely monitored and enforced at runtime by the policies for that particular party to ensure its security. In this article, we have made significant extensions to HybridGuard [67] with the following new contributions:

We extend the specification of multi-party permissions and policies to support user-centric usage control to protect users’ privacy. We present practical permission and policy patterns that developers can deploy in hybrid mobile apps to prevent potential real-world attacks and privacy violations.

We implement a proof-of-concept prototype that stores the pre-defined policy templates permanently in local storage. This mechanism ensures that policy states can be updated persistently. It also supports the customization of policies, i.e., end-users can personalize the policy parameters at the installation or runtime.

We perform significant evaluations and report practical experimental results on various aspects. Our framework is platform-agnostic as it is compatible with various hybrid app development frameworks and two major mobile platforms (Android and iOS). We show that practical policies can soundly prevent attack scenarios while posing lightweight overhead. We demonstrate that our framework is also applicable to real-world hybrid mobile apps.

We organize the rest of this article as follows. In the next section, we describe the background of this work, including the hybrid mobile app architecture, motivating attack scenarios, existing security mechanisms in hybrid mobile apps, and the threat model. We survey the literature and discuss related work compared with ours in Section 3. In Section 4, we present our design of the framework, and we describe our specification of multi-party, fine-grained permissions, and policies in Section 4.2. We describe our prototype implementation in Section 5 and introduce a wide range of policy patterns and templates in Section 6. In Section 7, we demonstrate the evaluation and discuss the experimental results. Section 8 concludes our contributions and discusses future work.

2. Background

In this section, we first give an overview of the hybrid mobile application architecture. We then present four motivating attack scenarios that motivate HybridGuard’s design and implementation, and that we use as running examples throughout the rest of the paper. Next, we describe existing security mechanisms available for hybrid mobile apps, while outlining why these do not provide robust security protection against our motivating attack examples. Finally, we conclude with a description of the threat model we use for our HybridGuard framework.

2.1. Hybrid mobile application architecture

Originally, hybrid mobile applications (apps) are cross-platform mobile apps where the core business logic of apps is developed using web technologies (i.e., with HTML, CSS, and JavaScript) [29,31]. In recent years, there is another type of hybrid mobile apps that are not based on the web but developed in a programming language that differs from the mobile platform, e.g., C# in Xamarin [54]. In both types of hybrid mobile apps, after developing an app, developers use a hybrid mobile app development framework to pack the core code into a native app for a particular mobile platform. This technology and approach allow hybrid mobile apps to be write-once-run-anywhere, i.e., on different platforms such as Android and iOS. Hybrid mobile app development, therefore, saves substantial time and resources required to develop different versions of the same app on a specific platform [17].

In this work, we consider the original type of hybrid mobile apps, i.e., web-based hybrid mobile apps. In this type of hybrid mobile apps, Apache Cordova/PhoneGap [9] is the first development framework [86] and was the most prominent framework for building hybrid mobile apps in the past [29]. Many other popular frameworks based on Cordova such as PhoneGap [1], Ionic [52], Onsen UI [63], Framework7 [38], Sencha Touch [32], Intel XDK [35], and others are used in practice [9,17,78]. There have also been many new web-based hybrid app development frameworks that have emerged in the past few years, such as React Native [23], NativeScript [72], jQuery Mobile [79], Mobile Angular UI [21], Touchstone.js [81], to name just a few [17,78]. With those frameworks and the advent of near desktop-quality smartphones, web-based hybrid mobile apps are almost at par with native apps across the dimensions of performance, UI design, and development support tools [20,43]. These advantages result from significant improvements achieved in the performance of JavaScript engines in mobile platforms [49,65].

Figure 1 describes the basic architecture of a hybrid mobile app where the embedded web browser is a container to render the web content. As a webpage, the web content in a hybrid app can include local web code, remote web code located on the app’s web server, and third-party web code, such as ad syndicator scripts or other external JavaScript code. The mobile platform provides an infrastructure via the bridge code – a combination of web APIs and native APIs, for the embedded web content to communicate with device resources, such as a microphone, camera, contact list, and others. For example, navigator.geolocation is a read-only property of the web API navigator which returns a Geolocation Java object that provides web content access to the device’s location. In Android, native APIs are in Java, and in iOS, they are in Objective C [28]. For instance, android.preference is a native API that provides classes that manage application preferences and implement the preferences UI. The android.preference.CheckBoxPreference class is used to provide checkbox widget functionality in an app. The web APIs also allow the web code to manipulate the Document Object Model (DOM).

Fig. 1.

Architecture of hybrid mobile apps.

2.2. Motivating attack scenarios

Scenario #1: Abusing device resources. Consider a hybrid mobile app that requires access to SMS and Contacts. By default, after a user grants the required permissions (could be at installation or run time), any JavaScript code running inside the application has access to these device resources [11]. If third-party JavaScript code included by the developer is infected with malicious code controlled by an attacker, the malicious code can access all the granted resources. For example, the malicious code can send bulk spam SMS messages to the user’s contacts or random numbers.

Scenario #2: Malvertisement and sensitive information leakage. Most free apps display in-app ads [19] to generate revenue through clicks and referrals. These ad services have an extensive screening process for supplied ads; however, the process is not airtight [92], as there have been many incidents of malicious ads in the past. These malicious ads reach users’ devices by either slipping through the screening process or by compromising the ad network [27,30,39]. This phenomenon is known as malvertising [75]. The malicious JavaScript in the ad can access the user’s sensitive information that may be available on the host page, such as Photo Gallery, File Storage or other personal information. Malicious JavaScript code in an ad with access to SMS and Email APIs, can use these channels to leak the stolen sensitive information.

Scenario #3: UI redress attacks. UI redress attacks are also known as clickjacking on the web or touchjacking/tapjacking on smartphones [64,73]. Malicious code can manipulate the DOM of the host page, including the creation of new elements or the modification of existing ones. Leveraging this ability, malicious JavaScript code in a hybrid app can launch such attacks by creating an invisible interface, such as an invisible iframe, on top of the app interface. Here, the attacker tricks a user into tapping a button or link on another page loaded in the iframe, assisting the attacker in ‘hijacking’ clicks to perform actions on behalf of the user, on the page loaded into the iframe. This scenario can also lead to drive-by-download attacks.

Scenario #4: Overusage of resources. A rogue third-party JavaScript with unlimited access to granted device resources, such as geolocation, can constantly monitor the current location of a user in real-time by hooking the navigator.geolocation.watchPosition() API and exfiltrating this data to the attacker. This attack scenario does not only breach the privacy of the user but also puts the physical safety of the user at risk.

2.3. Existing security mechanisms in hybrid mobile apps

In this subsection, we review existing security mechanisms in hybrid mobile apps. These mechanisms are either provided by a hybrid app framework, the embedded browser, or the underlying OS. We outline the advantages of each, but also describe why they are incapable of adequately protecting against the attack scenarios outlined in the previous subsection, thus motivating the need for a tool such as HybridGuard. For a detailed discussion of related work that proposes security techniques for protecting various security issues in hybrid mobile apps, we refer readers to Section 3.

Domain whitelisting. Some frameworks, such as Cordova, Ionic, React Native and Onsen UI, provide domain whitelisting, a security mechanism where developers can configure a security policy to define which external domains the WebView [45] can be navigated to, type of URLs (e.g., file:*, sms:*, tel:*) the app can ask the system to open, and network requests (e.g., images, XMLHttpRequests) that are allowed. The default settings allow complete interaction with any external domain [10]. A good whitelist can restrict navigation to malicious URLs and prevent attacks, such as drive-by-download, however, this mechanism does not prevent against attacks originating from third-party scripts that the developer trusts and includes intentionally [5,25,55], such as Scenario #1 and #2 in Section 2.2.

Same-Origin Policy (SOP). An origin is defined by the scheme, host, and port number of a URL [15]; two URLs have the same origin if they have the same scheme, host, and port number (if specified). The SOP is a web security policy that restricts how a document or script loaded from one origin can interact with a resource from another origin. For example, if an app’s web content includes an iframe with an ad, SOP prevents scripts in this ad from reading or modifying any non-trivial DOM attributes of the app’s content, preserving app integrity. The ad syndicator’s script runs in the app’s origin, but the actual ad runs in its own origin, isolated from the rest of the app’s content by the SOP. As a webpage, a hybrid app is enforced by the SOP through the embedded browser. However, JavaScript bridges are added to the browser by local code and have no web origin as far as the browser is concerned. Therefore, malicious web content from any origin can directly invoke the bridges, and SOP fails to protect against any attack scenario discussed in Section 2.2. In our threat model, we consider both malicious advertisers and malicious ad brokers. Even though app developers trust the later, they can still be under the control of an attacker [27,30,39].

Content-Security-Policy (CSP). CSP is a native browser capability that allows developers to control, at a granular level, exactly what content an app can access [56]. CSP is applied at page level either through the Content-Security-Policy HTTP header [57] or through the HTML meta tag. For hybrid mobile apps, typically the meta tag is used. By default, applying a CSP disables both runtime code execution, e.g., using eval(..), and inlined scripts. Only domains declared in the CSP can be loaded scripts from or for any bi-directional communication. This mechanism requires the developer to explicitly add the source of any third-party JavaScript, such as ad network’s source URLs, to the CSP. However, as CSP can only allow or disallow a certain domain, this makes it coarse-grained. CSP does not include any mechanism for developers to control the behavior of the included third-party code, which can be potentially malicious [56,83]. While CSP can protect against certain types of attacks, including Cross-Site Scripting (XSS) and code-injection attacks, it does not prevent any attack scenario described in Section 2.2.

OS-level permissions. Both Android and iOS implement permission-based access control, where an app is granted permission to access a resource at runtime [8,12]. The resources that can be accessed are limited to the set of resources requested by the developer for the correct functioning of the app. Each app is limited to accessing resources within the scope of this permission set. However, once the permission to access the resource has been granted, the OS has no control over how the app uses this permission. Although the OS level permission model is critical in preserving the privacy of a user by restricting malicious content in an app from accessing sensitive device resources, it is too coarse-grained. The OS-level permissions fail to protect against any attack scenario discussed in Section 2.2.

2.4. HybridGuard threat model

In this work, we consider scenarios where hybrid mobile apps are legitimate and trusted by users. We assume that hybrid app developers configure Content-Security-Policy (CSP) to prevent code injection attacks [36]. The in-scope threats originate from whitelisted third-party JavaScript code that developers allow in CSP for app functionality. However, once included in the apps, third-party JavaScript code has the same privilege as the first-party code, and developers have no mechanism to control its behavior. In this threat model, the third-party JavaScript code could be (1) benign but under the control of an attacker through web application attacks, such as SQL injection, or network attack on the third-party server; (2) malicious by intentions; it lures developers by its appealing functionalities.

3. Related work

In this section, we survey and discuss recent work that is most closely related to our approach. We categorize the related work into three subsections as follows.

3.1. Third-party JavaScript isolation

Numerous solutions in the literature provide protection against malicious third-party JavaScript [2,34,46–48,53,58,60,66,68,69,82,84]. However, the existing solutions do not capture the phone-related attack channels, such as SMS, Wi-Fi, Bluetooth, Contacts and other. Due to this, adapting these solutions to the hybrid mobile app environment is not a trivial task and requires significant modification to the existing proposals.

Furthermore, none of these solutions provides multi-party or principal-based permission for hybrid mobile apps, as we propose in HybridGuard. JaTE [82] supports the isolation of third-party JavaScript with labels using Proxy in ECMAScript 6. However, JaTE does not provide support for mobile app-based permission. Approaches like Adsafe [34] can be applicable; however, one must extend it with JavaScript bridge APIs, and this approach requires third-party JavaScript written in their JavaScript subset. In contrast, HybridGuard allows the full set of JavaScript and bridge APIs provided by frameworks. ConScript [53] requires browsers to be modified to enforce security policies. This approach limits the deployment of the protection as it requires modification of the mobile base platforms. HybridGuard does not require the modification of browsers, hybrid frameworks, or base platforms.

Adjail [46] and Webjail [84] use iframes to isolate third-party content and provide a mechanism for cross-platform interaction. However, these works cannot protect against attacks for JavaScript bridge APIs in hybrid apps because they are accessible for any JavaScript code allowed to load in a hybrid app. ScriptProtect [58] automatically strips third-party JavaScript code of the ability to conduct unsafe string-to-code conversions, effectively removing the root cause of client-side XSS without affecting the legitimate code. JSSignature [60] provides a method to bring digital signatures to third-party JavaScript inclusion, where all included JavaScript resources are checked against integrity, authentication, and non-repudiation risks before execution. NodeSentry [85] provides a policy infrastructure that allows the combining of common web hardening techniques and measures, common and custom access control policies on interactions between libraries and their environment, including any dependent libraries. However, unlike HybridGuard, none of these works protect against unauthorized bridge API accesses in hybrid mobile apps.

3.2. Fine-grained policy enforcement in mobile apps

There are various efforts to define and enforce fine-grained policies for mobile apps in general. For example, ConSpec [3] is an automata-based policy specification. ConSpec can specify and enforce both user policies, e.g., users may want to limit the number of SMSs sent from an app, and application contracts, i.e., policies that govern an app’s security-relevant behaviors. However, ConSpec targets type-safe byte-code languages only, which implies that unlike HybridGuard, it cannot monitor or enforce policies on JavaScript, a language that is not type-safe. LoPSiL [44] is another policy specification language that can specify and enforce location-dependent security and privacy policies for mobile apps. A sample privacy-based access-control policy in LoPSiL is constraining an app’s ability to read location data at specific times. HybridGuard is capable of enforcing a much more extensive range of policies, as presented in Section 6.

There are other mechanisms to enforce fine-grained policies for mobile apps; however, they are specific to the Android platform and require the modification of the Android OS. For example, AppGuard [13] is capable of enforcing user-customizable policies on untrusted apps by modifying the apps. AppGuard can enforce fine-grained policies such as the possibility of specifying a set of servers an app is allowed to contact over the Internet. Secure Application INTeraction (Saint) [62] is another access-control system that can enforce both installation time permission granting policies and run time inter-application communication policies. FlaskDroid [18] is another security framework that works simultaneously on both Android’s middleware and kernel layers to enforce access-control policies. Apex [61] introduces a user-centric policy specification technique by extending Android permissions with run time constraints with only two parameters: the number of times, and the time of the day.

In [33], Imamura et al. propose a web access monitoring mechanism that can monitor all web access via WebView on Android. This mechanism does not require any modification of the Android Framework or the Linux kernel and can be introduced by just replacing WebView with a modified version. However, it cannot protect against attacks that originate from third-party JavaScript like HybridGuard does.

3.3. Hybrid mobile application security

In subsection, we discuss the related work in the field of hybrid mobile app security. We classify these solutions into three subcategories as follows.

3.3.1. Access control systems/frameworks

Many proposals introduce access control mechanisms for hybrid mobile apps. The closest related work to HybridGuard is PhoneWrap [24], which enforces fine-grained ticket-based policies for hybrid mobile apps. These ticket-based policies ensure a limited number of resource accesses based on the user’s interaction with the app. Resource accesses through JavaScript interfaces are wrapped by a library, inspired by the “self-protecting JavaScript” approach [69]. However, PhoneWrap excludes a multi-party scenario and cannot enforce separate policies for different origins, as proposed in our work. POWERGATE [26] allows developers to define origin-based access control policies similar to our HybridGuard. However, POWERGATE only protects native objects and relies on the web-browser to protect DOM objects. Also, its implementation requires modification of the base system, such as Firefox OS. In contrast, HybridGuard can enforce policies on both bridge APIs and DOM objects to prevent unauthorized access. In [77], the authors introduce a context-aware permission control system for hybrid mobile apps. This system aims to enforce information flow policies to prevent potential data leakage. However, the work does not focus on policies and permissions for multiple parties as we concentrate on HybridGuard.

Draco [83] provides a declarative policy language for developers to define fine-grained access control policies for multiple origins, for web code running on Android in-app browsers. It also introduces the Draco Runtime System (DRS) to enforce these policies at runtime. Another fine-grained access control mechanism for Android hybrid mobile apps implements frame-level access control [37]. RestrictedPath [70] allows developers to define intended API paths of their apps and subsequently monitors all API invocations. The monitoring determines whether an app deviates from its intended path [70], thus enforcing access-control. MinPerm [50] automatically identifies over-privileged permissions by comparing permissions declared by the developer and permissions required by the app. However, all these approaches are specific to Android and, thus, require the modification of the Android base system. In contrast, we implement HybridGuard framework at the web layer, and therefore, it can apply to any mobile platform without modifying the base system.

Georgiev et al. introduce the term fracking for the generic class of vulnerabilities that allow untrusted web content to access device resources [25]. They propose NOFRAK, an access control mechanism that enforces the security policy, “NoBridge” – an app can load third-party content without accessing device resources. This approach is a highly coarse-grained mechanism compared to our multi-party and fine-grained policies. AlJarrah et al. propose an access-control mechanism that restricts access to only required device resources per page, to minimize the attack surface [76]. Unlike HybridGuard, this solution is only applicable to multi-page web-based mobile apps. The same researchers also propose a behavior-based approach to generating fine-grained security configurations to implement the least privilege principle automatically [5]. In another work, CordovaConfig [6], the authors implement a web-based tool prototype that provides automated interactive support for configuring hybrid apps. Kudo et al. [40] introduce a novel attack technique termed as app-repackaging, where an attacker repackages hybrid apps with malicious code intended to steal sensitive user data stealthily. They introduce a runtime access control mechanism to restrict access to device resources. As opposed to HybridGuard, these approaches modify the underlying Cordova library to implement the solution.

Yang et al. [90] identify a new security issue in postMessage in hybrid mobile apps. The work demonstrates that the origin information of a message is not respected or even lost during the message delivery. This issue allows adversaries to inject malicious code into WebView to passively monitor messages. These messages may contain sensitive information, or actively send messages to arbitrary receivers and access their internal functionalities and data. The authors define this issue as Origin-Stripping Vulnerability (OSV) and develop a tool called OSV-Hunter to detect such vulnerabilities. They also develop a defense tool to mitigate OSV by implementing three new postMessage APIs, called OSV-Free. However, unlike HybridGuard, OSV-Free cannot protect against fracking attacks or allow the developer to enforce principal based fine-grained policies on device resources.

3.3.2. Detecting and preventing code-injection

Several solutions focus on detecting code-injection attacks in hybrid mobile apps. Jin et al. introduce the possibility of code-injection attacks in hybrid mobile apps through non-web channels, such as SMS, Contact List, Calendar, NFC, camera, and even Wi-FI SSID, that are specific to smartphones [36]. DroidCIA [22] extends the previously mentioned work, i.e., [36] to introduce a new code-injection channel, where a malicious script can be injected by using the HTML5 textbox element along with document.getElementByID(“TagID”).value [22]. Xiao et al. introduce a new type of code injection attack that encodes the injected JavaScript code in a human-unreadable format [88]. The authors use machine learning algorithms to detect vulnerable apps. They also suggest an improved access control model that uses a combination of page-based and frame-based techniques. Yan et al. present a new deep learning network, Hybrid Deep Learning Network (HDLN), and use it to detect code-injection attacks [89]. Another work detects code-injection attacks by monitoring the execution of apps [51]. It generates behavior state machines to describe the app’s expected runtime behaviors based on the execution context of the app. In this work, any deviation from the pre-defined behavior state machines is considered an indication of a code-injection attack [51]. SCANCIF [41] is a static analysis tool identifying sensitive plugin APIs based on tags that can inject malicious code. The work also analyzes information flow based on modeling contexts of callback functions passed in function calls. BRIDGETAINT [14] is a novel bi-directional dynamic taint tracking method that can detect bridge security issues in hybrid apps. BRIDGEINSPECTOR [14] is a tool based on BRIDGETAINT that detects cross-language privacy leaks and code-injection attacks in hybrid apps.

In summary, all of these methods mentioned above detect and prevent code-injection attacks that can execute malicious code at runtime. However, hybrid app developers can prevent such code-injection attacks by disallowing inline scripts in CSP. In contrast, our work focuses on attacks that cannot be mitigated by CSP.

3.3.3. Security analysis and surveys

There are a few studies that provide an overview of security mechanisms and analyze the vulnerabilities in hybrid and web-based mobile apps. In [59], the authors reveal that 28% of one million web-based mobile apps have at least one vulnerability. If exploited, these vulnerabilities can cause serious cyber-attacks. [87] studies over a thousand Cordova apps downloaded from Google Play and gives a statistical overview of the adoption of Cordova security best practices and mechanisms, such as usage of whitelist or the occurrence of eval(), among others. Another study of 2111 hybrid mobile apps analyzes configurations and permissions usage patterns [7]. In that work, the authors provide the systematization of the hybrid mobile app configuration model. It shows the evidence of configuration misuse and the tendency of developers to use default settings and possible reasons for misconfigurations.

In [4], the authors summarize the statistics of the prevalence of hybrid apps, most widely used cross-platform tools, based on the analysis of around 15,000 hybrid apps. BridgeScope [91], investigates JavaScript bridge security issues, such as evading security checks in WebView event handlers, in Android hybrid apps. HybriDroid [42], a static analysis framework for Android hybrid apps, investigates bugs originating from the interoperability of Android Java and JavaScript in Android hybrid mobile apps. Hybrid-scanner [71] is another tool that tracks and analyzes the internal behavior of hybrid mobile apps. Using Hybrid-scanner, the authors found that almost 40% of security-sensitive APIs in hybrid mobile apps are invoked by third-party libraries, e.g., advertisement libraries. Apart from revealing numerous security issues in hybrid mobile apps, none of the works implement any defense solution.

Biørn-Hansen et al. conduct a comprehensive survey that assesses the cross-platform mobile app development academic body of knowledge [16]. The survey particularly emphasizes core concepts that include user experience, device features, performance, and security. Their findings illustrate that the state of research demands empirical verification of an array of unbacked claims and that a particular focus on qualitative user-oriented research is essential. HybridGuard provides the first steps towards this user-oriented by allowing users to customize the policies.

4. System design

4.1. Overview of the HybridGuard framework

The objective of our HybridGuard framework is to provide a mechanism for developers to define and enforce different policies for each included JavaScript code within a hybrid mobile app. The JavaScript code might be untrusted local script files, or remote scripts coming from various parties, e.g., advertisements. Our policy specification allows developers to express default and generic policies that can prevent frequent potential attacks such as attack scenarios discussed in Section 2.2. We separate the policy specification from the enforcement code, and we include both of them into the code base of the app. With the separated policies, our framework provides the capability to customize the policy parameters while or after installing an app. Figure 2 depicts the overview of our framework that complies with the development flow of a hybrid mobile app development process.

Fig. 2.

The overview of our framework and its development flow.

In general, when deploying our HybridGuard framework at the development phase, developers first include the core JavaScript library of the framework, i.e., the HybridGuard.js file, into the index webpage of an app. Our library JavaScript file needs to be placed right after a hybrid development framework library, e.g., cordova.js. The reason is that our framework must capture the references to device resource APIs provided by a development framework library, e.g., Cordova. Our experiments show that only loading before a development framework library, our enforcement code can capture the references and intercept all of the device resources provided by the development framework. On the other hand, we must load our code before any other included code. This loading order ensures that our enforcement code can monitor all of the code included later. It is also to guarantee that the JavaScript code included after our library cannot access the intercepted device resources directly but only via our monitor. Moreover, prior work such as [58,69] demonstrates that loading the monitoring and enforcement code before other untrusted code can protect the monitor from tampering the monitor or unauthorized access to the monitor.

In the next step, instead of including JavaScript code in any sources, either local or remote in the standard way, i.e., using <script src="..."></script>, developers will use the API loadJSwithPrincipal(<principal>,<uri>) provided in our library (cf. Section 5.1) to load that script under a specific principal if the developer wishes to enforce policies for that code. We leave this loading mechanism up to the developers since they are in the best position to know what included code should be monitored under which principal. This mechanism is similar to the Content-Security-Policy (CSP) (cf. Section 2.3), where developers need to “whitelist” external scripts. As discussed earlier, our loading mechanism advances the CSP by enforcing further fine-grained security policies for each included script. Moreover, some common script libraries, such as jQuery, might not need to be monitored since they usually do not interact with device resource APIs. In those cases, the developers do not need to load such scripts with our loading mechanism. We note that any script not loaded through this mechanism has no label (principal) at runtime, and therefore, has the lowest privilege in our monitor. As our monitor code first checks the principal of an API call, if there is no “principal” information in that call, we suppress the call by default. It means that scripts executed directly without our loading mechanism cannot bypass our policy enforcement mechanism.

After including all scripts for an app using our loading mechanism, the app developer needs to customize our policy template, i.e., the policy.json file, and save it in the app folder. This customization process is to specify fine-grained policies for each party’s included JavaScript code. These customized policies define which actions to proceed when code from a party/principal invokes an API call. The second part of our framework is the reference monitor to control the API execution based on the policy specification. Our monitor intercepts security-relevant API calls, including access to device resources and the DOM. API calls accessing device resources are typically provided by a hybrid development framework such as Cordova or can also be native objects shared by developers [80]. This deployment mechanism ensures that the monitor code checks all invocations to the intercepted APIs loaded under a principal. The monitor code later invokes the policy engine to decide whether to grant or deny the call based on the defined policies under that principal.

Thus in the next subsection, we introduce our design of the policy specification. We describe the implementation of the policy enforcement and monitoring component in Section 5. We note that the design and implementation of our policy and enforcement framework are independent of any particular web-based hybrid mobile app development framework.

4.2. Specification of multi-party, fine-grained permissions and policies

In this subsection, we describe the policy specification design and illustrate how to apply these policies in realistic scenarios. Our goal is to specify rules on how JavaScript code from different parties interact with device resources and users’ sensitive information. To this end, our policy specification supports two types of policies, as described below.

4.2.1. Multi-party and context-aware permissions

We extend the permission model in mobile architecture. Our new permission scheme allows developers to define and enforce context-aware properties for each party on a single granted permission. For each resource access or action, i.e., granted permission, developers can define which party can access or perform an action on that resource under a label “principal”. We support not only allowed or denied for each principal per resource, but also provide access qualifiers such as read, write, and create. We also support context-aware properties such as whitelist and bound in this permission specification. Our specification ensures that a granted permission must be monitored at runtime so that it does not compromise the security of the app and the privacy of users by any party. Our novel permission model overcomes the limitations of “all-or-nothing” conventional permission in mobile that open the possibilities for attacks, as discussed in Section 2.2.

We use JavaScript Object Notation (JSON) to specify our multi-party and context-aware permissions. We express each device resource in an array element inside a JSON file, each of which has an array of permission objects, identified by a principal (the label for a party). For each resource, developers can specify which principal can be allowed with further runtime constraints. For instance, Listing 1 illustrates an example of such multi-party permissions. This multi-party permission example allows the local code (loaded with principal “trusted.com”) to read and write on the contact resource with several restrictions. However, it only allows JavaScript code from “untrusted.com” with reading permission. JavaScript code loaded with other principals is denied access to this resource by default in this example. This specification is an extended version of our preliminary work [67], where more restrictions are defined. In particular, as shown in the example in Listing 1, a granted permission is restricted to runtime constraints such as the number of access times, duration, blacklist, or whitelist. We elaborate these new constraints as templates in Section 6. The motivation of this specification is to allow users to change the principal restrictions to enable a more customized fine-grained policy tailored to them.

Listing 1.

An abbreviated example of fine-grained permissions and policies for two origins

4.2.2. Stafeful and fine-grained security policies

Multi-party and context-aware permission can enforce policies that control code from a source to access a granted resource. However, permission-based policies cannot capture and prevent potential malicious actions. For example, permission-based policies are not possible to detect or prevent scenarios such as sensitive information leakage or UI attacks (cf. Section 2.2). In addition to the multi-party permission check, our framework also allows developers to define custom and fine-grained policies such as whitelist specification, stateful, and history-based policies. In this framework, we use JavaScript code to define these custom policies. An example of such policies is “after a principal reads the contact list, it is not allowed to send any SMS” (assume that the principal is allowed to read the contact list in principal-based permission). Listing 7 illustrates this type of policy that can prevent potential information leakage. We note that such a policy is also based on multi-party: the principal violating the policy is denied to send SMSs, but other principals can still be allowed to send SMS.

Privacy-based and custom policies. As our fine-grained policy specification can capture potential malicious actions at runtime, our framework can be used to protect the privacy of users. Since we develop our framework in JavaScript, developers can express any custom policies that cannot be generalized in rules. In Section 6, we provide wide-range policy templates in the structure of multi-party permissions presented previously. Depending on a specific app and its third-party code, developers can use all or select parts of the templates to deploy in the hybrid app. Customized policies from the templates are included at the development stage so that the policy can be enforced and customized by users at runtime.

5. Implementation

Fig. 3.

Enforcement mechanism of our HybridGuard framework.

This section describes how we implement key modules in our framework to enforce defined permissions and policies. Figure 3 illustrates the overview of the enforcement mechanism in our framework. We provide a new API, loadJSwithPrincipal(..), to load and execute a JavaScript program in a .js file under a label (principal) for each party. This new execution mechanism will ensure to mark any invocation from the loaded code with the labeled principal at runtime. Independent from the new loading mechanism, we leverage a wrapping method that forwards invocations to the guarded APIs to a reference monitor. When receiving an invocation request from a principal, the monitor will consult the policy manager to check permission and then security policies, defined in the specification presented previously. If there is no violation, the invocation is allowed and passed to the original API; otherwise, the monitor will suppress the invocation. In the next subsections, we describe the technical details of our implementation of each step.

5.1. Custom script execution with principal

As discussed, the origin of JavaScript code in hybrid mobile apps is not propagated, therefore the app developer cannot enforce policy rules based on the real origin of the invocation [83]. To solve this issue, we introduce and implement a new JavaScript API loadJSwithPrincipal(p, url) to replace the conventional script inclusion. Developers can use this API to load and execute a JavaScript file, local or remote, described in the url argument under a principal p. For example, instead of using <script src="http://example.com/ad.js"></script> to load the external JavaScript from example.com, the app developer can use the loadJSwithPrincipal(..) to load the code under a principal “example.com” as loadJSwithPrincipal("example.com","http://example.com/ad.js");.

We use CORS (Cross-Origin Resource Sharing, see: https://www.w3.org/TR/cors/) to retrieve the content of a JavaScript file in a string. CORS allows cross-domain communication based on the XMLHttpRequest object and is well-supported in hybrid mobile apps. Using CORS, we can retrieve either local files or any cross-domain remote file in the same way. We then create a new Function object with the retrieved JavaScript content. We then push the assigned principal p to a local protected stack (implemented as an array), execute the function, and pop the stack after the execution is complete. This implementation approach of loading JavaScript code is similar to our previous proposal [68]. However, we revise it to allow the loading of cross-domain scripts.

5.2. JavaScript APIs mediation

Our enforcement mechanism mediates JavaScript APIs, including the DOM/HTML5 APIs and JavaScript bridge APIs provided by hybrid frameworks or developers. This mediation method stands apart from the hybrid mobile app security literature, which only either mediates the bridge APIs, e.g., [26,83], or DOM/HTML5 APIs, e.g., [37]. The mediation mechanism monitors the invocation of the mediated APIs at runtime to control its execution based on the defined policies. We implement this monitoring mechanism by first storing the original API, and then redefining this API with a new function. This new function acts as a reference monitor for the API call and, therefore, controls the execution of this call, i.e., allow or deny based on the policies. Psuedo-code in Listing 2 illustrates the mediation mechanism for a bridge API example, the sms.send API to send SMS messages. We protect our code by placing them within an anonymous function. This protection ensures that any code outside of this scope cannot access any local variables [58,69].

Listing 2.

Illustration of mediation of API sms.send within an anonymous function

Our prototype implementation generalizes the mediation mechanism by providing an interface with three parameters: intercept(object, method, policy). In this interface, object is a device resource or DOM object, method is the method call of the API, and policy is a function to define the policy. The policy function needs to take two parameters: args, the arguments of the API call, and proceed, the function to control the execution. Calling the function proceed() within the policy function will execute the API; otherwise, the execution will be supressed. Listing 7 shows an usage example of these interfaces.

We adopt this mechanism from prior work [69]; however, we have advanced the previous work with two features that do not exist in the state-of-the-art JavaScript security solutions. First, our mediation is not only for the web APIs but also for JavaScript bridge APIs in hybrid mobile apps. Second, our implementation supports principal-based permission access control for multi-party scripts.

5.2.1. Complete mediation

One challenge in this implementation is the complete mediation of the interception that to ensure loaded JavaScript code cannot access the guarded API directly except through the monitor. For DOM/HTML5 APIs, we achieve this by capturing all possible aliases of the guarded API through its prototype inheritance chain in the monitor. There have been several known vulnerabilities in JavaScript that can be exploited in JavaScript interception implementation [48,53]. We apply the secure wrapper implementations in the literature [48] to assure that our monitor implementation is tamper-proof from potentially malicious code. In particular, we have implemented the following protections for the DOM/HTML5 APIs.

We first store the local copy of common method prototypes such as Function.prototype.apply and ensure that our code only uses these locally stored copies of the original methods. This implementation can prevent malicious code from bypassing the execution of the policy or even extracting the original method by modifying the corresponding function prototype.

We disconnect the chain of inheritance for an intercepted method by setting the __proto__ property to null. This method is to guarantee that external and malicious code cannot change the prototype of the intercepted method and extract values from a private scope.

We wrap static and dynamic aliases of a single API so that malicious cannot recover the intercepted API with these aliases. For a given method, we intercept the “root” object at the top of the prototype inheritance chain so that all the static aliases can be captured and intercepted. As being executed before other mediated scripts, our enforcement code has the advantage of intercepting all APIs that can create a window object, e.g., iframe. This method guarantees that malicious code cannot create a new window object to get the original reference of an intercepted method.

For JavaScript bridge APIs, there might be several different APIs provided by various plugins (JavaScript libraries) to access a device resource. As the app developer includes plugins to her app, she knows the specific APIs to intercept and enforce policies. Each JavaScript bridge API typically uses an internal function call to interact with the native API. For example, in Cordova, exec is the internal function to interact with Java API. To ensure that JavaScript code loaded by our framework cannot interact with the native APIs directly, we also need to intercept these internal functions.

5.2.2. Principal propagation in event handlers and dynamic code generation

Like native mobile apps, hybrid ones heavily rely on events such as user touch to trigger computation. In our framework, we capture and intercept these event channels, such as addEventListener and attachEvent, to wrap the handler functions. This interception ensures that when an event is fired, e.g., a button is touched, we execute its handler function under the same principal of its parent code. Therefore, the new code in the handler function is also enforced with the same policy for the same principal. Listing 3 illustrates this approach.

Listing 3.

Principal tracking for event handler

The same approach is applied to code generation on the fly through DOM APIs such as document.write, Node.insertBefore(..). As inline JavaScript code in HTML is not allowed by default CSP, we only need to take care of new script node inclusions in the same way as events. This mechanism is to execute any code generated at runtime as the same principal as the script that created the new code. We refer interested readers to our previous work [68] for the technical detail implementation of this approach.

5.3. Policy management and enforcement

As illustrated in Fig. 3, an invocation to a guarded API is dispatched together with its principal to the corresponding monitor. The monitor then consults the policy manager; based on the policy definition, the policy manager will decide whether to proceed with the invocation. As briefly outlined in the previous section, our framework supports principal-based permissions and stateful policies. We use JavaScript Object Notation (JSON) to specify principal-based permission for the device resource access (including DOM and JavaScript bridge APIs) by any party JavaScript code running inside the app as introduced in Section 4.2.

In our previous prototype implementation [67], we store the specification in a local JSON file within the app, and load it using XMLHttpRequest into a JSON object to perform principal-based permission checks. In this extended specification (cf. Section 4.2), we need to keep and update runtime parameters, e.g., the number of accesses; therefore, this JSON object needs to be updated and synchronized consistently. To this end, we revise the previous implementation by loading the policy template, provided at the development stage, and store it within a data directory of the app for the first time. Storing in a data directory allows our enforcement code can update the file content since all files within an app at the installation time are read-only. The first step is to check if the file is already present in the data directory. If it does not exist, we load the original JSON template file and store it in the new location. Otherwise, we use that existing file for policy checking and updating. Pseudo-code (for brevity as the real code is in an asynchronous version with more processing steps) in Listing 4 illustrates this process.

Listing 4.

Pseudo-code (for brevity) to load internal policy specification

Let us consider a scenario when a user installs a hybrid app that integrates our framework. As a norm, the user needs to grant permissions requested by the app. With our framework, ideally, the user can define more fine-grained restrictions or customized policies such as “revoke a granted permission for an origin in the app”. Also, the user should be able to customize some policy parameters to protect her own privacy. Our current implementation allows users to customize policies by editing the file content directly at runtime as we store the policy specification in a data directory. However, understanding and defining policies in JSON specification is not an easy task, especially for layman users. In the future, we plan to map this policy specification into user interfaces so that end-users can easily edit the parameters at the installation phase or runtime.

5.3.1. The policy manager

Our HybridGuard monitor intercepts API calls accessing a resource, as depicted in Fig. 3. Therefore, for each API invocation, the monitor invokes the Policy Manager module to check the policies to allow or disallow that API. The monitor code maps an API call to an action defined in the policy specification so that the Policy Manager can perform the check to return the decision.

There are two layers of checking in this Policy Manager module. An API call is allowed and executed if it passes both of these two layers. The first layer is to check the multi-party and context-aware permission in the JSON object cached in memory. We synchronize this cached object with the policy specification file stored in the data directory to ensure that all policy states are updated persistently. Our framework also performs the same synchronization mechanism when the end-user customizes existing policies on the fly. For example, when the user disallows a resource for an origin by editing the policy file content, the new content is loaded into the JSON cached object. This synchronization mechanism is to guarantee that the runtime monitor enforces the newly updated policy when the app invokes a corresponding API call.

For each policy pattern (cf. Section 6) defined in the JSON specification, we implement a corresponding function to look-up the permission based on the resource and principal (the caller) and check the policy parameters based on the context. The Policy Manager module also updates runtime parameters, such as the number of times when an API call is allowed and executed. The second layer of checking is the custom policies defined purely in JavaScript. The implementation of these checks is dependent on each policy category. In the next section, we introduce the policy patterns and templates, together with its implementation details that support this Policy Manager module.

6. Policy patterns and templates

Implemented as a reference monitor, our framework supports fine-grained security policies satisfying safety property of execution, i.e., preventing bad things from happening. These fine-grained policies can be leveraged and deployed in hybrid mobile apps to protect the privacy of users. In this section, we present a wide range of policy templates that developers can use to deploy in hybrid apps at the development stage, depending on the functionality of the app. These policy categories cannot be expressed in current coarse-grain permission models, and are novel compared to our previous work [67]. Table 1 elaborates on how these policy templates can be deployed and enforced for common device resources. These devices resources include bridge APIs, i.e., plugins provided by a hybrid development framework, and native objects shared by developers as discussed in Section 4.1. An API comprises a resource object and a method in the corresponding columns in Table 1. For example, the API to send SMS messages comprises the object “sms” (from the plugin “cordova-sms-plugin” provided by Cordova-based frameworks) and the method “send”. As illustrated in the table, this API, i.e., sms.send, can be enforced with four different policy categories. These include volume bound, duration usage, history-based, and location-based, as described in the following subsections. Listing 5 shows an example of volume bound policy for this sms.send API on two principals. We note that we have illustrated the interception this specific sms.send API in Listing 2 (Section 5.2), where the PolicyCheck function is a part of the Policy Manager module to handle these policy templates, as described in Section 5.3.1.

Table 1
List of policies can be enforced on plugins/resources

6.1. Configurable context-aware permission-based policies

In this subsection, we introduce fine-grained and context-aware policies based on permissions that end-users can personalize at the installation stage or runtime.

6.1.1. Volume bound policy

Many mobile apps abuse device resources by repeatedly invoking the resources such as reading the contact list a hundred times, as demonstrated in the litureture [24]. In some scenarios, users might want to limit the volume of resource usage, such as the number of SMS messages an app can send per day.

Our specification supports such a volume bound policy within a time unit. In our current specification, we support “day” as the time unit; however, we can extend it to support other time units such as an hour, or a week. We define this policy category in the “maxUseLimit” property. To enforce this policy category for a device resource over a principal, developers need to keep and set the value for the field "maxUseLimit" : ".." in the JSON specification, together with the field "currentUseLimit": "" with an empty value as illustrated in Listing 1 (Line 7–8). Developers can use this pattern to define policies for any device resource, as listed in Table 1. For example, developers may want to enforce a fine-grained restriction over a granted “geolocation” permission that allows local code to read it at most 5 times per day, and limits the code from “google.com” to read at most once per day. Such a policy can be specified for two different principals (“local”, and “google.com”) over a single resource “geolocation”, as illustrated in Listing 5. We note that, by default, in our enforcement mechanism, any code without principal information is disallowed access to resources even if the user has granted the corresponding permission.

Listing 5.

An example of volume bound policy

6.1.2. Duration usage policy

Mobile users might want to limit the duration that a device resource can be used to save energy or to protect their privacy. Our policy specification supports this policy category with “maxTimeLimit” property for each principal. Similar to the previous category, our current prototype implementation supports the duration per day and the time unit in minutes, although these are extensible. Similarly, developers need to keep and set the value for the field "maxTimeLimit" : ".." in the JSON specification, together with the field "currentTimeLimit": "" with an empty value. The policy specification illustrated in Listing 6 expresses a policy example in this category that allows the local code to watch the geolocation in 10 minutes and limits the code from “google.com” to watch 1 minute.

Listing 6.

An example of duration usage policy

6.1.3. Location-based policy

Some policies might be related to location, i.e., allowing a device resource access at particular places. For example, users might want to allow sending SMS messages only while the device is in domestic location. We support this policy category with a coordinate (“latitude” and “longitude” property) and a distance (“distanceAround” property), as illustrated in Listing 1.

6.1.4. Blacklist/whitelist policy

In some scenarios, a principal is allowed to invoke an API with parameters. For example, to send an SMS message, the code needs to call sms.send with the number to be sent together with other parameters. Users might want to allow (whitelist) or disallow (blacklist) a principal to send to a limited list of receivers. Our policy specification supports this type of policy with “whitelist” and “blacklist” properties, as shown in Listing 1. Developers can deploy this policy category in a hybrid app to allow end-users to customize such lists for further privacy protection.

6.2. Custom fine-grained policies

Implemented in JavaScript, our framework can enforce fine-grained policies expressed in JavaScript code that can be defined by developers at the development phase. We present several common history-based and generic web-based policies that can prevent potential attacks.

6.2.1. History-based policies

A common attack in malicious advertisements is to read sensitive user data and send it to the attacker through different channels, such as image source. Although CSP policy can prevent some of these channels, there are other channels specific to a mobile device that is not captured by CSP, such as SMS and email. Developers can prevent this potential information leakage by monitoring access to sensitive information and preventing certain APIs that are not captured by CSP and might leak data. For example, developers can define a policy such as “no SMS sending after the contact list is read” to prevent this potential phone-specific data leakage. Developers can implement this policy by intercepting the contact read action to toggle the contact read flag. If the flag is toggled when the SMS send API is invoked, the monitor will suppress the action. We illustrate this policy example in Listing 7.

Listing 7.

Example of “no SMS send after reading contact list” policy

6.3. Web-based security policies

There are several potential malicious behaviors of third-party JavaScript code. Examples of such behaviors include manipulating the DOM and creating UI attacks such as touchjacking (e.g., by creating an invisible iframe) or opening a webpage to launch a phishing attack. In our framework, in addition to the supported policies presented above, the app developer can implement any custom policies in JavaScript when intercepting HTML5/DOM APIs and JavaScript bridge APIs. In the touchjacking example, the developer can enforce a policy that disables the creation of an invisible iframe.

7. Evaluation

In this section, we report the evaluation of our HybridGuard framework, including the experiments and results on the functionality, compatibility on different hybrid app frameworks, mobile platforms, and real-world hybrid apps, the performance and overhead, and its security. We release our prototype and experimental results on https://github.com/isseclab-udayton/hybridguard2.0.

7.1. Compatibility

We evaluate the compatibility of our framework in two settings: a test suite and existing hybrid apps on an app store. First, we develop a test suite of variants of a hybrid app in multiple hybrid development platforms with standard bridge APIs to access device resources. We deploy our framework on these app variants to evaluate how our framework works in these settings. In the second evaluation setting, we want to test how our framework is compatible with existing hybrid apps in the wild. To this end, we use Android real-world hybrid apps since we can reverse engineer Android apps to inject code and rebuild the apps. We describe the experiments and their results below.

7.1.1. Test suite

We first develop a base hybrid app using four different hybrid app development frameworks, including Cordova v6.2.3, Framework7 v1.6.4, Onsen UI v2.4.2, and Intel XDK v3987. To test the functionality, we include corresponding plugins in each framework. These plugins include SMS, email, contacts, camera, geolocation, accelerometer, and file system. We list these resources and their corresponding APIs in the first and second columns of Table 1. This inclusion is to check that the base app can use common device resources. We write JavaScript code in a .js file and include it locally into the app to use the plugins to access the device resources. We also host the .js file remotely and include the remote script into the app as a third-party. We use each framework to build a variant of the app for both Android and iOS platforms and deploy them to real devices.

Before integrating our framework to the app variants, we build and deploy them to physical devices to ensure that the apps are functional on these devices. For Android, we deploy the app variants directly to a Google Pixel XL device with Android 7.1. For iOS, we use Xcode 9 to build and deploy the app variants to an iPhone 7 Plus device with iOS 10.0.1. We test these eight variants of the app on the two devices. As the Onsen UI variant does not work on the iOS device, we deploy and test them on an iOS 10.0.1 emulator. In all of these testing environments, the app functionally works as expected, and both local and remote scripts can access all of the device resources properly.

To evaluate the compatibility of our framework, we modify each original app variant to deploy the framework. We first customize the policy template for each app variant and store it in a JSON file within each app folder together with the framework library .js file. We specify the multi-party permission in the JSON file to allow/disallow some access to the resources by a principal. For simplification but still in general, we define two parties with two principals for this permission. We have performed several minor modifications in the policy code to make it consistent with the plugins and policies. We have implemented all policies introduced in the previous section. We then revise the main HTML code of the variants to include the framework library, and replace the existing script inclusion, i.e., <script src=".."></script> by the loadJSwithPrincipal function provided in our framework to load the JavaScript code with a principal, for both of the local and remote scripts, as illustrated in Section 5.1.

For this compatibility evaluation, we define policies to monitor and log the execution. This evaluation is to test if the apps integrated with our framework work as in their original versions. We then rebuild the app variants and deploy them to the devices again to test the functionality. We turn on debug messages so that we can observe all the execution logs from our framework. The logs demonstrate that our enforcement code intercepts and monitors all the calls to the device resources. Also, the principals (based on the source) are identified correctly for both local and remote scripts, and the functionality of the app variants is preserved. Among the app variants, we note that there is a minor issue in Framework7 on both Android and iOS devices, that the principals are not tracked in the same order. However, accessing the resources is functional and monitored by the policies. Figure 4 illustrates this compatibility evaluation. As we can see from the figure, our framework is compatible with every framework on the two major mobile platforms, Android and iOS.

Fig. 4.

Compatibility crossing frameworks and platforms of the modified app with HybridGuard embedded.

7.1.2. Real-world Android hybrid apps

By design, developers need to integrate our framework at the development stage to define and enforce policies. However, to evaluate the compatibility and usability of our framework, we integrate our framework into existing real-world hybrid apps. As Android apps allow us to reverse-engineer the code, we select the Android platform to test our framework. We first collect real-world Android-based hybrid mobile apps by downloading these apps in .apk files from a third-party app store (https://apkpure.com/) using a scripting program. We filter the apps to select hybrid mobile apps for our evaluation. We use the apktool tool (https://github.com/iBotPeaches/Apktool) to reverse-engineer the hybrid app APK files. This step helps in obtaining the entire web code and resources of the hybrid apps. We write a simple scripting program to identify apps that access device resources through included JavaScript files. Before integrating our framework, we rebuild these apps back to APK files to install and run on an Android device. To do this, we use the apktool tool to rebuild and then self-sign the apps with our own generated keys (we use the jarsigner tool to do this). These preparation steps allow us to select 40 Android hybrid mobile apps for our evaluation. These selected apps both include JavaScript files to access device resources and function correctly after the repackaging process without modifying the app code.

Next, we integrate our framework into these apps, following a similar step as done for the test suite described above. In particular, we copy the framework library (the HybridGuard.js file) and permission JSON file to the www folder within each app’s folder. We use the same general JSON permission for every app and define several fine-grained policies for testing. The classes of policies implemented include resource-bounds (e.g., access to SMS resource only five times a day), history-based (e.g., no network access after accessing geolocation) and white-list policies (e.g., only specific principals can write to contacts). We include the framework script into the main HTML file (usually the index.html file) and modify the script inclusions using our loading interface. We rebuild these modified apps again and install them on the same Android device to test. We successfully test on the 40 Android hybrid mobile apps, demonstrating that the apps modified with our framework preserve the developer’s intended functionality. Also, our execution logs show that our framework suppresses the calls to security-sensitive APIs that violate any policy. These results evidence that our framework is not only compatible with real-world hybrid apps, but also soundly enforce the defined policies for these apps. We publish this dataset, including the original APK files, the modified app folders with our framework, and the modified APK files on https://github.com/isseclab-udayton/hybridguard2.0/tree/master/evaluation/realAndroidapps.

7.2. Fine-grained policy enforcement

In the second round of evaluation, we revise the policies for the app variants in our test suite to evaluate whether our framework can soundly enforce these policies. Out test policies do not only log the execution but also to monitor the behaviors of the execution with fine-grained policies as provided in the templates presented in the previous section. These policy templates include multi-party and context-aware permissions in the JSON specification that can prevent the attack scenarios of abusing device resources, as identified in Section 2.2. We also define custom fine-grained policies in JavaScript. These custom policies are to prevent potential attacks such as malvertisements and sensitive information leakage as well as UI redress attacks, as also discussed in Section 2.2. To test the effectiveness of our policy enforcement framework, we modify the script code to intentionally violate the policies at some points and rebuild and deploy the apps. Experiments and logs confirm that the accesses to resources are functional until the policies are violated, demonstrating our framework enforces the defined policies correctly. For example, we enforce a volume bound policy that allows the maximum of 5 times of SMS sending, as illustrated in Listing 5. Our test code repeatedly calls the SMS sending API in every ten seconds to send an SMS message. The first five messages were successfully sent from the app and received on another phone. After that, our framework stops the execution of this SMS API and alerts a message, as shown on the left of Fig. 5. The other test cases in Fig. 5 illustrate the correct enforcement of other policy categories, including duration usage, and location-based, respectively.

Fig. 5.

Policy enforcement evaluation on different policy categories.

7.3. Performance

We evaluate our framework performance by measuring the runtime overhead posed by our policy enforcement mechanism. Typically, the runtime overhead of web-based systems like hybrid mobile apps can be measured by both in JavaScript operations, i.e., micro-benchmarks and the load or render time, macro-benchmarks [69,74]. We measure the load time of an app with and without our framework. We do not notice any slowdown as the load time of the original app and the modified app with our framework are almost identical. This result can be explained by the fact that JavaScript code in, e.g., hybrid apps, is mostly event-based, and asynchronous.1

¹
See: https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop.

For this reason, we are interested in evaluating the micro-benchmarks of operations that do not depend on triggered events, including getting the current position, acceleration, and direction. To this end, we modify the code in original app variants to execute these operations 1000 runs, to achieve high precision, and measure the time before and after the runs. For each case, we run the apps on the two devices with ten trials to get the averaged numbers.

We then integrate our framework in these apps with three different policies, including usage limit, the number of times per day, and the duration of execution time (cf., Section 6). We set very high limits in these policies to ensure that no violation will happen. Thus the operations are just executed as usual. We do the same measurements as in the original apps to get the corresponding averaged numbers. We report the overhead by showing the slowdown ratio over 1000 runs between the average execution time of each operation test with the HybridGuard-integrated app and that of the original app for each combination of a development framework and mobile platform. Table 2 shows these slowdown ratio numbers for each operation on the combination of three development frameworks (Cordova, Framework7, OnsenUI) and two mobile platforms (Android and iOS). Although our framework is compatible with Intel XDK as demonstrated in Section 7.1.1, the time measurement over 1000 runs on the app based on this framework, both the original and modified app, was inconsistent in 10 trials. Therefore, we exclude the Intel XDK framework in performance evaluation results.

Overall, the experimental results evidenced that our HybridGuard framework only poses a small additional runtime overhead on 1000 runs. Table 2 shows these numbers as slowdown ratios. Figure 6 visualize a notable runtime overhead test. Compared to similar approaches of JavaScript runtime monitors such as [74], our micro runtime overhead is very light. These overhead numbers are also in line with our prior work, such as [68,69]. However, there are no common patterns for the overhead of each operation crossing various frameworks and devices posed by our framework. In particular, for the acceleration operation, our framework has almost no overhead, crossing the three tested hybrid development frameworks and two mobile platforms. For the get current position operation, we see that the overhead of our framework for this operation is quite small for Android. At the same time, they vary in iOS for different hybrid development frameworks. For the get direction operation, our framework poses nearly no overhead for the app variants in iOS with Cordova and OnseiUI frameworks, a small overhead for all apps in Android, but surprisingly high overhead for Framework7 app in iOS. Interestingly, we have observed that each app execution time in each Android and iOS device is a significant difference. For example, our framework overhead on the acceleration operation is almost the same for Android and iOS, crossing hybrid frameworks, as shown in Table 2. However, the execution times in each platform are vastly different. In particular, an app variant in iOS executes much faster (about 70 times) than the one in Android, as visualized in Fig. 6.

Table 2

The slowdown ratio over 1000 runs of typical device resource operations. Numbers in each cell represent the slowdown ratio of an operation on a development framework (including Cordova, Framework7, OnsenUI) and mobile platform (including Android and iOS)

Resources/APIs	Cordova		Framework7		OnsenUI

	Android	iOS	Android	iOS	Android	iOS
Current Position	2.03	2.89	1.37	2.01	1.44	4.22
Acceleration	1.04	1.07	1.16	1.00	1.13	1.03
Get Direction	1.59	1.14	1.09	5.97	1.85	1.08

Fig. 6.

Overhead of the acceleration operation posed by our framework crossing development frameworks and two mobile platforms.

7.4. Security analysis

As discussed earlier, the standard Content-Security-Policy (CSP) in hybrid mobile apps can prevent potential code injections and information leakage attacks by web channels. However, CSP cannot detect and prevent information leakage with phone-related channels or attack scenarios we discussed in Section 2.2. Our HybridGuard framework provides an extra layer of protection on JavaScript code that is allowed by CSP. As required by default CSP, developers have to define each JavaScript code in a .js file, either for first-party or third-party code. HybridGuard provides a new JavaScript API to obtain the content of these .js files and execute them under a principal. This approach requires the code to run before other first-party or third-party code in the app so that our library has the highest priority to control the behaviors of the loaded code. This mechanism ensures that our enforcement code is tamper-proof. As described in the implementation section, we protect the enforcement code and security states of our framework within an anonymous function, which is inaccessible from outside code. Access to JSON policy specification files is prohibited from unauthorized principals, enforced by the monitor. Therefore, the integrity of our framework is guaranteed. We ensure the complete mediation of JavaScript web APIs by systematically exploring and mediating all their possible aliases and channels that generate JavaScript code on the fly. This protection is a known technique from prior work [48], as outlined in Section 5.2.1. For JavaScript bridge APIs provided by hybrid frameworks, we have to manually identify the possible channels for each API to ensure it is completely wrapped. As we can control the behaviors of the loaded code, any unauthorized access can be detected and prevented.

8. Conclusions and future work

In this article, we have introduced a robust and platform-independent policy enforcement framework, namely HybridGuard, for hybrid mobile apps. HybridGuard can enforce multi-party, fine-grained permissions, and policies to guard against attacks in JavaScript code in hybrid mobile apps originating from multiple parties. We define policies in JSON and develop the enforcement engine in JavaScript. Therefore, HybridGuard is platform-agnostic and is compatible with major mobile platforms and hybrid development frameworks without modifying them, as evidenced by the evaluation. We have provided a list of practical permission and policy patterns that developers can use as templates to define real policies for mitigating potential attacks and privacy violations.

Our design allows app users to customize the policy parameters for privacy protection. However, in the current prototype implementation, it only allows users to edit the specification in a raw JSON file. In future work, we plan to extend the policy system so that app users can specify their policies on a hybrid app through a graphical interface. Together with a graphical interface for policy customization, we plan to adopt a declarative approach to specifying policies without implementing them in a specific language, e.g., JavaScript. We will extend the context-aware permission-based policy specification to support more context categories such as timeframe, interval, event sequence. We also plan to construct a testbed of hybrid apps and an ontology of possible attacks. Such a testbed allows us to conduct a large-scale evaluation of real-world hybrid apps and effective security policies. Also, we want to study the developer experiences when deploying our framework so that we can improve its features and release it as an open-source tool.

Footnotes

Acknowledgments

This work was supported by The University of Dayton Research Council Seed Grants and The Dean’s Summer Fellowship Program from The University of Dayton College of Arts and Sciences. Meera Sridhar was supported by NSF CRII award #1566321. We thank the anonymous reviewers for their insightful comments and helpful suggestions. We acknowledge Rahul Rachapalli for his contribution to the preliminary version of this work.

References

Adobe Inc., Adobe PhoneGap, Online: https://phonegap.com/, accessed on 12/31/2019.

Agten,

S.V.

Acker,

Brondsema,

P.H.

Phung,

Desmet and

Piessens, JSand: Complete client-side sandboxing of third-party JavaScript without browser modifications, in: Proceedings of the 28th Annual Computer Security Applications Conference (ACSAC), 2012, pp. 1–10.

Aktug and

Naliuka, ConSpec – a formal language for policy specification, Science of Computer Programming 74(1–2) (2008), 2–12. doi:10.1016/j.scico.2008.09.004.

Ali and

Mesbah, Mining and characterizing hybrid apps, in: Proceedings of the International Workshop on App Market Analytics, WAMA 2016, 2016, pp. 50–56.

AlJarrah and

Shehab, The demon is in the configuration: Revisiting hybrid mobile apps configuration model, in: Proceedings of the 12th International Conference on Availability, Reliability and Security, ARES’17, 2017, pp. 57:1–57:10.

AlJarrah and

Shehab, CordovaConfig: A tool for mobile hybrid apps’ configuration, in: Proceedings of the 17th International Conference on Mobile and Ubiquitous Multimedia, MUM 2018, 2018, pp. 161–170.

AlJarrah and

Shehab, Closer look at mobile hybrid apps configurations: Statistics and implications, in: Advances in Information and Communication,

Arai and

Bhatia, eds, 2020, pp. 1016–1037. doi:10.1007/978-3-030-12385-7_69.

Android Developers, Permissions Overview, 2018, Latest update: August, 2018.

Apache Cordova, Architectural overview of Cordova platform, 2018, Online: https://cordova.apache.org/docs/en/latest/guide/overview/index.html, version 9.x, accessed on 12/30/2019.

10.

Apache Software Foundation, Whitelist Guide, https://cordova.apache.org/docs/en/latest/guide/appdev/whitelist/ Version 8.x. Accessed: August, 2018.

11.

Apache Software Foundation, Cordova – Security Guide, 2019, https://cordova.apache.org/docs/en/latest/guide/appdev/security/. Version: 9.x (latest). Accessed: August, 2019.

12.

Apple Developer, Requesting Permission, 2018, Accessed: August, 2018.

13.

Backes,

Gerling,

Hammer,

Maffei and

Styp-Rekowsky, AppGuard – enforcing user requirements on Android apps, in: Tools and Algorithms for the Construction and Analysis of Systems,

Piterman and

Smolka, eds, Lecture Notes in Computer Science, Springer Berlin Heidelberg, 2013, pp. 543–548. doi:10.1007/978-3-642-36742-7_39.

14.

Bai,

Wang,

Qin,

Zhang,

Wang and

Pan, BridgeTaint: A bi-directional dynamic taint tracking method for JavaScript bridges in Android hybrid applications, IEEE Transactions on Information Forensics and Security (2019), 677–692.

15.

Barth, The Web Origin Concept, https://tools.ietf.org/html/rfc6454.

16.

Biørn-Hansen,

T.-M.

Grønli and

Ghinea, A survey and taxonomy of core concepts and research challenges in cross-platform mobile development, ACM Comput. Surv. 51(5) (2018), 108:1–108:34. doi:10.1145/3241739.

17.

Biørn-Hansen,

T.-M.

Grønli,

Ghinea and

Alouneh, An empirical study of cross-platform mobile development in industry, Wireless Communications and Mobile Computing 2019 (2019).

18.

Bugiel,

Heuser and

A.-R.

Sadeghi, Flexible and fine-grained mandatory access control on Android for diverse security and privacy policies, in: Presented as Part of the 22nd USENIX Security Symposium (USENIX Security 13), 2013, pp. 131–146.

19.

Butner, How Much in Advertising Revenue Can a Mobile App Generate?, http://smallbusiness.chron.com/much-advertising-revenue-can-mobile-app-generate-76855.html.

20.

Butusov, Native vs Hybrid apps. What to choose in 2019?, 2019, Online: https://blog.techmagic.co/native-vs-hybrid-apps/, retrieved on 5/15/2019.

21.

Casimirri, Mobile Angular UI, Online: https://github.com/mcasimir/mobile-angular-ui, accessed on 12/31/2019.

22.

Chen,

Lee,

A.B.

Jeng and

Wei, DroidCIA: A novel detection method of code injection attacks on HTML5-based mobile apps, in: Proceedings of the 14th Trust, Security and Privacy in Computing and Communications (TRUSTCOM), Vol. 01, 2015, pp. 1014–1021.

23.

Facebook Inc., React – A JavaScript library for building user interfaces, https://facebook.github.io/react/.

24.

Franzen and

Aspinall, PhoneWrap-injecting the “how often” into mobile apps, in: The 1st International Workshop on Innovations in Mobile Privacy and Security (IMPS), 2011, pp. 11–19.

25.

Georgiev,

Jana and

Shmatikov, Breaking and fixing origin-based access control in hybrid web/mobile application frameworks, in: Proceedings of the 21st Annual Network and Distributed System Security Symposium (NDSS), 2014.

26.

Georgiev,

Jana and

Shmatikov, Rethinking security of web-based system applications, in: Proceedings of the 24th International Conference on World Wide Web (WWW), 2015, pp. 366–376. doi:10.1145/2736277.2741663.

27.

Goodin, Millions exposed to malvertising that hid attack code in banner pixels, 2016, http://arstechnica.com/security/2016/12/millions-exposed-to-malvertising-that-hid-attack-code-in-banner-pixels/.

28.

Google Inc., Android NDK Native APIs, https://developer.android.com/ndk/guides/stable_apis.html.

29.

Heitkötter,

Hanschke and

T.A.

Majchrzak, Evaluating cross-platform development approaches for mobile applications, in: International Conference on Web Information Systems and Technologies, Springer, 2012, pp. 120–138.

30.

Hern, Spotify hit by ‘malvertising’ in app, 2016, http://bit.ly/spotify-malvertising.

31.

Hu,

Wang,

C.-P.

Bezemer and

A.E.

Hassan, Studying the consistency of star ratings and reviews of popular free hybrid Android and iOS apps, Empirical Software Engineering 24(1) (2018), 7–32. doi:10.1007/s10664-018-9617-6.

32.

Idera Inc., Sencha Touch, 2019, Online: https://www.sencha.com/products/touch/, accessed on 12/31/2019.

33.

Imamura,

Uekawa,

Ishihara,

Sato and

Yamauchi, Web access monitoring mechanism for Android webview, in: Proceedings of the Australasian Computer Science Week Multiconference, ACM, 2018, p. 1.

34.

Integral Ad Science, Inc., Effectively influence consumers everywhere, 2016, https://integralads.com/.

35.

Intel Software, Intel XDK Release Notes, 2017, Online: https://software.intel.com/en-us/xdk/docs/release-notes-information-intel-xdk, accessed on 12/31/2019.

36.

Jin,

Hu,

Ying,

Du,

Yin and

G.N.

Peri, Code injection attacks on HTML5-based mobile apps: Characterization, detection and mitigation, in: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2014, pp. 66–77.

37.

Jin,

Wang,

Luo and

Du, Fine-grained access control for HTML5-based mobile applications in Android, in: Information Security (ISC), Springer, 2015, pp. 309–318. doi:10.1007/978-3-319-27659-5_22.

38.

Kharlampidi, Framework7 – Full Featured Framework For Building iOS, Android & Desktop Apps, Online: https://framework7.io/, accessed on 12/31/2019.

39.

Kirk, Massive Malvertising Campaign Hits MSN, Yahoo, 2016, http://bit.ly/mal-ads-msn.

40.

Kudo,

Yamauchi and

T.H.

Austin, Access control mechanism to mitigate cordova plugin attacks in hybrid applications, JIP 26 (2018), 396–405.

41.

P.T.

Lau, Scan code injection flaws in HTML5-based mobile applications, in: 2018 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW), 2018, pp. 81–88. doi:10.1109/ICSTW.2018.00032.

42.

Lee,

Dolby and

Ryu, HybriDroid: Static analysis framework for Android hybrid applications, in: Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering (ASE), 2016, pp. 250–261.

43.

P.-M.

Léger,

An Nguyen,

Charland,

Sénécal,

H.G.

Lapierre and

Fredette, How learner experience and types of mobile applications influence performance: The case of digital annotation, Computers in the Schools 36(2) (2019), 83–104. doi:10.1080/07380569.2019.1601957.

44.

Ligatti,

Rickey and

Saigal, LoPSiL: A location-based policy-specification language, in: Security and Privacy in Mobile Information and Communication Systems: First International ICST Conference, MobiSec 2009, Turin, Italy, June 3–5, 2009, Revised Selected Papers,

A.U.

Schmidt and

Lian, eds, Springer Berlin Heidelberg, Berlin, Heidelberg, 2009, pp. 265–277. doi:10.1007/978-3-642-04434-2_23.

45.

Looper, What is a WebView?, 2015, http://developer.telerik.com/featured/what-is-a-webview/.

46.

M.T.

Louw,

K.T.

Ganesh and

V.N.

Venkatakrishnan, AdJail: Practical enforcement of confidentiality and integrity policies on web advertisements, in: Proceedings of USENIX Security’10, USENIX Association, Berkeley, CA, USA, 2010, pp. 24–41. ISBN 888-7-6666-5555-4. http://dl.acm.org/citation.cfm?id=1929820.1929852.

47.

M.T.

Louw,

P.H.

Phung,

Krishnamurti and

V.N.

Venkatakrishnan, SafeScript: JavaScript transformation for policy enforcement, in: Proceedings of the 18th Nordic Conference on Secure IT Systems (NordSec 2013), 2013, pp. 67–83.

48.

Magazinius,

P.H.

Phung and

Sands, Safe wrappers and sane policies for self protecting JavaScript, in: Proceedings of the 15th Nordic Conference in Secure IT Systems (NordSec), 2010, pp. 239–255.

49.

Manchanda, Where Do Cross-Platform App Frameworks Stand in 2020?, 2019, Online: https://www.netsolutions.com/insights/cross-platform-app-frameworks-in-2019/, accessed on 12/30/2019.

50.

Mao,

Ma,

Chen,

Jia and

Liang, Automatic permission inference for hybrid mobile apps, Journal of High Speed Networks 22(1) (2016), 55–64. doi:10.3233/JHS-160538.

51.

Mao,

Wang,

Chen and

Jia, Detecting injected behaviors in HTML5-based Android applications, Journal of High Speed Networks 22(1) (2016), 15–34. doi:10.3233/JHS-160534.

52.

B.S.

Max Lynch and

Bradle, Ionic Framework, Online: https://ionicframework.com/, accessed on 12/31/2019.

53.

L.A.

Meyerovich and

Livshits, ConScript: Specifying and enforcing fine-grained security policies for javascript in the browser, in: 2010 IEEE Symposium on Security and Privacy, IEEE, 2010, pp. 481–496. doi:10.1109/SP.2010.36.

54.

Microsoft Corp., Visual Studio Tools for Xamarin – Deliver native Android, iOS, and Windows apps with a single shared .NET code base, Online: https://visualstudio.microsoft.com/xamarin/, accessed on 12/31/2019.

55.

Microsoft Development Network (MSDN), Cordova whitelist and Content Security Policy guide, https://taco.visualstudio.com/en-us/docs/cordova-security-whitlists/#the-w3c-content-security-policy-csp.

56.

Microsoft Development Network (MSDN), Cordova whitelist and Content Security Policy guide, https://taco.visualstudio.com/en-us/docs/cordova-security-whitlists/#the-w3c-content-security-policy-csp.

57.

Mozilla Development Network, Content-Security-Policy, https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy.

58.

Musch,

Steffens,

Roth,

Stock and

Johns, ScriptProtect: Mitigating Unsafe Third-Party JavaScript Practices (2019).

59.

Mutchler,

Doupé,

Mitchell,

Kruegel and

Vigna, A large-scale study of mobile web app security, in: Proceedings of the Mobile Security Technologies Workshop (MoST), 2015.

60.

Nakhaei,

Ansari and

Ansari, JSSignature: Eliminating Third-Party-Hosted JavaScript Infection Threats Using Digital Signatures, arXiv preprint arXiv:1812.03939 (2018).

61.

Nauman,

Khan and

Zhang, Apex: Extending Android permission model and enforcement with user-defined runtime constraints, in: Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security, ACM, 2010, pp. 328–332.

62.

Ongtang,

McLaughlin,

Enck and

McDaniel, Semantically rich application-centric security in Android, Security and Communication Networks 5(6) (2012), 658–673. doi:10.1002/sec.360.

63.

Onsen UI, Online: https://onsen.io/v2/guide/, accessed on 12/31/2019.

64.

OWASP, Clickjacking, https://www.owasp.org/index.php/Clickjacking.

65.

Peranzo, App Development Decisions: Native App Vs Web App Vs Hybrid?, 2018, Online: https://www.imaginovation.net/blog/app-development-decisions-native-web-or-hybrid/, retrieved on 5/15/2019.

66.

P.H.

Phung and

Desmet, A two-tier sandbox architecture for untrusted JavaScript, in: Proceedings of the Workshop on JavaScript Tools (JSTools), 2012, pp. 1–10.

67.

P.H.

Phung,

Mohanty,

Rachapalli and

Sridhar, Hybridguard: A principal-based permission and fine-grained policy enforcement framework for web-based mobile applications, in: Proceedings of 2017 IEEE Security and Privacy Workshops (SPW) – Mobile Security Technologies (MoST), IEEE, 2017, pp. 147–156. doi:10.1109/SPW.2017.34.

68.

P.H.

Phung,

Monshizadeh,

Sridhar,

K.W.

Hamlen and

V.N.

Venkatakrishnan, Between worlds: Securing mixed JavaScript/ActionScript multi-party web content, IEEE Transactions on Dependable and Secure Computing (TDSC) 12(4) (2015), 443–457. doi:10.1109/TDSC.2014.2355847.

69.

P.H.

Phung,

Sands and

Chudnov, Lightweight self-protecting JavaScript, in: Proceedings of the 4th International Symposium on Information, Computer, and Communications Security (ASIACCS), 2009, pp. 47–60.

70.

Pooryousef and

Amini, Fine-grained access control for hybrid mobile applications in Android using restricted paths, in: Proceedings of the 13th International ISC Conference on Information Security and Cryptology (ISCISC), 2016.

71.

Pouryousef,

Rezaiee and

Chizari, Let me join two worlds! Analyzing the integration of web and native technologies in hybrid mobile apps, in: 2018 17th IEEE International Conference on Trust, Security and Privacy in Computing and Communications/ 12th IEEE International Conference on Big Data Science and Engineering (TrustCom/BigDataSE), 2018, pp. 1814–1819.

72.

Progress Software, NativeScript: Create Native iOS and Android Apps with JavaScript, Online: https://www.nativescript.org/, accessed on 12/31/2019.

73.

Qiu, Tapjacking: An Untapped Threat in Android, https://blog.trendmicro.com/trendlabs-security-intelligence/tapjacking-an-untapped-threat-in-android/. Accessed on 01-09-2012.

74.

Reis,

Dunagan,

H.J.

Wang,

Dubrovsky and

Esmeir, BrowserShield: Vulnerability-driven filtering of dynamic HTML, ACM Transactions on the Web (TWEB) 1(3) (2007), 11. doi:10.1145/1281480.1281481.

75.

Rouse, Malvertisement (malicious advertisement or malvertising), 2011, http://searchsecurity.techtarget.com/definition/malvertisement-malicious-advertisement-or-malvertising.

76.

Shehab and

AlJarrah, Reducing attack surface on Cordova-based hybrid mobile apps, in: Proceedings of the 2nd International Workshop on Mobile Development Lifecycle (MobileDeli), 2014, pp. 1–8.

77.

Singh, Practical context-aware permission control for hybrid mobile applications, in: Proceedings of the 16th International Workshop on Recent Advances in Intrusion Detection (RAID), 2013, pp. 307–327.

78.

Stack Overflow, Developer Survey 2019, Online: https://insights.stackoverflow.com/survey/2019, accessed on 12/30/2019.

79.

The jQuery Foundation, jQuery Mobile – A Touch-Optimized Web Framework, 2019, Online: https://jquerymobile.com/, accessed on 12/31/2019.

80.

Tiwari,

Prakash,

Groß and

Hammer, LUDroid: A large scale analysis of Android–Web hybridization, in: 2019 19th International Working Conference on Source Code Analysis and Manipulation (SCAM), IEEE, pp. 256–267.

81.

TouchstoneJS – JS – Creating Your Visual Interaction, Online: https://touchstonejs.io/, accessed on 12/31/2019.

82.

Tran,

Pelizzi and

Sekar, JaTE: Transparent and efficient JavaScript confinement, in: Proceedings of the 31st Annual Computer Security Applications Conference, ACSAC 2015, 2015, pp. 151–160. ISBN 978-1-4503-3682-6.

83.

G.S.

Tuncay,

Demetriou and

C.A.

Gunter, Draco: A system for uniform and fine-grained access control for web code on Android, in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2016, pp. 104–115. ISBN 978-1-4503-4139-4.

84.

Van Acker,

De Ryck,

Desmet,

Piessens and

Joosen, WebJail: Least-privilege integration of third-party components in web mashups, in: Proceedings of the 27th Annual Computer Security Applications Conference, ACSAC’11, 2011, pp. 307–316. ISBN 978-1-4503-0672-0.

85.

van Ginkel,

De Groef,

Massacci and

Piessens, A server-side JavaScript security architecture for secure integration of third-party libraries, Security and Communication Networks 2019 (2019).

86.

Wikipedia Contributors, Mobile development framework – Wikipedia, The Free Encyclopedia, 2019, Online: https://en.wikipedia.org/w/index.php?title=Mobile_development_framework&oldid=933163995, accessed on 12/30/2019.

87.

Willocx,

Vossaert and

Naessens, Security analysis of cordova applications in Google play, in: Proceedings of the 12th International Conference on Availability, Reliability and Security, ARES’17, 2017, pp. 46:1–46:7.

88.

Xiao,

Yan,

Ye,

Li,

Peng and

Jiang, Detection and prevention of code injection attacks on HTML5-based apps, in: Proceedings of the 3rd International Conference on Advanced Cloud and Big Data (CBD), 2015, pp. 254–261.

89.

Yan,

Xiao,

Hu,

Peng and

Jiang, New deep learning method to detect code injection attacks on hybrid applications, Journal of Systems and Software 137 (2018), 67–77. doi:10.1016/j.jss.2017.11.001.

90.

Yang,

Huang,

Gu and

Mendoza, Study and mitigation of origin stripping vulnerabilities in hybrid-postMessage enabled mobile applications, in: 2018 IEEE Symposium on Security and Privacy (SP), 2018, pp. 742–755. doi:10.1109/SP.2018.00043.

91.

Yang,

Mendoza,

Zhang and

Gu, Precisely and scalably vetting JavaScript bridge in Android hybrid apps, in: RAID, 2017.

92.

Zamora, Truth in malvertising: How to beat bad ads, 2017, http://bit.ly/how-to-beat-bad-ads.

A multi-party,fine-grained permission and policy enforcement framework for hybrid mobile applications

Abstract

Keywords

1. Introduction

2. Background

2.1. Hybrid mobile application architecture

2.3. Existing security mechanisms in hybrid mobile apps

2.4. HybridGuard threat model

3. Related work

3.1. Third-party JavaScript isolation

3.2. Fine-grained policy enforcement in mobile apps

3.3. Hybrid mobile application security

3.3.1. Access control systems/frameworks

3.3.2. Detecting and preventing code-injection

3.3.3. Security analysis and surveys

4. System design

4.1. Overview of the HybridGuard framework

4.2.1. Multi-party and context-aware permissions

5. Implementation

5.2. JavaScript APIs mediation

5.2.2. Principal propagation in event handlers and dynamic code generation

6. Policy patterns and templates

Table 1 List of policies can be enforced on plugins/resources

6.1.1. Volume bound policy

6.1.4. Blacklist/whitelist policy

6.2. Custom fine-grained policies

6.2.1. History-based policies

7. Evaluation

7.1. Compatibility

7.1.1. Test suite

7.2. Fine-grained policy enforcement

1 See: https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop.

8. Conclusions and future work

Footnotes

Acknowledgments

References

Table 1
List of policies can be enforced on plugins/resources

¹
See: https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop.