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

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).

OPEN IN VIEWER

Fig. 1.

Architecture of hybrid mobile apps.

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.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.

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.

OPEN IN VIEWER

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.

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.

OPEN IN VIEWER

Listing 1.

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

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].

OPEN IN VIEWER

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.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.

OPEN IN VIEWER

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.

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.

OPEN IN VIEWER

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.

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.

OPEN IN VIEWER

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.

OPEN IN VIEWER

Listing 6.

An example of duration usage policy

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.

OPEN IN VIEWER

Listing 7.

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

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.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.

OPEN IN VIEWER

Fig. 4.

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

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.

OPEN IN VIEWER

Fig. 5.

Policy enforcement evaluation on different policy categories.

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

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.

OPEN IN VIEWER

Fig. 6.

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

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.