Learning Objectives
To understand the fundamental concepts of activities and intents in Android programming.
To understand the dangers of unauthorized intent interception.
To understand the basic defensive practice skills against unauthorized intent interception that may provide avenue of attack for malicious attacks in mobile software development.
The intent is the main communication mechanism between Android components such as activity, service, and broadcast receiver in intra-app and inter-app. An. An intent object is a messaging object (an instance of the android.content.Intent class) which can be used to start activities and services, bind to services, and convey notify and pass data to broadcast receivers. E.g., an activity B can register with intent A’s intent so that the bound activity B will be notified and activated when the event fires.
There two types of intent: Explicit and implicit intent.
Explicit intents have its explicit recipient and Implicit intents do not name its explicit recipient, and it will notify an appropriate component based on the specification of the intent.
E.x., An explicit intent tells Android system to run specific component such as ActivityB
Intent intent = new Intent(ActivityA.this, ActivityB.class);
startActivity(intent);
Activity, service and broadcast receiver can have multiple intent filters to tell the system that what kind of implicit intent they would accept. The filter can ignore illegal intents and keep the ones that the activities want to accept according to the characters described in the filter (action name, category, etc.). The explicit would ignore the intent filters.
An implicit intent does not specify a particular target application to receive the data, any application can process the intent by using an Intent Filter for that intent. An implicit Intent is sent to the Android OS system and the Android system will locate a best matched component based on action and category requirement. Implicit intent may leave a security vulnerability hole that can allow untrusted applications to obtain sensitive data.
E.x., An implicit intent tells Android system to run an activity(ActivityB in this case) that can do these things that are specified in the intent filter in a manifest file.
An implicit intent example
Intent intent = new Intent();
intent.addAction("thisAction");
intent.addCategory("thisCategory");
startActivity(intent);
The Android manifest file:
The Android manifest file:
<activity android:name="ActivityB">
<intent-filter>
<action android:name="thisAction"/>
<category android:name="thisCategory"/>
</intent-filter>
</activity>
For activities and broadcast receivers, intents are the preferred mechanism for asynchronous IPC. Android. An Implicit intent is mainly used for broadcasting if the receiver is unknown in advance. An explicit intent is directed to a specific application component.
Intent eavesdropping involves a malicious app receiving an intent that was not for it. This can cause a leak of sensitive information.
This figure illustrates the concept of intent eavesdropping where comp1 and comp2 are two Android components(Activity, Service, or BroadCastReceiver) in App 1. The comp2 in App1 expects to get intent with data from Comp1 inside App1. But also, an evil component in a malicious app catches informaion via an implicit intent. This is an inter-app intent eavesdropping which can be prevented by explicit intent or claiming permission requirement by app1.
As we know that Android system will locate a best-matched component based on action and category requirement. The intent filter can help to filter from the implicit intents to find out which activity should run. However, if the activities have the same action name, the system would get confused and cannot decide which activity to run. That means if the hacker application has one activity with the same action name and other characters, it might get the sensitive information via the intent we sent. The Implicit intent leaves a security vulnerability hole that the attacker would like to use.
Prevention: Many of the security elements are shared across IPC mechanisms. If your IPC mechanism is not intended for use by other applications, set the android:exported attribute to false in the component's manifest element,
If your IPC is accessible to other applications, you can apply a security policy by using the <permission> element. If IPC is between your own separate apps that are signed with the same key, it is preferable to use signature level permission in the android:protectionLevel.
Senders of an intent can verify that the recipient has permission by specifying a non-null permission with the method call. Only applications with that permission receive the intent. If data within a broadcast intent may be sensitive, you should consider applying a permission to make sure that malicious applications can't register to receive those messages without appropriate permissions.
For security purposes, explicit intents are preferred if it is possible. Although explicit intent is more secure than implicit intent but a component can be invoked with explicit intents and the component may not conform to the intent filter. To confirm that it is properly formatted for the invoked receiver, service, or activity, perform input validation within your intent receiver.