SDK Basic Security Requirements
a) It should be ensured that the distribution process has an effective integrity verification mechanism to prevent the provided code and resource files from being tampered with.
b) It should be ensured that distribution packages and demo packages do not contain viruses, Trojan horses and other malicious programs.
c) The debugging information function should avoid outputting sensitive information such as communication logs and key variables.
d) Test information such as intranet URLs, test accounts, and test data should be avoided in distribution packages and Demo packages.
e) Avoid embedding plug-ins and codes that have nothing to do with business functions, or privately package and provide other SDK products in the distribution package.
f) Applying for system permissions should follow the minimum necessary principle, and avoid asking for permissions that are not necessary to realize business functions.
Data Storage Security RequirementsSDK Data Storage Security Requirements
a) Files containing personal information and important data stored on end-user devices should be encrypted (such as table encryption, file encryption, etc.) to avoid illegal access and tampering by host apps, other apps, malicious programs, etc.
b) It is advisable to encrypt data that is jointly processed and used with the host App or other local programs, and agree on a safe and effective decryption scheme to ensure legally authorized access to data.
c) The digital certificate file stored on the end user's device shall be encrypted to prevent the digital certificate from being leaked or illegally tampered with.
d) Backup data stored on end-user devices should be encrypted to avoid backup data leakage.
e) Lightweight data read and write permissions such as configuration information and user preferences stored locally should be restricted to avoid unauthorized access and tampering by other programs.
f) It is advisable to limit the local storage time of personal information and important data to ensure that expired data is automatically deleted.
g) Local storage of the corresponding relationship information between the de-identified data and the original identification should be avoided, so as to prevent the leakage of relevant information from causing the de-identification to fail.
h) Local storage of plaintext authentication information (such as account numbers, passwords, etc.) should be avoided. It is advisable to store relevant data in the form of hash values with random salts to avoid leakage of sensitive personal information of users.
Security requirements for data interaction The security requirements that should be met for data interaction between the SDK and the host app and server
a) A secure transmission protocol should be adopted to ensure the confidentiality, integrity, and availability of data interaction between the SDK and the server.
b) For scenarios involving personal information and important data transmission, encrypted transmission protocols such as HTTPS should be adopted or relevant data should be encrypted separately to ensure encrypted transmission of personal information.
c) When using the HTTPS transmission protocol, it is advisable to enable the two-way authentication mechanism between the SDK and the server to ensure the authenticity of the identity of the server.
d) When using an HTTPS custom certificate, the host name of the server should be verified to verify the identity of the server host.
e) Safe encryption algorithms and key generation mechanisms should be used, and unsafe encryption algorithms (such as RC4, AES ECB or OFB working modes, etc.) should be avoided to avoid encryption algorithm cracking.
Safety Requirements for Important Components
The security requirements that the SDK should meet when using system functional components are as follows:
a) When using components to call system functions, ensure its configuration security to avoid security risks caused by unreasonable configurations.
b) The minimum necessary principle should be followed when using components to call system functions, and avoid calling functions that are not related to the realization of business functions.
c) When calling the web view (WebView), the security of its configuration should be ensured to avoid security risks caused by unreasonable configuration.
d) When calling the web view (WebView) to realize interaction with the server, it should meet the requirements of Section 5.1.3.
e) It is advisable to verify the legitimacy of the receiver and filter the parameters when calling the Intent component to avoid risks such as unauthorized calls and implicit calls.
f) It is advisable to add an exception capture mechanism when calling the Intent component to avoid risks such as program crashes.
Code and Resource File Security RequirementsSDK Code and Resource File Security Requirements
a) It is advisable to use methods such as code obfuscation and reinforcement to increase the difficulty of reverse analysis and reduce the risk of leakage of key functions and logic.
b) It is advisable to strengthen/obfuscate locally stored so files to avoid leakage of sensitive information.
c) It is advisable to encrypt the locally stored h5 resource files to avoid tampering with the resource files.
d) If the resource file hot update technology is used, it is advisable to restrict the file name of the file decompression to prevent the updated resource file from being illegally obtained.
e) It is advisable to randomize the address space of locally stored so files to reduce the risk of buffer overflow attacks.
f) Compiler stack protection should be implemented for locally stored so files to prevent the system from not protecting the program when the stack overflows.
g) It is advisable to encrypt the keys and certificates stored locally to avoid leakage or tampering of the local keys and certificates.
h) It is advisable to avoid hard-coded or strongly coupled URL addresses in the code to prevent links from being tampered with.
SDK security test items
SDK distribution lacks integrity checks
Risk description: The lack of an integrity verification mechanism in the distribution process may cause APP providers to obtain fake and tampered SDK codes
Test method: Visit the SDK download channel to check whether integrity verification mechanisms such as hash value comparison and signature certificate are provided
Contains malicious programs
Risk description: The distribution package contains viruses, Trojan horses, etc., which may pose a security threat to APP providers and end users
Test method: decompress the SDK distribution package, and scan for malicious programs such as malicious codes and Trojans
Debug log output sensitive information
Risk description: Debug information function output logs may leak sensitive information such as code logic, resulting in security risks
Test method: decompile the SDK code, check whether the debug information function is disabled, and if it is not disabled, check whether the output log contains sensitive information
Residue Testing Information
Risk description: Residual test data may leak test server address, test account and other information, threatening operation and maintenance security
Test method: decompile the SDK code, check whether there are server addresses, test accounts and other information left
Embedded irrelevant plug-ins, SDK
Risk description: plug-ins and SDKs that have nothing to do with business functions may carry malicious programs or cause other security risks
Test method: decompress the SDK distribution package, and check whether there are plug-ins and SDKs that are not related to business functions in the resource file
Ask for non-essential permissions
Risk description: Asking for unnecessary permissions that are not related to the implementation of SDK business functions may lead to compliance risks
Test method: Verify the SDK permission statement, compare business functions, and determine whether to apply for system permissions that are not related to business functions
Data plaintext storage
Risk description: Store data locally in clear text, which may lead to illegal access and tampering of personal information and important data
Test method: Enter the SDK local data storage path, check whether there is a database file stored in plain text, and if so, check whether there is sensitive information in its content
Shared data plaintext storage
Risk description: The data processed and used by the SDK and local programs is not encrypted, which may lead to the risk of unauthorized access to data
Test method: Enter the local data storage path of the host APP and SDK, and check whether there are shared files stored in plain text in combination with technical documents, and if so, check whether there is sensitive information in its content
Digital certificate plaintext storage
Risk description: Digital certificates stored in clear text may be stolen or tampered with, resulting in security risks such as interception of transmitted data and forged transmission requests
Test method: decompile the SDK code, and check whether there is a certificate file stored in clear text in the resource file
Backup data plaintext storage
Risk description: If the sdk enables the data backup function and stores the backup data in plain text, it may lead to unauthorized access to the backup data
Test method: decompile the SDK code, check whether the data backup function is enabled, if so, enter the SDK backup data storage directory, and check whether the backup data is stored in plain text
Data is globally readable and writable
Risk description: If the global read and write permissions for lightweight data are enabled, locally stored configuration information, user preferences, and other information may be accessed and tampered with without authorization
Test method: Check the technical information of the SDK, and check whether the permission to read and write lightweight data is closed or restricted during the development process of the SDK
Data expired storage
Risk description: If the data storage period is not limited, personal information and important data may be stored overdue
Test method: Check the SDK technical information, check whether the local data storage period is limited during the SDK development process, enter the SDK local storage path, and check whether the data beyond the storage period is deleted
Identification correspondence local storage
Risk description: If the information about the correspondence between the identification data in the local storage area and the original identification is leaked, it may lead to the failure of de-identification
Test method: combined with SDK technical information query, enter the SDK local storage path, and check whether there is any correspondence between the locally stored identification data and the original identification
Authentication information stored in plain text
Risk description: If authentication information (such as account number, password, etc.) is stored locally in clear text, it may lead to leakage of sensitive personal information of users
Test method: combined with the SDK technical information, check whether the SDK only stores the hash value of the authentication information, and a random salt is added during the calculation of the hash value
Sensitive information HTTP protocol transmission
Risk description: HTTP protocol communication uses clear text transmission and does not verify the identity and complete message of the communicating party, which may lead to security risks such as data leakage and man-in-the-middle attacks
Test method: Capture HTTP protocol data packets for analysis, and check whether there are sensitive information such as personal information and important data in plain text
Sensitive information transmitted in clear text
Risk description: The data transmitted in clear text may be intercepted, resulting in the leakage of sensitive information
Test method: capture communication traffic and analyze content, and check whether sensitive information such as personal information and important data in clear text can be intercepted
Two-way authentication is not enabled for HTTPS
Risk description: Failure to start HTTPS two-way certificate verification may lead to hijacking and decryption of encrypted data. risk of data leakage
Test method: configure the certificate file and conduct traffic analysis to check whether the HTTPS single authentication mechanism is used
HTTPS not validating hostname
Risk description: lack of host name verification mechanism, SDK may establish communication with counterfeit server, resulting in man-in-the-middle attack
Test method: decompile the sample file, check whether a custom SSL certificate is used, and if so, check whether the host name verification is enabled in HTTPS related settings
Random numbers are not safe to use
Risk description: Improper setting of the random number generation mechanism may lead to predictable random numbers, threatening the security of the secret key
Test method: decompile the sample and check whether an unsafe random number method is used
Encryption algorithm is not safe to use
Risk description: Improper settings related to the symmetric encryption algorithm may cause the encryption to fail, resulting in decryption of encrypted files and interception of transmitted data, etc.
Test method: decompile the sample file to check whether the unsafe AES/DES encryption algorithm is used
Insecure Configuration of System Components
Risk description: Unsafe configuration of system component policies and rules may cause related components to be maliciously invoked, providing convenience for malicious behavior
Test method: decompile the sample file, check whether there are unsafe configurations in the component call filtering rules and call paths
webview component insecure configuration
Risk description: When the webview component loads web pages, functions, and resources, if there are insecure configurations, it may lead to risks such as data leakage, hijacking, and tampering
Test method: decompile the sample file, and check whether there are unsafe configurations of webview related functions
Intent unauthorized call
Risk description: The intent component call is not strictly filtered, which may lead to the construction of a specially formatted URL to call the activity component without authorization
Test method: decompile the sample file and check whether the intent call is strictly filtered
Intent privacy call vulnerability
Risk description: When using the implicit intent call, there is no restriction on the message receiver, which may lead to the disclosure of the intent content
Test method: decompile the sample file and check whether the intent function is called for privacy
Application Local Denial of Service Vulnerability
Risk description: If the input parameter is not verified when calling the intent function, if there is an abnormal input, it may cause a crash
Test method: pass a non-existent serialized object to the component exported by intent, and check whether it causes the program process to crash
Code is not obfuscated and hardened
Risk description: The code is not obfuscated and hardened, which may reduce the difficulty of decompilation, easily expose the code logic, and lead to risks such as bypassing and cracking of security mechanisms
Test method: decompile the file, check whether the key class name, logic, assignment, etc. of the code are obfuscated
so files are not obfuscated and reinforced
Risk description: The so file contains a dynamic link library file, and if it is not obfuscated or reinforced, it may lead to information leakage such as code operation logic
Test method: decompile the sample file, statically scan the code file, and check whether the sample file obfuscates and strengthens the so file
Unlimited decompression file name
Risk description: Hot update prohibits unrestricted decompression file names, which may cause files to be decompressed to arbitrary paths, causing malicious files to overwrite normal files
Test method: decompile the sample file, check whether ziparchive is used to realize the decompression function and allow arbitrary file names
Dynamic loading dex file tampering
Risk description: The hot update mechanism allows dynamic loading of dex files and does not restrict dex editing, which may lead to tampering of target files
Test method: decompile the sample file, check whether dynamic loading of the dex file is allowed, and if so, check whether the dex file can be modified
Compiler stack protection techniques are not used
Risk description: Filling the memory buffer with data bits exceeding the capacity of the buffer itself may cause the overflowed data to be overwritten on the legal data, resulting in the modification of the address of the program executed in the memory
Test method: decompile the sample file, check whether the so file uses the compiler stack protection technology
Does not use address space randomization techniques
Risk description: If the address space layout of the application is fixed, the base address of its area may be obtained, resulting in the execution of injected code
Test method: decompile the sample file, check whether the so file uses address space randomization technology
hardcoded secret key
Risk description: There is hard-coded secret key information in the code, which may lead to the leakage of authentication information and the cracking of the encryption process
Test method: decompile the sample file, and check whether the encryption function and method in the code have hard-coded secret key information in plain text
URL information hardcoded
Risk description: There is URL plaintext information in the code, which may lead to the leakage of back-end server domain name, interface and other information
Test method: decompile the sample file, and check whether there is plaintext URL address information in the code