allow applications to call each other, reusing each other’s features
and allowing for replacement or improvement of individual system pieces
whenever the user likes. Activities are often run in their own process,
running as their own UID, and therefore don’t have access to the
caller’s data aside from any data provided in the Intent used to call
the Activity. (Note that Activities implemented by the caller’s program
may share a process, depending on configuration.)
easiest way to make Activities safe is just to confirm any changes or
actions clearly with the user. If simply starting your Activity with
any possible Intent could result in harm or confusion, you need to
require a permission to start it. An Intent received by an Activity is
untrusted input and must be carefully and correctly validated.
rely on IntentFilters (the <intent-filter> tag in
AndroidManifest.xml) to stop callers from passing them badly configured
Intents. Misunderstanding this is a relatively common source of bugs.
On the other hand, Activity implementers can rely on permission checks
as a security mechanism. Setting the android:permission attribute in an
<activity> declaration will prevent programs lacking the
specified permission from directly starting that Activity. Specifying a
manifest permission that callers must have doesn’t make the system
enforce an IntentFilter or clean Intents of unexpected values, so
always validate your input.
The following code shows
starting an Activity with an Intent. The Activity Manager will likely
decide to start the web browser to handle it, because the web browser
has an Activity registered with a matching IntentFilter.
Intent i = new Intent(Intent.ACTION_VIEW);
The following code
demonstrates forcing the web browser’s Activity to handle an Intent
with action and data settings that aren’t permitted by the IntentFilter:
// The browser's intent filter isn't interested in this action
Intent i = new Intent("Cat-Farm Aardvark Pidgen");
// The browser's intent filter isn't interested in this Uri scheme
// The browser activity is going to get it anyway!
If you run this code, you
will see that the browser Activity starts. However, the browser is
robust, and aside from being started it just ignores this weird Intent.
following code provides a sample AndroidManifest entry that declares an
Activity called “.BlankShoppingList”. This sample Activity clears the
current shopping list and gives the user an empty list to start
editing. Because clearing is destructive, and happens without user
confirmation, this Activity must be restricted to trustworthy callers.
The “com.isecpartners.ACCESS_SHOPPING_LIST” permission allows programs
to delete or add items to the shopping list, so programs with that
permission are already trusted not to wreck the list. The description
of that permission also explains to users that granting it gives an
applications the ability to read and change shopping lists. We protect
this Activity with the following entry:
without an IntentFilter or an android:exported attribute are not
publicly accessible—that is, other applications can’t start them with
Context.startActivity(Intent intent). These Activities are the safest
of all, but other applications won’t be able to reuse your
Developers need to be
careful when implementing Activities, but also when starting Activities
as well. Avoid putting data into Intents used to start Activities that
would be of interest to an attacker. A password-sensitive Binder or
message contents would be prime examples of data not to include! For
example, malware could register a higher priority IntentFilter and end
up getting the user’s sensitive data sent to its Activity instead.
When starting an
Activity, if you know the component you intend to have started, you can
specify that in the Intent by calling its setComponent() method. This
prevents the system from starting some other Activity in response to
your Intent. Even in this situation, it is still unsafe to pass
sensitive arguments in the Intent (for example, processes with the
GET_TASKS permission are able to see
ActivityManager.RecentTaskInformation, which includes the baseIntent
used to start Activities). You can think of the Intent used to start an
Activity as being like the command-line arguments of a program (and
these usually shouldn’t include secrets either).
put sensitive data into Intents used to start Activities. Callers can’t
easily require manifest permissions of the Activities they start, so
your data might be exposed.