The app declares some unprotected broadcast receivers in its Android Manifest file.
Broadcast receivers are an inter-process communication ingest mechanism, allowing apps to receive data in the form of intents coming from other apps. They can be statically declared in the Android Manifest or registered dynamically at runtime. The former are known as Manifest-declared receivers and sending intents to them will cause the system to launch your app if it is not already running.
Broadcast receivers can be exported, protected using permissions or using signature enforcement. If left unprotected, as is the case with this finding, third party apps can send data to these receivers.
The exact impact varies on case-by-case basis depending on how the app handles incoming broadcasts. Although many cases are harmless, commonly seen consequences for the affected apps are:
Performing unintended actions, perhaps on behalf of the user.
Displaying the incoming data to the user on behalf of the app for the purposes of phishing or social engineering, for example by loading a URL specified by the attacker into a WebView.
Exposing sensitive data, for example, by sending its own broadcast in response to the incoming one, or by writing it to a location accessible by other apps.
Steps to Reproduce
This test statically audits the app binary for any broadcast receivers declared in its AndroidManifest.xml file that have not been protected with permissions and have no android:exported or it's set to "true".
Business Impact
The app is not following secure best practices when handling data. This could lead to sensitive information being exposed to other apps on any device.
Remediation Resources
The evidence table presents all names for unprotected broadcast receivers as they appear in the app's AndroidManifest.xml file.
If the broadcast receiver handles sensitive information you need to restrict access to it. These are the options:
Completely prevent any other apps from triggering your broadcast receiver: set android:exported="false" in your <receiver>.
Restrict access to only certain apps: specify a <permission> with protection level of signature or signatureOrSystem.
If your app is supposed to only send and receive broadcasts to itself, avoid both Broadcast Receivers and using LocalBroadcastManager, which is deprecated.
Instead, Google recommends using an observable pattern, such as androidx.lifecycle.LiveData or reactive streams, depending on your use case.
Finding Description
The app declares some unprotected broadcast receivers in its Android Manifest file.
Broadcast receivers are an inter-process communication ingest mechanism, allowing apps to receive data in the form of intents coming from other apps. They can be statically declared in the Android Manifest or registered dynamically at runtime. The former are known as Manifest-declared receivers and sending intents to them will cause the system to launch your app if it is not already running.
Broadcast receivers can be exported, protected using permissions or using signature enforcement. If left unprotected, as is the case with this finding, third party apps can send data to these receivers.
The exact impact varies on case-by-case basis depending on how the app handles incoming broadcasts. Although many cases are harmless, commonly seen consequences for the affected apps are:
Steps to Reproduce
This test statically audits the app binary for any broadcast receivers declared in its AndroidManifest.xml file that have not been protected with permissions and have no
android:exportedor it's set to"true".Business Impact
The app is not following secure best practices when handling data. This could lead to sensitive information being exposed to other apps on any device.
Remediation Resources
The evidence table presents all names for unprotected broadcast receivers as they appear in the app's AndroidManifest.xml file.
Open your AndroidManifest.xml and search for
android:namewithin the<receiver>tag referencing those receivers.If the broadcast receiver handles sensitive information you need to restrict access to it. These are the options:
android:exported="false"in your<receiver>.<permission>with protection level ofsignatureorsignatureOrSystem.If your app is supposed to only send and receive broadcasts to itself, avoid both Broadcast Receivers and using
LocalBroadcastManager, which is deprecated.Instead, Google recommends using an observable pattern, such as androidx.lifecycle.LiveData or reactive streams, depending on your use case.
Risk and Regulatory Information
Severity: medium
CVSS: 4
Policy Category: Default Priority 1
Application
See more detail in the NowSecure Report