Android-design for security-1-development document translation

Designing for Security
Designed for security
 
Android was designed so that most developers will be able to build applications using the default settings and not be confronted with difficult decisions about security.
Android also has a number of security features built into the operating system that significantly reduce the frequency and impact of application security issues.
Android is designed to generate a large number of developers with the ability to create default settings for applications without having to face difficult security decisions.
Android also has a large number of security features built into the operating system, greatly reducing the frequency and impact of application security issues.
 
 
Some of the security features that help developers build secure applications include:
Some security features help developers establish secure applications, including:
 
1. The Android Application Sandbox that isolates data and code execution on a per-application basis.
2. Android application framework with robust implementations of common security functionality such as cryptography, permissions, and secure IPC.
3. Technologies like ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, and Linux mmap_min_addr to mitigate risks associated with common memory management errors
4. An encrypted filesystem that can be enabled to protect data on lost or stolen devices.
1. Android Application sandbox isolates data and code execution based on each application.
2. The Android Application Framework has strong common security functions, such as encryption, permissions, and secure IPC.
3. ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, and Linux mmap_min_addr are used to mitigate risks related to common memory management errors.
4. The encrypted file system can protect data on lost or stolen devices.
 
 
Nevertheless, it is important for developers to be familiar with Android security best practices to make sure they take advantage of these capabilities and to reduce the amount of privilege introducing security issues that can affect their applications.
The best practice for developers to familiarize themselves with Android security is to ensure that they use these capabilities to reduce the security problems that may be inadvertently introduced that affect their applications.
 
 
This document is organized around common APIs and development techniques that can have security implications for your application and its users.
As these best practices are constantly evolving, we recommend you check back occasionally throughout your application development process.
This document focuses on common APIs and development technologies related to your application and its user security.
As these best practices continue to develop, we recommend that you occasionally go back and check in your application development process.
 
 
Using Dalvik Code
Use Dalvik code
Writing secure code that runs in virtual machines is a well-known topic and category of the issues are not specific to Android.
Rather than attempting to rehash these topics, we 'd recommend that you familiarize yourself with the existing literature.
Two of the more popular resources are:
Writing security code running on a virtual machine is a well-studied topic, and many issues are not specific to Android.
We recommend that you familiarize yourself with the existing documents.
1. http://www.securingjava.com/toc.html
2. https://www.owasp.org/index.php/Java_Security_Resources
This document is focused on the areas which are Android specific and/or different from other environments.
For developers experienced with VM programming in other environments, there are two broad issues that may be different about writing apps for Android:
This document focuses on Android proprietary and/or different from other environments.
For developers with VM programming experience in other environments, there are two common problems that may be somewhat different for compiling Android applications.
 
 
Some virtual machines, such as the JVM or. net runtime, act as a security boundary, isolating code from the underlying operating system capabilities.
On Android, the Dalvik VM is not a security boundary -- the application sandbox is implemented at the OS level, so Dalvik can interoperate with native code in the same application without any security constraints.
Some virtual machines, such as JVM or. net, act as a security boundary, and the code is isolated from the underlying operating system capabilities.
On Android, Dalvik VM is not a security boundary-the application sandbox is implemented at the system level. Therefore, Dalvik can operate with native code on the same application without any constraints.
 
 
Given the limited storage on mobile devices, it's common for developers to want to build modular applications and use dynamic class loading.
When doing this consider both the source where you retrieve your application logic and where you store it locally.
Do not use dynamic class loading from sources that are not verified, such as unsecured network sources or external storage, since that code can be modified to include malicious behavior.
Known storage restrictions on mobile phones are common for senders who want to build modular applications and use dynamic class loading.
In this case, we need to consider two resources: one is where you restore your application logic, and the other is where you store them.
Do not use dynamic class loaders for resources that have never been verified, such as insecure network resources or external storage, because the code may be modified to include malicious behaviors.
 
 
Using Native Code
Use Native code
In general, we encourage developers to use the Android SDK for most application development, rather than using native code.
Applications built with native code are more complex, less portable, and more like to include common memory partition uption errors such as buffer overflows.
In general, for most application development, we encourage developers to use Android SDK instead of native code.
Applications that compile native code are more complex and less portable. They are more likely to include common memory crash errors, such as buffer overflow.
 
 
Android is built using the Linux kernel and being familiar with Linux development security best practices is especially useful if you are going to use native code.
This document is too short to discuss all of those best practices, but one of the most popular resources is "Secure Programming for Linux and Unix HOWTO", available at http://www.dwheeler.com/secure-programs.
Android uses Linux kernel compilation and is similar to Linux development. If you plan to use native code, security best practices are particularly useful.
This article discusses all these best practices too short, but one of the most popular resources is "Secure Programming for Linux and Unix HOWTO", where you can find the http://www.dwheeler.com/secure-programs
 
 
An important difference between Android and most Linux environments is the Application Sandbox.
On Android, all applications run in the Application Sandbox, including those written with native code.
At the most basic level, a good way to think about it for developers familiar with Linux is to know that every application is given a unique UID with very limited permissions.
This is discussed in more detail in the Android Security Overview and you shoshould be familiar with application permissions even if you are using native code.
An important difference between Android and most Linux environments is the application sandbox.
In Android, all applications run in the application sandbox, including those written in native code.
At the most basic level, for developers, a good way to consider it is similar to Linux, knowing that each application is assigned a unique UID with very limited permissions.
This article is more detailed than the Android Security Overview. You should be familiar with the application license, even if you are using native code.
 
 
Storing Data
Data Storage
Using internal files
Use internal files
By default, files created on internal storage are only accessible to the application that created the file.
This protection is implemented by Android and is sufficient for most applications.
By default, files created in internal storage are only accessible to applications that create this file.
This protection is implemented by Android and is sufficient for most applications.
 
 
Use of world writable or world readable files for IPC is discouraged because it does not provide the ability to limit data access to particle applications, nor does it provide any control on data format.
As an alternative, you might consider using a ContentProvider which provides read and write permissions, and can make dynamic permission grants on a case-by-case basis.
IPC (inter-process communication) is frustrating to use world writable or world readable files because it does not provide the ability to restrict data access to specific applications, nor provides any data formatting control.
As an alternative, you should consider using a ContentProvider to provide a read/write license, and establish a dynamic license guarantee based on the specific analysis of specific issues.
 
 
To provide additional protection for sensitive data, some applications choose to encrypt local files using a key that is not accessible to the application. (For example, a key can be placed in a KeyStore and protected with a user password that is not stored on the device ).
While this does not protect data from a root compromise that can monitor the user inputting the password, it can provide protection for a lost device without file system encryption.
To provide additional sensitive data protection, some applications use an inaccessible key to encrypt local files (for example: A key may be stored in the KeyStore and protected by a password stored outside the device)
This does not protect data to prevent the intrusion of root permissions that allow users to enter passwords. It can protect lost devices without file system encryption.
 
 
Using external storage
Use External Storage
Files created on external storage, such as SD Cards, are globally readable and writable.
Since external storage can be removed by the user and also modified by any application, applications shocould not store sensitive information using external storage.
Files created on external storage, such as the SD card, can be read and written globally.
Because external storage can be removed by users and can be modified by any application, the application should not use external storage to store sensitive information.
 
 
As with data from any untrusted source, applications shocould perform input validation when handling data from external storage (see Input Validation section ).
We stronugly recommend that applications not store executables or class files on external storage prior to dynamic loading.
If an application does retrieve executable files from external storage they shoshould be signed and cryptographically verified prior to dynamic loading.
When processing data from external storage, the application should perform input verification (see input verification)
We strongly recommend that applications do not store executable or class files to external storage before dynamic loading.
If an application retrieves executable files from external storage, they should be signed and encrypted for verification before being Dynamically Loaded.
 
 
Using content providers
Use content providers
ContentProviders provide a structured storage mechanisms that can be limited to your own application, or exported to allow access by other applications.
By default, a ContentProvider is exported for use by other applications.
If you do not intend to provide other applications with access to your ContentProvider, mark them as android: exported = false in the application manifest.
ContentProviders provides a structured storage mechanism that can restrict your own applications or export them to other applications for access.
By default, a ContentProvider is exported by other applications for use. (For using ?)
If you do not want to provide other applications with the ContentProvider function, mark them as android: exported = false in manifest.
 
 
When creating a ContentProvider that will be exported for use by other applications, you can specify a single permission for reading and writing, or distinct permissions for reading and writing within the manifest.
We recommend that you limit your permissions to those required to accomplish the task at hand.
Keep in mind that it's usually easier to add permissions later to expose new functionality than it is to take them away and break existing users.
When you create a ContentProvider that is exported by other applications for use, you can specify a single License for read and write, or specify a specific license for read and write in manifest.
We strongly recommend that you restrict your permission to the necessary tasks.
Remember, it is easier to show new features to join a license later than to remove the license and interrupt existing users.
 
 
If you are using a ContentProvider for sharing data between applications built by the same developer, it is preferable to use signature level permissions.
Signature permissions do not require user confirmation, so they provide a better user experience and more controlled access to the ContentProvider.
If you are using ContentProvider to share data between applications of the same developer, signature-level licensing is more desirable.
The signature license does not need to be confirmed by the user, so this provides a better user experience and better control of ContentProvider access.
 
 
ContentProviders can also provide more granular access by declaring the grantUriPermissions element and using the FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flags in the Intent object that activates the component.
The scope of these permissions can be further limited by the grant-uri-permission element.
ContentProviders can also provide more granular access by declaring the grantUriPermissions element and using the FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flag in the Intent object of the trigger component.
The scope of these licenses can be further restricted by the grant-uri-permission element.
 
 
When accessing a ContentProvider, use parameterized query methods such as query (), update (), and delete () to avoid potential SQL Injection from untrusted data.
Note that using parameterized methods is not sufficient if the selection is built by concatenating user data prior to submitting it to the method.
When accessing a ContentProvider, you can use parameterized query methods, such as query (), update (), and delete () to avoid potential SQL injection from data that is not new to users.
Note: If you select to connect to user data before submitting the method, it is not enough to use the parameterized method.
 
 
Do not have a false sense of security about the write permission.
Consider that the write permission allows SQL statements which make it possible for some data to be confirmed using creative WHERE clses and parsing the results.
For example, an attacker might probe for presence of a specific phone number in a call-log by modifying a row only if that phone number already exists.
If the content provider data has predictable structure, the write permission may be equivalent to providing both reading and writing.
Do not have a wrong idea about "write" permission security
Consider "write" permission to allow SQL statements so that some data is confirmed to use creative WHERE clauses and the analysis results become possible.
For example, an intruder may modify a record in a call record to detect an existing phone number, as long as the phone number already exists.
If the content provider data has a predictable structure, the "write" license may be equivalent to providing "read/write.