Three-Step gray-box test and evaluation of mobile device applications

Gray-box testing for mobile device applications refers to a technology that combines traditional source code checks (white-box testing) with preliminary testing (black box testing. Testers must check the application code library, review key functional code, and review common error codes or illegal coding methods. In addition, testers can perform a black box test to review applications and locate the target code in the code library based on the identified vulnerability location.
Why do we need to perform gray-box tests and evaluations for mobile apps? The answer is simple: Find high-risk code and identify the root cause of the vulnerability.
The gray-box test should follow the three steps below:
1. Threat modeling
Threat modeling allows the test team to first identify the threats that may have the greatest impact on mobile applications. In this phase, testers primarily aim to prioritize specific application components or codes. The testing team should gradually familiarize themselves with the basic architecture and usage of mobile applications by understanding the documentation of the application architecture.
Collect information
By working with the development team of mobile apps, the testing team should obtain documents that help them understand the design and functions of mobile apps. The details described in these documents can lay the foundation for all steps in the threat modeling process.
Perform reconnaissance and application ing
Understanding how a mobile application implements its functions is essential to creating a mobile application model. In this phase, the test team should manually check the mobile application instances. Then, the team should check the anonymous part and authentication part of the mobile application, and focus on the part that processes sensitive data and functions. In this phase, the architecture, configuration, process, user, and technology certification documents should be provided to facilitate the use of the next phase.
Areas that need to be focused on and used for targeted testing in the next stage include management interfaces, transmission of sensitive information, interfaces of external or third-party applications, and mobile protocols (such as SMS, MMS, and WAP).
The test team should record each type of request and response during this period to facilitate future analysis using local proxy and network sniffing tools.
Define system and trusted boundaries
In the next phase of the inspection, the evaluation team should build a visual model of a series of processes in the mobile application and data flowchart. The data flow chart confirms the system boundaries and the trusted boundaries of each component around the mobile application. Validation of system boundaries can enable the test team to preliminarily identify all the locations of Data inflows or outflows from the system or its components (that is, data entry points and exit points. Then, in the code check phase, the test team should check whether appropriate verification and coding technologies are executed at each system boundary. Similarly, determining trusted boundaries can identify the test team's ability to verify the authentication and authorization sections in the code.
Map threats to Functions
After defining all the flow chart elements, the test team should map all elements to the asset threat to define the "Hotspot" in the mobile application and then build a test plan. In the targeted code check phase, the test team should fully test each project in the plan.
2. Vulnerability confirmation
During application evaluation, the hotspot source code confirmed in the previous stage should be checked with emphasis. In addition to checking the source code for undiscovered application vulnerabilities, enterprises should also perform a Black Box assessment to identify network or host-layer vulnerabilities. To supplement manual inspection of application components, automated scanning should be used in this testing phase.
Code Analysis and Scanning
Automated scanning tools can analyze all source code to detect security issues. In this phase, testers should use commercial and private tools to scan code with signs of security issues and common programming errors that can cause vulnerabilities. In the source code analysis phase, efforts should be made to identify vulnerabilities that may affect hosts, servers, and networks.
Manual Analysis
At this stage, we recommend that you check the application code in detail to discover the security vulnerabilities that are unique to the application architecture. When checking the code, we recommend that you use the following technologies in combination:
1. License analysis:Many platforms require mobile apps to declare what features they are trying to access during execution. The device then limits the application to use these specific features. Testers can launch attacks against these features and try to bypass these restrictions to verify their effectiveness.
2. Control Flow Analysis:This technique is used to analyze the logical conditions in the code. This method allows testers to identify common logical vulnerabilities, such as exceptions that cannot be handled by programs and inappropriate authorization restrictions.
3Data Stream Analysis:This technique tracks data from input points to output points, especially for identifying common input verification errors, such as SQL injection and cross-site scripting.
To apply these technologies, we recommend that enterprises split mobile applications into different functional components. Testers should check each component to find common insecure programming methods, including:
1. Authentication:Weak password requirements, poor user names, Account suspension, cookie replay attacks, and backdoors.
2. Authorization:Privilege Escalation, inappropriate power distribution, exposure of confidential data, and data damage.
3. session management:Session traps, Session Timeout, session hijacking, inappropriate session termination, session replay, man-in-the-middle attacks, etc.
4. Configuration Management: Unauthorized access to the management interface, unauthorized access to the configuration file, retrieval of configuration data, excessive privileges assigned to the process and service account.
5. input verification:Parameter damage, buffer area overflow, cross-site scripting attacks, SQL injection, XPATH hijacking, command hijacking, and so on.
6. Data protection:Perform hard coding, network communication sniffing, incorrect key generation, key management, and weak encryption for the privacy of mobile apps or users.
7. Exception Handling:Information Leakage and denial of service.
8. Audit and log:Logs are forged, manipulated, and damaged.
9. cache:During the lifecycle of a mobile application, the keys, snapshots, clipboard content, and files may be cached to different storage locations of the device.
10. Release notification:Transfers data from the server to the application.
11. Location-Based Services:Attempts to leak or spoof location data.
In addition, passwords are stored in plain text in the database.
Check architecture security issues in the code
This step is important if the application uses a specific security mechanism or has a function that can mitigate some "Notorious" security threats. The final code check is used to verify the specific security features of the application architecture:
Encryption: Because custom encryption solutions generally do not have robust encryption mechanisms, enterprises should check the solutions to verify whether they can fully protect sensitive data.
Protocol: testers should check the private protocol of Application Communication to determine their ability to respond to damages and listen.
Session management: The tester should check the following two aspects: one is the attempt to create a specific session identifier, and the other is the session management process. This aims to measure the protection capability when a management error occurs in the session.
Access restriction: The tester checks the use of specific HTTP headers or other specific protocol elements to control access and prevent unauthorized access.
Security code: some code is written to solve the previously discovered security problems. This tester needs to examine it to test its effectiveness.
Server Architecture: testers should check the external Web services and servers used to support mobile applications.
3. Vulnerability Exploitation
At this stage, the tester must develop a test plan to conduct in-depth analysis of the source code and find out whether common unsafe coding methods exist. Then, focus on the specific security mechanisms of mobile apps. The tester also looks for and checks the architecture security issues in the code.
Verify the identified issues
The test team should analyze the results from the vulnerability scan, remove the seemingly false information, and start to build usable cases.
Leverage unique features of mobile apps
The main benefit of the gray-box testing method is the ability to exploit vulnerabilities to the maximum extent. In this phase, testers will try to exploit non-obvious authentication and authorization vulnerabilities in mobile app instances. These vulnerabilities may lead to illegal access to functions or data, and pose a huge risk to enterprises. Testers also need to take advantage of business logic (used to control how users perform operations in mobile apps. These defects are generally used by users or companies that defraud mobile applications.
Link vulnerability exploitation with source code
Once the tester proves that the vulnerability is usable, it is necessary to associate the vulnerability with the specific part of the relevant code. This allows developers to quickly understand the problem and evaluate the workload required to fix the vulnerability.
Analyze risks
Testers should evaluate the vulnerabilities they can exploit and rate the Vulnerabilities Based on the risks that each vulnerability brings to the company. For vulnerabilities, testers also need to assess the potential impact on the company after the vulnerability is exploited. If testers can exploit multiple vulnerabilities and have a greater impact, this analysis has multiple meanings.
Provide specific technical suggestions
After evaluating the risk of each vulnerability, the tester should give specific suggestions on the mobile application architecture and code writing. If possible, it is best to include the source code. Then, developers can use these suggestions to mitigate or fix vulnerabilities and reduce application risks. The tester's suggestion also provides a secure coding guide to solve or fix mobile app vulnerabilities.
Here are several mobile security suggestions for developers and testers: incorporate the mobile security concept into development projects; build and implement a policy that can supervise mobile app development and ensure comprehensibility; train mobile app developers to help them implement secure coding; test whether sensitive data transmitted to mobile devices can be restricted; evaluate threats to Web applications and infrastructure.