Mobile Application Security Testing Practices
Introduction
Today the number of mobile applications is increasing dramatically. Every month about 100,000 new mobile app releases appear only on Google Play (more detailsmore details). As of the second quarter of 2020, Google Play offered 2.7 million apps for Android. The Apple App Store provides 1.82 million apps for iOS (more detailsmore details). The number of mobile apps users is also growing rapidly. The whole world becomes mobile. Now every bank, every shop, every institution has its mobile application. And it is very convenient for its consumers. Everyone who owns a mobile device uses mobile apps extensively and spends an average of 4.2 hours per day on mobile devices (more detailsmore details ).
It is necessary to ensure safety regarding data privacy and data security while working with mobile applications. Mobile application providers shall ensure that consumers’ data are not lost. How can a user be sure that the mobile applications are secured and his or her personal and financial data are safe?
Nowadays, cyberattacks continue to occur frequently with data breaches and vulnerabilities. Hackers often have a good chance of success because more than 70% of mobile applications never pass security testing at all, and meanwhile more than 80% of them have at least one security vulnerability.
Industry requirements for mobile applications development and security testing have been developed to address this problem. Mobile Application Security Testing (MAST) is a practical remedy for this problem. MAST is a rapidly developing area. MAST tools have evolved over the past decade.
Let’s go through the MAST practices in detail.
MAST Practices
Application Security Testing (AST) includes a wide range of mature practices. A good overview of the AST practices is provided on the Maverix company website. (https://maverix.co/maverix-blog).
MAST is a part of AST. It has a similar set of practices; however, MAST practices have some specifics compared to AST.
How does MAST work with the architecture of mobile applications?
It consists of two layers – frontend on mobile device (mobile application) and backend. Strictly speaking, backend has a complex architecture (it may contain API gateway, database, server-side code, microservices, etc.), but for MAST backend is just an API.
MAST practices cover both layers frontend and backend. A frontend vulnerability affects only a single user per application at once, while a backend vulnerability can affect multiple users. For example, multiple users can suffer from one security flaw when using the same encryption key. In practice, there was such a case where a character string generated from the "secret" and the user name was used to access the chat, but the "secret" was the same for all users. After receiving this string, it was possible to chat on behalf of the user.
Backend vulnerabilities can often be exploited by vulnerabilities on the frontend This means that there is a certain connection between the exploitation of the frontend and backend security flaws.
For instance, when a user logins to the application or a website no new session is generated, only the rights are set for the current session. A link is then sent to the user, which could be opened through the deep link mechanism, the user logged into the application and the attacker received an active user session. The list of examples of vulnerabilities in mobile applications can be continued. They affect all users and cause reputational damage and losses.
The following diagram shows the architecture of a mobile application and the use of MAST practices to test the application:
All MAST practices can be divided into two groups. The first group includes practices applicable when the source code of the application is available. Practices from the second group are used when there is no application source code access, but only a binary file of an application.
If application source code is available, MAST includes the following practices:
- OSA (Open Source Analysis) for both frontend and backend (API) testing
- SCA (Software Composition Analysis) for both frontend and backend (API)
- SAST (Static Application Security Testing) for both frontend and backend (API)
These practices are effective during the mobile application code development process. They also complement the “no source code access” dynamic practices well when a workable version of the application is available. Different practices work better at finding different types of vulnerabilities. Also, dynamic “no source code access” practices can confirm vulnerabilities found by static “source code access” practices. In general, finding security vulnerabilities is a complex process that ideally should involve several different practices.
In case of no source code access, MAST practices are:
- BCA (Bytecode and Container Analysis) for frontend testing
- IAST (Interactive Application Security Testing) for frontend testing
- DAST (Dynamic Application Security Testing) for frontend testing
- API ST (API Security Testing) for backend (API) testing
- BAST (Behavioral Application Security Testing) for frontend testing
- Penetration Testing (Pen Test) for both frontend and backend (API)
These practices are applicable when a workable version of the application is available. This part of MAST is close to what a hacker can do with a mobile application having no application source code.
Let’s consider the specifics of MAST practices one by one.
SAST
Static Application Security Testing (SAST) is a white box method of security testing based on the static analysis of application source code. SAST tools use different methods of code static analysis.
From the view of mobile application architecture, SAST practice is used for both application frontend and backend (API) testing.
One of the SAST techniques is to graph all data flows in an application and check how the data flows from entry points to exit points. If the data is not validated during their itinerary or sanitized properly, we can say that there is a potential security breach in this place. SAST can also analyze configuration files, scan for unsafe application settings, and detect the use of potentially dangerous methods. The main disadvantage of SAST is the large number of potential vulnerabilities that may never be implemented or may even be false positives. In most cases, false positives are caused by the complexity of the applications being analyzed and the many different frameworks and methods to do the same thing in entirely different ways.
Typical vulnerabilities that SAST detects are, for example, hardcoded passwords, tokens and encryption keys, as well as various injections and incorrect work with user data that can result in the injections or overflows. Despite the fact that SAST shows a relatively large number of vulnerabilities, they have yet to be confirmed, and this is where the DAST and IAST practices can help.
OSA
Open Source Analysis (OSA) is applied for application source code. OSA protects software engineering perimeter at the company level from vulnerable components at the early stage. OSA is applied to check the security of new open-source software code libraries and components before adding them to the company's repository. All open-source software code libraries and components stored in the company repository are considered secured after the OSA check and can be used by all development teams in the company. OSA uses public issue trackers (for example, National Vulnerability Database) for open source components to define a list of vulnerabilities. OSA shall be mainly targeted to the new open source code that is being added to the application.
OSA is used for mobile application frontend and backend (API) testing.
SCA
Software Composition Analysis (SCA) is based on application source code analysis.
SCA is applied to check the security of all open source code libraries and components included in the mobile application development project. The use of OSA does not guarantee the absence of vulnerable open source code. Developers can take a library not from the secure repository of the company. SCA identifies a list of source code libraries and components used by the mobile application based on the application build file. SCA of open source libraries and components used by applications is performed in terms of known security vulnerabilities and license violations. Having the components list, SCA uses public issue trackers for open source components to define a list of vulnerabilities. SCA is applied to all source code of the application.
SCA is used for mobile application frontend and backend (API) testing.
As an example of applying the SCA practice, let's mention a case with a vulnerability that existed in the Google Play Core Library that allowed an application to be updated at runtime, add arbitrary code, and run it in the context of an application. In this way, malicious software could be added to a mobile device using this library to retrieve any personal information. This vulnerability affected absolutely all applications that used this library and its functionality. Without using the SCA practice, it would be challenging to know if your applications are using this library and which particular version of it.
DAST
Dynamic Application Security Testing (DAST) is a black box method of testing. DAST is performed over the user interface. It tests the mobile application frontend from the user’s point of view. DAST often uses fuzzing as a testing method. It essentially involves sending irrelevant data and using inappropriate commands and analyzing what happened to the application after it sent this data and commands.
Several models of malefactor mode of operation can be used for dynamic testing of mobile applications. One model is when a malefactor has the root access permissions for Android or jailbreak mode for iOS. Another model is when a malefactor has no root access or jailbreak and works with regular user permission. In this case, DAST is performed for a non-privileged mobile application. DAST adds value when testing a non-privileged application using various techniques to find “live” vulnerabilities without root access/ jailbreak. Vulnerabilities found using only public methods for non-privileged applications are the most valuable because exploiting them is possible right after installing the mobile application from Play Market or App Store.
DAST is used for mobile application frontend testing.
The dynamic analysis allows you to confirm potential vulnerabilities found using the SAST practice. It also helps to find out what was not covered by SAST and is only revealing itself in the dynamics. For example, a classic method of applying the DAST practice is to look for different injection and fuzzing entry points in an application. In this way, you can determine how an application will react to invalid data in various requests to application components. On the other hand, you can find the most interesting vulnerabilities in the dynamics. One example is bypassing address validation when passing a link to WebView. There are at least four methods of forcing an application to open any address instead of the desired one, despite the built-in code checks (which SAST marks as correct data validation).
API ST
Application Programming Interface Security Testing (API ST) is used for mobile application backend (API) testing. It is based on messaging between the application frontend and backend. API ST essentially involves sending irrelevant data and using inappropriate commands. Some sources consider API ST as a part of DAST. However, API ST tests mobile application backend (API), while DAST tests mobile application frontend.
If you just got an application binary file, there is no information about its API. In this context, it works like a black box. Because of this, API ST is a non-trivial task in the absence of supporting things like Swagger.
Swagger framework and its open source tools help increase the effectiveness of API ST. Knowing the application APIs via Swagger enables you to create tests based on the interactions between the application frontend and backend. However, Swagger does not provide the complete information required for API ST tests creation.
For example, application API often contains data fields, which depends on the operating system. Thus, an effective API ST requires additional information in addition to that provided by Swagger. Moreover, Swagger, in most cases, is not available. It is typically used internally by the application development team only.
The Web Services Description Language (WSDL)/ Web Application Description Language (WADL) file for the application can be considered as an alternative to Swagger, if this file is available.
If no Swagger or WSDL file is available, you can sniff traffic between the application frontend and backend and use this information for an effective API ST.
IAST
Interactive Application Security Testing (IAST) checks application behavior on the device. IAST performs interception and analysis of application sensitive information, including writing to files and logs, communication with internal and external components, network traffic, communication with SQL databases, system functions calls, etc. IAST allows to compose advanced attack scenarios based on the collected data.
The IAST practice is based on user interactions with an application. During this interaction, a certain amount of relevant test data for further analysis is generated. You can execute IAST test cases and collect test data by manually performing the application's business operations. However, one cannot include such manual activities in the CI/CD process. To fulfill this requirement, you need to think over the test automation process. For full-fledged IAST that can be included in the CI/CD process, IAST test automation shall include two aspects:
- Automate the test cases creation. It is optional for IAST. IAST test cases can either be generated automatically or recorded by the test engineer. Practically, auto generated tests do not provide good results. Therefore, the option of creating them by the test engineer and further automatic launch during the CI/CD process is preferable.
- Automate the test case execution. Execution of IAST test cases essentially requires test automation. It is a must for IAST.
IAST is used for mobile application frontend testing.
With the IAST practice, one can find a variety of vulnerabilities that cannot be covered by the SAST and DAST practices. Thus, IAST can be used in identifying the new types of vulnerabilities. Since IAST is built based on observing the behavior of the application, it is possible to identify and determine all the sensitive information the application is working with and understand the flow of the information.
For instance, you can track the transfer of the user's personal data to a third party (for example, to analytics systems) or caching authentication data on the device. Another interesting vulnerability that IAST practice can discover is the execution of arbitrary code in the application context when monitoring calls to load native libraries and work with zip files from publicly accessible parts of the file system. Having detected the work with zip files, which can be affected by the user and the operation of an application with native libraries, you can create a particular zip file ,when unzipped, implements the Path Traversal vulnerability and overwrites the native library, which is then loaded the next time the device is started.
BAST
Behavioral Application Security Testing (BAST) is used for the analysis of the application behavior. Based on the model of application behavior, you can determine if this application is malware or a virus, or not. BAST gathers application behavior profiles and compares them with known malware profiles. It is referred to as a method of virus detection based on a profile of application behavior. The other method is signature-based. It checks the application hash sum.
BAST can be used for corporate mobile device management, when users cannot install some mobile applications, whose behavior is classified as potentially dangerous.
BAST is used for mobile application frontend testing.
BCA
Byte Code Analysis (BCA) shall be applied for application binary code derived from application artifacts. Intentional obfuscation of the application source code can complicate BCA.
The base for BCA differs for different mobile operating systems:
- Android: APK file decomplication allows you to get almost the original readable application source code. The source code derived from the application artifact can differ significantly from the original source code if obfuscated. Intentional obfuscation of the application source code complicates BCA.
- iOS: IPA file disassembling allows you to get application assembler code. It cannot obtain readable source code for analysis.
The BCA practice is beneficial for checking the release version of the application to make sure it was built with the correct settings, and it does not contain debug and test data. Also, BCA checks that the release version only uses the files necessary for its operation, and it does not include files such as build scripts, dependency files, etc.
BCA is used for mobile application frontend testing.
Pen Test
Penetration testing is performed manually using a black box (without access to application source code) approach. It simulates an external attack much like an actual attacker would do. For example, it can simulate targeted phishing or exfiltration of sensitive data or credentials. This type of attempt to uncover potential vulnerabilities exploited to attack the application is also known as “ethical hacking”.
Data on potential problems identified using other AST practices can significantly improve the effectiveness of manual penetration testing.
One cannot automate the manual penetration testing. That is why it is often not used by development companies for security testing on applications they produce. Many companies outsource penetration testing to a professional vendor to evaluate their application security as a one-time check.
Penetration testing allows you to get the current snapshot of the application's security relatively quickly. Unfortunately, it cannot be integrated into the development process, since it is manual work. But this is also its advantage. If you examine an application by hand, primarily using information from other practices (SAST, DAST, IAST, OSA), you can find much more complex vulnerabilities that automated tools cannot find. However, in most cases, this is only possible after the completion of other practices. By using this, you can get 80% of the vulnerabilities with 20% of the effort. The remaining 20% of vulnerabilities can be found manually, using penetration testing.
Summary
Mobile AST shall be planned, organized and performed as follows:
- Cover both the mobile application front-end code on the mobile device, and its interaction with the application back-end code (this type of testing is called Application Programming Interface Security Testing, API ST).
- Combine the static and dynamic application security testing methods adapted to Mobile AST. The static analysis can be performed based on the source, binary, or bytecode of an application, and support different programming languages (like Swift or Objective-C). The dynamic analysis methods have to test interactions between the mobile application front-end and the back-end.
- It is recommended to perform testing of typical business operations when working with an application in order to identify actions that a malefactor could exploit.
- If there is a web version of the application, mobile AST shall be integrated with AST of web application. For example, the same application API is often used for mobile and web versions of the application. By using such application implementation features, you gain synergies in performing application security testing.
- Use tools and approaches that enable automated testing and DevSecOps.