As a die-hard fan of Android phones, if your phone suddenly drops, would your first thought be "Oh my god!" or that your money in Google Pay or Paypal is not safe? If the latest downloaded app not only pops up various boring ads but also unexpected notifications, would you think it might be a phishing attempt and immediately uninstall the app?
How can we ensure that our app provides a safe experience for users who have insufficient awareness of Android security vulnerabilities? What are the security vulnerabilities in the Android ecosystem? Where can we explore new Android security testing techniques? How can we streamline the security testing process?
Firstly, the open-source development advantage of the Android operating system also conceals inherent security issues in its development, such as the Android system's sandbox system (i.e., virtual machine). However, the underlying layer has one vulnerability after another, allowing malicious programs (or tools) to gain root access and break the sandbox's restrictions. Just like in the PC era, there is no absolutely secure PC operating system; in the mobile internet era, there is no absolutely secure mobile operating system either. The security risks of the Android open-source ecosystem are like blood-stained alarm bells, striking the hearts of every Android developer.
Secondly, the security risks in the Android APP/SDK development process are like unknown black holes. We never know where the endpoint of security confrontation is, who the attackers are, who the terminators are, and how to defend against them.
Finally, at the user level, what are some common and recognizable security behavior vulnerabilities?
Both Android Apps and SDKs have security vulnerabilities to some extent. Perhaps one day, your application might be affected by one of the above security vulnerabilities. Coincidentally, while testing an Android SDK recently, we discovered a security vulnerability related to Android application components. Based on this example, the methods, techniques, and processes for Android SDK security testing are summarised.
Overview of Vulnerability Causes
An optional component of an application (hereinafter referred to as the application) Android SDK has opened a random port locally to monitor whether the Java layer service is alive. However, when the Java layer communicates with the component, it does not strictly check the input parameters, resulting in the possibility of being filled with attack code and malicious attacks when calling the "system()" function of the Linux system.
The following screenshot shows that after the simulation port is attacked, the application component intent modifies the URL content during communication, and the Webview displays garbled code:
The four major application components of Android APPs: Activity, Receiver, Service, and Content Provider, as well as the security roles of application components communicating through intent for IPC, will not be discussed in detail here. Leveraging the component-related vulnerability in the above example, the following diagram shows the attack dimensions related to the terminal APP side:
Due to the local application environment of Android APP, the network socket is inherently lack of fine-grained authentication and authorization mechanism. Therefore, if the Android client is used as the server, the reverse code is used to search the local random port number of the application, and the attack is actively sent to the port, the following security hazards will lurk:
Local command execution: When the Package name of the embedded application is specified as the application itself and the Component name is specified as the activity of the application, any activity of the application can be started, including the protected non-exported activity, thus causing a security hazard. For example, a denial of service vulnerability can be found by starting several unexported activities one by one through HTTP requests.
Command control to modify application permissions: Pass in the intention to start Android application components through the open socket port, and then execute operations such as starting activity and sending broadcast with the permissions of the attacked application. Because the intents passed in through the socket cannot perform fine-grained checks on the identity and permissions of the sender, bypassing the permission protection provided by Android for application components, and can start the unexported and permission-protected application components, posing a security hazard
Sensitive information disclosure, mobile phone control: A local service opens the UDP port to listen, and after receiving a specific command word, it can return the sensitive information of the mobile phone. For example, Baidu mobile phone butler can remotely manage the cell phone's secretKey, and then unauthorized attackers can fully manage the cell phone through the network.
Android Security Hardening Version Optimization
Add checks for system commands and special character filtering in both the Native and Java layers.
Encrypt socket communication for JNI Watchdog daemon process.
Add feature verification for URLs, intents, and activities in local notification functions to prevent redirection to malicious links when clicking on notifications.
Change the storage location of Package name in the app's local storage.
Add online configuration functionality.
These are the important requirements for this security hardening optimization.
If you follow conventional system testing or performance testing, you only need to perform forward testing based on the changing requirements. However, for security testing, ensuring the robustness of the SDK's security requires reverse special testing, simulating various security attack methods, and diverging test cases for the modified points.
Privacy data: External storage security and internal storage security; check if user names, passwords, chat records, configuration information, and other private information are saved locally and encrypted; verify the integrity of the information before using it.
Permission attacks: Check the app's directory and ensure that its permissions do not allow other group members to read or write; check if system permissions are under attack.
Android component permission protection: Prevent app internal components from being arbitrarily called by third-party programs: prevent Activities from being called by third-party programs, prevent Activity hijacking; ensure Broadcast reception and transmission security, only receive broadcasts sent out by the app, and prevent third parties from receiving transmitted content; prevent maliciously starting or stopping services; check Content Provider operation permissions; if components need to be called externally, verify if signature restrictions have been applied to the caller.
Upgrades: Check the integrity and legality of the upgrade package to avoid hijacking.
3rd-party libraries: If third-party libraries are used, follow up on their updates and check their security.
ROM security: Use official ROMs or ROMs provided by authoritative teams to avoid the addition of implanted ads, Trojans, etc.
Anti-cracking countermeasures: Counteract decompilation, making it impossible to decompile using decompilation tools or obtain the correct disassembly code after decompilation; counteract static analysis by using code obfuscation and encryption; counteract dynamic debugging by adding code to detect debuggers and emulators; prevent recompilation by checking signatures and verifying the hash value of the compiled dex file.
After completing the security special testing and regular process testing, perform rolling regression testing for the app's existing features, compatibility between new and old versions, and compatibility with different Android operating system versions.
Compared to ordinary performance and system functionality test cases, security test cases require a more comprehensive understanding of the Android ecosystem, such as: covering user security appearance level, application system local and remote attack level, and operating system vulnerability level, with more focus on designing reverse attack thinking test cases.
If the starting point of development is security defense, the starting point of testing is the hacker attack mindset. Designing test cases for attack scenarios and implementing attack testing techniques determines the robustness of the SDK's security.
To ensure the highest level of security for your applications, consider utilizing WeTest Application Security Testing. This service provides a comprehensive evaluation of security issues in applications, timely detection of program vulnerabilities, and offers code repair examples to assist with vulnerability repairs.
Trust WeTest to safeguard your application against potential threats and maintain a secure user experience.
The above is the detailed content of How to Do Android App Security Testing: A Guide for Developers and Testers. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
