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.


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.


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

Most View
Life Logging - Is It Worth The Effort? (Part 3)
LG Optimus 3D Max Review (Part 2)
Sony VAIO Tap 11 Ultrabook - Sleek And Sexy
Galaxy Note 10.1 - The Pen Sets This Tablet Apart
Windows Management and Maintenance : The Windows 7 Control Panel (part 6) - Devices and Printers
Push Your Phone To Its Limits (Part 2) : Swype for tablets
Windows 8 : Installing Programs - Working with Autorun, Application Setup and Compatibility, Making Programs Available to All or Selected Users
Y-cam Bullet HD 1080 - Superb Night-Time Performance
Solve PC, Software And Internet-Related Problems – December 2012 (Part 2)
My SQL : Replication for High Availability - Procedures (part 1) - The Outage
Top 10
Microsoft Exchange Server 2007 : Components of a Secure Messaging Environment (part 5) - Using Email Disclaimers
Microsoft Exchange Server 2007 : Components of a Secure Messaging Environment (part 4) - Establishing a Corporate Email Policy, Securing Groups
Microsoft Exchange Server 2007 : Components of a Secure Messaging Environment (part 3) - Hardening Windows Server 2003 - Running SCW
Microsoft Exchange Server 2007 : Components of a Secure Messaging Environment (part 2) - Hardening Windows Server 2003 - Using the Microsoft Baseline Security Analyzer
Microsoft Exchange Server 2007 : Components of a Secure Messaging Environment (part 1) - Hardening Windows Server 2003 - Auditing Policies
Microsoft Exchange Server 2007 : Server and Transport-Level Security - Considering the Importance of Security in an Exchange Server 2007 Environment
Sharepoint 2013 : List and library essentials - Organizing items by using folders
Sharepoint 2013 : List and library essentials - Sorting or filtering a list view
Sharepoint 2013 : List and library essentials - Creating and selecting a list view
Windows Server 2012 : Managing and Troubleshooting Hardware (part 11) - Resolving resource conflicts