CNIT 128 9. Writing Secure Android Applications
0 likes138 views
This document discusses various techniques for writing secure Android apps, including minimizing the app's attack surface, securing activities, content providers, and communications. It covers essential security mechanisms like permission protection and fragment attacks. Advanced techniques include protection level downgrade checking, adding request tokens to non-exported components, and ways to slow down reverse engineering like obfuscation, root detection, emulator detection, and tamper detection.
![Fragment Attacks
• Fragments are small UI elements that customize activities
• But fragment injection vulnerabilities were found
• 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-210414175451/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-210414175451/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-210414175451/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 Updated 4-14-2021
- 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 • To avoid exposing private information on that image • Put this code in OnCreate() to show a blank screen in the list getWindow().addFlags(WindowManager.LayoutParams.FLAG_SE CURE) ; • 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:inputType="textVisiblePassword"
- 18. Fragment Attacks • Fragments are small UI elements that customize activities • But fragment injection vulnerabilities were found • 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:inputType="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 • Pattern- matching checks may fail for variations of the path • 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. • replit.com • Every run produces the same numbers Online Java Tester
- 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 • Transferring data from one app to another • Android API is the best method • Activities with intent-filters • In more recent Android versions • ChooserTargets, Shortcuts, direct share targets • 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 • More recommendations at • https://www.checkmarx.com/blog/android- webview-secure-coding-practices/
- 43. 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
- 44. API Version Targeting • minSdkVersion should be as large as possible • Lower values remove new security fixes • Values below 17 export content providers by default
- 45. 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
- 47. Logging • Should be disabled in release builds • Use a centralized logging class • So it can be easily disabled • ProGuard can remove logging code
- 48. Native Code • Notoriously difficult to secure • Limit its exposure to the outside world • Enable exploit mitigations • Use latest NDK version
- 49. 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
- 51. Protection Level Downgrade • A malicious app can define a permission first with an insecure protection level • So your app inherits that level • Your app can check to make sure the protection levels are intact at each entry point
- 52. 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
- 53. Slowing Down a Reverse Engineer
- 54. Obfuscation • ProGuard -- free but very ineffective • DexGuard -- paid version of ProGuard • Dash-O is good but expensive ($3000) • Arxan is another
- 55. 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
- 56. Emulator Detection • Check for emulator build properties
- 57. Debugger Detection • Attacker may have modified your app or the environment to allow debugging
- 58. Tamper Detection • Check signature