App security inspection and well-known security inspection are two completely different concepts. First of all, the app industry itself has certain requirements and specifications for app security inspection. Secondly, the "China Cybersecurity Law" officially implemented on June 1, 2017 required the app to conduct real-name authentication when the channel is launched, and at the same time complete the corresponding security check. The online process of the app is called security clearance or security pending review.
What problems are encountered in the process of App security inspection
One of the rules that the app refers to during the specific inspection is the "Basic Requirements for Mobile Application Security Inspection". This requirement is divided into four categories, including the application layer, the network layer, the data layer and the server side. And some security points of the Android App itself are divided into ten, namely program code security, program code protection, password and security policy, permission and interface security, dynamic debugging detection, SO injection detection, memory data protection, privacy and storage Security, log leak detection, communication data security, etc.
First, the program code security
The first block relates to user information collection requirements. There are certain requirements for the collection of user information when the APP is launched, and the relevant legal statements and relevant privacy policies shall be clarified when collecting user information. If the app does not obtain user privacy data, but uses a third-party platform to collect it, it should also declare clearly which third-party platform the app uses to collect user data, and the purpose of collecting user data.
The above picture is a common APP display page. Although most users have not read the above information carefully, the display of legal notices and privacy policies is a mandatory requirement for collecting user information.
The second block is related to calling system permission detection. Invoking system permissions needs to follow the principle of least permissions, and the permissions applied by the app must comply with the user's consent.
The third block is the security of the source code. The APP should provide normal services to users, and there should be no malicious behavior.
2. Program code protection
App developers must have a basic awareness of security development, and always pay attention to whether the app has mistyped packages, whether it uses code obfuscation technology, whether it has basic anti-decompilation capabilities, and whether it can be tamper-proof to a certain extent.
The first obfuscation refers to whether the client uses code obfuscation technology;
The second anti-decompilation refers to the ability to prevent third-party reverse tools from performing reverse decompilation or decompilation through hardening features;
The third anti-tampering refers to the anti-tampering mechanism of App integrity verification at runtime, preventing secondary packaging, and repacking and running flashback after modification to pass.
3. Password and Security Policy
Passwords and security policies require users to enter account passwords to log in to apps, especially financial apps. When entering account passwords, it is necessary to prevent third-party programs from capturing or intercepting or taking screenshots. This requires the app to have certain keyboard protection. The anti-keylogging SDK means that when the user enters the account and password, the SDK is used to display the keyboard for the user to input. This SDK must require that the character sequence displayed each time it starts is different, so that it will be considered as passed. Yes qualified.
4. Permissions and Interface Security
Program data backup needs to see if the allowBackup flag is set in AndroidManifest.xml (default is true) or allowBackup is set to true. If true application data can be backed up and restored.
Interface hijacking is when the account password is entered, in addition to the characters entered on the keyboard will be intercepted, the malicious program may also provide a fake interface, cover the page entered by the account, and forge a login page. Ordinary users cannot identify the login page. authenticity, so it is likely to be phished. Such a program has a requirement. When testing it, it will also provide a fake interface. At this time, the App should pop up a relevant risk prompt.
Another is to take screenshots and record the screen. Some malicious programs do not intercept character input, because the characters appear at the moment of password input, and the previous character will become an asterisk when the next password character is input, and some malicious programs will also Use this screen capture technology.
It is worth mentioning that there is currently no specific protection method for Activity hijacking, because this kind of attack is at the user level and cannot be eradicated at the code level.
However, we can appropriately give the user some warning information in the App, indicating that the login or key interface has been overwritten. The specific solutions are as follows:
Override the onKeyDown method and the onPause method in the App's Activity interface (that is, MainActivity). When it is overridden, a warning message will pop up. Determine whether the program enters the background is triggered by the user (touch the return key or the HOME key).
Five, dynamic debugging detection
Anti-dynamic debugging is basically judged by ptrace. When the application is called back by the testing agency, the agency will give relevant repair suggestions, and some solutions will be mentioned in the repair suggestions.
If the process is attached in the debugging state, the procid is judged in /etc/$(procID)/status. If the process id is not zero, the process is directly killed and exited. If the process is attached in the debugging state, the process ID behind the TracerPid is judged in /etc/self/status. If the process ID is not zero, the process is directly killed and exited, a child process is created, and the child process performs ptrace on it. But not the child process ptrace, check the ptrace status of each other; at the same time, check each other whether the process is suspended.
Once the APK is debugged, the APP exits abnormally, blocking debugging
Of course, it can also be achieved with three-party reinforcement products. Some reinforcements may be dynamic if they are relatively complete. This can also be achieved.
By strengthening the app, the app is strengthened with a reinforcement scheme to prevent the app from being dynamically debugged.
6. SO injection detection
SO injection, there are many cracking methods in the App case, whether it is from the linker service or the dlopen service, SO injection is a more practical skill. SO with the so library technology, it is very convenient to analyze some logic of the application and some effects to be achieved by the App.
The prevention methods of SO injection mainly include the following three points:
1. Judging the dlopen function, modify the dlopen function in the linker to prevent third-party so loading.
2. Regularly detect the third-party so library loaded by the application. If it is found that the so is injected, unload the loaded so.
3. Reinforce the system under test to prevent the system under test from being dynamically injected into a third-party so.
7. Memory data protection
anti-dump
Dump is actually the reading of memory data. Anti-dump is to prevent the memory from being read by third-party programs. You can use a command like the following to dump the process memory: dd if=/proc/3039/mem of=/data/local/tmp/dump_mem.zip skip =1979047936 ibs=1 count=1490944. Monitor the read and write operations of files such as /proc/pid/mem and /proc/tid/mem. When these files are accessed by third-party programs, the set callback function is triggered and further processed.
Anti-memory modification
The modification of memory data is the writing of memory data, and the principle is the same as anti-dump. With anti-injection, anti-debugging and other methods, the anti-memory modification is finally realized.
8. Privacy and storage security
Check whether the local data storage leaks information: whether the xml and db files are stored in plaintext; whether the log information is safe to check;
1. Do not store sensitive information such as passwords in internal storage such as Shared Preferences. Sensitive information should be encrypted and stored.
2. Avoid using the MODE_WORLD_WRITEABLE and MODE_WORLD_READABLE modes to create inter-process communication files, which are Shared Preferences.
9. Communication data security
Whether sensitive data is encrypted and transmitted: whether the network capture sensitive data is encrypted;
Security detection of encrypted channels (including man-in-the-middle attack detection, etc.) HTTPS communication protocol;
Recommendation: The client of the system under test should use protocols such as SSL to encrypt and transmit sensitive information when communicating with the server.
In the custom-implemented X509TrustManager subclass, the server-side certificate is not verified, and any server-side certificate is accepted by default, which may cause security risks. The system under test ignores server-side certificate verification errors or trusts any certificate, which can easily lead to man-in-the-middle attacks and may lead to leakage of user sensitive information.
The certificate is verified in the checkServerTrusted method of the client-to-server certificate verification.
10. Other vulnerability detection
WebView Vulnerability: Whether the client App uses the interface function addJavascriptInterface of the webview component, and whether there is a remote code execution vulnerability.
Component causes vulnerability detection
Authentication mechanism defect detection
SQL Injection Vulnerability Detection
Cross-site scripting (xss) vulnerability detection
Alibaba Cloud OSS Credential Leak Vulnerability Detection
Struts2 Vulnerability Detection