[Android Application Development]-(7) Security design (for the full version, refer to the official website)

Android is designed for most developers to build applications using the default settings without thinking about security. Android also has many built-in security functions in the operating system, greatly reducing the security issues and frequency of applications.

Some security features help developers build secure applications, including:

1. The Android Application sandbox separates data and executes code on the basis of each application.

2. The Android Application Framework implements common security functions, such as encryption, permissions, and secure inter-process communication.

3. technologies such as ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, and Linux mmap_min_addr to mitigate related risks and common memory allocation errors

4. The encrypted file system can protect the loss or theft of device data

However, it is important to familiarize developers with the best Android security practices to ensure the advantages of developers in using these features and Reduce Unintentional security issues, these unintentional problems may affect application security.

This document focuses on common APIs and development technologies to provide the best practices for your applications and users' security risks. The best practices are constantly evolving, we recommend that you check the application development process at any time.

This article includes:

Ø use virtual machine code

Use local code

Ø Data Storage

Use IPC

Use Permissions

Ø network usage

Ø dynamically load code

Perform input verification

Process User Data

Use encryption

 

1) use virtual machine code

 

This article focuses on Android features or security issues in different environments. Developers with programming experience in other virtual machine environments may also write Android applications, which have two major problems:

3. Some virtual machines, such as the JVM or. net runtime, act as a security boundary and isolate code from the underlying operating system functions. On Android, The Dalvik virtual machine is not a security boundary. It implements the application sandbox at the operating system level, so that the virtual machine can have no security restrictions, operate on local code in the same application.

4. Considering the limited storage space on mobile devices, developers are willing to build modular applications and achieve dynamic loading. Make sure that both the source and application logic are stored locally. Do not use dynamic loading or insecure network resources or external storage for sources without verification, because the code can be modified and may contain malicious behaviors.

 

2) use local code

In general, we encourage developers to use the Android SDK to develop applications, instead of using local code (*. so), applications built with local code are more complex and portable, but it is difficult to control common memory corruption errors, such as buffer overflow.

Android uses the Linux kernel. If you want to use the local code, it is necessary to familiarize yourself with the best method for Linux development security. Discussing these best practices this article is too short, but you can refer to "Secure Programming" for Linux and Unix and click this link to view: http://www.dwheeler.com/secure-programs

An important difference between Android and most Linux environments is the application sandbox. In Android, all applications run in the application sandbox, including local code. At the most basic level, developers familiar with Linux think it is a good way to know that each application is given a unique UID and has very limited permissions. This issue will be discussed in detail in the Android security overview. You should be familiar with application permissions, even if you are using local code.

3) Data Storage

1. Use internal files

By default, Android files can only be created in internal memory. This protection is implemented by Android, which is sufficient for most applications, because it does not provide the ability of specific applications to access data formats, nor any data control capabilities, as an alternative solution, you can consider using ContentProvider to provide read and write permissions, dynamic Authorization is supported.

To provide additional protection for sensitive data, some applications choose to use a Key to encrypt local files. (For example, a key can be placed in a KeyStore to protect the user password but not stored on the device ). Although this is not fundamentally protected, if the device is lost and the file system is not encrypted, it can protect data by monitoring the password entered by the user.

2. Use External Storage

Create a file in an external store, such as an SD card, which can be read and written by all programs. Since external storage can be removed by users, any application can modify the storage data. It is recommended that applications do not use external storage to store sensitive information.

Any untrusted data source, the application should perform input verification when storing data from outside. We strongly recommend that applications dynamically load executable files or class files stored in external storage. If the application is retrieving executable files from external storage, it should sign and encrypt the verification before dynamic loading.

3. Use Context providers

ContentProviders provides a structured storage mechanism. Allow or restrict access from other applications in your own applications. By default, one ContentProviders can be used by other applications. If you do not want other applications to access your ContentProvider, you can set android: exported to false in the mainfest of the application. Www.2cto.com

When creating a ContentProvider for other applications, You can separately specify the read/write permissions. It is recommended that the given permissions can complete the current job.

If you use ContentProvider to share data in different applications of unified developers, it is best to use signature-level permissions. The signature permission does not need to be confirmed by the user, so as to provide a better user experience and access control.

...

For more design methods, please refer to the official document. If you can understand the meaning but haven't reached the translation level, you can write it here. I think more of my tasks may be below, rather than being translated. Sorry ~

4) use IPC

5) Permission

6) use the network

7) dynamically load code

8) perform input verification.

9) process user data

10) use encryption

Author: tangcheng_ OK