Expert column: Intent Filter and security in Android

1. Introduction to Intent and IntentFilter

The three core component activities of an application, services and broadcast receivers, are activated by messages (Intents. Intent message transmission is a mechanism that binds components in the same or different applications at a later time. An intent object itself) is a passive data structure that contains the abstract description of the executed operation. Or, for broadcast, It is a description of something that has occurred and has been declared. There are several different mechanisms to transfer intent to each component:

• An intent object is passed to Context. startActivity () or Activity. startActivityForResult () to start an Activity or let an existing Activity do something new.
• An intent object is passed to Context. startService () to initiate a service or submit a new command to the running service. Similarly, an intent can be passed to Context. bindService () to establish a connection between a calling component and a target service. As an option, it can initiate this service if it is not yet running.
• The intent object passed to any broadcast method (such as Context. sendBroadcast (), Context. sendOrderedBroadcast (), or Context. sendStickyBroadcast () is passed to all interested broadcast recipients. Many types of broadcast come from system code.

In each example, the Android system finds an appropriate activity, service, or a group of broadcast recipients to respond to this intent and instantiate them if necessary. These message transmission systems do not overlap: the broadcast intent is transmitted only to the broadcast receiver and never to the activity or service. The intention of a message sent to startActivity () is to be transmitted only to an activity, never to a service or broadcast recipient, and so on.

To notify the System of the intent they can process, the activity, service, and broadcast receiver can have one or more intent filters. Each filter describes the capabilities of a component and the intent that a series of components want to receive. It actually filters the intent according to an expected type, filter out unwanted intentions at the same time-but only unwanted implicit intentions will be filtered out for object classes without naming targets ). An explicit intent is always the target that can be submitted to it, no matter what it contains. In this case, the filter does not work. However, an explicit intent can be submitted to this component only when it can pass a filter of the component.

Each task that a component can do is divided into different filters for each aspect presented to the user. For example, the main activity in the example notepad application contains three filters: one is a blank board, and the other is a designated recording directory that users can view, edit, or select, the third is to find a specific record without the initial directory description. An intent filter is an instance of the IntentFilter class. However, because the Android system must know the capabilities of this component before starting a component, intent filter is usually not set in Java code, but in the AndroidManifest file of the Application List. xml) to set the <intent-filter> element. One exception is that the filters of broadcast receivers registered by calling Context. registerReceiver () are directly created as intent filter objects.

Ii. Filters and security

We cannot trust the security of an intent filter. When it opens a component to receive certain types of implicit intent, it cannot block explicit intent targeting this component. Even if the filter limits certain actions and data sources for the intent to be processed by the component, someone can always combine an explicit intent with a different action and data source, and then name the component as the target.

A filter has the same action, data, and category fields as the intent object. An implicit intent is tested in all three aspects of the filter. To deliver to a component that owns the filter, it must pass all three tests. Even if only one fails, the Android system will not submit it to this component. However, since a component can contain multiple intent filters, one intent that cannot be filtered by one component may pass through another filter.

The three related tests are described as follows:

Test 1: Actiontest)

The intent filter element in the list file lists action elements, such:

 
 

  
  
<intent-filter. . . > 
  
  
<action android:name="com.example.project.SHOW_CURRENT" /> 
  
  
<action android:name="com.example.project.SHOW_RECENT" /> 
  
  
<action android:name="com.example.project.SHOW_PENDING" /> 
  
  
. . . 
  
  
</intent-filter> 
 
 

As shown in the example, an intent object only names a single action, and a filter may list multiple. The list cannot be blank. A filter must contain at least one action element, otherwise it will block all intent.

To pass this test, the action specified in the intent object must match one of the actions listed in the filter. If the intent object or filter does not specify an action, the result is: If the filter does not list any actions, there is no matching intention, so all intentions will fail to be tested. There is no intention to pass this filter. On the other hand, an intent object without a specified action automatically passes this test-as long as the filter contains at least one action.

Test 2: Categorytest)

