(THIS CODING RULE OR GUIDELINE IS UNDER CONSTRUCTION)
A malicious application may send an intent to an exported component that is not expecting to receive an intent from that application. This may trick the receiving application into taking some inappropriate action with undesirable results. In particular, if the component is not meant to be public but is nonetheless exported then such an attack may be possible.
...
Component exposure should be limited by setting permission requirements in the manifest or by dynamically checking the caller's identity.
Noncompliant Code Example
This noncompliant code example shows an application that acts on receiving an intent without checking the caller's identity:
Code Block | ||
---|---|---|
| ||
TBD |
Compliant Solution (Checking Caller's Identity)
In this compliant solution the caller's identity is checked before any action is taken:
Code Block | ||
---|---|---|
| ||
TBD |
Compliant Solution (Setting Permission Requirements)
This compliant solution shows the permissions set in the manifest that prevent a malicious application from triggering an inappropriate action:
Code Block | ||
---|---|---|
| ||
TBD |
Risk Assessment
Acting on receipt of an intent without validating the caller's identity may lead to sensitive data being revealed or to denial of service.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
DRD06-J | High | Probable | Medium | P12 | L1 |
Automated Detection
Automatic detection of the receipt of an intent is straightforward. It is not feasible to automatically determine whether appropriate checks are made of the caller's identity or whether appropriate permission requirements have been set in the manifest.
Bibliography
...