You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

DRD05-J

High

Probable

Medium

P12

L1

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

  • No labels