An intent filter <intent-filter> element also lists categories as child elements. For example:

 
 

  
  
<intent-filter. . . > 
  
  
<category android:name="android.intent.category.DEFAULT" /> 
  
  
<category android:name="android.intent.category.BROWSABLE" /> 
  
  
. . . 
  
  
</intent-filter> 
 
 

Note that the action and category constant described above are not used in the listing file. Instead, the complete string is used. For example, corresponding to the aforementioned CATEGORY_BROWSABLE constant, the above example uses the "android. intent. category. BROWSABLE" string. Similarly, the string "android. intent. action. EDIT" corresponds to the ACTION_EDIT constant.

For an intent that passes the class test, the category in each intent object must match the category in one filter. This filter can list another category, but it cannot omit any category in this intent.

Therefore, in principle, a non-classification intent object should always be able to pass the test, regardless of what is in the filter. This is true in most cases. With one exception, Android treats all the implicit intent sent to startActivity () as containing at least one category: "android. intent. category. DEFAULT" CATEGORY_DEFAULT constant ). Therefore, activities that want to receive implicit intent must include "android. intent. category. DEFAULT" in their intent filter "., The filters with "android. intent. action. MAIN" and "android. intent. category. LAUNCHER" are exceptions. They mark the activities that start new tasks and appear on the startup screen. They can include "android. intent. category. DEFAULT" in the category list, but they are not necessary.

Test 3: Data test)

Like actions and categories, the Data Type of an intent filter is contained in a child element. This sub-element can appear multiple times or once. For example:

 
 

  
  
<intent-filter. . . > 
  
  
<data android:type="video/mpeg" android:scheme="http" .. . /> 
  
  
<data android:type="audio/mpeg" android:scheme="http" .. . /> 
  
  
. . . 
  
  
</intent-filter> 
 
 

Each data <data> element can specify a URI and a data-type MIME media type ). There are some separate attributes-mode, host, port, and Path-each part of URI:

Scheme: // host: port/path

For example, in the URI below,

Content: // com. example. project: 200/folder/subfolder/etc

The mode is "content", the host is "com. example. project", the port is "200", and the path is "folder/subfolder/etc ". The host and port form the URI authentication authority). If no host is specified, the port is ignored.

These attributes are optional, but they are dependent on each other. To make an authorization meaningful, you must specify a mode. To make a path meaningful, you must specify both the mode and authentication.

When a URI in an intent object is used to compare with the URI specification in a filter, it actually compares each part of the URI mentioned above. For example, if the filter only specifies one mode, all the URIs in that mode matches the filter. If the filter specifies a mode, authentication, but no path, all URLs in the same mode and authentication can match, regardless of their channels. If the filter specifies a mode, authentication, and channel, only the URL with the same mode, authentication, and path can match. Of course, the path type in a filter can contain wildcards, so that only partial matching is required.

The Type attribute of the <data> element specifies the MIME type of the data. This is more common in filters than in Uris. Both intent objects and filters can use a "*" wildcard to specify child-type fields-for example, "text/*" or "audio/*"-to indicate any matching child types.

The data test compares the URI and data type specified in the intent object and filter at the same time. The rules are as follows:

1) An intent object that neither contains the URI nor the data type can pass the test only when the filter does not specify any URIs and data type.

2) an intent object that contains a URI but does not have a data type can pass the test only when its URI matches the URI in a filter that does not specify a data type. This usually happens on a URL like mailto: And tel: they do not reference actual data.

3) an intent object that contains a data type but does not contain a URI can pass the test only when the filter lists the same data type and does not specify a URI.

4) an intent object that contains both the URI and the data type or can deduce the data type from the URI) can be tested if its type matches the type listed in the filter. If its URI matches a URI in the filter, or it has a content: or file: URI, and this filter does not specify a URI, it can also pass the test. In other words, a component is assumed to support content: and file: data if its filter lists only one data type.

If an intent can be filtered by more than one activity or service, the user may be asked to activate the component, and an exception will occur if the target object is not found.