Android Security Tips Notes

Http://developer.android.com/training/articles/security-tips.html
1. Data storage
Internal storage
The data stored by internal storage can only be accessed by the app itself.
For sensitive data, it is recommended to use KeyStore.
External storage
External storage, such as an SD card, can be read or written by any app, and can be removed by the user, so it cannot be used to store sensitive data.
If you are processing data from external storage, validation must be done.
It is strongly recommended that you do not store executable files or class files that are used for dynamic loading. If you must do this, the files must be signed and encrypted.
Content Provider
He provides a structured storage mechanism to restrict access to restricted content by his app or other apps.
If you're not going to let other apps access your content provider, set Android:exported=false
If you create a content provider for use by another app, you must indicate the appropriate permissions.
If you use content provider to share data between several apps, you need to Android:protectionlevel =signature

2. Permissions
Request permission
Reduce the requested permissions as much as possible, such as storing the data in an internal store instead of being stored in an external storage area.
Create permissions
Define as few permissions as possible.
If you define permissions, you must have a string that explicitly tells the user what to do, the string must be translated, and the user can reject the request without installing the app.

3. Network
IP network
Because mobile devices frequently connect to networks that are not encrypted, such as public Wi-Fi hotspots, it is recommended to use HTTPS instead of HTTP.
HTTP access is recommended for use with Httpsurlconnection,socket, and Sslsocket is recommended.
The app uses localhost to handle interprocess communication, which is not recommended because it can be used by other apps. It is best to use service.
Do not trust data downloaded by HTTP or other non-secure protocols.
Moving data
Don't use text messages to store or transfer sensitive data, because other apps can read text messages.

4. Verify the input
If you use native code, data passed from the network and other processes can introduce security issues.
Note Access script or SQL injection attacks.

5. Processing User Data
Try to avoid storing or transmitting user-sensitive data, such as email.
If you need to access information such as a user name password, you may need to provide a privacy protection policy to the user.
Please do not expose sensitive data to apps that are not trusted by third parties.
If you need a GUID, create one yourself, do not use the IMEI or phone serial number.
Careful use of the device Log,log is also a shared resource, and other apps can request Read_logs permissions to access log.

6.WebView
WebView will load HTML and JavaScript, possibly introducing cross-site attacks. If you do not need to use JavaScript, do not call setjavascriptenabled ().
Addjavascriptinterface () is best to use only for your own app.
If you use WebView to access sensitive data, remember to clean up the cache.

7. Credentials
Try not to request credentials to the user.
If possible, try not to store your user name and password on your device, and recommend using a short-term valid token.
Use Accountmanager to process some credential information, or Keystore,keychain.

8. Encryption
If you need a custom encryption algorithm, it is recommended to use the system's AES sum RSA

9. Inter-process communication
It is recommended to use Intent,binder,messenger,servier,broadcast instead of traditional Linux technology implementations.

10.Intent
If the data passed by intent contains sensitive information, you need to set permissions to ensure that the app that owns the permission can receive it.

11.Service
By default, the service does not export and is not called by other apps.
If necessary, add permissions,
Before calling, you can use Checkcallingpermission () to check

Binder and Messenger
Defining Permissions and Interfaces

Broadcast receiver
This can be called by any app, notice the definition of permissions

14 Dynamic load Code
It is strongly recommended that you do not dynamically load code from outside, and if necessary, sign and use Dexclassloader.

15 Virtual Machine Security
Dynamic load code is not recommended

Native Code
Try using the Android SDK, not really, using the Android NDK.

Android Security Tips Notes