3. Basic Knowledge of Secure Design and Secure Coding
Although the Guidebook is a collection of security advice concerning Android application development, this chapter will deal with the basic knowledge on general secure design and secure coding of Android smartphones and tablets. Since we will be referring to secure design and coding concepts in the later chapters we recommend that you familiarize yourself with the content contained in this chapter first.
3.1. Android Application Security
There is a commonly accepted way of thinking when examining security issues concerning systems or applications. First, we need to have a grasp over the objects we want to protect. We will call these "assets". Next, we want to gain an understanding over the possible attacks that can take place on an asset. We will call these "threats". Finally, we will examine and implement measures to protect "assets" from the various "threats". We will call these "countermeasures".
What we mean by "countermeasures" here is secure design and secure coding, and will deal with these subjects after Chapter 4. In this section, we will focus on explaining "assets" and "threats".
3.1.1. "Asset": Object of Protection
There are two types of "objects of protection" within a system or an application: "information" and "functions". We will call these "information assets" and "function assets". "An information asset" refers to the type of information that can be referred to or changed only by people who have permission. It is a type of information that cannot be referred to or changed by anyone who does not have the permission. "A function asset" refers to a function that can be used only by people who have permission and no one else.
Below, we will introduce types of information assets and functional assets that exist in Android smartphones and tablets. We would like you to use the following as a point of reference to deliberate on matters with regard to assets when developing a system that utilizes Android applications or Android smartphones/tablets. For the sake of simplicity, we will collectively call Android smartphones/tablets as Android smartphones.
3.1.1.1. Information Assets of the Android Smartphone
Table 3.1.1 and Table 3.1.2 are examples of information contained in Android smartphones. This information is personal information, privacy information, or similar information about smartphone users and must be properly protected.
Information |
Remarks |
Phone number |
Telephone number of the smartphone itself |
Call history |
Time and date of incoming and outgoing calls as well as phone numbers |
IMEI |
Device ID of the smartphone |
IMSI |
Subscriber ID |
Sensor information |
GPS, geomagnetic, rate of acceleration, etc. |
Various setup information |
Wi-Fi setting value, etc... |
Account information |
arious account information, authentication information, etc. |
Media data |
Pictures, videos, music, recording, etc… |
… |
Information |
Remarks |
Contacts |
Contacts of acquaintances |
E-mail address |
User's e-mail address |
Web bookmarks |
Bookmarks |
Web browsing history |
Browsing history |
Calendar |
Plans, to-do list, events, etc. |
SNS content, etc. |
|
X |
SNS content, etc. |
… |
The information in Table 3.1.1 is mainly contained in the Android smartphone itself or on the SD card, while the information in Table 3.1.2 is mainly managed by applications. Especially for the information in Table 3.1.2, the more applications that are installed, the more information will be stored in the device.
Table 3.1.3 shows the information contained in a single Contacts entry. This information is not about the smartphone user, but about the smartphone user’s acquaintances, friends, and others. In other words, the smartphone contains information not only about the user, but also about other people, and so caution is necessary.
Information |
Description |
Telephone numbers |
Home, mobile, work, fax, MMS,… |
Email addresses |
Home, work, mobile,… |
Profile images |
Thumbnail image, large image,… |
Instant messengers |
Messages, WhatsApp, LINE, Facebook Messenger, WeChat, Telegram,… |
Nickname |
Abbreviations, initials, maiden name, alias,… |
Addresses |
Country, postal code, region, province, town, street,… |
Groups |
Favorites, family, friends, colleagues,… |
Websites |
Blog, profile site, home page, FTP server, home, office,… |
Events |
Birthdays, anniversaries, other,… |
People involved with |
Spouse, children, father, mother, manager, assistant, live-in relationship, partner,… |
SIP addresses |
Home, work, other,… |
… |
… |
In the previous explanations, we have mainly presented information about smartphone users, but applications also handle information other than that of users.
Fig. 3.1.1 shows the information managed by an application, which can be roughly divided into a program part and a data part. The program part is mainly information about the application manufacturer, and the data part is mainly information about the user. Since some of the application manufacturer’s information may not be used by the user without permission, such information must be protected so that the user cannot refer to or change it.
Fig. 3.1.1 Information Contained in an Application
When creating an Android application, it is important to note that not only the information managed by the application itself, shown in Fig. 3.1.1, but also the information obtained from the Android smartphone itself and other applications, shown in Table 3.1.1, Table 3.1.2, and Table 3.1.3.
3.1.1.2. Function Assets of an Android Smartphone
Table 3.1.4 is an example of functions provided by Android OS to the application. If these functions are exploited by malware or other malicious software, damages including unintended charges and compromise of privacy may occur. For this reason, function assets must be protected appropriately as with information assets.
Function |
Function |
Function that sends and receives SMS messages |
Camera shooting function |
Telephone call function |
Volume changing function |
Network communication function |
Function that reads the phone number and mobile phone status |
Function that acquires the current location through GPS, etc. |
SD card writing function |
Bluetooth communication function |
System setting change function |
NFC/FeliCa communication function |
Log data reading function |
Internet communication (SIP) function |
Function that acquires information of currently running application |
… |
… |
In addition to functions provided to the application from Android OS, inter-application communication functions of the Android application are included as function assets. The Android application enables use of functions available within the application from other applications. This mechanism is called inter-application communication. While this function is useful, there are cases in which functions that are to be used solely within the application can be mistakenly used from other applications. This is due to the Android application developer’s lack of secure coding knowledge. Depending on the content of functions that can be used by other applications, there are cases that may be troublesome if used by malware. For this reason, proper protection is required so that the functions can be used only from intended applications.
he API Level of targetSdkVersion is set to 30 on the sample code of this guide and access definition is in the <queries> element for the sample that sends queries to or operates other applications. This complies with the principle of least privilege introduced for the package access specification for Android 11 .
Also, Google Play restricts the use of high risk or sensitive information permissions, including the SMS or call log permission groups, and applications that fail to meet policy requirements or submit a declaration form may be removed from Google Play [1] .
3.1.2. "Threats": Attacks that Threaten Assets
In the previous section, we discussed assets in Android smartphones. This section describes the threats to those assets, in other words, the attacks that threaten them. Simply put, an asset is threatened when information assets are referenced, modified, deleted, or created by others without permission, or when functional assets are used by others without permission. Attacks that directly or indirectly manipulate such assets are called threats. The person or thing that carries out the attack is called the threat source. Attackers and malware are threat sources, not threats. We refer to the attacking behavior of the attacker or malware as the threat. The relationship between these terms is shown in Fig. 3.1.2.
Fig. 3.1.2 Relationship between Assets, Threats, Threat Sources, Vulnerabilities, and Damage
Fig. 3.1.3 shows the general environment in which an Android application runs. In the following sections, we will use this figure as a basis for explaining threats to Android applications, so we will first explain how to view this figure.
Fig. 3.1.3 Android General Environment in which an Android Application Runs
Smartphones and servers are placed on the left and right sides in the figure. Smartphones and servers communicate via 3G/4G/5G/Wi-Fi and the Internet. Although there are multiple applications in a smartphone, this figure focuses on a single application in order to explain the threats related to one application in the subsequent explanations. The application on a smartphone mainly handles the information of its user, while the web service on a server represents the centralized management of all users’ information. Therefore, server security remains as important as before. Server security is not covered in this Guidebook because it is outside its scope.
In the following sections, we will use this diagram to explain the threats in Android applications.
3.1.2.1. Network-based Third-Party
Fig. 3.1.4 Network-Based Malicious Third Party Attacking an Application
Generally, a smartphone application manages user information on a server so the information assets will move between the networks connecting them. As indicated in Fig. 3.1.4, a network-based malicious third party may access (sniff) any information during this communication or try to change information (data manipulation). The malicious attacker in the middle (also referred to as "Man in The Middle") can also pretend to be the real server tricking the application. Without saying, network-based malicious third parties will usually try to attack the server as well.
3.1.2.2. Threat Due to User-Installed Malware
Fig. 3.1.5 Malware Installed by a User Attacks an Application
The biggest selling point of a smartphone is in its ability to acquire numerous applications from the market in order to expand on its features. The downside to users being able to freely install many applications is that they will sometimes mistakenly install malware. As shown in Fig. 3.1.5, malware may exploit the inter-application communication functions or a vulnerability in the application in order to gain access to information or function assets.
3.1.2.3. Threat of an Malicious File that Exploits a Vulnerability in an Application
Fig. 3.1.6 Attack from Malicious Files that Exploit a Vulnerability in an Application
Various types of files such as music, images, videos and documents are widely available on the Internet and typically users will download many files to their SD card in order to use them on their smartphone. Furthermore, it is also common to download attached files sent in an e-mail. These files are later opened by a viewing or editing application.
If there is any vulnerability in the function of an application that processes these files, an attacker can use a malicious file to exploit it and gain access to information or function assets of the application. In particular, vulnerabilities are often present in processing a file format with a complex data structure. The attacker can fulfill many different goals when exploiting an application in this way.
As shown in Fig. 3.1.6, an attack file stays dormant until it is opened by a vulnerable application. Once it is opened, it will start causing havoc by taking advantage of an application's vulnerability. In comparison to an active attack, we call this attack method a "Passive Attack."
3.1.2.4. Threats from a Malicious Smartphone User
Fig. 3.1.7 Attacks from a Malicious Smartphone User
With regard to application development for an Android smartphone, the environment as well as features that help to develop and analyze an application are openly provided to the general user. Among the features that are provided, the useful ADB debugging feature can be accessed by anyone without registration or screening. This feature allows an Android smartphone user to easily perform OS or application analysis.
As it is shown in Fig. 3.1.7, a smartphone user with malicious intent can analyze an application by taking advantage of the debugging feature of ADB and try to gain access to information or function assets of an application. If the actual asset contained in the application belongs to the user, it poses no problem, but if the asset belongs to someone other than the user, such as the application developer, then it will become a concern. Accordingly, we need to be aware that the legitimate smartphone user can maliciously target the assets within an application.
3.1.2.5. Threats from Third Party in the Proximity of a Smartphone
Fig. 3.1.8 Attacks from a Malicious Third Party in the Proximity of a Smartphone
Due to face that most smartphones possess a variety of near-field communication mechanisms, such as NFC, Bluetooth and Wi-Fi, we must not forget that attacks can occur from a malicious attacker who is in physical proximity of a smartphone. An attacker can shoulder surf a password while peeping over a user who is inputting it in. Or, as indicated in Fig. 3.1.8, an attacker can be more sophisticated and attack the Bluetooth functionality of an application from a remote distance. There is also the threat that a malicious person could steal the smartphone creating a risk of data leakage or even destroy the smartphone causing a loss of critical information. Developers need to take these risks into consideration as well as early as the design stage.
3.1.2.6. Summary of Threats
Fig. 3.1.9 Summary of the Various Attacks on Smartphone Applications
Fig. 3.1.9 summarizes the main types of threats explained in the previous sections. Smartphones are surrounded by a wide variety of threats and the figure above does not include all of them. Through our daily information gathering, we need to spread the awareness concerning the various threats that surround an Android application and be aware of them during the application's secure design and coding. The following literature that was created by Japan's Smartphone Security Association (JSSEC) contains other valuable information on the threats to smartphone security.
3.1.3. Asset Classification and Protective Countermeasures
As was discussed in the previous sections, Android smartphones are surrounded by a variety of threats. Protecting every asset in an application from such threats could prove to be very difficult given the time it takes for development and due to technical limitations. Consequently, Android application developers should examine feasible countermeasures for their assets. This should be done according to priority level based on the developer's judgement criteria. This is a subjective matter that is based on how the importance of an asset is viewed and what the accepted level of damage is.
In order to help decide on the protective countermeasures for each asset, we will classify them and stipulate the level of protective countermeasures for each group. This will be achieved by examining the legal basis, pertaining to the level of importance regarding the impact of any damages that can occur and the social responsibility of the developer (or organization). These will prove to be the judgement criteria when deciding on how to handle each asset and the implementation of the type of countermeasures. Since this will become a standard for application developers and organizations on determining how to handle an asset and provide protective countermeasures, it is necessary to specify the classification methods and pertaining countermeasures in accordance the application developer's (or organization's) circumstances.
Asset classification and protective countermeasure levels that are adopted in the Guidebook are shown below for reference:
Asset Classification |
Asset Level |
Level of Protective Counter-Measures |
|---|---|---|
High [2] |
The amount of damage the asset causes is fatal and catastrophic to the organization or an individual's activity. i.e.) When an asset at this level is damaged, the organization will not be able to continue its business. |
Provide protection against sophisticated attacks that break through the Android OS security model and prevent root privilege compromises and attacks that alter the dex portion of an APK. Ensure security takes priority over other elements such as user experience, etc. |
Medium |
The amount of damage the asset causes has a substantial impact the organization or an individual's activity. i.e.) When an asset at this level is damaged, the organization's profit level deteriorates, adversely affecting its business. |
Utilize the Android OS security model. It will provide protection covered under its scope. Ensure security takes priority over other elements such as user experience, etc. |
Low |
The amount of damage the asset causes has a limited impact on the organization or an individual's activity. i.e.) When an asset at this level is damaged, the organization's profit level will be affected but is able to compensate its losses from other resources. |
Utilize the Android OS security model. It will provide protection covered under its scope. Compare security countermeasures with other elements such as user experience, etc. At this level, it is possible for non-security issues to take precedence over security issues. |
Asset classification and protective countermeasures described in the Guidebook are proposed under the premise of a secure Android device where root privilege has not been compromised. Furthermore, it is based on the security measures that utilize the security model of Android OS. Specifically, we are hypothetically devising protective countermeasures by utilizing the Android OS security model on the premise of a functioning Android OS security model against assets that are classified lower than or equal to the medium level asset.
3.1.4. Sensitive Information
The term "sensitive information", instead of information asset, will be used from now on in the Guidebook. As it has been aforementioned in the previous section, we have to determine the asset level and the level of protective countermeasures for each information asset that an application handles.
3.2. Handling Input Data Carefully and Securely
Validating input data is the easiest and yet most effective secure coding method. All data that is inputted into the application either directly or indirectly by an outside source needs to be properly validated. To illustrate best practices of input data validation, the following is an example of an Activity as used in a program that receives data from Intent.
It is possible that an Activity can receive data from an Intent that was tampered by an attacker. By sending data with a format or a value that a programmer is not expecting, the attacker can induce a malfunction in the application that leads to some sort of security incident. We must not forget that a user can become an attacker as well.
Intents are configured by action, data and extras, and we must be careful when accepting all forms of data that can be controlled by an attacker. We always need to validate the following items in any code that handles data from an untrusted source.
(a) Does the received data match the format that was expected by the programmer and does the value fall in the expected scope?
(b) Even if you have received the expected format and value, can you guarantee that the code which handles that data will not behave unexpectedly?
The next example is a simple sample where HTML is acquired from a remote web page in a designated URL and the code is displayed in TextView. However, there is a bug.
Sample Code that Displays HTML of a Remote Web page in TextView
TextView tv = (TextView) findViewById(R.id.textview);
InputStreamReader isr = null;
char[] text = new char[1024];
int read;
try {
String urlstr = getIntent().getStringExtra("WEBPAGE_URL");
URL url = new URL(urlstr);
isr = new InputStreamReader(url.openConnection().getInputStream());
while ((read=isr.read(text)) != -1) {
tv.append(new String(text, 0, read));
}
} catch (MalformedURLException e) { //...
From the viewpoint of (a), "urlstr is the correct URL", verified through the non-occurrence of a MalformedURLException by a new URL(). However, this is not sufficient. Furthermore, when a "file://..." formatted URL is designated by urlstr, the file of the internal file system is opened and is displayed in TextView rather than the remote web page. This does not fulfill the viewpoint of (b), since it does not guarantee the behavior which was expected by the programmer.
The next example shows a revision to fix the security bugs. Through the viewpoint of (a), the input data is validated by checking that "urlstr is a legitimate URL and the protocol is limited to http or https." As a result, even by the viewpoint of (b), the acquisition of an Internet-routed InputStream is guaranteed through url.openConnection().getInputStream().
Revised sample code that displays HTML of Internet-based Web page in TextView
TextView tv = (TextView) findViewById(R.id.textview);
InputStreamReader isr = null;
char[] text = new char[1024];
int read;
try {
String urlstr = getIntent().getStringExtra("WEBPAGE_URL");
URL url = new URL(urlstr);
String prot = url.getProtocol();
if (!"http".equals(prot) && !"https".equals(prot)) {
throw new MalformedURLException("invalid protocol");
}
isr = new InputStreamReader(url.openConnection().getInputStream());
while ((read=isr.read(text)) != -1) {
tv.append(new String(text, 0, read));
}
} catch (MalformedURLException e) { //...
Validating the safety of input data is called "Input Validation" and it is a fundamental secure coding method. Surmising from the sense of the word of Input Validation, it is quite often the case where the viewpoint of (a) is heeded but the viewpoint of (b) is forgotten. It is important to remember that damage does not take place when data enters the program but when the program "uses" that data in an incorrect way. We hope that you will refer the URLs listed below.