Application Security for the Android Platform by Jeff Six

Author:Jeff Six [Jeff Six]
Language: eng
Format: epub, mobi, pdf
Tags: COMPUTERS / Programming / General
ISBN: 9781449315061
Publisher: O'Reilly Media
Published: 2011-12-01T16:00:00+00:00

Securing Broadcast Intents

As you will recall from our earlier discussion, messages are commonly broadcast out to any app that is listening for them using Broadcast Receivers. We discussed our email client app example and how the Service that is constantly checking for new mail may choose to send out a broadcast Intent when a new message has been received, so that multiple components may choose to act upon this. In this case, we most likely want to limit the components that can receive such a broadcast, as we do not want to go announcing to the whole world that an email message has just come in.

The sender of broadcasts can choose to apply an Android permission to each broadcast it sends, that broadcast will be delivered only to those Broadcast Receivers that both have an Intent filter that allows them to receive it and the specified permissions that indicate they are authorized to do so. In the case of our Service example, we can restrict which Broadcast Receivers are allowed to receive our broadcasts by sending the broadcast only to those with a MSG_NOTIFY_RECEIVE permission that we create for this purpose:

Intent bdctIntent = new Intent(MESSAGE_RECEIVED); myContext.sendBroadcast(bdctIntent, "com.example.testapps.test1.permission.MSG_NOTIFY_RECEIVE");

Note that in many cases, when a permission check fails, a SecurityException is thrown. When we lock down broadcasts in this manner, no SecurityException will be thrown if a Broadcast Receiver specifies that they should receive these broadcasts but they do not have the specified permissions. Indeed, since this code attempts to send the specified broadcast Intent to any Broadcast Receiver with a matching Intent filter, some of these receivers may have the specified permission and some may not; no feedback is returned to the component sending the broadcast Intent as to which succeeded and which failed.

This mechanism enables the sender of a broadcast to specify which receivers are allowed to receive it. It is also possible to do the reverse: to configure a Broadcast Receiver to accept incoming broadcast Intents only from senders that hold the specified permissions. To do this, simply specify a permission attribute in the <receiver> element in AndroidManifest.xml. For example:

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.testapps.test1"> ... <receiver android:name=".UIMailBroadcastReceiver" android:permission= "com.example.testapps.test1.permission.MSG_NOTIFY_SEND"> <intent-filter> <action android:name="com.example.testapps.test1.action.MESSAGE_RECEVIED"> </intent-filet> </receiver> ... </manifest>

This declares a Broadcast Receiver that listens for MESSAGE_RECEIVED broadcast Intents and accepts them only from senders that have been granted the MSG_NOTIFY_SEND permission. If a MESSAGE_RECEIVED broadcast Intent arrives from a sender without that permission, it will not be delivered to this Broadcast Receiver.

It is also possible to register a Broadcast Receiver programmatically, instead of in the AndroidManifest.xml file, by calling registerReceiver(). In this case, you can still apply a permission restriction, only allowing senders with that permission to send to the registering Broadcast Receiver. For example:

IntentFilter intentFilter = new IntentFilter(MESSAGE_RECEIVED); UIMailBroadcastReceiver rcv = new UIMailBroadcastReceiver(); myContext.registerReceiver(rcv, intentFilter, "com.example.testapps.test1.permission.MSG_NOTIFY_SEND", null);

As you can see, broadcasts can be secured in either direction. Senders of broadcasts can configure them so that only receivers with specific permissions are allowed to receive them. Receivers of broadcasts can be configured to accept them only from senders with specific permissions.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.