PhoneWrap - Injecting the “How Often” into Mobile Apps Daniel Franzen David Aspinall LFCS, University of Edinburgh LFCS, University of Edinburgh D.Franzen@ed.ac.uk David.Aspinall@ed.ac.uk should only access my contacts when I open the app. Deleted that app is what I did.”[9] A policy based on Abstract the least-privilege principle should specify how often and in which context a resource can be accessed. Mobile apps have access to a variety of sensi- At the same time, we see a rise of JavaScript as tive resources and data. Current permission- a programming language for mobile devices. Mobile based policies guarding these resources are not operating systems like Tizen and ChromeOS building expressive enough to distinguish the wanted directly on JavaScript are emerging, but frameworks, functionality from malicious attacks. We such as PhoneGap [1], utilising a built-in browser to present the tool PhoneWrap which inserts execute JavaScript and HTML apps on established op- fine-grained ticket-based policies into mobile erating systems are widely adopted by developers al- JavaScript apps written with the PhoneGap ready. framework. Our policies grant a bounded In this paper, we introduce PhoneWrap, a tool to number of accesses for each functionality provide more expressive policies for JavaScript apps. based on the user’s interaction with the app. PhoneWrap manages a set of tickets via an inline ref- The policies are enforced without modification erence monitor; it requires one ticket for each resource of the execution environment. We have ap- access. Tickets are either granted at launch or gen- plied PhoneWrap successfully to hand-crafted erated according to the user’s interaction with the examples and real-world Android apps to app to allow user-requested functionality. Special local show that accurate policies can be retrofitted. tickets are only valid during the processing of a spe- cific user event. If access is requested without tickets, 1 Introduction PhoneWrap executes a denial behaviour. Modern mobile devices have access to private data, 1.1 Wrapping sensors and services. Mobile operating systems like Android and iOS govern access with permissions which PhoneWrap enforces its policies by “wrapping” the that are either fully granted ahead of time, or can be resource-consuming APIs, inspired by Phung et switched on or off during use in limited ways. Neither al’s Self-Protecting JavaScript [15]. Each resource- mechanism allows precise fine-grained control on how consuming function is provided with a a resource- often or in which context a granted resource may be counting instrumented version, and references to the used. But when users notice resources being overused original are replaced. Subsequently, application code in the wrong context, they react. A user of a permis- can only access the instrumented API which, depend- sion usage monitoring app complained: “Why would ing on the policy state, either calls the original API WhatsApp access my contacts over 7000 times [...]. It or a deny behaviour. To isolate the original func- tion and the policy state from the application code, Copyright c by the paper’s authors. Copying permitted for the policy is implemented inside a function scope in private and academic purposes. This volume is published and which PhoneWrap stores the policy state and the orig- copyrighted by its editors. inal resource consuming APIs as local variable. The In: D. Aspinall, L. Cavallaro, M. N. Seghir, M. Volkamer (eds.): Proceedings of the Workshop on Innovations in Mobile Privacy JavaScript scope mechanism ensures that local vari- and Security IMPS at ESSoS’16, London, UK, 06-April-2016, ables cannot be accessed from outside the function published at http://ceur-ws.org body; this ensures that the policy is enforced. 11 1 1.2 Motivating example • A violating access can be replaced by any JavaScript definable function. The app “TrackMyVisit” (Figure 1) manages a list of journeys. While a journey is active, the app logs the Previously, inlined reference monitors were used GPS position and sends a message to up to 3 specified to implement different policies for JavaScript [15] contacts in case of an emergency. Furthermore the app and Android apps [2]. Quantitative policies [6] or can store pictures for each journey. This functional- interaction-dependent policies [18] have been stud- ied separately. PhoneWrap is, to the best of our knowledge, the first system which enforces quantita- tive interaction-dependent policies for JavaScript apps in an unmodified execution environment. The remainder of this paper is structured in the following way. Section 2 will discuss the interaction- dependent ticket-based policies. Section 3 presents an overview of the PhoneWrap system. Section 4 presents the results of the evaluation on real-world apps and Section 5 discusses related work. Finally, Section 6 concludes by discussing the results and limitations of the current system. Figure 1: TrackMyVisit (myzealit.TMV.apk) ity requires Android permissions to take pictures, to 2 Interaction-dependent Ticket-based access the GPS position and to send messages. How- Policies ever, these permissions could be abused to invade the user’s privacy, to send personal data, to impersonate PhoneWrap enforces bounds on the resource consump- the user or to charge for premium messages. The per- tion based on tickets, each “paying” for one-time ac- missions model is not fine-grained enough to deny this cess to the guarded resource. Tickets are granted at potential malicious behaviour while preserving the ex- launch and for specific UI events to allow the func- pected functionality. PhoneWrap can enforce that the tionality activated by the interaction. Tickets can be GPS sensor is only accessed while a journey is active. specified as local to a UI event to limit their scope this It grants exactly one camera ticket for each time the event. Unused local tickets are cancelled after all event “Add Image” button is pressed and 3 message tickets handlers for that event have been executed. for the “Emergency” button. The latter tickets are marked as local and are cancelled once this emergency 2.1 Policy Model routine has been performed to ensure that unused tick- The policies considered here react to API calls and user ets cannot be abused later. events e ∈ UIEvents = {click, mousedown, ...} includ- ing the special event start ∈ UIEvents. JavaScript’s 1.3 Contribution “Run-to-completion” model guarantees that each user This paper presents the following: event e is handled before the next user event is ex- ecuted. The properties of the policies consider the • a formalisation of interaction-dependent ticket- resource consumption of traces. based policies; • the PhoneWrap system, which semi-automatically Definition 2.1. 1. Let a R be the set of resource injects a policy into PhoneGap apps; accessing APIs and • a small-scale evaluation of PhoneWrap. RM : API → {0, 1} : RM (f ) = 1 ⇔ f ∈ R Previous research has established that apps are often be called the resource model. over-privileged [3] and use resources differently than the user expects [11]. (For more related work, see Sec- 2. Let BP be a set of button policies. Each bp ∈ BP tion 5.) PhoneWrap fixes both issues by enforcing ex- consists of a triple (cond , mperms, local ), indicat- plicit resource bounds. The enforced policies have the ing mperms tickets will be generated for each following features: event matching the condition cond . The flag local of bp indicates whether the generated tickets is lo- • Access can be granted or revoked according to cal to the event. user interaction. • Each resource can be restricted to a finite number 3. From a set of button policies BP , the policy pol = of accesses. (pol l , pol g ) is a pair of functions that describes the 12 2 local and global tickets generated by each event, From this definition some desirable properties for a defined as: P policy follow: pol l (e) = bp∈BP bp.mperms bp.local bp.cond(e) 1. The resource consumption of a conforming trace pol l (start) = 0P w = w1 , w P2 , ... is bounded by the policy: pol g (e) = bp∈BP bp.mperms cres (w) < poll (e) + polg (e). ¬bp.local wi =E(e) bp.cond(e) pol g (start) = m0 2. Since w|pol conforms with pol, the enforced trace where m0 is the number of tickets granted by is bounded by this bound. PhoneWrap at launch. Definition 2.2. 1. We distinguish the following 3. Functionality conforming with the policy is pre- policy events: served: w|pol = w if w conforms with pol. (a) API (f ): the API f is called (b) E(e): the event e ∈ UIEvents occurred 2.2 Policy Specification (c) Done(e) the event e has been processed A PhoneWrap policy consist of 3 parts: (1) the 2. We define a trace as the possibly infinite sequence guarded resource (2) the button policies (3) the deny w1 , w2 , ... of policy events occurring during an ex- behaviour. ecution of an app P . PhoneWrap guards services (phone calls, messages or social network interaction), sensors (microphone, 3. For each finite prefix w1 , ..., wk of a trace w define camera, GPS location) or content (contact and cal- the resource count cres by: ender data, conversations, documents, pictures). A X cres (w1 , ..., wk ) = RM (f ) resource is specified by its APIs, for example, the API wi =API (f ) smsplugin.send which sends SMS messages. This de- termines R and therefore RM . 4. Let w|e be the sub-trace E(e), ..., Done(e) of w. The button policies in PhoneWrap are defined as 5. Define the ticket count ctic of a trace w1 , ..., wk the triples (cond, mperms, local). The condition cond recursively as is defined by the HTML properties of the target el- ctic () =0 ement of the event. In the “TrackMyVisit” exam- ctic (w0 , API (f )) = ctic (w0 ) − RM (f ) ple, the button with the icon path src ending in ctic (w0 , E(e)) = pol l (e) + pol g (e) + ctic (w0 ) images/emergency icon2.png generates 3 tickets for 0 ctic (w , Done(e)) = min (0, cres (w|e ) − pol l (e)) each click. +ctic (w0 ) Finally, the policy defines the deny behaviour which with w = (w0 , Done(e)) in the last case is executed in case of an attempted policy violation. It is defined as a JavaScript function with access to the Intuitively, ctic tracks the number of available tick- policy state. This enables many possible reactions ad- ets. It subtracts tickets for each API call and adds justed for the guarded resource, e.g., terminating the them if an event occurs. After an event is handled, app, ignoring the resource request, returning dummy it subtracts local tickets if they have not been used values or inquiring with the user. To match the for- within the event scope. Not that due to JavaScript’s mal definition of enforced traces, the deny behaviour “Run-to-completion” model event traces cannot be is set to exit(0) to terminate the execution on policy nested. violation. We say a trace w = w1 , w2 , ... conforms with the PhoneWrap policies include many other classes of policy pol if there is no i such that ctic (w1 , ..., wi ) < 0. policies. By granting infinitely-many local/global tick- Definition 2.3. Given a trace w and a policy pol, ets for each user interaction, PhoneWrap can enforce let the enforced trace w|pol be the longest conforming “no resources in the background” and “only after first prefix of w: interaction” policies. With the deny behaviour set to display a confirmation dialog and to grant 1 or (w1 , w2 , ...)|pol = w1 , ..., wi ∞ many tickets when confirmed the policy is equiv- where i is the smallest index with ctic (w1 , ..., wi+1 ) < 0 alent to OneShot or Session permissions in J2ME or and the iOS operating system. PhoneWrap can also deny (w1 , w2 , ...)|pol = w1 , w2 , ... access completely like the Android system when the if no such i exists. corresponding permission is missing. 13 3 3 The PhoneWrap system way that they show their properties during the nor- mal interaction with the app. To check a given pol- The PhoneWrap system has been developed with the icy PhoneWrap can highlight all effected UI elements. following core aims: The deny behaviour is specified as a JavaScript func- Usability PhoneWrap is aimed at users with a basic tion. The whole policy can be written in JavaScript understanding of the user interface and resource or using PhoneWrap’s HTML form shown in Figure 3 behaviour of the guarded app and the ticket-based which embeds the policy parameters into full English policies. We do not assume knowledge of the sentences. app’s source code or the PhoneWrap’s enforce- ment method. 3.1 Policy enforcement Stand-alone PhoneWrap is contained within the PhoneWrap provides the wrapper script which con- guarded app. Modifications of the execution en- tains the policy and the code to wrap the necessary vironment or the Android system require root ac- functions according to [15]. For each call to the criti- cess to the phone which undermines important cal APIs, PhoneWrap decreases one of the two coun- security principles and many users are not able or ters mperms local and mperms global which indicate willing to make this modification. the number of available local / global tickets. Local tickets are used with preference. If no ticket is avail- Real-world The enforcement of PhoneWrap has to able, PhoneWrap calls the specified deny behaviour in- work on apps executable on real mobile phones. stead. Additionally, PhoneWrap listens for UI events at the root of the DOM-tree. Since every event is first An app is fitted with a policy in 5 steps (see Fig- evaluated at the root node, PhoneWrap receives all UI ure 2): (1) unpacking, (2) information extraction, (3) events this way. When PhoneWrap receives a match- policy creation, (4) injection and (5) repackaging. For ing event, it uses setTimeout with 0 seconds to insert steps (1) and (5), PhoneWrap uses the available tools a callback into the HTML event handler queue behind adb, zip and apktool. Unfortunately, the policy in- all handlers for this event. As a consequence, this call- jection invalidates the developer signature of the origi- back is executed after all handlers have finished and nal package. PhoneWrap resigns the modified package cancels all remaining local tickets. with a new key, the policy key. Assuming the policy All code necessary for the enforcement is contained creator verifies the original signature, this new policy in one JavaScript file which is inserted into the header signature certifies the integrity of the original package of the main HTML file. When executed, the file im- and the injected policy. In isolated cases the signa- mediately wraps all available critical APIs. ture can be vital to the functionality of the app. Apps Most PhoneGap APIs to access the resources are that were signed with the same key originally should provided as plugin and implemented as Java class. be signed with the same key after policy injection such Each plugin provides a JavaScript API which inter- that inter app communication is preserved. In isolated nally calls its Java API using the PhoneGap bridge cases, for example for the Google Maps web API, a li- exec. Additionally, PhoneGap uses the require func- cense can be linked to the signature. In this case, the tion to obtain the JavaScript API. PhoneWrap wraps policy creator would need to obtain a new license for the JavaScript API but also wraps the functions exec the policy key. and require in case the application code calls them di- For the information extraction, the PhoneWrap rectly. The wrapped versions of these functions check script m20 analyse finds the Android manifest and the whether the requested API accesses the guarded re- PhoneGap configuration file according to the package source and enforces the policy. layout. From these files PhoneWrap extracts the re- Different PhoneGap APIs become available at dif- quested permissions and PhoneGap plugins used to ferent times in the app’s life cycle. Some are avail- access the resources as well as the main source file able from the start, others after the PhoneGap library and source folder. The injection step inserts the has been loaded or initialised and some are defined PhoneWrap enforcement script into this main HTML in a separate source file. PhoneWrap uses JavaScript folder and links it into the main HTML file using the methods to recognise these situations and immediately HTML src tag. wraps all available APIs. Since it is not trivial to de- The policy creation requires human action. The termine whether an API has been wrapped already, policy creator has to identify the guarded APIs from PhoneWrap re-wraps all APIs multiple times. For ex- the extracted permissions and plugins and specify the ample, if the function smsplugin.send has already UI elements for the button policies. PhoneWrap as- been wrapped and a new source file is loaded into the sist the latter by instrumenting all buttons in such a app, PhoneWrap re-wraps smsplugin.send since the 14 4 Resources UI elements unpack extract create inject pack policy Figure 2: Policy injection Each event is first passed to the root node and the JavaScript standard executes event handlers in the or- der of registration. Finally, the policies enforced by PhoneWrap imple- ment the formal model of interaction-dependent ticket- based policies described earlier: Lemma 3.4. Given the definition of RM and pol g , pol l in Section 3, the PhoneWrap counters mperms global+mperms local after execution of the trace w are equal to ctic (w). Proof. This can be proven by induction on the length of the trace w. The only interesting case is w = Figure 3: Policy Creation Form (w0 , Done(e)): new source file could have redefined this API. This be- • Assume after w0 the counters are equal to ctic (w0 ). haviour might result in a second wrapping layer around • Done(e) means PhoneWrap sets the counter smsplugin.send. However, in this case the outer lay- mperms local to 0. ers do not subtract additional tickets, which ensures • cres (w|e ) is the resource consumption of the the that each API call is only paid by 1 ticket. As final scope of the event e. ⇒ During the execution of fortification, PhoneWrap prevents the app from gen- w|e PhoneWrap has decreased the counters (with erating additional tickets by simulating user events. preference on mperms local) cres (w|e ) times. 3.1.1 Policy security properties If cres (w|e ) ≥ pol l (e), PhoneWrap has already reduced mperms local to 0, so the event Done(e) does not Claim 3.1. The application code cannot change the change the counters. By the definition of ctic it follows state of the policy. min(0, cres (w|e ) − pol l (e)) = 0 ⇒ ctic (w) = ctic (w0 ). Justification. JavaScript protects the local variables Otherwise, if cres (w|e ) < pol l (e), mperms local has of the policy function, including the policy state, from pol l (e) − cres (w|e ) tickets left to cancel. Similarly access outside the policy function. min(0, cres (w|e ) − pol l (e)) = −(pol l (e) − cres (w|e )) and therefore ctic (w) = ctic (w0 ) − (pol l (e) − cres (w|e )). Claim 3.2. The application code cannot access the Claim 3.5. PhoneWrap implements a ticket-based original API directly. policy for the default-deny behaviour exit(0) (termi- Justification. The PhoneWrap script is inserted at the nate execution). top of the header of the main HTML file. Therefore, Justification. This claim follows from the preceding it is executed before any other scripts and overwrites Lemma and the fact that the deny behaviour exit(0) all API references specified in the policy. The original replaces the first API call resulting in a non-positive references are protected like the policy state. In par- ticket count with the terminating statement equivalent ticular, JavaScript’s dynamic scoping means that also to w|pol . all libraries internally calling the resource API only PhoneWrap can also define more complex deny be- have access to the wrapped API. haviours. This makes it possible to execute parts of Claim 3.3. The tickets for a UI element are produced policy-violating apps. With different deny behaviours before the resource consuming action occurs. the claimed properties still hold. However, the be- haviour of violating traces might be changed arbitrar- Justification. The PhoneWrap script is executed ily if the continuation after a policy violation depends first and registers the first listener at the root node. on the result of the violating action. 15 5 PhoneWrap can be used to inject multiple policies for the dialogs. To incorporate dialogs into policies, into the same app to restrict the use of multiple re- PhoneWrap instruments the dialog APIs and wraps sources or policies of different parties (developer, dis- the callback functions of each dialog. If a button policy tributor, user). PhoneWrap inserts multiple wrapper specifies a list of captions in the confirm parameter, scripts into the DOM tree, each executing the pre- PhoneWrap, rather than granting the specific number viously injected wrapper if its own policy is fulfilled. of tickets for this UI event, only reserves them. If in the The application code only has access to the outermost subsequent dialog a button with one of the specified wrapper and the original API is only called if all in- captions is pressed, the reserved tickets are granted. jected policies accept the behaviour. Since each wrap- If the user presses a dialog button not specified in the per is executed in its own function scope, the different confirm list, PhoneWrap deletes all reserved tickets. wrappers cannot access each others’ policy state. Due to this fact, the final decision whether to execute an 4 Evaluation original API f is independent of the order in which The following evaluation was set to answer the follow- the policies are injected into the app. In this way, ing two questions: PhoneWrap is completely modular. The precision of the enforced behaviour only de- 1. Does PhoneWrap restrict the resource behaviour pends on the specification of the policy. By describ- to the claimed bounds? ing the granting UI elements with enough properties 2. Can the expected behaviour of real-world apps be e.g. their icon, caption, colour or opacity PhoneWrap described by PhoneWrap policies? makes sure that the app cannot generate tickets by making the user interact with harmless looking but- For the first question we applied PhoneWrap to a tons. In practice, actual end users might rely on third specifically crafted app which executes various code parties to perform this policy creation step to provide a snippets to circumvent PhoneWrap’s wrapping and ac- policy file which PhoneWrap can insert into the pack- cess the vibration service. The vibration feature of the age automatically or a full package with a custom pol- phone was chosen as the resource, for its immediate icy injected. effect. We fitted this app with a policy allowing the vibration only for a control button. PhoneWrap was 3.1.2 Real-world resource behaviour able to successfully deny access to the resource while the control button preserved its functionality and func- PhoneWrap policies also include a few features to bet- tionality independent of the vibration was preserved as ter capture the resource behaviour of real-world apps. well. First, the policy state contains the additional For the second question we applied PhoneWrap to switches blockAll and allowAll. They can be set a set of real-world apps. From the test set of 8757 in the starting state of the policy and overwritten by PhoneGap app packages PhoneWrap can inject a pol- any button policy. If the first switch is set, all access icy into 6843 (78%). The remaining apps either use is denied independent of the ticket state. Otherwise, if a very early version of PhoneGap where the package allowAll is set, all access is allowed. The tickets are structure was not fixed yet or include the PhoneGap only subtracted if neither of the switches is set. This library without using the PhoneGap framework. Most way, access to the GPS location in the example app earlier versions of PhoneGap could be injected using “TrackMyVisit” can be granted unconditionally when PhoneWrap by manually adopting the wrapping script the user starts a journey. to the version. Second, other apps, for example, send messages to We chose the messaging service as test resource each contact the user has marked in a list of check- since it is used in real apps with verifiable and quantifi- boxes. The consumption is therefore equal to the num- able result on the user’s privacy and phone bill. In the ber of selected checkboxes. In PhoneWrap’s button candidate set we found only 10 apps sending messages policies, a UI element can be identified as a checkbox through a PhoneGap plugin, which were subjected to which instructs PhoneWrap to grant tickets when the a closer examination. The behaviour of these apps was box is checked and revoke the tickets when the user inspected manually to identify the resource behaviour, unchecks the box. PhoneWrap was applied to the app to enforce the iden- Finally, some of the real-world examples try to make tified behaviour and the behaviour of the modified app the user aware of the resource consumption by dis- was manually verified. Since PhoneGap does not of- playing a confirmation dialog. The resource is only ac- fer a default messaging plugin, we found 5 different cessed if the user presses the confirming button. How- PhoneGap messaging plugins with different APIs1 . ever, confirmation dialogs are not part of the DOM 1 more details on the apps and APIs: tree and, therefore, PhoneWrap does not receive events https://github.com/DFranzen/PhoneWrap 16 6 4.1 Results of Real-World Evaluations cess Control Gadgets [18] propose similar interaction- dependent policies. However, rather than augment- We were able to describe the resource behaviour ing UI elements of the app itself to generate tickets, and the required bounds for all 10 apps precisely they require each library to provide special permission after a few minutes of interaction with the app. granting UI elements which can be embedded into the The resulting PhoneWrap policies are summarised app. Furthermore, their approach requires a modified in Figure 4. The policy for “TrackMyVisit” (9) execution environment to capture the events and pro- is shown in Figure 5, all other policies are avail- tect the privileged UI elements. able at https://github.com/DFranzen/PhoneWrap. There are several other frameworks to enforce poli- It shows that each button with an icon end- cies for JavaScript. Compared to our approach, they ing in either images/emergency icon.png or either do not take user input into account [12, 4] or images/emergency icon2.png generates 3 lo- modify parts of the operating system or the browser cal tickets per click when confirmed by the [16, 14, 8, 17]. dialog button “Yes”. The policy guards the JavaScript API smsplugin.send, the Java API Security systems with quantitative policies have SmsPlugin.SEND SMS and the plugin function mainly been studied for Java [5, 19]. Since Java ap- cordova/plugin/smssendingplugin.send. plications are usually compiled, the light-wight en- Apps 1-5 are fitted with a simple policy where a forcement contained within the language used by specific button is allowed to send exactly one message. PhoneWrap is not possible here. However, similar ap- Apps 6-9 display a confirmation dialog before the mes- proaches achieve wrapping by taking advantage of the sage is sent which is captured with the confirm policy dynamic linking to libraries [20]. The tool Dr. An- parameter. App 9 sends up-to 3 messages for each but- droid and Mr. Hide [10] implements a finer-grained ton press. Local tickets prevent the app to abuse the access-control permission system for Android by wrap- unused tickets later. App 10 lets the user select contact ping APIs. Like PhoneWrap, it modifies Android apps numbers from a list and later sends 1 message to each and repacks them, but only refines the general permis- selected contact which is captured by the checkbox sions and does not consider quantitative or interaction- policy. Here, PhoneWrap needs to create non-local dependent policies. tickets since ticket generation and ticket consumption are triggered by separate events. All other apps (1-8) 6 Conclusion and Discussion spend generated tickets immediately which makes lo- We presented the system PhoneWrap which injects cal and non-local tickets equivalent. Where possible, interaction-dependent ticked-based policies into mo- local tickets are preferred as the fail-safe behaviour. bile apps written in JavaScript by wrapping the re- In app 8, we were able to improve the resource source consuming APIs. The implementation extracts behaviour by restricting unwanted resource consump- all necessary information from standard Android pack- tion, probably caused by a bug. This app displays a ages and automatically inserts user-created policies confirmation dialog before the message is sent. How- into real-world apps. Therefore, it is usable without ever, we discovered that the message is sent regardless, knowledge of the code of either the guarded app or of even if the user presses the “Cancel” button. The in- the PhoneWrap system and executes real-world apps jected PhoneWrap policy grants the message only if on an unmodified mobile phone system. the “OK” button is pressed. PhoneWrap can enforce policies on all API acti- The apps 5 and 7 send charged premium messages. vated resources. However, it only enforces a bound on Before such a message is sent, Android warns the user the number of calls to the critical API not the use of in a confirmation dialog. This dialog is out of the scope potentially returned values. For example, PhoneWrap of PhoneWrap, since PhoneWrap enforces its policy does not restrict the app from sharing obtained pri- on the application level. As a consequence, the dia- vate information. This can be achieved by different log is displayed if the PhoneWrap policy grants the techniques like flow analysis. message and suppressed as part of the API call if the Using the tool, we successfully identified and in- PhoneWrap policy denies the message. jected appropriate policies into 10 apps restricting their behaviour to a fine-grained least-privilege access 5 Related Work to the messaging service. A larger scale evaluation The wrapping method used in this work is inspired by has to show whether these examples are representa- Self-Protecting JavaScript [15], but extended to mobile tive and whether additional resource behaviour pat- apps and the concrete interaction-dependent ticket- terns like the checkbox and confirm pattern need to based policies. The improvements of Magazinius et be covered. al. [13] apply in the same way to PhoneWrap. Ac- Similar results could be achieved by rewriting 17 7 App (version, versionCode) Button Condition Tickets Policy features used 1 com.GPAInsurance.myinsurance.apk(1.0, 2) Caption: “Send Text” 1 2 nu.fdp.Boatsteward.apk(1.5, 6) id: “btnSendTheMessage” 1 3 nu.fdp.optimaxx gsm.apk(2.6, 26) id: “btnSendTheMessage” 1 4 nu.fdp.Sms RC.apk(4.1, 19) Caption: “Send” 1 Caption: “Ge med SMS” 5 se.fjellandermedia.tidegarden.apk(3.1, 310) id: “donateSMS” 1 6 nu.fdp.Sms RC Mini.apk(1.7, 8) src: (ends with) “/pict/send.png” 1 confirm: “Send” 7 no.idium.apps.maf.apk(1.0.1, 68) id: “stage Gi” 1 confirm: “Ok” 8 no.idium.apps.apk(1.0, 52) class: “sms small” 1 confirm: “OK” 9 myzealit.TMV.apk(2.2, 22) src: (ends with) “emergency icon.png” 3 confirm: “Yes”, local 10 com.ServiceHours.ServiceHours.apk(1.3.3, 8) name: “contactnumber” 1 checkbox Figure 4: Apps and their Policies 1 policy = { portantly, in the current version the policy creator 2 mperms : 0 , has to identify all critical plugins and APIs manu- 3 buttons : [ 4 { cond : { ally. Future work should include a relation between 5 src : " images / emergency_ icon . png " resources and corresponding plugins (as provided at 6 }, 7 match : " ends " , https://github.com/DFranzen/PhoneWrap) to auto- 8 mperms :3 , matically find the critical APIs and to propose which 9 local : true , 10 confirm : [ " Yes " ] , resources to guard. Extracting also the correct bounds 11 }, from the description of the app is an interesting and 12 { cond : { 13 src : " images / em ergency_i con2 . png " useful addition to this system, but would be subject 14 }, to a different field of research. Finally, for integrity, 15 match : " ends " , 16 mperms :3 , PhoneWrap needs to verify the PhoneGap library and 17 local : true , the plugin files included in an app to ensure that no 18 confirm : [ " Yes " ] , 19 } hidden APIs have been injected. This can be achieved 20 ], by checking against a white list of all official versions. 21 guard : [ " smsplugin . send " ] , 22 guard_exec : [ " SmsPlugin . SEND_SMS " ] , 23 guard_require : [ " cordova / plugin / smsse n ding plu gin . send " ] , References 24 deny : function () { alert ( " Policy : Denied " ) } 25 } [1] Adobe Systems Inc. Adobe phoneGap homepage. http://phonegap.com/. Accessed March 2016. Figure 5: Policy: TrackMyVisit [2] M. Backes, S. Gerling, C. Hammer, M. Maffei, and P. v. Styp-Rekowsky. AppGuard Fine-Grained Policy Enforce- ment for Untrusted Android Applications. In Data Pri- the JavaScript code, which is more difficult due to vacy Management and Autonomous Spontaneous Security, JavaScript’s dynamic nature and its ability to rewrite pages 213–231. Springer Berlin Heidelberg, 2014. itself in the DOM tree. PhoneWrap naturally han- [3] A. Bartel, J. Klein, Y. Le Traon, and M. Monperrus. Auto- matically Securing Permission-based Software by Reducing dles these JavaScript features, since the original meth- the Attack Surface: An Application to Android. In Proceed- ods are protected in the JavaScript scope rather than ings of the 27th IEEE/ACM International Conference on the DOM tree. Changing the native part could also Automated Software Engineering (ASE), pages 274–277. ACM, 2012. capture all resource consumption of PhoneGap apps. [4] A. Barthe, C. Jackson, and J. C. Mitchell. Securing However, the native part is only available in compiled Frame Communication in Browsers. Communications of form and the multiple different versions of the Phone- the ACM, 52(6):83–91, 2009. Gap library make it difficult to achieve consistent mod- [5] G. Czajkowski and T. von Eicken. JRes: A Resource Ac- ifications. In comparison, a PhoneWrap policy works counting Interface for Java. In Proceedings of the 13th ACM SIGPLAN Conference on Object-oriented Program- for all versions of the PhoneGap library as long as ming, Systems, Languages, and Applications (OOPSLA), the API of the plugin stays unchanged. Compared to pages 21–35, 1998. static analysis, PhoneWrap does not over-approximate [6] D. Evans and A. Twyman. Flexible Policy-Directed Code all possible runs of the app and can even alter the app Safety. In Proceedings of the 1999 IEEE Symposium on Security and Privacy, 1999, pages 32–45, 1999. to adhere to the policy in the case of policy violation. In parallel work [7] we infer the quantitative resource [7] D. Franzen and D. Aspinall. Towards an amortized type system for JavaScript. In 6th International Symposium on behaviour of unmodified JavaScript code, where pos- Symbolic Computation in Software Science (SCSS), pages sible, resulting in bounds with similar shape. The re- 12–26, 2014. sults of either system could improve the other. [8] W. D. Groef, D. Devriese, and F. Piessens. Better Security and Privacy for Web Browsers: A Survey of Techniques, Before PhoneWrap can be deployed in real world and a New Implementation. In Formal Aspects of Security scenarios, it needs some improvements. Most im- and Trust, pages 21–38. Springer Berlin Heidelberg, 2012. 18 8 [9] J. Hakimi. Play Store user review of DTEK by Black- Berry. play.google.com/store/apps/details?id=com. blackberry.privacydashboard, Nov. 2015. [10] J. Jeon, K. K. Micinski, J. A. Vaughan, A. Fogel, N. Reddy, J. S. Foster, and T. Millstein. Dr. Android and Mr. Hide: Fine-grained Permissions in Android Applications. In Pro- ceedings of the Second ACM Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM), page 314, 2012. [11] J. Jung, S. Han, and D. Wetherall. Short Paper: Enhanc- ing Mobile Application Permissions with Runtime Feed- back and Constraints. In Proceedings of the Second ACM Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM, pages 45–50, 2012. [12] M. T. Louw, P. H. Phung, R. Krishnamurti, and V. N. Venkatakrishnan. SafeScript: JavaScript Transformation for Policy Enforcement. In Secure IT Systems, pages 67– 83. Springer Berlin Heidelberg, 2013. [13] J. Magazinius, P. H. Phung, and D. Sands. Safe Wrap- pers and Sane Policies for Self Protecting JavaScript. In Information Security Technology for Applications, pages 239–255. Springer Berlin Heidelberg, 2012. [14] L. Meyerovich and B. Livshits. ConScript: Specifying and Enforcing Fine-Grained Security Policies for JavaScript in the Browser. In 2010 IEEE Symposium on Security and Privacy (SP), pages 481–496, 2010. [15] P. H. Phung, D. Sands, and A. Chudnov. Lightweight Self-Protecting JavaScript. In Proceedings of the 4th In- ternational Symposium on Information, Computer, and Communications Security (ASIACCS), pages 47–60. ACM, 2009. [16] C. Reis, J. Dunagan, H. J. Wang, O. Dubrovsky, and S. Es- meir. BrowserShield: Vulnerability-driven filtering of dy- namic HTML. ACM Trans. Web, 1(3):11, 2007. [17] G. Richards, C. Hammer, F. Zappa Nardelli, S. Ja- gannathan, and J. Vitek. Flexible Access Control for JavaScript. In Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Programming Systems Languages & Applications (OOPSLA), pages 305– 322, 2013. [18] F. Roesner, T. Kohno, A. Moshchuk, B. Parno, H. J. Wang, and C. Cowan. User-Driven Access Control: Rethinking Permission Granting in Modern Operating Systems. In Proceedings of the 2012 IEEE Symposium on Security and Privacy (SP), pages 224–238, 2012. [19] N. Suri, J. M. Bradshaw, M. R. Breedy, P. T. Groth, G. A. Hill, and R. Jeffers. Strong Mobility and Fine-Grained Resource Control NOMADS. In Agent Systems, Mobile Agents, and Applications, pages 2–15. Springer Berlin Hei- delberg, 2000. [20] T. Wang, K. Lu, L. Lu, S. P. Chung, and W. Lee. Jekyll on ios: When benign apps become evil. In Proceedings of the 22nd USENIX Security Symposium, pages 559–572, 2013. 19 9