Android Apps Security


Android operating system is designed in such a way that most developers will be able to build apps with default settings without having to bother about external securities.

Some of the security features that help developers build secure applications include:
  •  Android application data that isolates data and code execution.
  •  Security functionalities like cryptography, Inter Process Communication and Permissions.
  • Technologies like ASLR, NX, Propolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, and Linux mmap_min_addr to mitigate risks assiociated with common memory management errors.
  • An encrypted file system that can be enabled to protect data on lost or stored devices.



Privacy Policy

All apps should have a privacy policy. The Play Store contains a place to upload a privacy policy so this is no longer needed within the app itself. 

Storing data
  • Internal  files -  Files stored internally are accessible only to that particular app. For most of the apps, this method is sufficient. We should use Context.MODE_PRIVATE when writing data.
  • 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 should not store sensitive information using external storage. Never store personal data on external storage. 
  • Content Providers -  They provide a structured storage mechanism that can be limited to your own application, or exported to allow access by other applications. If Content Providers are using for sharing data between applications built by the same developer, it is preferable to use signature - level permissions. We need to keep in mind that Content Providers export data by default. 
  • Never leave personal data in logcat logs. Any app can read logcat logs.




·      InterProcess Communication
  •  Intents -  Intents are the preferred mechanism for asynchronous IPC in Android. Senders of an intent can verify that the recipient has a permission  specifying a non -null permission upon sending. Only applications with that permission will receive the intent. 
  •   Binder and AIDL Interfaces - Binders are preferred mechanism for RPC - style IPC in android. Binders  generally inherit permissions declared in the application manifest for the service or activity within which it is implemented. 
  •   Broadcast receivers - Used to handle asynchronous requests initiated via an intent.
  •   Services - Used to supply functionality for other applications. It can protect individual IPC calls into it with permissions, by calling checkCallingPermission() before executing the implementation of that call.
  •  Activities - Activities are most often used for providing the core - user facing functionality of an application.
Using Permissions
  • Requesting Permissions - It is always recommended to minimize the number of permissions requested by an application.
  • Creating Permissions - Like requesting permissions, it is always recommended to minimize the number of permissions. Users should check access using existing permissions.
Networking
  • IP Networking - The key consideration is making sure that appropriate protocols are used for sensitive data, such as HTTPS for web traffic.
  • Telephony Networking - SMS is the telephony protocol most frequently used by Android developers. It is mainly for user - to -user communications and is not suited for application purposes.
Dynamic loading code
  • Loading code from outside of the APK is not recommended. If it is unavoidable, make sure that the code comes from a trust worthy source.
  • Using WebView - WebView Consumes web content that can include HTML and Java Script, improper use can introduce common web security issues such as cross - site  - Script, 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.
User Validation
  • Insufficient input validation will always lead to serious problems affecting the security of the system. If the native code is used , then any data send from files, received over the network, or received from IPC has the potential to introduce a security issues.
Handling User Data
The best approach is to minimize use of APIs that access sensitive or personal data. Storing and transmission of data is not recommended. If the application accesses personal information such as passwords or usernames, keep in some jurisdictions may require to provide a privacy policy explaining the use and storage of that data.
  • Handling credentials - The frequency of asking user credentials should be minimized. The username and password should not be stored on the device.
Cryptography


In addition to providing data isolation, supporting full - file system encryption, and providing secure communications channels Android provides a wide array of algorithms for protecting data using cryptography. The basic cryptographic algorithm used is AES algorithm for encryption.

Next - Best Design Approach for Encryption

Comments

Popular posts from this blog

Difference between "diff" and "sdiff" commands in Unix

Anonymous classes in C++