About data openness in Android applications
Some information about what data in your application may be available to other programs and what measures you can take to prevent it.
The architecture of an Android application can be represented as a set of components (activities, services, etc.) and the links between them. The Android API provides several standard ways of communicating between application components: starting an activation / service through context, sending intent messages, using a ServiceConnection or ContentProvider, and more. All this can be read in any tutorial on data transfer to Android. However, there is one nuance about which, as a rule, is silent. It is about the availability of your components and the data transferred between them for other applications.
To start one of your activations, you probably use a specially prepared intent:
')
Using Context and Class, which you passed to the intent builder, Android determines the application package and the class itself, and then launches it.
You can also try to launch someone else's activations, knowing its package name and class name:
The result is a running activation.
Does this mean that all activations can be launched by a third-party application? Not. If we replace the classname in the previous example with
then we will get java.lang.SecurityException.
In fact, the application developer himself decides which activations will be available and which will not, indicating the android: exported tag for each activation in the manifest to true or false, respectively. The default value for this tag is false, i.e. All activities in AndroidManifest.xml that do not have this tag are available only within the application.
However, looking at the manifesto of the Contacts application (for example, here ) you can see that PeopleActivity does not have an android tag: exported = “true”, why did we manage to launch it? The answer can be found in the official documentation: if the activation contains any intent filter, then the default value for android: exported is true.
The application developer does not need to worry about the visibility of their activity outside the application until intent-filter appears in any activity. As soon as you declare an intent-filter, ask yourself if you are ready for the fact that this activity can be started by someone else. If not, do not forget to specify <android: exported = "false">.
The visibility of the service is defined as well as the visibility of the activit, and we would not give a separate item to the services if it were not for one “but”. In the case of the service, its visibility can lead far further than an unplanned start, as in the case of activation. If your service provides the possibility of binding , then others can use this opportunity and get a link to your service through the ServiceConnection. Let's look at an example of connecting to a standard music playback service.
Note: the following example is relevant only on fairly old versions of the player. The latest version of the developers figured out the exported flag and set it to false :)
After binding, the link to the service will be stored in the variable boundService. Then you can use java reflection or Android Interface Definition Language (AIDL) to be able to call service methods directly, as a result of which you can, for example, stop playback if the standard player already plays something.
The recommendations in this case are the same: set <android: exported = "false"> for all services that have any intent filter if you do not plan to leave it public.
The main purpose of ContentProvider is to provide data to other applications. That is why the default value of the <android: exported> tag for this component is true. But the main purpose is not the only one. ContentProvider is often used:
In all these cases, you most likely do not need to provide data outside the application. If this is true, then do not forget to specify the provider <android: exported = "false">.
Communication with the help of broadcast messages can be divided into 3 stages:
Each receiver specifies an IntentFilter when registering, and messages will be delivered to this receiver in accordance with this filter. As you can guess, the message receiver can satisfy the filter and be outside our application. You can achieve the privacy of messages sent by specifying the required package to the intent:
or use LocalBroadcastManager (available in the support library), which will also prevent the message from flying beyond the boundaries of the application (actually the process):
Moreover, LocalBroadcastManager allows you to register receivers, so you can be sure that the intents received by such receivers are also local, and do not arrive from the outside.
In short, all the resources used in the application are readable outside the application. To get some of them, all you need to know is the package name of the target application:
If you know the activation information inside the application, you can do similar operations for each of them separately.
Finding the name of a particular resource, you can get it:
In this way, we were able to display a preview image for the Youtube widget inside our own application.
The main problem with resources is that there is no way to hide them. Storing private data in resources is a bad idea, but if you have such a need, it is better to store them in encrypted form.
At the end of the article I would like to say a few more words about the file system in Android. This question is already well lit, many people know that in Android each application creates its own directory / data / data / "app package name", which only the application itself (or a group of applications with one sharedUserId) has access to. In this directory are the SharedPreferences settings files, application database files, cache and much more, however, you should not rely on the security of this repository. Files in this directory are unavailable only as long as:
This means that private data, as well as in the case of resources, must be encrypted, even if they are in internal storage.
Useful resources on the topic:
Security tips on developer.android.com article
Book Application Security For The Android Platform by Jeff Six
Components
The architecture of an Android application can be represented as a set of components (activities, services, etc.) and the links between them. The Android API provides several standard ways of communicating between application components: starting an activation / service through context, sending intent messages, using a ServiceConnection or ContentProvider, and more. All this can be read in any tutorial on data transfer to Android. However, there is one nuance about which, as a rule, is silent. It is about the availability of your components and the data transferred between them for other applications.
Activity
To start one of your activations, you probably use a specially prepared intent:
')
Intent myIntent = new Intent(CurrentActivity.this, NextActivity.class); startActivity(myIntent); Using Context and Class, which you passed to the intent builder, Android determines the application package and the class itself, and then launches it.
You can also try to launch someone else's activations, knowing its package name and class name:
Intent intent = new Intent(); /* */ intent.setClassName("com.android.contacts", "com.android.contacts.activities.PeopleActivity"); startActivity(intent); The result is a running activation.
Does this mean that all activations can be launched by a third-party application? Not. If we replace the classname in the previous example with
intent.setClassName("com.android.contacts", "com.android.contacts.preference.ContactsPreferenceActivity"); then we will get java.lang.SecurityException.
In fact, the application developer himself decides which activations will be available and which will not, indicating the android: exported tag for each activation in the manifest to true or false, respectively. The default value for this tag is false, i.e. All activities in AndroidManifest.xml that do not have this tag are available only within the application.
However, looking at the manifesto of the Contacts application (for example, here ) you can see that PeopleActivity does not have an android tag: exported = “true”, why did we manage to launch it? The answer can be found in the official documentation: if the activation contains any intent filter, then the default value for android: exported is true.
The application developer does not need to worry about the visibility of their activity outside the application until intent-filter appears in any activity. As soon as you declare an intent-filter, ask yourself if you are ready for the fact that this activity can be started by someone else. If not, do not forget to specify <android: exported = "false">.
Service
The visibility of the service is defined as well as the visibility of the activit, and we would not give a separate item to the services if it were not for one “but”. In the case of the service, its visibility can lead far further than an unplanned start, as in the case of activation. If your service provides the possibility of binding , then others can use this opportunity and get a link to your service through the ServiceConnection. Let's look at an example of connecting to a standard music playback service.
Note: the following example is relevant only on fairly old versions of the player. The latest version of the developers figured out the exported flag and set it to false :)
Intent intent = new Intent(); /* - */ intent.setClassName("com.android.music", "com.android.music.MediaPlaybackService"); ServiceConnection conn = new MediaPlayerServiceConnection(); /* */ bindService(intent , conn, 1); class MediaPlayerServiceConnection implements ServiceConnection { public void onServiceConnected(ComponentName name, IBinder boundService) { Log.i("service connection", "Connected! Name: " + name.getClassName()); } public void onServiceDisconnected(ComponentName name) { Log.i("MediaPlayerServiceConnection", "Disconnected!"); } } After binding, the link to the service will be stored in the variable boundService. Then you can use java reflection or Android Interface Definition Language (AIDL) to be able to call service methods directly, as a result of which you can, for example, stop playback if the standard player already plays something.
The recommendations in this case are the same: set <android: exported = "false"> for all services that have any intent filter if you do not plan to leave it public.
ContentProvider
The main purpose of ContentProvider is to provide data to other applications. That is why the default value of the <android: exported> tag for this component is true. But the main purpose is not the only one. ContentProvider is often used:
- when implementing hints when searching
- when exchanging data through the Sync Adapter
- as a level of abstraction over the database
In all these cases, you most likely do not need to provide data outside the application. If this is true, then do not forget to specify the provider <android: exported = "false">.
Broadcast
Communication with the help of broadcast messages can be divided into 3 stages:
- Creating intent
- Sending intent via Context # sendBroadcast (...)
- Obtaining intent by all registered BroadcastReceivers.
Each receiver specifies an IntentFilter when registering, and messages will be delivered to this receiver in accordance with this filter. As you can guess, the message receiver can satisfy the filter and be outside our application. You can achieve the privacy of messages sent by specifying the required package to the intent:
intent.setPackage(“com.android.example.mypackage”) or use LocalBroadcastManager (available in the support library), which will also prevent the message from flying beyond the boundaries of the application (actually the process):
LocalBroadcastManager.getInstance(context).sendBroadcast(intent); Moreover, LocalBroadcastManager allows you to register receivers, so you can be sure that the intents received by such receivers are also local, and do not arrive from the outside.
Resources
In short, all the resources used in the application are readable outside the application. To get some of them, all you need to know is the package name of the target application:
PackageManager pm = getPackageManager(); /* Youtube */ Drawable icon = pm.getApplicationIcon("com.google.android.youtube"); /* Youtube */ Drawable logo = pm.getApplicationLogo("com.google.android.youtube"); ApplicationInfo applicationInfo = pm.getApplicationInfo("com.google.android.youtube", 0); /* Youtube */ CharSequence applicationLabel = pm.getApplicationLabel(applicationInfo); If you know the activation information inside the application, you can do similar operations for each of them separately.
Finding the name of a particular resource, you can get it:
Resources r = getPackageManager().getResourcesForApplication("com.google.android.youtube"); /* - Youtube * youtube_widget_preview - * drawable - , * com.google.android.youtube - package name */ int id = r.getIdentifier("youtube_widget_preview", "drawable", "com.google.android.youtube"); Drawable drawable = r.getDrawable(id); ImageView iw = new ImageView(context); iw.setImageDrawable(drawable); rootView.addView(iw); In this way, we were able to display a preview image for the Youtube widget inside our own application.
The main problem with resources is that there is no way to hide them. Storing private data in resources is a bad idea, but if you have such a need, it is better to store them in encrypted form.
At the end of the article I would like to say a few more words about the file system in Android. This question is already well lit, many people know that in Android each application creates its own directory / data / data / "app package name", which only the application itself (or a group of applications with one sharedUserId) has access to. In this directory are the SharedPreferences settings files, application database files, cache and much more, however, you should not rely on the security of this repository. Files in this directory are unavailable only as long as:
- you create files with the Context.MODE_PRIVATE flag
- root access not received on device
- The application will not be processed by any backup manager.
This means that private data, as well as in the case of resources, must be encrypted, even if they are in internal storage.
Useful resources on the topic:
Security tips on developer.android.com article
Book Application Security For The Android Platform by Jeff Six
Source: https://habr.com/ru/post/212321/
All Articles