{'fraction_non_alphanumeric': 0.033906345928447844, 'fraction_numerical': 0.008678908299380476, 'mean_word_length': 4.91239069460485, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
SecComp: Towards Practically Defending Against Component Hijacking in Android Applications

Cross-app collaboration via inter-component communication is a fundamental mechanism on Android. Although it brings the benefits such as functionality reuse and data sharing, a threat called component hijacking is also introduced. By hijacking a vulnerable component in victim apps, an attack app can escalate its privilege for originally prohibited operations. Many prior studies have been performed to understand and mitigate this issue, but component hijacking remains a serious open problem in the Android ecosystem due to no effective defense deployed in the wild. In this paper, we present our vision on practically defending against component hijacking in Android apps. First, we argue that to fundamentally prevent component hijacking, we need to switch from the previous mindset (i.e., performing system-level control or repackaging vulnerable apps after they are already released) to a more proactive version that aims to help security-inexperienced developers make secure components in the first place. To this end, we propose to embed into apps a secure component library (SecComp), which performs in-app mandatory access control on behalf of app components. An important factor for SecComp to be effective is that we find it is possible to devise a set of practical in-app policies to stop component hijacking. Furthermore, we allow developers design custom policies, beyond our by-default generic policies, to support more fine-grained access control. We have overcome challenges to implement a preliminary SecComp prototype, which stops component hijacking with very low performance overhead. We hope the future research that fully implements our vision can eventually help real-world apps get rid of component hijacking.


INTRODUCTION
Android has been the dominant player in recent years' smartphone markets. On Android, different apps are allowed to collaborate with each other via inter-component communication [36]. Although such flexible cross-app collaboration brings the benefits such as functionality reuse and data sharing, a threat called component hijacking [44] is also introduced. By hijacking a vulnerable component in victim apps, an attack app can bypass Android sandbox and escalate its privilege [33], causing confused deputy problems [40] such as permission misuse [39], data manipulation [44], and content leaks [64].
To mitigate component hijacking, many approaches have been proposed. One major line of the research [51,38,34,29,30,28,42,54,31,55] is to modify or extend Android operating system so that inter-component communication could be supervised. The other direction [62] is to patch app binaries by performing app repackaging [61,63]. Both are useful if they could be deployed in the wild. But reality is harsh: nearly no proposal 1 has been integrated into Android or adopted by Google Play, probably due to the compatibility and performance concerns. For example, the repackaging approach violates Android's signature-based app verification and thus is not favorable by app markets and developers who own source codes. Consequently, component hijacking remains a serious open problem in the Android ecosystem.
In this paper, we try to provide a new perspective for the research community to reconsider how to practically defend against component hijacking. We find that neither earlier proposals consider the problem from developers' perspective; they are either from the OS or the app market's perspectives. However, to fundamentally prevent component hijacking, we do need a more proactive mindset that aims to help security-inexperienced developers make secure components in the first place. To this end, we propose to embed into apps a secure component library (SecComp), which performs in-app mandatory access control on behalf of app components. Compared to the traditional secure development education, the SecComp solution is systematic, mandatory, and low-cost. Moreover, by leveraging automatic code rewriting techniques, we expect that SecComp could be easily adopted by developers to produce security-enhanced apps which are resistant to component hijacking.
An important enabling factor for SecComp to work is that we find it is possible to devise a set of practical inapp policies to stop component hijacking. By analyzing the root causes of different hijacking attacks, we have derived six generic mandatory access control policies for SecComp to enforce. In addition, for cases with no fixed patterns, we propose to leverage user-driven access control to handle them. Furthermore, we allow developers design custom policies, beyond our by-default generic policies, to support more fine-grained access control.
The remainder of this paper is organized as follows. We first introduce the threat model in §2, followed by the design of SecComp in §3. In §4, we present a SecComp prototype implementation and evaluate it in §5. Related works are outlined in §6, and finally we conclude in §7.  Figure 1 presents the threat model of component hijacking on Android. The adversary is a caller app, and the victim is a callee app that has certain capabilities or owns some sensitive data. A necessary condition of component hijacking is the target component in the callee app being exported, an Android terminology that describes a component is exposed to other apps on the same phone. The attack component in the caller app then can send a crafted IPC (inter-process communication) 2 request to the exported component, to maliciously trigger its code execution for a privileged operation, e.g., permission misuse [39] and data manipulation [44]. In this sense, component hijacking belongs to the classic confused deputy problem [40].

THREAT MODEL
More specifically, we underline two in-scope threats that are not considered in some related works.
• Unlike [39,64,60], we do not assume that exported components protected with above-normal 3 permissions are always safe. Because for an exported component protected with an dangerous-level permission, an attack app still can register the corresponding permission for sending IPC requests. Additionally, a recent report [19] showed that even components with a signature-level permission could be compromised, because the attack app can pre-claim that permission as normal if it is installed earlier than the victim app. • Similarly, for the attack app, we do not assume it always has zero or few permissions. Indeed, it can claim the same permission as the misused permission in a victim app. The benefit for doing so is that it may deceive the IPC call chain-based permission checking [38,34]. On the other hand, we do assume that the attack app has no root privilege, which is reasonable and a widely adopted practice in Android research. It is worth noting that a related threat called unauthorized Intent receipt [32] is out of the scope of this paper. This threat is essentially different from component hijacking. In its model, the attack app is the callee, and vulnerability occurs because the caller victim app mistakenly sends out sensitive information in its IPC messages. A systematic defense [47] has been proposed to mitigate this issue.

Overview
2 In some references, this kind of IPC is also called ICC (intercomponent communication) [50] or inter-app communication. In this paper, we unify these terms using IPC. 3 There are four levels of Android permissions [20]: normal, dangerous, signature, and signatureOrSystem.  SecComp supports two kinds of enforcements, i.e., entrypoint access control (EP-AC) and sink-point access control (SP-AC). EP-AC is enforced just after the entry of an app component, whereas SP-AC is performed just before each sensitive API call (i.e., the so-called sink, a term commonly used in taint analysis [24]). EP-AC serves as the first line of defense, so every incoming IPC request will be checked by this module. As to be illustrated in §3.5, we design a set of mandatory access control policies for EP-AC to confine common attacks and mistakes. Only IPC requests that EP-AC cannot determine legal or not will be further assessed by SP-AC, at the point a sink API going to be executed. To guarantee the completeness, we launch user-driven access control in SP-AC to handle cases with no fixed patterns.
To route incoming IPC flows to SecComp for access control, we pre-insert entry-point and sink-point instrumentation points into original app component codes. These instrumentation points are very lightweight-only one or two lines of codes each. After SecComp's checking, we either return the execution flow back to the component codes (if the IPC request is legal) or terminate it (if the request is non-legal). For cases that user decisions are required, we hold on the execution flow and wait for users to make a decision via a pop-up dialog.

Identifying Entry Functions and Sink APIs
Entry function identification. Table 1 characterizes the component entry functions that need to be intercepted by SecComp. We organize them by different component types query API, the corresponding Con-tentProvider.query entry function in a victim component will be activated. BroadcastReceiver [5]: There is only one entry for Broad-castReceiver, namely the onReceive callback function. An adversary can call the sendBroadcast API to trigger onReceive. Other IPC call APIs that are built upon sendBroadcast could be also used, such as sendOrderedBroadcast and sendStickyBroadcast. All these calls lead to the execution of onReceive in a callee component. Service [17]: There are two ways to call a Service component, either by starting it via the startService API, or by binding it via the bindService API. Both cases will first go through the onCreate() entry function if the service is not created. The onStartCommand entry (in the first case) operates in a way similar to the onReceive function, whereas the onBind or onRebind entry (in the second case) only returns a Binder [3] object and has no further sequential execution. Indeed, with the retrieved Binder object, an adversary can invoke any IPC interface functions [4,2] that are pre-defined by the Binder object. These custom interface functions thus become additional Service entries, which should be also instrumented. Activity [1]: Similar to Service, the entry functions of Activity also include onCreate and onStart, which could be activated by the startActivity() API and its variants. Additionally, there is a special entry function in Activity, i.e., onNewIntent. This entry would be triggered if the caller app sets a special Intent flag called FLAG_ACTIVITY_SINGLE_TOP.
Sink API selection. To pick sink APIs that are relevant to component hijacking, we can leverage some earlier works. Notably, Stowaway [37] and PScout [25] released a list of permission-protected APIs, and SuSi [52] leveraged supervised learning to output a large set of privacy-related APIs. These results are very useful, but still need manual efforts to form a hijacking-specific API set. On the other hand, works for detecting component hijacking issues [39,44,64] described the sink APIs that are specific to their problems or component types. Our earlier effort [60] tried to synthesize these results and has released a preliminary dataset [21]. In the future, we plan to further collaborate with the open source community to build a comprehensive dataset.

Instrumenting Entry and Sink Points
After identifying entry functions and sink APIs, we perform code instrumentation to insert entry and sink points. To pack the instrumentation codes, SecComp defines four static Java classes, namely SecActivity, SecService, Se-cReceiver, and SecProvider. We find that there are two types of EP-AC instrumentation and one kind of SP-AC instrumentation: 1. Basic EP-AC Instrumentation: Most of EP-AC instrumentation just add two lines of codes in the prologue of entry functions. They intercept original entry parameters and a few context parameters to Sec-Comp for decision making. Listing 1 shows the example of instrumenting BroadcastReceiver's onReceive. It simply delivers the original Context and Intent parameters to SecReceiver's receive function for access control (line 2). If the access is not allowed by policies, the instrumentation code returns without giving the control flow back to original code (line 3). In most cases, we need to intercept additional parameters such as component Context, from which SecComp then can extract component identity and attribute for policy enforcement. To obtain the Context, we deliver a this variable to EP-AC instrumentation. Moreover, to intercept the incoming Intent for Activity, we invoke the getIntent() API to explicitly obtain its value.
2. EP-AC instrumentation for bound services: As mentioned earlier, we should treat Binder interface functions as individual entries. Therefore, for a bound Service such as RemoteService [2] in Listing 2, we Listing 2: The special EP-AC instrumentation for a bound Service named RemoteService [2]. It instruments onBind as usual, and further instruments Binder interface functions (getPid here) as for ContentProvider's entries.
String num = intent . getStringExtra ( " phone " ) ; 3 String text = ge tRa ndom Stri ng (8)  instrument not only its onBind as usual, but also the getPid function in a way similar to how we instrument ContentProvider's entries.
3. SP-AC instrumentation: It intercepts both API names and parameters, and delivers them to the userdriven access control module ( §3.5.2) for output. Listing 3 shows a sample SP-AC instrumentation for the popular Go SMS Pro app [10], which was vulnerable to the SEND_SMS permission leak [6]. At line 6, SecComp records the sendTextMessage call and its five parameters, along with the this variable for capturing the component context.

Extracting Enforcement Primitives
As an in-app defense, SecComp can collect a set of valuable enforcement primitives that will be used in the policy enforcement: App identity: We extract the identity information of both caller and callee apps for policy making. We use package name (e.g., com.whatsapp for WhatsApp) instead of app UID to represent an app identity, because some apps (e.g., Chrome) may have multiple UIDs. We further combine app signatures to determine whether two apps are from the same developer. In this paper, we uniformly denote these identity information by Ida and Idv, which represent the caller and the callee identity, respectively. Then, Ida = Idv represents that an incoming IPC request is from a third-party app. Component attribute: Android apps claim different component attributes in the manifest file, i.e., AndroidManifest.xml. We denote these attributes by XxxAttr, such as ExportedAttr for the "exported" attribute, P ermAttr for the permission attribute, and ActionAttr for the Intent actions registered by components. Additionally, we denote system-defined permissions and actions by SysP erms and SysActions, respectively. A list of permissions and actions that are defined by Android is available in [15,18]. If a permission can be claimed only by system or an action can be sent only by system, we denote them by SysOnlyP erm and SysOnlyAction, respectively. Entry-point input data: Likewise, we denote different input values by InputXxx. For example, the incoming Intent action is represented as InputAction, and the incoming data Uri is denoted by InputU ri. Sink-point parameters: We denote a sink API parameter by SinkP ara. This primitive is used only by SP-AC. In particular, we will detail how to collect app identity and component attributes in §4.2. The input data and sink parameters can be obtained through the entry-point and sink-point instrumentation codes (see Listing 1 and 3).

MAC Policies for EP-AC
We find that it is possible to devise mandatory access control (MAC) policies to stop common component hijacking issues. These issues arise because of system flaws or developer mistakes. We study their root causes and design the corresponding MAC policies for EP-AC to enforce. Table 2 lists six representative MAC policies (P1 to P6) we have designed. From a high-level view, policies P1 to P3 patch the system weaknesses, P4 and P5 mitigate common developer mistakes, and P6 filters a common attack.
A common point among all six policies is that we treat the IPC requests initiated from the same app or developer trusted. That is, only an external IPC request from a thirdparty app will be checked. This is denoted by Ida = Idv, as mentioned in §3.4. However, an experienced adversary may bypass this policy by detouring IPC requests first to another component in the victim app. We propose to mitigate this problem by adding a flag during each IPC relay so that Sec-Comp can infer the origin of an IPC call chain. For example, we can add one line of code, intent.putExtra('seclibflag', 'outside'), into each SP-AC instrumentation that contains IPC call functions.
The policy P1 is derived from a system flaw [19] that an attack app who installed earlier can pre-claim a custom permission in the victim app, such as setting its permission level from signature to normal. Consequently, the attack app can hijack any component that was originally protected with signature-level permissions. Based on this root cause, our policy first determines whether there is a custom permission defined in the callee component, i.e., ∃(P ermAttrv / ∈ SysP erms). If there is a such custom permission, we further check whether or not it has been pre-claimed by the caller app, i.e., P ermAttrv = P ermAttra. If yes, we deny the request to prevent a component hijacking attack.
The policy P2 and P3 aim to mitigate the gap that components could be by default exported by system whereas developers may not be aware of that. Specifically, components that define Intent Filters are implicitly exported [11] even if they do not claim the "exported" attribute. Furthermore, ContentProvider components are automatically All: all four components; A: Activity; S: Service; B: BroadcastReceiver; P: ContentProvider.
exported unless developers explicitly assign "false" to the "exported" attribute. This by-default rule led to thousands of vulnerable ContentProvider components [64]. Although Google later revised this rule since Android 4.2, it still requires developers to manually update apps' SDK attributes to a safe version. According to a very recent study [45], there are still many by-exported ContentProvider components.
To protect by-default exported component from hijacking, policy P2 and P3 first determine whether there exists the "exported" attribute. For ContentProvider, we can deny the IPC request if there is no "exported" attribute, in order to mimic the current system rule. For other components, we further check what kinds of Intent actions are registered. Only for those custom actions (ActionAttr / ∈ SysActions), the corresponding IPC requests will be denied. Additionally, we will provide a debug mode with user interfaces, to help developers resolve the potential (but less likely) conflict between their original intentions and our policies.
Following P3, we further propose the policy P4 to handle the case of system actions. In particular, a component listening to system-only broadcasts is hijack-able if it does not check the incoming Intent action explicitly in the code. A prior work [60] showed that there are around 150 system-only broadcasts on Android. To prevent component hijacking due to missed action checks, P4 automatically checks the input action against the system-only action claimed in manifest, i.e., ∃(ActionAttr ∈ SysAction) ∧ InputAction = ActionAttr.
The policy P5 aims to mitigate the denial-of-service hijacking due to missed null checks on IPC input. This is a common mistake that affected a large portion of Android apps, according to a previous empirical study [35]. To stop such hijacking, we record the app crash times corresponding to each caller app. And if it has exceeded the threshold value (e.g., 3 times), SecComp then denies the request. Moreover, we can consider only the recent crashes to avoid over-checking.
Finally, we propose the policy P6 to filter SQL injection for ContentProvider. As demonstrated in [64], an attack app can hijack a provider component to inject malicious SQL statements. For example, the adversary sets the projection parameter of the query function as a special phase "* from private_table;". Since these special inputs are usually different from normal queries, we thus can use keyword-based filtering (such as the keyword ";") to stop them.

User-driven Control for SP-AC
For IPC requests that cannot be determined by EP-AC, we further launch the user-driven control when they are going to arrive at a sink point. Basically, SecComp pops out an alert dialog interface and asks users to make a decision. Fig-Figure 3: An UI example of user-driven control. ure 3 shows a sample alert box that we have implemented. By collecting all the enforcement primitives in §3.4, we can provide sufficient context information to help users choose "Deny" or "Allow". We plan to also leverage recent advances on usable security [57,23,53] to make SecComp's userdriven control more accessible to end users. Furthermore, we allow developers to revise each individual pop-up dialog through SecComp's debugging mode. They can even draft custom policies to black-or white-list certain sink points.
It is also possible to derive MAC policies for SP-AC, although we currently use the user-driven control scheme. One potential MAC policy is to deny all background sink access (initiated from a third-party app) when users are not using their phones. The policy P6 in Table 2 could be also evolved to a sink-point version, i.e., preventing SQL injection for database sink APIs in all components. Moreover, we may leverage the IPC call chain-based permission checking [38,34] to perform mandatory access control. For instance, if the caller app has no SEND_SMS permission, it should be also denied to access a component that has such permission. In practice, this kind of MAC needs more careful design to minimize the negative impact to normal functionalities. For example, it is legal for a file management app (with zero permission) to instruct the Dropbox app to upload a file.

Towards Fine-grained Custom Policies
As both EP-AC and SP-AC policies are general-purpose and made by us, there is a need for individual developer to craft app-specific policies for more fine-grained access control. We plan to support such custom policies in SecComp, which enables new use cases. We introduce two cases below: Whitelist and blacklist: Developers can write custom poli-cies to support whitelist and blacklist based access control. For example, they can specify App A is allowed to access my Component C. This is in particular useful to big vendors that own several development teams with each using different app signature. By using whitelist, apps made by different teams can still easily collaborate with one another. Policy update and hotfix: Using custom policies allows developers to update their policies on-the-fly, such as pushing hotfixes to protect their apps from being exploited by a newly identified system flaw.

Deploying SecComp in the Wild
The lightweight nature and requiring no OS change make SecComp have a great potential to be deployed in the wild. The primary SecComp users are app developers. They are free to choose any of the following two deployment models: Selective SecComp planting: Developers can selectively plant SecComp to protect particular components that are more likely to be attacked. Specifically, developers import the SecComp jar file as like using other thirdparty libraries. Once imported, they can selectively add the instrumentation codes as in §3.3. Automatic SecComp planting: To further minimize developers' efforts, we are on the way of implementing a code rewriting technique to automatically plant SecComp. It can be a standalone script tool or a plugin integrated in Eclipse and Android Studio. The basic workflow is like this. By default, it locates the entry functions of each exported component and inserts the EP-AC codes. Optionally, developers could further instruct this tool to perform control flow analysis to identify reachable sink APIs and adds SP-AC. Besides app developers, end users can directly use Sec-Comp by incorporating the recent advance of app sandboxing called Boxify [27].

IMPLEMENTING A SecComp PROTOTYPE
We have implemented a SecComp prototype for Content-Provider components, i.e., SecProvider. We choose Con-tentProvider as the first implementation choice because only this type of components has no known defense proposal. Implementing SecComp for other three components is generally similar and also underway. In the course of implementing SecProvider, we have identified and overcame two main challenges: ( §4.1) how to achieve user-driven control for background components such as ContentProvider; ( §4.2) how to extract app identity and component attributes within the context of different Android components. In particular, we have developed a novel UI (user interface) transition technique to overcome the first challenge.

Achieving User-driven Access Control
To achieve user-driven access control, we need to pop out an alert box as in Figure 3. However, we find that this is a non-trivial task for ContentProvider components. Because ContentProvider is the only type of components that retrieves a caller app's Context object instead of a callee app's [9]. As it is forbidden to display one app's UI elements using another app's Context, SecComp cannot properly pop out an alert box for ContentProvider.
We take a different strategy to address this problem. Instead of directly displaying an alert box on top of a caller app, we initialize a dialog-like Activity and use the caller app's Context object to launch this alert Activity via the startActivity() API. It is worth noting that launching Activity components from ContentProvider requires to set a special Intent flag called FLAG_ACTIVITY_NEW_TASK. Besides popping out a dialog-like Activity, we also need a method to automatically return to the original caller UI after users click alert box buttons. This is quite important for maintaining user experience. A trivial solution is to invoke the star-tActivity again with the caller component as the target. We find a more efficient way. By setting one more special Intent flag called FLAG_ACTIVITY_MULTIPLE_TASK, our alert Activity can naturally go back to the caller UI after invoking the Activity.finish() API. Moreover, we set the third Intent flag called FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS to avoid the alert box appear in the history of recent Activity components.
After successfully launching the alert dialog in Content-Provider, we need a mechanism to pause the current component execution and wait for users' decisions. To do so, SecComp initializes a lock object and sets this object into the "wait" status after invoking the startActivity. Once users click the buttons, the alert Activity will notify the "waited" lock object to be released. Consequently, the lock object will no longer wait and the paused ContentProvider component resumes its execution. To avoid the unnecessary long-time waiting, we further set a timeout value (e.g., 30 seconds in our current prototype). Even if users do not make decisions after the timeout value, SecComp will by default deny the access.

Extracting App Identity and Component Attributes
We now present the implementation of the enforcement primitive extraction as previously shown in §3.4. Among the four types of primitives, obtaining entry-point input data and sink-point parameters are straightforward via our instrumentation code in Listing 1 and 3. Therefore, we focus on how to extract app identity and component attributes.
App identity extraction. To extract the package name of a caller app, we can use the getCallingPackage() API. However, this API is only available since Android 4.4 for ContentProvider. To maintain the compatibility of Sec-Comp, we opt to a generic way. We first extract the caller UID via Binder.getCallingUid() and then use the UID to retrieve the caller package. Meantime, the callee app package can be directly retrieved from ApplicationInfo, which is available through Context.getApplicationInfo().
Component attribute extraction. To illustrate component attribute extraction, we use the ExportedAttr as a representative example. It aims to determine the export status of a callee component, i.e., explicitly or implicitly exported. Unfortunately, this is non-trivial. Initially, we try to obtain the status via the ProviderInfo.exported flag. But we find that Android has already set this flag to true even for those implicitly exported components. Consequently, it is impossible to determine the real export status according to the exported flag.
Without the Android API support, we have to seek another way to obtain the component export status. Our solution is to retrieve the whole AndroidManifest.xml file of the callee app and parse the export status from that. More specifically, if our parser does not encounter the exported attribute, we determine the corresponding component is implicitly exported.

Security Evaluation
We now evaluate the effectiveness of SecComp against different hijacking attacks in ContentProvider. We use the open source Zirco Browser [22] as our evaluation subject. It has the following two ContentProvider components, the explicitly exported WeaveContentProvider and the implicitly exported ZircoBookmarksContentProvider. We have implemented SecComp to defend against three ContentProvider hijacking attacks: (i) the EEC attack that exploits explicitly exported components, (ii) the IEC attack that exploits implicitly exported components, and (iii) the SQL attack that performs SQL injections at Con-tentProvider components. More specifically, we leverage the policy P2 and P6 (in Table 2) to stop the last two attacks, and further extend the policy P2 as the following custom policy to defend against the EEC attack. ifIda = Idv ∧ ExportedAttr = true : alert Defending the EEC attack. We use WeaveContent-Provider to evaluate SecComp against the EEC attack. As shown in Figure 4(a), without SecComp, an adversary can access all information from the weave.db database when our library is not included into the Zirco Browser. After Sec-Comp is included in the Zirco Browser, it will pop out an alert dialog for users to do control (see Figure 3). When users select the "Deny" button, no information could be accessed from the WeaveContentProvider, as shown in Figure 4(b).
Defending the IEC attack. We use ZircoBookmarksCon-tentProvider to evaluate SecComp against the IEC attack. As shown in Figure 5(a), an adversary can access all information from the bookmarks.db database when SecComp is not included into the Zirco Browser. After including SecComp, as shown in Figure 5(b), it will directly deny IPC requests from other apps. As a result, no information of ZircoBook-marksContentProvider could be leaked any more.
Defending the SQL attack. We still use WeaveCon-tentProvider to evaluate SecComp against the SQL attack. This time the adversary sets the projection parameter as a special phase "* from private_table", which can launch the SQL injection. But SecComp can directly defend against such malicious behaviors, as shown in Figure 6.
Self protection. The adversary may exploit the fact that SecComp for stopping the EEC attack pops out an alert dialog to launch the GUI-based denial-of-service attack. To prevent such attack, we can provide users a choice button called "Remember my decision" so that next time no alert   dialog will be popped out. We also can set a threshold value that defines how many alert dialogs could be popped out within a time slot.

Performance Evaluation
We further evaluate the overhead introduced by SecComp. To this end, we record the execution time of SecComp under different operations. It is worth noting that for measuring the overhead of defending the EEC attack, we temporarily remove the lock wait code. Because user decision time should not be included as our overhead. Table 3 shows the overhead results. We can see that the  265ms. This is because we only add one more checking at this step, i.e., to check the caller app identity. We further add the component semantic checking to defend against the IEC attack, the overhead of which is 0.243-0.369ms. As the overhead of all these three operations is under 0.5ms, we conclude that their overhead is very low. The overhead of defending EEC attack is the largest, requiring around 200ms, because launching an alert Activity is a bit expensive. But since it is finished within 0.5s, we believe that this is still a low overhead.

RELATED WORK
Many works have been conducted to mitigate component hijacking on Android or secure cross-app communication in general. Most of them [51,38,34,29,30,28,42,54,31,26,55,46] aim to evolve Android's security architecture by introducing fine-grained, mandatory, and extensible access control at different system levels.
A notable example is SEAndroid [54], which reconstructs Android from the previous Linux UID-based discretionary access control to the recent SELinux-enabled mandatory access control. It can restrict certain app flaws such as direct file leak [59,58] but not component hijacking, because it is quite challenging to efficiently audit every IPC at the sys-tem level without affecting any normal app functionality. Probably due to the same reason, Android IntentFirewall is still an experimental feature [13,14] despite its code release over three years ago [12]. Moreover, IntentFirewall is a sender -oriented policy framework [41] and thus requires the malicious Intent patterns. In contrast, SecComp has no such requirement and can be applied to both Intent and non-Intent based components. Additionally, Kantola et. al. [42] made OS change to restrict component exposure. Although this is effective to reduce attack surfaces, it is not flexible and cannot handle some component hijacking attacks such as those defended by our policy P1, P4, P5, and P6.
The other line of defense solutions is to perform app repackaging [61,63,43]. Notably, AppSealer [62] repackages apps to generate component hijacking patches which performs the sink-point enforcement. Aurasium [61] offers a similar capability although it is not specialized for component hijacking. Our SP-AC is inspired by these works but not in a form of repackaging.
As orthogonal to the defense research, many prior studies try to understand and detect component hijacking issues in real-world apps. They have leveraged program analysis techniques to propose various detection systems, including Com-Droid [32], Woodpecker [39], CHEX [44], ContentScope [64], and Epicc [50]. Android app analysis frameworks, such as FlowDroid [24] and Amandroid [56], could be also extended to analyze component hijacking. Recently, more solid and scalable inter-component analysis methods [49,48] have also been proposed.

CONCLUSION AND FUTURE WORKS
In this paper, we presented our vision on practically defending against component hijacking in Android apps. We proposed SecComp, a secure component library for performing in-app mandatory access control on behalf of app components. We further designed a set of generic and practical policies for SecComp to enforce. We have implemented a preliminary SecComp prototype and demonstrated its efficacy and efficiency. We are on the way of implementing a complete SecComp system, and will open source it soon so that more hands could join to help real-world apps get rid of component hijacking.