Mitre technical report

Parameter Content

7. Secure Inter-App Communication

14. Securing Android Intents

1. Sender Risks and Mitigations

1. Implicit Intents

To mitigate these threats, applications should use explicit Intents when it is possible to address Intents to a specific component, and must use explicit Intents if the Intent is for an internal component (intra-application communication).

When sending broadcast Intents, applications can define custom permissions and only send the Intent to receivers that hold the permission. Permissions are an effective security mechanism when they are combined with an effective enterprise management approach that provides control over the permissions held by other installed applications to ensure that they do not maliciously request the permission. For additional protection, the custom permission could be declared as a "signature" level permission, which would require both applications be signed by the same private key (usually meaning they are both written by the same developer).

The same permissions approach is not available for sending implicit Intents to an Activity or Service. Explicit Intents should be used when possible, but if an implicit Intent is necessary, applications should avoid placing sensitive information in implicit Intents sent to an Activity or Service and should perform input validation on any received responses.

2. Explicit Intents

res = getPackageManager().checkPermission(permToCheck, name.getPackageName());

then compare res with PackageManager.PERMISSION_GRANTED or PackageManager.PERMISSION_DENIED

As described in the above section, an enterprise management approach is needed to control the permissions held by other installed applications to ensure that they do not maliciously request the permission.

Another, stronger approach is to obtain the receiving application's package signature and ensure that it matches an expected value.

2. Receiver Risks and Mitigations

Many application components are only used internally and have no need to be invoked by external applications. To be safe, developers should declare these components in the manifest as explicitly internal:

As described in Enck, et al., applications must perform null checks on all received objects. Otherwise, an unintended dereference of a null variable, potentially provided by a malicious application through an Intent, may cause the application to crash.

Broadcast Receivers are at risk of attack. As described by Chin, et al., certain Intents are supposed to be broadcast by only the operating system (rather than by any application), so these Intents may be given more trust by the application. However, when applications declare the ability to receive broadcast messages from the system, they are able to receive messages from any other application, not just the system. Applications must be sure to explicitly ensure that the received message matches a system action (which can only be sent by the operating system) before proceeding:

public void onReceive(Context ctxt, Intent i){

if (i.getAction().equals("expected.action"))

return;

Intent filters are not a security mechanism. Even if an Intent recipient (such as an Activity, Service, or BroadcastReceiver) declares an IntentFilter, a malicious sender can still send an explicit Intent to invoke the activity with an Intent that does not match the filter. Recipients must be prepared to receive unexpected data in Intents and appropriately filter their contents.

Recipients can use permissions to control who can invoke them. These permissions are checked by the Activity Manager to ensure the sender meets the requirements to send the Intent before delivering it.

For example, the following activity can only be invoked by applications that hold the custom permission "my.permission":