Security in Android

Transcript

1. Security in Android Orhan Obut © 2003–2014 Monitise Group Limited. All Rights Reserved. Confidential.
2. Android Security Architecture
3. Android seeks to • Protect user data • Protect system resources (including the network) • Provide application isolation Application
4. Android provides : • Robust security at the OS level through the Linux kernel • Mandatory application sandbox for all applications • Secure interprocess communication • Application signing • Permissions
5. Linux Security • A user-based permissions model • Process isolation • Extensible mechanism for secure IPC
6. Linux Security • Prevents user A from reading user B's files • Ensures that user A does not exhaust user B's memory • Ensures that user A does not exhaust user B's CPU resources • Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS, bluetooth) A B
7. The Application Sandbox • Unique user ID (UID) to each Android application and runs it as that user in a separate process • By default, applications cannot interact with each other and applications have limited access to the operating system
8. Sensivite Information Access to sensitive user data is only available through protected APIs
9. Security Tips
10. Storing Data - Internal Storage • By default, files that you create on internal storage are accessible only to your app. • Avoid MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE • Use content provider for share • Consider Encryption for additional protection
11. Storing Data - External Storage • Globally readable and writeable • Always perform input validation • Do not store class files • Always retrieve verified files.
12. Storing Data - Content Providers • A structured storage mechanism • Protection Level, use "signature" to limit with your own apps • User parameterized query methods such as query(), update(), delete to avoid SQL injection • Do not use content provider if you will use only in your app. android:exported = "false" Limited to your own app android:exported = "true" Allow access by other apps
13. Storing Data - Content Providers
14. Requesting Permissions • Minimize the number • Do not request unless you really need it • Do not leak permission-protected data • User <permissions> to protect IPC
15. Creating Permissions • Consider "signature" protection level • Consider complexities when you use "dangerous" protection level
16. Using IP Networking • Mobile uses public Wi-Fi hotspots • Prefer HTTPS over HTTP • Do not trust data downloaded from HTTP or other insecure protocols
17. Using Telephony Networking • Consider using GCM or IP Networking for data transfer • SMS is neither encrpyted not strongly authenticated • SMS messages can be read by other apps
18. Input Validation • Beware of script injection such as javascript and SQL • Use parameterized queries to avoid injections • Always verify the format • Beware of potential secure issues when using native code.
19. Handling User Data • Minimize the use of APIs that access sensivite data • Consider hash/non-reversible form of the data when storing. • Do not expose user data to other apps • If a GUID is required, use UUID. Do not use phone identifiers.
20. Using WebView • Beware of cross-site-scripting (Javascript) • By default, WebView does not execute JavaScript • Do not call setJavaScriptEnabled() if your app does not directly use JavaScript • Use clearCache() when accessing sensitive data
21. Handling Credentials • Minimize the frequency of asking for user credentials, use authorization token and refresh it • Where possible, do not store username and password in the device • Use account manager • Consider KeyStore for storage
22. Using Cryptography • Do not implement your own cryptographic algorithms • Use AES or RSA • Use a secure random generator, (SecureRandom) • Use KeyStore for storing a key
23. Interprocess Communication Use Android system functionality over traditional techniques such as network sockets or shared files. Process A Process B IPC
24. IPC - Broadcast Receiver • By default, receivers are exported • Consider applying a permission to make sure the malicious apps cannot receive. • Use LocalBroadcastManager for internal broadcast.
25. IPC - Services • By default, they are not exported unless you add any intent filter. • Always use exported attribute • Use permission attribute • Use checkCallingPermission()
26. • Preferred for RPC-style IPC • Use checkCallingPermission() to verify whether the caller has a required permission • Binder and Messenger objects are not declared in manifest, therefore you cannot apply permissions IPC - Binder and Messenger Interface
27. Dynamically Loading Code • Do not load code from outside • The code runs in the same permissions as the application • Verify the source if you need to load
28. NDK Use SDK over NDK
29. Logging • Logs are a shared resource • Do not log sensitive data • Do not log data provided from 3rd parties • Remove debug logs in release version
30. Use proguard • Obfuscates your code • Removes your debug logs • Decreases the size
31. Signing APK • Do not sign the application with a publicly known key • Do not sign with the platform key • Applications with the same package name should not be signed with the different keys
32. Security with HTTPS and SSL • Anyone can generate their own certificate and private key, simple handshake does NOT prove that it is secure. • Certificate Authorities (CA) • Android 4.2 currently contains over 100 CAs.
33. Security with HTTPS and SSL • Blacklisting • Pinning • Client certificates
34. References http://developer.android.com