Trending

Android Application Security Testing Part-14: Android Manifest File



Android Manifest File
·         Every application must have a AndroidManifest.xml file (with precisely that name) in its root directory.
·         The manifest file provides essential information about your app to the Android build tools, the Android operating system, and Google Play.
·         The manifest file is required to declare the following
o    The app's package name, which usually matches your code's namespace. The Android build tools use this to determine the location of code entities when building your project. When packaging the app, the build tools replace this value with the application ID from the Gradle build files, which is used as the unique app identifier on the system and on Google Play.
o    The permissions that the app needs in order to access protected parts of the system or other apps. It also declares any permissions that other apps must have if they want to access content from this app.
o    The components of the app, which include all activities, services, broadcast receivers, and content providers. Each component must define basic properties such as the name of its Kotlin or Java class. It can also declare capabilities such as which device configurations it can handle, and intent filters that describe how the component can be started
o    The hardware and software features the app requires, which affects which devices can install the app from Google Play
·         Structure of the Manifest File
<?xml version="1.0" encoding="utf-8"?>

<manifest>

    <uses-permission />
    <permission />
    <permission-tree />
    <permission-group />
    <instrumentation />
    <uses-sdk />
    <uses-configuration /> 
    <uses-feature /> 
    <supports-screens /> 
    <compatible-screens /> 
    <supports-gl-texture /> 

    <application>

        <activity>
            <intent-filter>
                <action />
                <category />
                <data />
            </intent-filter>
            <meta-data />
        </activity>

        <activity-alias>
            <intent-filter> . . . </intent-filter>
            <meta-data />
        </activity-alias>

        <service>
            <intent-filter> . . . </intent-filter>
            <meta-data/>
        </service>

        <receiver>
            <intent-filter> . . . </intent-filter>
            <meta-data />
        </receiver>

        <provider>
            <grant-uri-permission />
            <meta-data />
            <path-permission />
        </provider>

         <uses-library />
     </application>
 </manifest>
·         Elements of the AndroidManifest.xml file
The elements used in the above xml file are described below.

<manifest>

manifest is the root element of the AndroidManifest.xml file. It has package attribute that describes the package name of the activity class.

<application>

application is the subelement of the manifest. It includes the namespace declaration. This element contains several subelements that declares the application component such as activity etc.
The commonly used attributes are of this element are iconlabeltheme etc.
android:icon represents the icon for all the android application components.
android: label works as the default label for all the application components.
android: theme represents a common theme for all the android activities.

<activity>

activity is the sub element of application and represents an activity that must be defined in the AndroidManifest.xml file. It has many attributes such as label, name, theme, launch Mode etc.
android: label represents a label i.e. displayed on the screen.
android: name represents a name for the activity class. It is required attribute.

<intent-filter>

intent-filter is the sub-element of activity that describes the type of intent to which activity, service or broadcast receiver can respond to.

<action>

It adds an action for the intent-filter. The intent-filter must have at least one action element.

<category>

It adds a category name to an intent-filter.
·         Elements for Application Properties
o    uses-permission – used to specify permissions that are requested for the purpose of security.
o    permission – used to set permissions to provide access control for some specific component of the application.
o    permission-group – does the same as above for a set of components.
o    permission-tree – refer one specific name of the component which is the owner or parent of the set of component.
o    instrumentation – enables to know interaction between Android system and application.
o    uses-sdk – specifies the platform compatibility of the application.
o    uses-configuration – specifies set of hardware and software requirement of the application.
o    uses-feature – specifies single hardware and software requirement and their related entity.
o    supports-screens, compatible-screens – both these tags deals with screen configuration mode and size of the screen and etc.
o    supports-gl-texture – specifies texture based on which the application is filtered.
·         Elements for Application Components
·         These should be enclosed in <application> container.
o    activity – has the set of attributes based on user interface.
o    activity-alias – specifies target activities.
o    service – has the operation provided by any library or API, running in background that is not visible.
o    receiver – that makes to receive message broadcasted by the same application or by outside entity.
o    provider – provides some structure to access application data.
o    uses-library – it specifies set of library files need to run the application.
Security in AndroidManifest file
·         Standard security guidelines in AndroidManifest.xml:
o    Debug Mode
o    Backup Flag
o    External Storage
o    Permissions
o    Application Components
o    Intents
·         Debug Mode
Inspect Androidmanifest.xml file for the following line.

android:debuggable=”true”

If we find the above line in the AndroidManifest.xml file, the application is debuggable and it can be exploited.

Solutions:
<application
android:debuggable="false"
</application>

Useful Link
·         BackUp Flag
Inspect Androidmanifest.xml file for the following line.

android:allowBackup="true"

       This setting defines application data can be backed up and restored by a user who has enabled usb debugging. Therefore applications that handle and store sensitive information such as card details, passwords etc. should have this setting set to false to prevent such risks.
Solution:
<application
android:allowBackup="false"
</application>

·         External Storage
Applications that have the permission to copy data to external storage should be reviewed to ensure that no sensitive information is stored.

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

·         Permissions
The android protection Level attribute defines the procedure that the system should follow before grants the permission to the application that has requested it. There are four values that can be used with this attribute:
    Normal
    Dangerous
    Signature
    SignatureOrSystem
All the permissions that the application requests should be reviewed to ensure that they don’t introduce a security risk.

<permission>
android:protectionLevel="signature"
</permission>permission.WRITE_EXTERNAL_STORAGE"/>

·         Application Components
         Depending of the functionality an application can launch a service, perform an activity, receive content from another source or receive intents by the phone or by other applications. We know that there are four application components:
    Activities
    Services
    Content Providers
    Broadcast Receivers
             Activities, Services, Content Providers and Broadcast Receivers can all be exported. Therefore all of them they should be reviewed that they don’t perform any sensitive action and that they are protected by appropriate permissions as otherwise information could be exposed to malicious third parties.

The following Code demonstrates how a broadcast receiver is defined in the manifest file:
<receiver
android:exported="true"
android:name="string"
android:permission="string"
</receiver>
·         Intents
                      Intents can be used to launch an activity, to send it to any interested broadcast receiver components, and to communicate with a background service. Intents messages should be reviewed to ensure that they doesn’t contain any sensitive information that could be intercepted.

<intent-filter>
<action android:name="string" />
<category android:name="string" />
</intent-filter>

Useful Links:



No comments