Grey box test for mobile device applications

The so-called gray-box test for mobile devices is a technique that combines traditional source code checking (white box testing) with pre-Test (Black-box testing). Testers must examine the code base of the application, review critical functionality code, and review common error codes or illegal encoding methods. In addition, the tester can perform a black-box test to review the application and locate the target code in the code base based on the identified vulnerability.

Why do the gray-box tests and evaluations of mobile applications? The answer is simple: find the high risk code, and identify the root cause of the vulnerability.

Gray-Box testing should follow the following three major steps:

One threat modeling

Threat modeling allows the test team to first identify threats that could have the greatest impact on mobile applications. The primary purpose of testers at this stage is to prioritize specific application components or code. The test team should be familiar with the basic architecture and usage of mobile applications by understanding the documentation of the application architecture.

Gather information

By collaborating with the development team for mobile applications, the test team should have access to documentation that helps them understand the design and functionality of mobile applications. The details described in these documentation can provide a basis for all the steps in the threat modeling process.

Perform reconnaissance and application mapping

Understanding how mobile applications implement their capabilities is critical to creating a mobile application model. At this stage, the test team should manually examine the instance of the mobile application. The team should then review the anonymous and authenticated parts of the mobile application, while focusing on the parts that handle sensitive data and functionality. At this stage, we will provide the framework, configuration, process, user, technology and other supporting documents to facilitate the next phase of use.

The areas that need to be focused and used for the next phase of targeted testing are: management interface, transmission of sensitive information, interfaces for external or third-party applications, mobile protocols such as SMS, MMS, WAP, etc.

The test team should record each request and response during this period to facilitate future analysis using the local agent tool and the network sniffer tool.

Defining systems and trusted boundaries

In the next phase of the review, the evaluation team should build a visual model of the series of processes in the mobile application and data flow diagrams. The data flow diagram confirms the system boundaries and the trusted boundaries of each component that surrounds the mobile application. Confirming the system boundary allows the Test team to initially identify all of the data flows or outflows from the system or its components (that is, data entry and exit points). Subsequently, during the code review phase, the test team should verify that appropriate validation and coding techniques are in place at each system boundary. Similarly, identifying a trusted boundary can identify the test team's ability to verify the authentication and authorization portions of the code.

Mapping threats to Functionality

After defining all of the flowchart elements, the test team should map all the elements to an asset threat to define "hotspots" in the mobile application and build a test plan. During the targeted code review phase, the test team should fully test each project in the plan.

Two vulnerability Confirmation

In the application evaluation process, should focus on checking the previous phase of the hot source identified. In addition to examining application vulnerabilities that are not easily identified by source code checks, enterprises should also perform a black box class assessment to identify vulnerabilities in the network or host layer. To supplement the manual inspection of the application components, the test phase should be automated scanning.

Code Analysis and scanning

The automated scanning Tool can analyze all the source code to detect security issues initially. At this stage, testers should use business-class tools and private tools to scan code with signs of security problems and common programming errors that can lead to vulnerabilities. The source code Analysis phase should try to identify vulnerabilities that can affect hosts, servers, and networks.

Artificial analysis

At this stage, we recommend that the code for the application be examined in detail to identify security vulnerabilities unique to the application architecture. When reviewing code, it is recommended that you use the following technologies in combination:

1. License Analysis: Many platforms require mobile application declarations to try to access which features during execution. The device will then limit the use of these specific features to the application. Testers can launch attacks against these features and try to circumvent these limitations to test their effects.

2. Control Flow Analysis: This technique is used to analyze logical conditions in code. This approach allows testers to identify common logical vulnerabilities, such as the inability of programs to handle exceptions, improper authorization restrictions, and so on.

3. Data Flow Analysis: This technique tracks data from the input point to the output point, especially for identifying common input validation errors, such as SQL injection and cross station scripting exploits.

To apply these technologies, we recommend that enterprises segment mobile applications into different functional components. Testers should examine each component to find common, unsafe programming methods, including:

1, authentication: Weak password requirements, user name exhaustive, account deactivation, cookie replay attacks, backdoor and so on.

