In this chapter, we will learn about "Sending Implicit Broadcast Risk". This risk echoes the risk of dynamically registering Receiver , so you can read it together.
1. Vulnerability principle
Implicit broadcast means that no recipient (receiving range) is specified. During the broadcast process, all APPs can receive the broadcast, so there is a risk that the broadcast will be intercepted. If the sent broadcast carries data, then there is The risk of data leakage, if there are sensitive operations in the sent broadcast, there is a risk of malicious hijacking.从Android8.0开始就要显示的指定广播接收方，但是也可以绕过这个限制比如添加FLAG：FLAG_RECEIVER_INCLUDE_BACKGROUND，但不建议这样做，Google既然有这个限制说明确实很影响安全
2. Detection method
step1：Scan the global code to see if there is an implicit broadcast (broadcast with no specified receiving range, broadcast without permission), see the repair method summary
step2：results for details
3. Repair method
1. Use Intent.setPackage 、Intent.setComponent、Intent.setClassName、Intent.setClass、new Intent(context,receiver.class)any of the methods to clearly specify the target receiver.
2. It is recommended to use in-process sending messages LocalBroadcastManager, or use other means to send messages.
3. Use sendBoardcast(Intent, receiverPermission)instead of sendBoardcast(Intent) to ensure that other applications cannot receive the broadcast information
4. Relevant information
From Google Docs (Science Online)
broadcast restriction
If an app registers to receive broadcasts, the app's receivers consume resources each time a broadcast is sent. This can cause problems if multiple apps register to receive system event-based broadcasts: a system event that triggers a broadcast can cause all apps to consume resources in rapid succession, degrading the user experience. To alleviate this problem, Android 7.0 (API level 24) imposes some restrictions on broadcasting, as described in Background optimizations. Android 8.0 (API level 26) tightens these restrictions.
- Apps targeting Android 8.0 or higher can no longer register broadcast receivers for implicit broadcasts in their manifest. An implicit broadcast is one that is not specific to the application. For example, ACTION_PACKAGE_REPLACED is an implicit broadcast because it is sent to all registered listeners to let them know that some packages on the device have been replaced. However, ACTION_MY_PACKAGE_REPLACED is not an implicit broadcast because it will only be sent to the app whose package has been replaced, regardless of how many other apps have registered listeners for the broadcast.
- Apps can continue to register for explicit broadcasts in their manifest.
- Applications can register receivers for any broadcast (either implicitly or explicitly) at runtime using Context.registerReceiver().
- Broadcasts that require signing permissions are exempt from this restriction because they are only sent to apps signed with the same certificate, not to all apps on the device.
In many cases, applications that previously registered for implicit broadcasts can obtain similar functionality using JobScheduler jobs. For example, a social photo app might need to perform data scrubbing from time to time, and tend to do so while the device is connected to a charger. Previously, the application had registered a receiver for ACTION_POWER_CONNECTED in the manifest; when the application received this broadcast, it checked whether cleanup was necessary. To migrate to Android 8.0 or higher, apps remove this receiver from their manifest. The app schedules cleaning jobs to run when the device is idle and charging.
asjhan for Android reverse