Recommendations for Android program security

<span id="Label3"></p>Recommendations for Android program security<p><p>Transferred from: http://geyubin.iteye.com/blog/1688583</p></p><p><p>If you ensure that your program is more secure, you can improve the safety of your program by the following measures:</p></p><p><p>1. Do not store sensitive data on external storage devices, such as memory cards. Store the user name password in keystore.</p></p><p><p>2.ContentProvider to use data manipulation with parameters to prevent SQL Injection.</p></p><p><p>3. Broadcast receivers, activities, services, etc. do not require other program access, set in the manifest File: android:exported property is False.</p></p><p><p>Also set the filter condition, or increase access rights</p></p><p><p>4. Use IP networks as much as possible, C2DM instead of Sms. Use the security protocol to connect to the service, such as using HTTPS instead of using HTTP.</p></p><p><p>5. It is not recommended to load dynamic code EXTERNALLY. The source of dynamic code to be trusted, code can be verified, there are encryption Measures.</p></p><p><p>6. When using webview, do not use javascript, do not turn on JavaScript features, prevent cross-site scripting attacks. When transferring data</p></p><p><p>It is recommended to use HTTPS. Do not cache user Information.</p></p><p><p>7. Check the re-use of all input data First.</p></p><p><p>8. Do not store the User's sensitive information on the device or transmit it to the Network. storage, the transfer process to be Encrypted.</p></p><p><p>9. Do not require the user to enter credentials more than once, the recommended way to use Access Tokens.</p></p><p><p>10. To encrypt the data, it is best to choose an existing encryption algorithm instead of designing the algorithm Yourself.</p></p><p><p></p></p><p><p></p></p><p><p><strong>Detailed explanation:</strong></p></p><p>Some virtual machines run within a security boundary and are isolated from the programs on which the operating system resides, such as the Java Virtual machine and the. NET runtime Environment.<br>On android, the Dalvik virtual machine does not have such a security boundary, the application sandbox is implemented at the operating system level, so<br>In the same program, Dalvik interacts with native code without any security Boundaries.<br><br><br>Idle Storage Policy for mobile Devices. Under normal circumstances, developers want to create modular applications that are implemented through dynamic class Loading. As a matter of fact<br>There are two issues to Consider: program logic and storage Location. Do not use class resources that are not checked, such as insecure network resources or external storage<br>Resources on the device, because such resources can be modified to include malicious actions.<br><br><br><strong><strong>using native code</strong></strong><br><br><br>In general, we recommend that developers use the Android SDK to develop most programs, rather than using native Code. The program uses native code to go<br>The build will be more complex and bulky, and there may be some common memory usage errors, such as buffer exceptions.<br><br><br>Android is built on the Linux kernel, and if you're familiar with Linux development, it's better to use native Code. This document is only a small amount of space<br>Introducing this recent practice, to learn more about the security resources for Linux and UNIX programming, please visit this URL http://www.dwheeler.com/secure-programs<br><br><br>An important difference between Android and most other Linux runtime environments is the sandbox of programs. On android, All programs are run in the sandbox, even if the program contains<br>Native Code. Developers familiar with Linux know that each program is assigned a unique UID and limited permissions, But even if you are unfamiliar with linux, you should understand This.<br>If you use native code you need to be familiar with the content of program Permissions. Http://source.android.com/tech/security/index.html<br><br><br><strong><strong>Storing Data</strong></strong><br>Using program internal storage<br>By default, files created inside a program can only be used by this Program. It is sufficient for the secure storage of most PROGRAMS.<br><br><br>It is not recommended to use global read or write permissions between processes, so there is no way to restrict certain programs from accessing the data and not to control the data format.<br>As an option, it is possible to use ContentProvider with Read/write permission, or to grant access to the data dynamically, depending on the Situation.<br><br><br>To provide more protection for sensitive data, Some programs choose how to encrypt local files using a key. For example, The key is placed in the keystore, with<br>To protect the User's password, rather than storing it directly on the Device. however, The data cannot be protected in this case: the device is root, the User's input password<br>Can be heard by the Supervisor. You can protect a device that has a file encryption system from being Lost.<br><br><br><strong><strong>using external storage</strong></strong><br><br><br>Global Read and Write permission to store files on an external storage device, such as on an SD Card. Because the external storage device can be removed by the user, it can be modified by any program,<br>Do not store sensitive data using external storage Devices.<br><br><br>For data obtained from any source that cannot be trusted, the input should be checked by the program from the external Store. We strongly recommend against external storage Devices.<br>Stores a dynamically loaded executable file or class File. If a program loads an executable file from an external store, the file must be signed and encrypted, and checked before Loading.<br><br><br><strong><strong>Using Content providers</strong></strong><br><br><br>ContentProvider provides a storage mechanism that can restrict its own programs or provide an access portal to other Programs. by default,<br>A contentprovider is a portal that other programs provide to the User. If you don't want other programs to access your contentprovider, in the manifest file<br>This indicates android:exported=false.<br><br><br>Creating a ContentProvider will open a portal for other programs, you can specify a read-write permission or separate read and write Permissions. We recommend<br>You separate the permissions and allocate them on demand. remember, It is usually easier to add permissions for future new features rather than removing them and affecting existing Users.<br><br><br>If ContentProvider is used to share data between two programs developed by the same developer, it should tend to use Signature-level permissions, and signature permissions do not require user Confirmation.<br>So there will be a better user experience, more access control for Contentprovider.<br><br><br>ContentProvider also grams provide more rhetorical statements, specified by Granturipermison elements, using Flag_grant_read_uri_permission and Flag_grant_write_uri_ PERMISSION<br>These flags are on the intent Object. The scope of the permission can be further restricted with the grant-uri-permisstion Element.<br><br><br>When accessing contentprovider, using methods with parameters, such as query (), update (), and delete (), can prevent potential SQL injection risks from untrusted Data.<br>Note that it is not safe to use parameterized methods if you are using assembled data to submit to these METHODS.<br><br><br><br><br>Do not have such a false view of write permissions, you can imagine that write permissions allow the use of SQL statements, so that some data can use the WHERE clause to assemble the Results.<br>For example, an attacker might want to see an existing phone number, and if that number already exists, modify a row of data in Call-log.<br>If the content provider has a predictable structure, the Write permission is equivalent to providing both read and write Permissions.<br><br><br>Using interprocess communication (IPC)<br><strong><strong>using interprocess communication</strong></strong><br><br><br>Some Android programs attempt to use traditional Linux interprocess communication technologies such as network sockets and shared Files. We are strongly in the process of using the Android system<br>Communication technology is not as good as the IPC mechanism of Intent,binder,service and receiver.android allows you to verify that the program connects your IPC program if it is legal and can<br>Set security policy for IPC.<br><br><br>Many security components share data through the IPC MECHANISM. Broadcast receivers, activities, and services are declared in the manifest of the Program. If your IPC mechanism is not<br>For other programs to access, set the Android:exported property to False. This is useful for multiple processes that use the same UID for multiple programs, or<br>You later decide that you don't want to share data through the ipc, you don't need to rewrite the Code.<br><br><br>If your IPC is intended for other programs to access, you can set the permission flags as security Policy. If the IPC is a program of the same developer,<br>You should use the signature level of permission control, signing permissions do not require user confirmation, so there will be a better user experience, more IPC access Control.<br><br><br><br><br>Using intent filtering is easy to confuse, note that intent filtering should not be considered a security feature, this component can be called directly, and will not have<br>Confirmation of the intent Filter. You should perform input validation to ensure that your intent recipient receives receiver,service, and that the activity is sent in the correct format.<br><br><strong><strong>Using intents</strong></strong><br><br><br>The intent is the asynchronous IPC mechanism recommended in ANDROID. Based on your program needs, you can use Sendbroadcaset (), sendorderedbraodcast () or<br>Sends intent directly to the specified program Component.<br><br><br>Note that ordered broadcast can be consumed by all recipients and may not be sent to all Programs. If you want to send a intent to a designated recipient, This intent must be sent directly<br>To the recipient of the Designation.<br><br><br>If you do not specify a permission limit of intent, it may be received by another Recipient. Restricted to recipients with the specified permission to receive this Intent. set intent permissions to<br>Improve Security.<br><br><br><strong><strong>using binder and Aidl interfaces</strong></strong><br>Binder is the recommended mechanism for Android to remotely invoke Ipc.<br><br><br>We strongly encourage designing interfaces in a manner so does not require interface specific<br>Permission Checks. Binders is not declared within the application manifest, and therefore you<br>Cannot apply declarative permissions directly to a Binder. Binders generally inherit permissions<br>Declared in the application manifest for the Service or Activity within which they is implemented.<br>If you is creating an interface the requires authentication and/or access controls on a specific<br>Binder interface, Those controls must is explicitly added as code in the Interface.<br><br><br>If providing an interface this does require access controls, use Checkcallingpermission ()<br>To verify whether the caller of the Binder has a required permission. This is especially<br>Important before accessing a Service on behalf of the caller, as the identify of your<br>Application is passed to other Interfaces. If invoking an interface provided by a Service,<br>The Bindservice () invocation may fail if you don't have a permission to access the given Service.<br>If calling an interface provided locally by your own application<br>Clearcallingidentity () to satisfy internal security checks.<br><br><br><strong><strong>using an IP network:</strong></strong><br>It is recommended to use the HTTPS protocol network, other unsecured protocols of the network try not to Use. When using public Wiff hotspots, These open networks are not<br>The encrypted Network.<br><br><br><strong><strong>using the telephone network</strong></strong>：<br>SMS is designed for People-to-people communication, so it is not appropriate for some programs to use C2DM and IP networks to send data messages to Devices.<br>SMS in the process of network transmission, there is no data encryption, there is no strong authentication Mechanism. In particular, any SMS recipient can receive information sent by a malicious person to your program,<br>Do not use a command that does not have authenticated SMS to perform operational sensitive Information. It is also recognized that SMS may be intercepted or spoofed via Sms. Devices on Android<br>, the SMS message transmission is sent in the form of broadcast intent, so the message may be read by a program that has the ability to read SMS Permissions.<br><br><br><strong><strong>Dynamic Load Code</strong></strong><br><br><br>We strongly do not recommend the APK program to dynamically load code from Outside. If you do this, you will increase the risk of code injection and code TAMPERING.<br>It also affects version control box program Testing. finally, The program's behavior is poorly validated, so in some cases the program is Blocked.<br><br><br>If your program does dynamic load code, The most important thing to remember is that dynamically loaded code is in the same security permissions as the Loader. User decides<br>The installation of your program is based on a unified labeling Certification.<br><br><br>The greatest security risk for dynamically loading code is to verify the source of the Code. If the program module is included directly in your apk, then other programs cannot be Modified. Whether it's a native library or a dexclassloader-loaded<br>This is the case with Code. We've come across a lot of programs that try to load code that's unsafe, like downloading code That's not encrypted with security protocols from the web, or something like external storage.<br>Load code where the global write permission is Available. These locations will allow some people to modify the contents of the data during the transmission of the network, or the program installed on the device to modify the data Content.<br><br><br><strong><strong>using WebView</strong></strong><br><br><br>Because the WebView component can parse Web page content such as HTML and javascript, it may encounter some common security issues, such as Cross-site scripting attacks (cross-site-scripting,javascript injection).<br>Android contains a number of security mechanisms to reduce this cross-domain condemnation problem, such as by restricting the use of webview with minimal Functionality.<br><br><br>If WebView in your program does not use JavaScript directly, do not call setjavascriptenabled (). By default, WebView does not perform cross-site scripting<br>The execution of Javascript.<br><br><br>Pay special attention when using Addjavascriptinterface (), because this allows JavaScript to invoke the Android program code to execute the Program.<br>Just open the Addjavascriptinterface () to the trusted input source, and if not, sometimes it makes the untrusted JavaScript call the Android Function.<br>generally, We recommend opening addjavascriptinterface () portals only to JavaScript within this Program.<br><br><br>Do not trust data that is downloaded over HTTP and use HTTPS Instead. If you are only accessing a single website, even if it is trusted and controllable, http may be attacked by an intermediate process,<br>The data is intercepted during Transmission. Be vigilant when using addjavascriptinterface (), and be sure not to trust an unauthenticated script that was downloaded via HTTP.<br>Note: even the use of Https,addjavascriptinterface () also increases the likelihood of a program being attacked, although it includes the Server's security settings and the Android device owning all of the trusted Cas.<br><br><br>If you have webview access to sensitive information, you should use the ClearCache () method to remove any cached files that are stored locally. Small message headers on the server side can be used<br>A sign like No-cache to tell the program not to cache specific Content.<br><br><br><strong><strong>Perform input checks</strong></strong><br><br><br>A common security issue is to run the input directly without adequate security checks on the Inputs. Android has a platform-level measure to reduce the problem of exposing the program to no input checks,<br>You should use this feature wherever possible in any place you can use. also, be aware that choosing a language of a security type can reduce the problem of input Validation. We strongly recommend using the Android SDK<br>To build your Program.<br><br><br>Using native code obtained from files, networks, and IPC also increases potential security issues. Common problems are buffer overflows, user exits, Off-by-one errors, and so On. Android<br>Many of the technologies like ASLR and DEP are available to reduce development errors, but they do not resolve these potential errors. Those techniques can be used to prevent pointer control and buffer management Problems.<br><br><br>dynamic, string-based languages, such as JavaScript and sql, for input checking can prevent special characters and script injection Problems.<br><br><br>SQL injection can make a problem if you are using a SQL database or content provider when you are querying a row of Data. The final counter-measure is to use a parameterized query, just like the content provider<br>Section described in the Same. Restricting read-only and Write-only permissions can also reduce the risk of potential SQL Injections.<br><br><br>If you use WebView be sure to consider the possibility of exaggerating scripting attacks (XSS). If your program, WebView does not directly use javascript,<br>Do not call setjavascriptenabled (), then XSS will not Occur. If your program must use javascript, consider other security measures<br>To prevent xss.<br><br><br>If you cannot use the security features described above, we strongly recommend using a well structured data format and fully validating the data format, as well as making special character blacklists, and character substitution libraries, so<br>Will make a more effective strategy. These techniques are very error-prone in the process of use, so be sure to avoid errors as much as Possible.<br><br><br><strong><strong>Process User Data</strong></strong><br><br><br>typically, the most effective way is to use the API sparingly to access sensitive data and personal Information. If this data is actually accessed, then the data is not jant stored and Transmitted.<br>finally, consider using a hashing algorithm or an irreversible algorithm to process the Data. For example, If your program uses a hash algorithm for the e-mail as a key, be sure to<br>Avoid storing and transferring email addresses. This prevents inadvertent exposure to the data, which can also reduce the chance of an exposed program being Attacked.<br><br><br>If your program wants to access personal information such as user name, password, etc., Be sure to remember to use the privacy agreement to interpret the information you use and Store. So<br>In the security best practices that follow, try to minimize access to user data<br><br><br>You also need to consider whether your program inadvertently exposes personal information to other parts of the program, such as third-party ad components or third-party services such as those used in your Program.<br>If you do not know why these components or services need personal information, do not provide the Program. typically, Reducing access to personal information can reduce the potential for program<br>Security Issues.<br><br><br>If you have to access sensitive data, evaluate whether the data is to be transferred to the server, or if you want to perform it on the Client. Allows code in the client to use sensitive Data.<br>Try to prohibit the transmission of user Data.<br><br><br><br><br>Also make sure that you do not pass user data through loose ipc, globally writable files, or inadvertently exposed to other programs by the Web. Here is a special case about permission duplication authorization in the request permission<br>Part of the Discussion.<br><br>It is necessary to create a large, unique globally unique identity to save it. Do not use the identity of a phone such as a phone number or imei, as these relate to personal Information.<br>More information on this topic is on the Android developer Blog. Http://android-developers.blogspot.com/2011/03/identifying-app-installations.html<br><br><br>Program developers need to pay special attention to log information written on the device, on android, the log is a shared resource, to prevent the program from having Read_logs permissions.<br>Even if the Phone's log is temporary or restarted, logging of user information may reveal the User's information to other PROGRAMS.<br><br><br>Handling Credentials<br><strong><strong>Process Vouchers</strong></strong><br>usually, I recommend the minimum frequency to the User's credential information, which can reduce the success rate of phishing attacks. instead, Use the authorization token, and refresh the Token.<br><br><br>Do not store the user name password on the device under any Circumstances.<br>Only the user-supplied user name and password are required for the first authentication, and the authorization token for the service is specified using a short activity cycle.<br><br><br>If a service needs to access multiple programs, you should use Accountmanager. if possible, use the Acctountmangaer class to call the cloud service and not<br>The password is stored on the Device. Http://developer.android.com/reference/android/accounts/AccountManager.html<br><br><br>After using Accountmanager to retrieve a account, check the CREATOR before passing in any credentials,<br>so, you don't inadvertently pass credentials to the wrong application.<br>After using Accountmanager to retrieve the account, please check the creator before passing the voucher, do not pass the voucher to the wrong program.<br><br><br>If the credential information allows its own program to use, when the program accesses Accounmanager to use Checksignature () this method to Wild Goose lineup program Signature.<br>If only one program accesses credential information, you can use KeyStore to store credential Information.<br><br><br>Using Cryptography<br><strong><strong>Using encryption technology</strong></strong><br><br><br>Increase the isolation of data, can support the encryption of the full file system, provide secure channel Access. Android provides a variety of array encryption algorithms to protect Data.<br><br><br>typically, using a high-level framework that already exists can support most usage scenarios. If you need to safely retrieve files from one location, a simple https URI is Sufficient.<br>If you need a secure channel, consider using httpsurlconnection or sslsocket instead of writing your own Protocol.<br><br><br>If you don't find yourself needing to implement your own protocol, we strongly recommend so you don't implement your<br>Own cryptographic Algorithms. Use existing cryptographic algorithms such as those in the implementation of AES or<br>RSA provided in the Cipher class.<br>If you need to implement your own protocol, it is highly recommended that you do not implement your own encryption Algorithm. Use an existing cryptographic algorithm, such as AES or rsa, with the cipher class.<br><br><br>Use the secure random number generator (securerandom) to initialize any encrypted key (keygenerator). if the key used is not a secure random number, it will reduce the encryption Strength.<br>And will allow offline attacks.<br><br><br>If you want to save the key and reuse it, you can use a mechanism like keystore to make long-term access through the encryption Key.<br><br><br><strong><strong>Conclusion</strong></strong><br>Android for developers Oh that the design program security various Measures. These best practices ensure that your program can gain some benefit from Security.<br><br><br>You can receive more information in these topics and discuss security best practices with<br>Other developers in the Android Security discuss Google Group<br><br><br>You can see more security topics or discussions in Android security discuss Google Group.</p><p><p>Recommendations for Android program security</p></p></span>