Best practices to protect data in Android applications - Part 1

Android has security features built into the operating system that significantly reduce the frequency and impact of application security issues. The system is designed so you can typically build your apps with

default system and file permissions and avoid difficult decisions about security.

It is important to be familiar with Android security best practices, following these practices as general coding habits will reduce the likelihood of inadvertently introducing security issues that adversely affect your users.:

• The Android Application runs in a Sandbox, which automatically isolates your app data and code execution from other apps.

• User-granted permissions is another level of security provided to restrict access to system features and user data.

• Application-defined permissions to control application data on a per-app basis.

• Storing Data
• Using Internal Storage : By default, files that you create on internal storage are accessible only to your app. You should generally avoid using the MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE modes for IPC files because they do not provide the ability to limit data access to particular applications, nor do they provide any control on data format.
• Using External Storage : It is strongly recommend that you not store executables or class files on external storage prior to dynamic loading. If your app does retrieve executable files from external storage, the files should be signed and cryptographically verified prior to dynamic loading.
• Using Content Providers : Content providers offer a structured storage mechanism that can be limited to your own application or exported to allow access by other applications. If you do not intend to provide other applications with access to yourContentProvider, mark them as android:exported=false in the application manifest. Otherwise, set theandroid:exported attribute "true" to allow other apps to access the stored data.

• Using Permissions - As Android sandboxes applications from each other, applications must explicitly share resources and data. They do this by declaring the permissions they need for additional capabilities not provided by the basic sandbox, including access to device features such as the camera.
• Requesting permissions : In general, it is recommend using access controls other than user confirmed permissions where possible because permissions can be confusing for users. For example, consider using the signature protection level on permissions for IPC communication between applications provided by a single developer.
• Creating permissions : Generally, you should strive to define as few permissions as possible while satisfying your security requirements. If you must create a new permission, consider whether you can accomplish your task with a "signature" protection level. Signature permissions are transparent to the user and only allow access by applications signed by the same developer as application performing the permission check. If you create a permission with the "dangerous" protection level, there are a number of complexities that you need to consider:
• The permission must have a string that concisely expresses to a user the security decision they will be required to make.
• The permission string must be localized to many different languages.
• Users may choose not to install an application because a permission is confusing or perceived as risky.
• Applications may request the permission when the creator of the permission has not been installed.

• Using Networking : Network transactions are inherently risky for security, because it involves transmitting data that is potentially private to the user.
• Using IP Networking : Networking on Android is not significantly different from other Linux environments. The key consideration is making sure that appropriate protocols are used for sensitive data, such as HttpsURLConnection for secure web traffic. We prefer use of HTTPS over HTTP anywhere that HTTPS is supported on the server, because mobile devices frequently connect on networks that are not secured, such as public Wi-Fi hotspots. Authenticated, encrypted socket-level communication can be easily implemented using the SSLSocket class. 

• Using WebView : Because WebView consumes web content that can include HTML and JavaScript, improper use can introduce common web security issues such as cross-site-scripting (JavaScript injection). Android includes a number of mechanisms to reduce the scope of these potential issues by limiting the capability of WebView to the minimum functionality required by your application. 
• If your application does not directly use JavaScript within a WebView, do not call setJavaScriptEnabled(). 
• Use addJavaScriptInterface() with particular care because it allows JavaScript to invoke operations that are normally reserved for Android applications. If you use it, expose addJavaScriptInterface() only to web pages from which all input is trustworthy. If untrusted input is allowed, untrusted JavaScript may be able to invoke Android methods within your app. In general, we recommend exposing addJavaScriptInterface()only to JavaScript that is contained within your application APK.
• f your application accesses sensitive data with a WebView, you may want to use the clearCache() method to delete any files stored locally. Server-side headers like no-cache can also be used to indicate that an application should not cache particular content.
• Devices running platforms older than Android 4.4 (API level 19) use a version of webkit that has a number of security issues. As a workaround, if your app is running on these devices, it should confirm that WebView objects display only trusted content. You should also use the updatable security Provider object to make sure your app isn’t exposed to potential vulnerabilities in SSL, as described in Updating Your Security Provider to Protect Against SSL Exploits. If your application must render content from the open web, consider providing your own renderer so you can keep it up to date with the latest security patches.

• Handling Credentials : In general, it is recommend to minimize the frequency of asking for user credentials—to make phishing attacks more conspicuous, and less likely to be successful. Instead use an authorization token and refresh it.
• Where possible, username and password should not be stored on the device. Instead, perform initial authentication using the username and password supplied by the user, and then use a short-lived, service-specific authorization token.
• Services that will be accessible to multiple applications should be accessed using AccountManager. If possible, use the AccountManager class to invoke a cloud-based service and do not store passwords on the device.
• After using AccountManager to retrieve an Account, CREATOR before passing in any credentials, so that you do not inadvertently pass credentials to the wrong application.
• If credentials are to be used only by applications that you create, then you can verify the application which accesses the AccountManager using checkSignature(). Alternatively, if only one application will use the credential, you might use a KeyStore for storage.

• Using Cryptography : In addition to providing data isolation, supporting full-filesystem encryption, and providing secure communications channels, Android provides a wide array of algorithms for protecting data using cryptography. 

Will explain with an example on using Cryptography in Part 2