2, Authorization: privilege promotion, improper distribution of power, confidential data exposure, data damage, etc.

3. Session Management: Session trap, session timeout, session hijacking, improper session termination, session replay, man-in-the-middle attack, etc.

4. Configuration management: Unauthorized access to the management interface, unauthorized access to configuration files, retrieval of configuration data, and excessive privileges assigned to processes and service accounts.

5, Input Validation: parameter damage, buffer area overflow, cross-site scripting attacks, SQL injection, XPath hijacking, command hijacking and so on.

6. Data protection: Hard coding, network communication sniffing, incorrect key generation or key management, weak encryption, etc. for mobile applications or users ' privacy.

7, Exception handling: Information disclosure, denial of service and so on.

8, Audit and log: Log forgery, manipulation of log files, log file damage.

9. Caching: During the life cycle of mobile applications, keystrokes, snapshots, clipboard contents, and files may be cached to different storage locations of the device.

10, Release Notice: Transfer data from the server to the application.

11. Location-based Services: Attempts to divulge or deceive location data.

In addition, the password is stored in plaintext in the database medium.

Check for schema security issues in your code

This is important if your application uses specific security mechanisms or features that mitigate some of the "notorious" security threats. The final code check is used to verify the specific security features of the application architecture:

Cryptography: Because custom encryption schemes generally do not have robust encryption mechanisms, enterprises should examine the scenarios to verify that they can provide adequate protection for sensitive data.

Protocol: Testers should examine the proprietary protocols used for communication to determine their ability to respond to damage and interception.

Session Management: Testers should check the following two aspects, one is the attempt to create a specific session identifier, the other is the session management process. The purpose of this is to measure the protection that occurs when the session is managed incorrectly.

Access Restrictions: Testers Check the use of a particular HTTP header or other specific protocol elements to control access and prevent unauthorized access.

Security Code: Some code is written to address previously discovered security issues, and this tester should be specifically checked to verify its effectiveness.

Server Architecture: Testers Check external Web services and servers that are used to support mobile applications.

Three vulnerabilities exploit

At this stage, the tester must develop a test plan to analyze the source code in depth to find out if there are common unsafe coding methods. Then, focus on specific security mechanisms for mobile applications. Testers also look for and examine schema security issues in the code.

Verify the identified problem

The Test team analyzes the results from the vulnerability scan, removes the specious information, and proceeds to build a case of exploitable vulnerabilities.

Take advantage of the unique features of mobile applications

The main advantage of the gray-box test method is the ability to exploit vulnerabilities to the maximum extent possible. In this phase, the tester attempts to exploit the authentication vulnerabilities and authorization vulnerabilities that are not apparent in the instance of the mobile application. These vulnerabilities can lead to illegal access to functionality or data and pose a significant risk to the enterprise. Testers also take advantage of flaws in the business logic that controls how users perform operations in mobile applications. These defects are commonly used in fraudulent mobile applications for users or companies.

To connect the exploit to the source code

After the tester has proven the exploitable vulnerabilities, it is necessary to associate the exploitable vulnerabilities with the specific code parts associated with them. This allows developers to quickly understand the problem and assess the amount of work that is required to fix the vulnerability.

Analyze risk

Testers evaluate exploitable vulnerabilities and rate vulnerabilities based on the risks that each vulnerability poses to the company. For vulnerabilities, testers also assess the impact it may have on the company after the exploit has been exploited. This analysis has multiple implications if testers are able to exploit multiple vulnerabilities and bring greater impact.

Provide specific technical advice

After assessing the risk of each exploitable vulnerability, testers will give specific recommendations for the mobile application architecture and code writing, if possible including source code. Developers can then use these suggestions to mitigate or fix vulnerabilities, thereby reducing application risk. Testers ' recommendations can also provide a secure coding guide to resolve or fix vulnerabilities in mobile applications.

Here are some suggestions for mobile security that developers and testers can refer to: Incorporating mobile security concepts into development projects, building and implementing a strategy that regulates the development of mobile applications and ensures understanding, and training developers of mobile applications to help them implement secure coding; Test whether you can limit sensitive data that is transferred to your mobile device, and evaluate threats to Web applications and infrastructure.