Shulou(Shulou.com)06/03 Report--

This article will explain in detail how to prevent the risk of component export in Android development. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Preface

In recent years, a very important problem in mobile APP is security, which may result in user privacy leakage and property loss, which is undoubtedly the deadliest for a mature APP or financial and banking APP, so it is necessary to prevent APP effectively.

Recently, the company arranged for a security company to conduct a comprehensive security test on our APP. According to the document test results, it is still very safe on the whole, one of which is the risk of component export. Next, let's talk about the four major components, the necessity of component export, the risk and how to prevent it.

One and four major components

Engaged in Android development, we all know that Android has four major components, which are:

Activity (Activity), which is used to express function, is a visual interface of user operation, which provides a window for users to complete operation instructions.

Service (Service), which runs in the background and does not provide interface rendering

Broadcast recipient (Broadcast Receive) for receiving broadcasts

Content provider (Content Provider), which supports storing and reading data in multiple applications, which is equivalent to a database.

From the brief introduction of these components, we know their importance and give app richer functions, so the security of these four components is more important to our app and users.

II. Necessity of component export

What is component export? Component export means that the component can be called by external applications. We can set whether the component is exported or not in the manifest file declared by the four components, as follows:

Or:

Both of the above two methods are exported by Activity components, mainly the value of exported. If it is true, it means export. The default value of exported in Activity:

When there is no intent filter, the default is false

When there is intent filter, the default is true

The default values for Broadcast Receive and Service are the same as those for Activity.

Default values for exported in Content Provider:

When minSdkVersion or targetSdkVersion is less than 16:00, the default is true

Greater than 17:00. Default is false.

In the process of development, app will have some specific requirements that will use three-party SDK, such as Wechat sharing, payment, push and other functions. We find that there is one thing in common, which will involve the export of components, such as Wechat's.

WXEntryActivity:

This will be detected by security agencies. If you do not set WXEntryActivity for component export, Wechat sharing and other functions cannot be adjusted at all. This is the official way of writing. We think this must be set as component export. Unless you kill Wechat sharing requirements, the business will not scold you to death. Or the broadcast receiver that listens for network changes (above version 7.0 can only be dynamically registered in the code to receive the broadcast), push function, some push SDK will be impressed, and some Service will also declare android:exported= "true" and so on.

These inevitable components export, we can reply to the security agency: Wechat sharing, push and other functions must be set component export, so we can only ensure that their own settings of the four major components, to ensure that it is secure, so that we can ensure that app is in a relatively secure state, deal with security testing, and give your leader an account.

III. Component export risk

Previously explained the importance of components, component export, so what is the risk of component export?

Activity, as one of the four components of Apk, is the interface between Android programs and users. If Activity opens the export permission, it may be directly called out and used by the system or third-party App. Activity export may cause the login interface to be bypassed, denial of service attacks, program interface malicious invocation by third parties and other risks.

As one of the four components of Apk, Broadcast Receiver filters and receives external events and executes responses according to the content of the message. If export permissions are set, it may be directly called out and used by the system or third-party App. Broadcast Receiver exports can lead to risks such as disclosure of sensitive information and bypass of the login interface. S

Ervice, as one of the four components of Apk, generally runs as a service process in the background. If the export permission is set, it may be directly called out and used by the system or the third-party App. Service export may lead to denial of service attacks, program functions are maliciously invoked by third parties and other risks.

Content Provider, one of the four components of Apk, is a container for sharing data between applications. It can provide the specified dataset of the application to the third-party App. If the export permission is set, it may be directly called out and used by the system or the third-party App. Content Provider export may lead to the disclosure of sensitive information within the program, database SQL injection and other risks.

Next, take the Activity export as an example to illustrate its risks, and other component analogies are fine. First, Activity registers in the manifest file AndroidManifest.xml:

There are usually two ways to start Activity

To start explicitly, you need to specify the Activity to start:

Intent intent = new Intent (getContext (), WebActivity.class); intent.putExtra ("URL", "https://blog.csdn.net"); startActivity (intent))

Implicit startup, Intent no longer contains the specific Activity classes that need to be started, but provides some information through Intent, and the system retrieves the Activity that conforms to the startup intention. Here, the Intent information is declared through the intention filter: action (action), data (data), classification (Category), type (Type), component (Component), and extended information (Extra).

/ / call method to start WebActivity Intent intent = new Intent (); intent.setAction ("com.littlejerk.sample.action.VIEW_URL"); intent.putExtra ("URL", "https://blog.csdn.net"); startActivity (intent))

With Action jump, if the same Action is defined in the IntentFilter section of an Activity in the AndroidManifest.xml of a program, then the Intent matches the target Action. If Type and Category are not defined in the IntentFilter section, then the Activity matches. But if more than two programs match on the phone, a dialog box will pop up to indicate.

It is mentioned above that there is IntentFilter. If android:exported is not specified, the default value is true, and the external application can also start the corresponding component by implicit intention. In this case, we are talking about component export, which means that there are likely to be security problems. Let's take a look at the WebActivity page:

