CNIT 128 9. Writing Secure Android Applications
1 like425 views
The document outlines essential strategies for developing secure Android apps, highlighting common vulnerabilities such as code injection, insecure storage, and permissions management. It emphasizes adopting security mechanisms like minimal permissions, cryptographic protections, and secure communication practices, as well as proactive measures to prevent reverse engineering. Additionally, it discusses advanced security techniques, including obfuscation, root detection, and tamper detection, to safeguard app integrity and user data.
![Fragment Attacks
• Since Android 4.4, fragments are blocked by
default
• Use this code to allow a whitelist of fragments:
@Override
protected boolean isValidFragment(String
fragmentName) {
String[] validFragments =
{"com.myapp.pref.frag1",
"com.myapp.pref.frag2"};
return Arrays.asList(validFragments).
contains(fragmentName);
}](https://image.slidesharecdn.com/128-ch9-190417221018/85/CNIT-128-9-Writing-Secure-Android-Applications-18-320.jpg)
![SQL Injection
• Use prepared statements, like this:
String[] userInput = new String[] {"book",
"wiley"};
Cursor c = database.rawQuery("SELECT * FROM
Products WHERE type=?
AND brand=?", userInput);](https://image.slidesharecdn.com/128-ch9-190417221018/85/CNIT-128-9-Writing-Secure-Android-Applications-24-320.jpg)
![Random()
import java.util.Random;
class Main {
public static void main(String[] args) {
// create instance of Random class
Random rand = new Random(1);
// Generate random integers in range 0 to 999
int rand_int1 = rand.nextInt(1000);
int rand_int2 = rand.nextInt(1000);
// Print random integers
System.out.println("Random Integers: "+rand_int1);
System.out.println("Random Integers: "+rand_int2);
}
}](https://image.slidesharecdn.com/128-ch9-190417221018/85/CNIT-128-9-Writing-Secure-Android-Applications-33-320.jpg)
CNIT 128 9. Writing Secure Android Applications
- 1. CNIT 128 Hacking Mobile Devices 9. Writing Secure Android Apps
- 2. Common Vulnerabilities • Code injection • Logic flaws • Insecure storage • Application configuration • Insecure communication • Logging
- 3. Topics • Principle of Least Exposure • Essential Security Mechanisms • Advanced Security Mechanisms • Slowing Down a Reverse Engineer
- 4. Principle of Least Exposure
- 5. Minimizing Attack Surface • Find all entry points • Code exposed to inputs from outside sources • Remove unnecessary entry points • Perform security checks at necessary entry points
- 6. App Components • Don't export more components than required • The safest case is shown below • Most apps require some integration with other apps
- 7. Data Storage • Avoid storing unnecessary data • Such as passwords! • Private directory is protected somewhat by the sandboxing • SD card is less protected
- 8. Untrusted Sources • Inputs from SD card, Internet, Wi-Fi, Bluetooth, etc. • Verify authenticity with signature, encryption, or some other validation • Be careful loading classes or running executables from untrusted locations • Cryptographic protections are the best
- 9. Minimal Permissions • Request the fewest permissions needed for your app • This is safer, and also avoids worrying careful users • Avoid risky permissions • INSTALL_PACKAGES • Using powerful shared users such as android.uid.system
- 10. Bundling Files in the APK • APK can contain extra files by accident • May contain SSH credentials or other secrets
- 12. Review Entry Points • Trace these functions
- 13. Permission Protection • Exported components should be limited with permissions • Only available to apps with the same signature • If you really want to offer a component for public use • Great care is required in the implementation
- 15. Task Manager Snooping • Remove your app from the recent app list • Put this code in OnCreate() to show a blank screen in the list getWindow().addFlags(WindowManager.LayoutParams .FLAG_SECURE); • Set this attribute in an activity to remove it entirely from the list intent.addFlags(Intent.FLAG_ACTIVITY_EXCLUDE_ FROM_RECENTS);
- 16. Tapjacking • Prevent touches from being sent through elements with this attribute: android:filterTouchesWhenObscured="true" • Or by using this method: view.setFilterTouchesWhenObscured(true);
- 17. Dictionary • Disable additions to the dictionary to keep passwords and other secrets out • Add this attribute to an EditText box: android:imputType="textVisiblePassword"
- 18. Fragment Attacks • Since Android 4.4, fragments are blocked by default • Use this code to allow a whitelist of fragments: @Override protected boolean isValidFragment(String fragmentName) { String[] validFragments = {"com.myapp.pref.frag1", "com.myapp.pref.frag2"}; return Arrays.asList(validFragments). contains(fragmentName); }
- 19. Secure Trust Boundaries • Make sure there's no way to open an authenticated activity from unauthenticated areas of the app • One way: implement an app-wide authentication variable
- 20. Masking Password Displays • Add this attribute to an EditText box: android:imputType="textPassword"
- 21. Browsable Activities • Can be used directly from a web browser • High-value targets for attackers • Avoid using BROWSABLE • If you use it, consider all possible intents that could cause actions in your app
- 23. Default Export Behavior • Prior to API 17, content providers were exported by default • To prevent this, put this code in the manifest: <provider android:name=".ContentProvider" android:authorities="com.myapp.ContentProvider" android:exported="false" > </provider>
- 24. SQL Injection • Use prepared statements, like this: String[] userInput = new String[] {"book", "wiley"}; Cursor c = database.rawQuery("SELECT * FROM Products WHERE type=? AND brand=?", userInput);
- 25. Directory Traversal • The getCanonicalPath() method removes .. characters and provides the absolute path to a file • The code on the next page uses this to limit paths to the /files/ subdirectory of the app's private data directory
- 27. Pattern Matching • Link Ch 9a
- 28. Securing Broadcast Receivers • Secret codes are easily enumerated using apps on the Play Store • Don't trust them
- 30. Creating Files and Folders Securely • Explicitly set permissions
- 31. Encryption • Use AES for symmetric encryption, avoid ECB • Use RSA-2048 for asymmetric encryption • Password hashing advice in textbook is wrong • You need salting and stretching; better to avoid doing it yourself
- 32. Random Numbers • Random() produces the same series of numbers each time it's run from the same seed • SecureRandom is better • Java provides methods to seed it from a source of entropy
- 33. Random() import java.util.Random; class Main { public static void main(String[] args) { // create instance of Random class Random rand = new Random(1); // Generate random integers in range 0 to 999 int rand_int1 = rand.nextInt(1000); int rand_int2 = rand.nextInt(1000); // Print random integers System.out.println("Random Integers: "+rand_int1); System.out.println("Random Integers: "+rand_int2); } }
- 34. • Link Ch 9b
- 35. Key Generation • PBKDF2 uses many rounds of hashing to derive a key from a password • Key should be stored in Android Keystore
- 36. Exposing Files • To allow specified other apps to see a file • Those apps need com.myapp.docs.READWITE permission • They can only access the /document/ folder
- 38. HTTPS • HTTP is very unsafe • HTTPS is much better, but depends on trusted Certificate Authorities (CAs) • Certificate pinning makes HTTPS even more secure • Requiring a specific certificate or CA
- 39. Local Communications • Android API is the best method • Using network sockets or the clipboard is less safe
- 41. WebView • Lets you display a Web page in an activity • Often leads to security problems • If loaded over HTTP, subject to interception and modification
- 42. • Link Ch 9c
- 43. • Link Ch 9c
- 44. • Link Ch 9c
- 45. • Link Ch 9c
- 47. Backups and Debugging • If android:allowBackup is false, an attacker can't back up files with physical access to the device • android:debuggable allows debugging • Link Ch 9d
- 48. API Version Targeting • minSdkVersion should be as large as possible • Lower values remove new security fixes • Values below 17 export content providers by default
- 49. Android 9 • Targeting SDK 28+ gives you • DNS over TLS • Network TLS by default • Cleartext traffic must be explicitly set • Separate WebView directories for each process • Can't steal cookies • Many more changes: link Ch 9e
- 50. Logging • Should be disabled in release builds • Use a centralized logging class • So it can be easily disabled • ProGuard can remove logging code
- 51. Native Code • Notoriously difficult to secure • Limit its exposure to the outside world • Enable exploit mitigations • Use latest NDK version
- 52. Exploit Mitigations • RELRO: Relocation Read-Only • Prevents GOT rewrites • RPATH / RUNPATH • Allows attacker to load modified libraries from a user-controlled path • Link Ch 9f
- 54. Protection Level Downgrade • Your app can check to make sure the protection levels are intact at each entry point
- 55. Protecting Non-Exported Components • Attacker with root permissions can interact with them • You can add a request token to prevent that • Randomly generated • Stored in a static variable in memory • Intents must have this token to run
- 56. Slowing Down a Reverse Engineer
- 57. Obfuscation • ProGuard -- free but very ineffective • DexGuard -- paid version of ProGuard • Dash-O is good but expensive ($3000) • Others compared at link Ch 9g
- 58. Root Detection • Search for su • See if default.prop allows ADB shell to run as root • See if adbd is running as root • Look for packages with names like • SuperSU or Superuser
- 59. Emulator Detection • Check for emulator build properties
- 60. Debugger Detection • Attacker may have modified your app or the environment to allow debugging
- 61. Tamper Detection • Check signature