Introduction to mobile application covers a large amount of personal data of users. Once leaked, it may have a major impact on individuals and society, and it is also a devastating blow to the long-term development of the mobile application industry. Mobile application developers should also pay attention to the standardization and safety of the development process, fear security issues, and prevent compliance risks.
According to statistics, at least 1.5 million new types of mobile malware are added every year, causing at least 16 million mobile malware attacks.
Due to its open ecological environment, Android's security issues are even more serious. In the application market, many Android apps have potential security risks. Once used, it will have a great impact on users and developers.
At the same time, with the promulgation and implementation of the "Cyber Security Law" and "Personal Information Protection Law" and other related laws and regulations, mobile application developers also need to collaborate with government departments to jointly create a safe mobile application environment and promote the standardization and safety of network security. And healthy development.
To help mobile developers effectively respond to security requirements, many modules in mPaaS have adopted security strategies:
- Mobile application security hardening
- Privacy compliance testing
- RPC signature encryption
- Signature verification of offline packages
- The tcp+ssl mechanism of mobile synchronization
- Hotfix encryption configuration
……
This article will introduce you to several modules of the above-mentioned common mPaaS regarding security design for better use in the future.
Privacy compliance testing
As policies, regulations and regulatory standards continue to be refined and deepened, and regulatory investigations continue to increase, the policy risks that App developers need to face are also gradually increasing.
The mPaaS privacy compliance testing service, in accordance with relevant national laws and regulations and industry standards, conducts compliance analysis on the privacy and security of mobile apps, and the collection and use of personal data.
It helps companies and App developers identify security risks from personal information collection, permission usage scenarios, and privacy policies, and provide corresponding expert rectification suggestions to help customers avoid regulatory penalties and pass audits.
Mobile security hardening
Combined with the upgrade of Alibaba's internal mobile application security reinforcement capabilities, we have now exported mobile application security reinforcement capabilities in mPaaS.
In response to various security risks such as cracking, tampering, piracy, phishing fraud, memory debugging, and data theft that are common in mobile applications on the market, mPaaS mobile security reinforcement provides stable, simple and effective security protection for the app, and improves the overall security level of the app. Ensure that the App is not cracked and attacked.
While dealing with common Android attack methods, such as decompilation, secondary packaging, dynamic debugging, etc., we also pay attention to performance and compatibility.
- Reinforcement ability has experienced the practice of hundreds of millions of businesses such as Taobao and Cainiao, and it is guaranteed in terms of safety;
- In terms of compatibility, we support versions from 4.2 to Android Q;
- Able to support arm, x86, x64 system architecture, stable operation in a complex environment, low crash rate;
- In addition, through the obfuscation protection of the class, it is more difficult for the attacker to reverse the App, making the attack impossible to start.
RPC
As one of the most important components of mPaaS, RPC provides a secure communication channel between the client and the server. Security aspects include signature and encryption. Among them, the signature solution is to prevent the client from being forged, and the encryption solution is to prevent the request data from being leaked.
1 endorsement
The overall process:
- When the application is initialized in the background of mPaaS, a unique appSecret will be created for each App;
- The client uses appid, WorkspaceID, appSecret and other information to generate wireless bodyguard pictures. Through the encryption of the wireless bodyguard module, the security of the appSecret stored in the client is guaranteed;
- When the client requests it, it obtains the appSecret from the wireless bodyguard, and adds factors such as OperationType, time, requestData, etc. for MD5 calculation, and adds it to the header and sends it to the MGS gateway;
- After receiving the MGS, calculate the MD5 again in the same way. If they are consistent, the verification is passed.
Advantages: Through the wireless bodyguard mechanism, the security of the built-in appSecret in the client is guaranteed.
2 Encryption
The overall process:
- Generate an asymmetric secret key through openssl, the client saves the public key, and the server reports an error with the private key;
- The client will generate a new symmetric key every time it requests RPC, and encrypt it with the asymmetric key generated in the first step to generate a SecKey;
- The client uses the symmetric key to encrypt the original data at the same time to obtain the encrypted data SecData;
- The mobile gateway decrypts the SecKey through the stored private key to obtain the symmetric key;
- Using the symmetric key obtained in the previous step, decrypt the encrypted data SecData to obtain the original data.
Advantages: RPC's encryption adopts a hybrid encryption mode, using a combination of asymmetric encryption and symmetric encryption. If you simply use the symmetric key, although the performance is better, it cannot guarantee sufficient security. If you use asymmetric encryption alone, although security is guaranteed, performance will deteriorate, and it is not suitable for RPC scenarios with large amounts of communication.
Therefore, the mixed encryption mode adopted by RPC combines the advantages of both.
3 Anti-grabbing
In order to prevent the data from being captured by the packet capture software on the client side, the client has been configured to prevent packet capture. By setting the network library to prohibit the proxy, the risk of packet capture is resolved. code show as below:
Offline package
Many offline modules are used as services. In order to ensure that the offline package modules sent to the local are not tampered with, the offline package provides a signature verification mechanism.
The overall process:
- Generate public and private keys through openssl in advance. The public key is built into the client and the private key is stored on the server;
- When the offline package is packaged, the server performs MD5 calculation on the file of the current offline package, and then encrypts the calculated value with an asymmetric key to generate encrypted signature data, and sends it to the client along with the offline package;
- Every time the client opens the offline package, it obtains the MD5 sent by the public key in the client and compares the MD5 with the local offline package file. If they are consistent, the verification is passed. If they are inconsistent, the offline package will be deleted and directly accessed. fallback resources.
Advantage:
- Since the verification is done every time the offline package is opened, it ensures that the source of the offline package is correct and not tampered with;
- After the verification fails, it is directly downgraded to the fallback address to reduce the impact on customer use
MDS real-time release
The MDS real-time publishing service provides the apk publishing function. At the same time, in order to ensure that the downloaded apk file is not tampered with, it provides an MD5-based integrity check.
When uploading the apk, MD5 will be generated based on the current apk for distribution. During local installation, the MD5 of the locally downloaded file will be matched with the MD5 sent by the server. If the match is successful, the installation will continue.
The MD5 field issued by the server is shown in the following figure:
MSS mobile sync
The mobile synchronization service Sync communicates based on TCP. To ensure security, Sync can be configured to communicate in TCP+SSL mode.
When the port number of Sync is designated as port 433, the client will start to realize the long connection based on TCP+SSL. After the long connection request is sent to the server, it needs to complete SSL offloading through F5 or other similar load devices, and finally to the MSS to realize the long connection .
The overall process is shown in the figure below:
Concluding remarks
With the rapid development of mobile applications, users are increasingly concerned about privacy and security issues involved in mobile applications.
Mobile applications cover a large amount of personal data of users. Once a leak occurs, it may have a major impact on individuals and society, and it will also be a devastating blow to the long-term development of the mobile application industry.
Mobile application developers should also pay attention to the standardization and safety of the development process, fear security issues, and prevent compliance risks.
Author of this article: Alibaba Cloud mPaaS TAM team (Rongyang)
END
Copyright Notice: content of this article is contributed spontaneously by Alibaba Cloud real-name registered users, and the copyright belongs to the original author. The Alibaba Cloud Developer Community does not own its copyright and does not assume corresponding legal responsibilities. For specific rules, please refer to the "Alibaba Cloud Developer Community User Service Agreement" and the "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines". If you find suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。