Developing Secure Android Application

Talk Presented on Google Developers Group, Ahmedabad's DevFest 2015!
Just as we keep our office, home, and family secure. We as developers need to keep our Applications also secured. Like all other Platforms or Languages, secure coding guidelines are there also for Android.The main objective of this session is to share about secure coding guidelines and how small tricks and tips can help securing applications.

Transcript

1. Android Developing Secure Application Harsh Dattani, GDG Baroda A learner like you all! No body is PRO in security
2. AboutMe.apk A Cyber Security Student @Gujarat Forensic Sciences University and a Learner! Always! :P Om Shanti Harsh Dattani
3. Secure Coding Guidelines • Such guidelines even exists on Earth?? :D
4. Secure Coding Guidelines • Such guidelines even exists on Earth?? :D • Who cares! No one’s gonna hack my app :P
5. Secure Coding Guidelines • Such guidelines even exists on Earth?? :D • Who cares! No one’s gonna hack my app :P • Lets finish this project anyhow!! ;)
6. Secure Coding Guidelines • Computer Emergency Response Teams (CERT) are expert groups that handle Computer/IT security incidents. • Issued Android Secure Coding Guidelines.
7. We all Know this!
8. And this! • Activity • Content Providers • Intents • Permissions • Services • Shared Prefs • Views (Mostly WebView)
9. Also this!
10. Assets in Android
11. Assets in Android • Device Information • Personal Information (User’s) • Friend’s Personal Information
12. Attack Vectors in Android
14. Attack Vectors in Android • Mounting SD Card in PC
15. Attack Vectors in Android • Mounting SD Card in PC • Malicious App
16. Attack Vectors in Android • Mounting SD Card in PC • Malicious App • Network Attack
17. Attack Vectors in Android • Mounting SD Card in PC • Malicious App • Network Attack • Malicious File Attack
18. Attack Vectors in Android • Mounting SD Card in PC • Malicious App • Network Attack • Malicious File Attack • User’s Unawareness
19. Attack Vectors in Android • Mounting SD Card in PC • Malicious App • Network Attack • Malicious File Attack • User’s Unawareness • USB Debugging
20. Attack Vectors in Android • Mounting SD Card in PC • Malicious App • Network Attack • Malicious File Attack • User’s Unawareness • USB Debugging • Root permissions!! (Can do anything)
21. Attack Vectors in Android • Mounting SD Card in PC • Malicious App • Network Attack • Malicious File Attack • User’s Unawareness • USB Debugging • Root permissions!! (Can do anything)
22. Security Policies
23. Unix Security Policy 1. Process Isolation 2. Hardware Isolation 3. User Permission Model 4. R/W/X Permissions to file 5. Secure IPC
24. Android Security Policy 1. Application Isolation 2. Sandbox of Application 3. Secure Communication 4. Signing the Application 5. Permission model of Application
25. To Do’s to Secure Apps
26. 1. Avoid Simple Logics
27. 1: Avoid Simple logics if(LoginAccess==1){ ... ... } ---------------------------------------------------------------------------- if(Login.Access = True){ ... ... }
28. 2. Test 3rd Party Libraries!
29. “Caution: Developers rely heavily on third-party libraries. It is important to thoroughly probe and test this as you test your code. Third-party libraries can contain vulnerabilities and weaknesses. Many developers assume third-party libraries are well-developed and tested, however, issues can and do exist in their code.
30. 3. Use Encryption
31. “Caution: External storage can become unavailable if the user mounts the external storage on a computer or removes the media, and there's no security enforced upon files you save to the external storage. All applications can read and write files placed on the external storage and the user can remove them.” -- http://developer.android.com/guide/topics/data/data-storage.html
32. But How to Encrypt?
33. How to Encrypt or Encode? 1. Encode Shared Preferences 2. Encrypt SQLite: SQLCipher 3. Encrypt Network: TLS 4. Data Encryption: Facebook’s Conceal Library 5. MD5, SHA Sensitive Data
34. 4. Handle Input Data
35. “Caution: An Android application can be coded in Java or native code, which is C++. When Java is used, many of the data validation issues like buffer overflow, format string issues, and others are eliminated, as the language itself is not vulnerable. When using native code, special care needs to be taken when data is read from an untrusted source because it is vulnerable to issues like buffer overflow, format string issues, and more.” -- White Paper by Mcafee
36. 5. Secure Intents
37. <Activity android:name="com.example.ProfilePage" android:exported="true”> </activity> ---------------------------------------------------------------------------- <Activity android:name="com.example.ProfilePage" android:exported="false”> </activity> P.S. Custom Permissions can also be helpful to limit Intent usage by Malicious applications
38. 6. Secure WebView
39. • setJavaScriptEnabled(): Default is False • setPluginState(): Default is OFF • setAllowFileAccess(): Default is True • setAllowContentAccess(): Default is True • setAllowFileAccessFromFileURLs(): Default value is True for API level 15 and below, and False for API level level 16 and above. • setAllowUniversalAccessFromFileURLs(): Default value is True for API level 15 and below, and False for API level level 16 and above. --------------------------------------------------------------------------------------------------------------------------------------------- • Don’t: Enable JavaScript for all pages. • Do: If Enabled, make sure it’s a local address or trusted address. • Use HTTPS, whenever possible
40. 7. Secure Logs
41. Log.v("method", Login.TAG + ", username=" + name); Log.v("method", Login.TAG + ", password=" + pass); ---------------------------------------------------------------------------- -assumenosideeffects class android.util.Log { public static *** d(...); public static *** w(...); public static *** v(...); public static *** i(...); }
42. 8. Secure Intent Leaks
43. • Don’t Broadcast Sensitive information in Intents • Attacker can intercept the broadcasted data. (Demo) • Broadcast Securely using: LocalBroadcastManager.getInstance(this).sendBroadcast(intent);
44. 9. Code Obfuscation
45. • Proguard • Don’t include unused Classes and Libraries • Difficult to protect from Smali Decompilation
46. 10. Use of Tokens for Authentication
47. 11. Use of HTTPS!
48. Our Evils: 1. ADB 2. Malicious Applications 3. Unprotected Network 4. Sniffers
49. Our Friends: 1. Android Fuzzers 2. Xposed Framework 3. Drozer 4. APKtool or any other Static Analysis Tool 5. Penetration Tools for Android and Many more...
50. AskMe.apk?
51. ContactMe.apk! dattaniharsh12@gmail.com github.com/harshdattani