Intent intent = getIntent (); String url = intent.getStringExtra ("URL"); UILog.e (TAG, url.charAt (0)); mTvContent.setText (url)

We notice that WebActivity only receives a URL and displays it (without loading the URL), from which we can see that URL does not do parameter checking, and the application may crash; because the page can also be called by three-party applications, at this time, if someone maliciously transmits some bad web page information, then your application will be loaded without blocking, and the application may be removed from the shelves.

Fourth, how to prevent

We use the most common Activity as an example to illustrate the risk of component export, because we handle this URL parameter, we can prevent null pointer exceptions from being applied, which is no problem, but what if a bad URL is loaded? In fact, the most fundamental reason for the risk of component export is that it has been called by others, so is there any way to control the scope of others and only allow people we trust to invoke it?

Here we have to mention the permission mechanism of Android. Android's Permission checking mechanism is used to control which execution rights an application has. For example, if an app has the right to take photos, can we control whether an application has the right to launch WebActivity through permissions?

Android provides the ability to customize permissions, and applications can define their own permissions, such as customizing a permission in the manifest file:

Label: description of permissions

Name: the name of this permission, which is specified by name when using this permission

ProtectionLevel: the level at which this permission is protected, which is important, it has three levels

Signature: signature-level permission, that is, the defining party of the permission and the registrant must have the same signature to be valid

System: system-level permissions, that is, the defining party and registrant of the permissions must be applied to the system

SignatureOrSystem: with the same signature or system application, you can have either of the above

The permission definition is complete, how to use it to protect the exposed components, take a look at the following code:

When the activity is declared, there is a permission under the activity tag, and the name of the permission to protect the activity can be specified through permission, so that only the activity with this permission can start it (note that both the definer and the user define and declare the custom permission in the manifest file), declare and use this permission in the caller's manifest file:

With permission control, the scope of the export of activity components can be controlled. When there are mutual component calls between our applications, we can use the permissions with the same signature to restrict them, while other applications cannot call our exposed components because they do not have the same signature, which effectively avoids the risk.

Activity is one of our most common components, but BroadcastReceiver also uses a lot of places. General security assessments mention this component, so we need to mention it. In fact, the security control of each component can also be controlled through permission.

There are two ways to register BroadcastReceiver

Static registration, declaring registration in Manifest

Dynamic registration, depending on other components in the code, registration through registerReceiver

BroadcastReceiver has both sender and receiver of broadcast, so two-way verification is generally required when using permission to verify communication, that is, both sender and receiver of broadcast need to add permission check to ensure that the sender only sends the broadcast to the trusted receiver, and the same receiver only accepts the broadcast from the trusted party.

Broadcast sender

The sender needs to declare permissions in the manifest file AndroidManifest.xml:

Then use the sendBroadcast (Intent intent, String receiverPermission) method to send the broadcast:

/ / send broadcast Intent intent = new Intent (); intent.setAction ("com.littlejerk.sample.broadcast.action.TEST"); sendBroadcast (intent, "com.littlejerk.sample.permission.BROADCAST_SEND")

It is known from the literal meaning of receiverPermission that the receiver must apply for the custom permission of com.littlejerk.sample.permission.BROADCAST_SEND, otherwise, he or she will not be able to receive action notifications, such as the receiver's manifest file AndroidManifest.xml:

If the receiver's broadcast receiver does not control its own permissions, the application with the developer can only listen to the action of com.littlejerk.sample.broadcast.action.TEST, but for double verification, we also need to declare our permissions to the receiver.

Broadcast receiver

We define a broadcast receiver TestReceiver:

Public class TestReceiver extends BroadcastReceiver {private static final String TAG = "TestReceiver"; / / callback @ Override public void onReceive (Context context, Intent intent) {/ / A pair of foreign parameters should be legally checked String action = intent.getAction (); if (TextUtils.isEmpty (action)) {return;} UILog.e (TAG, "action:" + action) }}

Then declare the control permissions in the manifest file AndroidManifest.xml:

Then give this control to the broadcast receiver, which can be registered in two ways

Static registration method, in the manifest file AndroidManifest.xml:

Then there is dynamic registration, which declares where you need to register:

Receiver receiver = new Receiver (); IntentFilter intentFilter = new IntentFilter (); intentFilter.addAction ("com.littlejerk.sample.broadcast.action.TEST"); registerReceiver (receiver, intentFilter, "com.littlejerk.sample.permission.BROADCAST_RECEIVER", null)

Both of these registration methods are OK, but dynamic registration broadcasting is recommended, because static registration broadcasting is greatly restricted on Android O for the sake of App performance and power consumption.

We have also imposed permission restrictions on the receiver, so the sender must apply for this permission to send action to it, so the sender's manifest file AndroidManifest.xml needs to be added on the original basis:

At this point, the two-way verification of the broadcast is completed, and all the above code has been tested without any problems, filtering extraneous broadcasts well and protecting the security of the components.

On how to guard against the risk of component export in Android development is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.