Improper Export of Android Application Components
The Android application exports a component for use by other applications, but does not properly restrict which applications can launch the component or access the data it contains.
Description
The attacks and consequences of improperly exporting a component may depend on the exported component:
If access to an exported Activity is not restricted, any application will be able to launch the activity. This may allow a malicious application to gain access to sensitive information, modify the internal state of the application, or trick a user into interacting with the victim application while believing they are still interacting with the malicious application.
If access to an exported Service is not restricted, any application may start and bind to the Service. Depending on the exposed functionality, this may allow a malicious application to perform unauthorized actions, gain access to sensitive information, or corrupt the internal state of the application.
If access to a Content Provider is not restricted to only the expected applications, then malicious applications might be able to access the sensitive data. Note that in Android before 4.2, the Content Provider is automatically exported unless it has been explicitly declared as NOT exported.
Background
There are three types of components that can be exported in an Android application.
An Activity is an application component that provides a UI for users to interact with. A typical application will have multiple Activity screens that perform different functions, such as a main Activity screen and a separate settings Activity screen.
A Service is an application component that is started by another component to execute an operation in the background, even after the invoking component is terminated. Services do not have a UI component visible to the user.
The Content Provider mechanism can be used to share data with other applications or internally within the same application.
Demonstrations
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
Example One
This application is exporting an activity and a service in its manifest.xml:
<activity android:name="com.example.vulnerableApp.mainScreen">
...
<intent-filter>
<action android:name="com.example.vulnerableApp.OPEN_UI" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
...
</activity>
<service android:name="com.example.vulnerableApp.backgroundService">
...
<intent-filter>
<action android:name="com.example.vulnerableApp.START_BACKGROUND" />
</intent-filter>
...
</service>Because these components have intent filters but have not explicitly set 'android:exported=false' elsewhere in the manifest, they are automatically exported so that any other application can launch them. This may lead to unintended behavior or exploits.
Example Two
This application has created a content provider to enable custom search suggestions within the application:
<provider>
android:name="com.example.vulnerableApp.searchDB"
android:authorities="com.example.vulnerableApp.searchDB">
</provider>Because this content provider is only intended to be used within the application, it does not need to be exported. However, in Android before 4.2, it is automatically exported thus potentially allowing malicious applications to access sensitive information.
See Also
Weaknesses in this category are related to access control.
This view (slice) covers all the elements in CWE.
CWE entries in this view (slice) are often seen in mobile applications.
Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.