MOBILE

Android Security : Broadcasts

10/11/2010 2:03:53 PM
Broadcasts provide a way applications and system components can communicate securely and efficiently. The messages are sent as Intents, and the system handles dispatching them, including starting receivers and enforcing permissions.

Receiving Broadcast Intents

Intents can be broadcast to BroadcastReceivers, allowing messaging between applications. By registering a BroadcastReceiver in your application’s AndroidManifest .xml file, you can have your application’s receiver class started and called whenever someone sends a broadcast your application is interested in. Activity Manager uses the IntentFilter’s applications register to figure out which program to use to handle a given broadcast. As we discussed in the sections on IntentFilters and Activity permissions, filters are not a security mechanism and can’t be relied upon by Intent recipients. (IntentFilters can sometimes help Intent sender safety by allowing the sending of an Intent that is qualified by a category. Receivers that don’t meet the category requirements won’t receive it, unless the sender forces delivery by specifying a component. Senders adding categories to narrow deliver therefore shouldn’t specify a component.) As with Activities, a broadcast sender can send a receiver an Intent that would not pass its IntentFilter just by specifying the target receiver component explicitly. (See the examples given for Activities in the “Activities” section. These examples can be applied to broadcasts by using sendBroadcast() rather than startActivity() and adjusting the components appropriately for your test classes.) Receivers must be robust against unexpected Intents or bad data. As always, in secure IPC programming, programs must carefully validate their input.

BroadcastReceivers are registered in AndroidManifest.xml with the <receiver> tag. By default they are not exported. However, you can export them easily by adding an <intent-filter> tag (including an empty one) or by setting the attribute android:exported=“true”. Once exported, receivers can be called by other programs. Like Activities, the Intents that BroadcastReceivers get may not match the IntentFilter they registered. To restrict who can send your receiver an Intent, use the android: permission attribute on the receiver tag to specify a manifest permission. When a permission is specified on a receiver, Activity Manager validates that the sender has the specified permission before delivering the Intent. Permissions are the right way to ensure your receivers only get Intents from appropriate senders, but permissions don’t otherwise affect the properties of the Intent that will be received.

Safely Sending Broadcast Intents

When sending a broadcast, developers include some information or sometimes even a sensitive object such as a Binder. If the data being sent is sensitive, they will need to be careful who it is sent to. The simplest way to protect this while keeping the system dynamic is to require the receiver to have permission. By passing a manifest permission name (receiverPermission is the parameter name) to one of Context’s broadcastIntent() family of methods, you can require recipients to have that permission. This lets you control which applications can receive the Intent. Broadcasts are special in being able to very easily require permissions of recipients; when you need to send sensitive messages, you should use this IPC mechanism.

For example, an SMS application might want to notify other interested applications of an SMS it received by broadcasting an Intent. It can limit the receivers to those applications with the RECEIVE_SMS permission by specifying this as a required permission when sending. If an application sends the contents of an SMS message on to other applications by broadcasting an Intent without asserting that the receiver must have the RECEIVE_SMS permission, then unprivileged applications could register to receive that Intent, thus creating a security hole. Applications can register to receive Intents without any special privileges. Therefore, applications must require that potential receivers have some relevant permission before sending off an Intent containing sensitive data.

Tip

It is easier to secure implementing Activities than BroadcastReceivers because Activities can ask the user before acting. However, it is easier to secure sending a broadcast than starting an Activity because broadcasts can assert a manifest permission the receiver must have.


Sticky Broadcasts

Sticky broadcasts are usually informational and designed to tell other processes some fact about the system state. Sticky broadcasts stay around after they have been sent, and also have a few funny security properties. Applications need a special privilege, BROADCAST_STICKY, to send or remove a sticky Intent. You can’t require a permission when sending sticky broadcasts, so don’t use them for exchanging sensitive information! Also, anyone else with BROADCAST_STICKY can remove a sticky Intent you create, so consider that before trusting them to persist.

Tip

Avoid using sticky broadcasts for sharing sensitive information because they can’t be secured like other broadcasts can.

Other  
 
Most View
Holiday Gift Guide – Smartphones – Aug 2013
Booting on HP 9000 Servers (part 2) - The setboot Command, Boot Console Handler (BCH) and Processor Dependent Code (PDC)
Keep Selective Colour In Mono Conversions (Part 1)
The Contemporary APUs - AMD Trinity vs Intel Ivy Bridge (Part 8)
Amazon Isn’t Just For Books Anymore...
Best Photo Printers Revealed – Jan 2013 (Part 2) : Canon PIXMA MG6250
Analysis Design For Repair And Recycling
Asus Vivobook S550CM Ultrabook Review
iphone SDK : Using the ABUnknownPersonViewController Class, Using the ABPeoplePickerNavigationController Class
Deconstructed - Five Classic Bass Music Tunes And Discover Some Key Ideas (Part 3)
Top 10
Microsoft Exchange Server 2010 : Configuring Anti-Spam and Message Filtering Options (part 4) - Preventing Internal Servers from Being Filtered
Microsoft Exchange Server 2010 : Configuring Anti-Spam and Message Filtering Options (part 3) - Defining Block List Exceptions and Global Allow/Block Lists
Microsoft Exchange Server 2010 : Configuring Anti-Spam and Message Filtering Options (part 2) - Filtering Connections with IP Block Lists
Microsoft Exchange Server 2010 : Configuring Anti-Spam and Message Filtering Options (part 1) - Filtering Spam and Other Unwanted E-Mail by Sender, Filtering Spam and Other Unwanted E-Mail by Recipien
Microsoft Exchange Server 2010 : Creating and Managing Remote Domains (part 3) - Configuring Messaging Options for Remote Domains , Removing Remote Domains
Microsoft Exchange Server 2010 : Creating and Managing Remote Domains (part 2) - Creating Remote Domains
Microsoft Exchange Server 2010 : Creating and Managing Remote Domains (part 1) - Viewing Remote Domains
Microsoft Exchange Server 2010 : Creating and Managing E-Mail Address Policies (part 3) - Editing and Applying E-Mail Address Policies , Removing E-Mail Address Policies
Microsoft Exchange Server 2010 : Creating and Managing E-Mail Address Policies (part 2) - Creating E-Mail Address Policies
Microsoft Exchange Server 2010 : Creating and Managing E-Mail Address Policies (part 1) - Viewing E-Mail Address Policies