(THIS CODING RULE OR GUIDELINE IS UNDER CONSTRUCTION)

Data stored in an application's service provider can be referenced by URIs that are included in intents. If the recipient of the intent does not have the required privileges to access the URI, the sender of the intent can set either of the flags FLAG_GRANT_READ_URI_PERMISSION or FLAG_GRANT_WRITE_URI_PERMISSION on the intent. If the provider has specified in the manifest that URI permissions may be granted then the recipient of the intent will be able to read or write (respectively) the data at the URI.

Chin, et al., [Chin 2011] points out that, if a malicious component is able to intercept the intent, then it can access the data at the URI. Implicit intents can be intercepted by any component so, if the data is intended to be private, any intent carrying data privileges must be explicitly addressed, rather than being implicit. (See DRD03-J. Do not broadcast sensitive information using an implicit intent for more information about the interception of implicit intents.)

Noncompliant Code Example

This noncompliant code example shows an application that grants FLAG_GRANT_READ_URI_PERMISSION on an implicit intent.

TBD

An application could intercept the implicit intent and access the data at the URI.

Compliant Solution

In this compliant solution the intent is made explicit so that it cannot be intercepted:

TBD

Risk Assessment

Granting URI permissions in implicit intents can leak sensitive information.

Automated Detection

Automatic detection of the setting of a URI permission on an implicit intent is straightforward. It is not feasible to automatically determine whether the data at the URI is sensitive.

Bibliography