...
| Rule | Applicable to Android Application Development? | Comments | ||||
|---|---|---|---|---|---|---|
| IDS00-J. Sanitize untrusted data passed across a trust boundary | Applicable in principle | The rule uses MS SQL Server as an example to show a database connection. However, on Android, DatabaseHelper from SQLite is used for a database connection. Because Android apps may receive untrusted data via network connections, the rule is applicable. | ||||
| IDS01-J. Normalize strings before validating them | Applicable in principle | Android apps can receive string data from the outside and normalize it. | ||||
| IDS02-J. Canonicalize path names before validating them | Applicable in principle | The rule is applicable in principle. Please refer to the Android specific instance of this rule: DRD08-J. Always canonicalize a URL received by a content provider. | ||||
| IDS04-J. Safely extract files from ZipInputStream | Applicable in principle | Although not directly a violation of this rule, the Android Master Key vulnerability (insecure use of ZipEntry) is related to this rule. Another attack vector found by a Chinese researcher is also related to this rule. | ||||
| IDS07-J. Do not pass untrusted, unsanitized data to the Runtime.exec() method | Applicable in principle | Runtime.exec() can be called from Android apps to execute operating system commands. | ||||
| IDS09-J. Do not use locale-dependent methods on locale-dependent data without specifying the appropriate locale | Applicable in principle | A developer can specify locale on Android using java.util.Locale. | ||||
| EXP01-J. Never dereference null pointers | Applicable in principle | Android applications are more sensitive to NullPointerException due to the constraint of the limited mobile device memory. Static members or members of an Activity may become null when memory runs out. | ||||
| EXP06-J. Do not use side-effecting expressions in assertions | Applicable in principle | The assert statement is supported on the Dalvik VM but is ignored under the default configuration. Assertions may be enabled by setting the system property "debug.assert" via: adb shell setprop debug.assert 1 or by sending the command line argument "--enable-assert" to the Dalvik VM. | ||||
| NUM00-J. Detect or prevent integer overflow | Applicable in principle | Mezzofanti for Android contained an integer overflow which prevented the use of a big SD card. Mezzofanti contained an expression:
to calculate the available memory in a SD card, which could result in a negative value when the available memory is bigger than Note these methods are deprecated in API level 18 and replaced by | ||||
| NUM04-J. Do not use floating-point numbers if precise computation is required | Applicable in principle | The use of floating-point is not recommended for performance reasons on Android. | ||||
| NUM06-J. Use the strictfp modifier for floating-point calculation consistency across platforms | Applicable in principle | |||||
| NUM11-J. Do not compare or inspect the string representation of floating-point values | Applicable in principle | Comparing or inspecting the string representation of floating-point values may have unexpected results on Android. | ||||
| OBJ03-J. Do not mix generic with nongeneric raw types in new code | [Applicable] | <Could not find a page with this title.> | ||||
| MET01-J. Never use assertions to validate method arguments | Applicable in principle | The assert statement is supported on the Dalvik VM but is ignored under the default configuration. Assertions may be enabled by setting the system property "debug.assert" via: adb shell setprop debug.assert 1 or by sending the command line argument "--enable-assert" to the Dalvik VM. | ||||
| MET02-J. Do not use deprecated or obsolete classes or methods | Applicable in principle | The Android SDK also has deprecated or obsolete APIs. Also, there may exist incompatible APIs depending on the SDK version. Therefore, it is recommended that developers refer to the "Android API Difference report" and consider replacing the deprecated APIs. | ||||
| MET03-J. Methods that perform a security check must be declared private or final | Applicable in principle | On Android, System.getSecurityManager() is not used and the use of a Security Manager is not exercised. However, an Android developer can implement security-sensitive methods so the principle may be applicable on Android. | ||||
| ERR09-J. Do not allow untrusted code to terminate the JVM | Applicable in principle | On Android, System.exit() should not be used because it will terminate the virtual machine abruptly, ignoring the activity lifecycle which may prevent proper garbage collection. | ||||
| LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code | Applicable in principle | |||||
| LCK05-J. Synchronize access to static fields that can be modified by untrusted code | Applicable in principle | |||||
| LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy | Applicable in principle | |||||
| THI00-J. Do not invoke Thread.run() | Applicable in principle | Android provides a couple of solutions for threading. The Android Developers Blog's article "Painless threading" discusses those solutions. | ||||
| THI02-J. Notify all waiting threads rather than a single thread | Applicable in principle | |||||
| THI03-J. Always invoke wait() and await() methods inside a loop | Applicable in principle | |||||
| THI04-J. Ensure that threads performing blocking operations can be terminated | Applicable in principle | |||||
| THI05-J. Do not use Thread.stop() to terminate threads | Applicable in principle | On Android, Thread.stop() was deprecated in API level 1. | ||||
| TPS00-J. Use thread pools to enable graceful degradation of service during traffic bursts | Applicable in principle | |||||
| TPS01-J. Do not execute interdependent tasks in a bounded thread pool | Applicable in principle | |||||
| TPS02-J. Ensure that tasks submitted to a thread pool are interruptible | Applicable in principle | |||||
| TPS03-J. Ensure that tasks executing in a thread pool do not fail silently | Applicable in principle | |||||
| TPS04-J. Ensure ThreadLocal variables are reinitialized when using thread pools | Applicable in principle | |||||
| TSM00-J. Do not override thread-safe methods with methods that are not thread-safe | Applicable in principle | |||||
| TSM01-J. Do not let the this reference escape during object construction | Applicable in principle | |||||
| TSM02-J. Do not use background threads during class initialization | Applicable in principle | |||||
| FIO00-J. Do not operate on files in shared directories | Applicable in principle | On Android, the SD card ( /sdcard or /mnt/sdcard ) is shared among multiple applications, thus sensitive files should not be stored on the SD card. | ||||
| FIO01-J. Create files with appropriate access permissions | Applicable in principle | Creating files with weak permissions may allow malicious applications to access the files. | ||||
| FIO04-J. Release resources when they are no longer needed | Applicable in principle | The compliant solution (Java SE 7: try-with-resources) is not yet supported at API level 18 (Android 4.3). | ||||
| FIO06-J. Do not create multiple buffered wrappers on a single InputStream | Applicable in principle | |||||
| FIO08-J. Use an int to capture the return value of methods that read a character or byte | [Applicable] | <This page was deleted. We can ask for it to be undeleted. Please advise.> | ||||
| FIO11-J. Do not attempt to read raw binary data as character data | [Applicable] | <The link on the left does not work. Please advise.> | ||||
| FIO13-J. Do not log sensitive information outside a trust boundary | Applicable in principle | DRD04-J. Do not log sensitive information is an Android specific instance of this rule. | ||||
| FIO14-J. Perform proper cleanup at program termination | Applicable in principle | Although most of the code examples are not applicable to the Android platform, the principle is applicable to Android. There are a number of ways to terminate a process on Android: android.app.Activity.finish(), and the related finish... methods, android.app.Activity.moveTaskToBack(boolean flag), android.os.Process.killProcess(int pid), System.exit(). | ||||
| FIO15-J. Do not operate on untrusted file links | Applicable in principle | |||||
| SER04SEC01-J. Do not allow serialization and deserialization to bypass the security manager | Not applicable | tainted variables in privileged blocks | Applicable in principle | The code examples using the The java.security package exists on Android for compatibility purposes only and it should not be used.are not applicable to Android but the principle of the rule is applicable to Android apps. | ||
| SEC02SEC00-J. Do not allow privileged blocks to leak sensitive information across a trust boundary | Not applicable | The java.security package exists on Android for compatibility purposes only and it should not be used. | base security checks on untrusted sources | SEC01-J. Do not allow tainted variables in privileged blocks | Applicable in principle | The code examples using the java.security package are not applicable to Android but the principle of the rule is applicable to Android apps. |
| SEC02SEC03-J. Do not base security checks on untrusted sources | Applicable in principle | The code examples using the java.security package are not applicable to Android but the principle of the rule is applicable to Android apps. | SEC03-J. Do not load trusted classes after allowing untrusted code to load load trusted classes after allowing untrusted code to load arbitrary classes | Applicable in principle | On Android, the use of DexClassLoader or PathClassLoader requires caution. | |
| SEC04-J. Protect sensitive operations with security manager checks | Not applicable | The java.security package exists on Android for compatibility purposes only and it should not be used. | ||||
| SEC05-J. Do not use reflection to increase accessibility SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields | Applicable in principle | Reflection can be used on Android so the rule is applicable. Also the use of reflection may allow a developer to access private Android APIs and so requires caution. | ||||
| SEC06 JNI03-J. Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar | Not applicable | |||||
| SEC07-J. Call the superclass's getPermissions() method when writing a custom class loader | Not applicable | The java.security package exists on Android for compatibility purposes only and it should not be used. | ||||
| JNI03-J. Do not use direct pointers to Java objects in JNI code | Applicable in principle | Applicable to API versions 14 and above, with NDK versions 7 and above. | ||||
| ENV00-J. Do not sign code that performs only unprivileged operations | Not applicable | The Android system uses code signing as a means of identifying the author of an application and establishing trust relationships between applications, not as a means of granting elevated privileges to code. | ||||
| ENV01-J. Place all security-sensitive code in a single JAR and sign and seal it | Not applicable | java.security.AccessController exists on Android for compatibility purposes only and it should not be used. | ||||
| ENV02-J. Do not trust the values of environment variables | Applicable in principle | On Android, the environment variable user.name is not used and is left blank. However, environment variables exist and are used on Android so the rule is applicable. | ||||
| ENV03-J. Do not grant dangerous combinations of permissions | Not applicable | The java.security package exists on Android for compatibility purposes only and it should not be used. Android uses another permission mechanism for security purposes. | ||||
| ENV04-J. Do not disable bytecode verification | Applicable in principle | Under the default settings, bytecode verification is enabled on the Dalvik VM. To change the settings use the adb shell to set the appropriate system property, for example: adb shell setprop dalvik.vm.dexopt-flags v=a or pass -Xverify:all as an argument to the Dalvik VM. | ||||
| ENV05-J. Do not deploy an application that can be remotely monitored | Not applicable | JVMTI is not supported on the Dalvik VM. | ||||
| MSC03-J. Never hard code sensitive information | Applicable in principle | Hard coded information can be easily obtained on Android by using the apktool to decompile an application or by using dex2jar to convert a dex file to a jar file. |
Recommendations
| use direct pointers to Java objects in JNI code | Applicable in principle | Applicable to API versions 14 and above, with NDK versions 7 and above. |
| ENV02-J. Do not trust the values of environment variables | Applicable in principle | On Android, the environment variable user.name is not used and is left blank. However, environment variables exist and are used on Android so the rule is applicable. |
| ENV04-J. Do not disable bytecode verification | Applicable in principle | Under the default settings, bytecode verification is enabled on the Dalvik VM. To change the settings use the adb shell to set the appropriate system property, for example: adb shell setprop dalvik.vm.dexopt-flags v=a or pass -Xverify:all as an argument to the Dalvik VM. |
| MSC03-J. Never hard code sensitive information | Applicable in principle | Hard coded information can be easily obtained on Android by using the apktool to decompile an application or by using dex2jar to convert a dex file to a jar file. |
Recommendations
Guideline | Applicable to Android Application Development? | Comments | |||
| MSC59-J. Limit the lifetime of sensitive data | Applicable in principle | The non-compliant code example is probably not problematic on Dalvik because each app has its own Dalvik VM and string objects would not be accessible from other apps (?) | |||
| OBJ56-J. Provide sensitive mutable classes with unmodifiable wrappers | Unknown | ? | |||
| SEC55-J. Ensure security-sensitive methods are called with validated arguments | Applicable in principle | On Android, accessControlContext is not available. | |||
| IDS56-J. Prevent arbitrary file upload | Applicable in principle | ||||
| IDS51-J. Properly encode or escape output | Applicable in principle | ||||
| IDS52-J. Prevent code injection | Applicable in principle | ScriptEngineManager is not included in the Android SDK. | |||
| IDS54-J. Prevent LDAP injection | Applicable in principle | Applicable in principle for android apps that tries to implement its own LDAP | |||
| SEC50-J. Avoid granting excess privileges | Applicable in principle | The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android, because Android does not use AccessController. The following text supplements that section, to make it applicable to Android.: An application should use as few "<uses-permission>"s in AndroidManifest.xml as possible. App developers should also avoid signature/system/dangerous permissions, and having a shared system UID. System API calls are code running as system, and apps which make system API calls require standard permissions the app must specify in the application manifest with "<uses-permission>". http://developer.android.com/guide/topics/manifest/uses-permission-element.html | |||
| SEC51-J. Minimize privileged code | Applicable in principle | The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android, because Android does not use AccessController. The following text supplements that section, to make it applicable to Android.: Minimize the code running as system, with permissions defined in another app’s manifest, or in shared user ID applications. System API calls are code running as system, and apps which make system API calls require standard permissions the app must specify in the application manifest with "<uses-permission>". Only applications which are signed with the same signature and also request the same sharedUserID are granted a shared user ID. Data/files stored by apps which share a user ID are accessible to all those apps.http://developer.android.com/guide/topics/security/permissions.html http://developer.android.com/guide/topics/manifest/uses-permission-element.html | |||
| SEC53-J. Define custom security permissions for fine-grained security | Applicable | ||||
Guideline | Applicable to Android Application Development? | Comments | |||
| MSC59-J. Limit the lifetime of sensitive data | Applicable in principle | The non-compliant code example is probably not problematic on Dalvik because each app has its own Dalvik VM and string objects would not be accessible from other apps (?) | |||
| FIO52-J. Do not store unencrypted sensitive information on the client side | Applicable | ||||
| OBJ56-J. Provide sensitive mutable classes with unmodifiable wrappers | Unknown | ? | |||
| SEC55-J. Ensure security-sensitive methods are called with validated arguments | Applicable in principle | On Android, accessControlContext is not available. | |||
| IDS56-J. Prevent arbitrary file upload | Applicable in principle | ||||
| IDS51-J. Properly encode or escape output | Applicable in principle | ||||
| IDS52-J. Prevent code injection | Applicable in principle | ScriptEngineManager is not included in the Android SDK. | |||
| IDS53-J. Prevent XPath Injection | Applicable | ||||
| IDS54-J. Prevent LDAP injection | Applicable in principle | Applicable in principle for android apps that tries to implement its own LDAP | |||
| MET52-J. Do not use the clone method to copy untrusted method parameters | Applicable | ||||
MET56-J. Do not use Object.equals() to compare cryptographic keys | Applicable | ||||
| MSC61-J. Do not use insecure or weak cryptographic algorithms | Applicable | ||||
| MSC62-J. Store passwords using a hash function | Applicable | ||||
MSC63-J. Ensure SecureRandom is properly seeded | Applicable | ||||
| OBJ57-J. Do not rely on overridden methods provided by untrusted code | Applicable | ||||
| SEC50-J. Avoid granting excess privileges | Applicable in principle | The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android, because Android does not use AccessController. The following text supplements that section, to make it applicable to Android.: An application should use as few "<uses-permission>"s in AndroidManifest.xml as possible. App developers should also avoid signature/system/dangerous permissions, and having a shared system UID. System API calls are code running as system, and apps which make system API calls require standard permissions the app must specify in the application manifest with "<uses-permission>". http://developer.android.com/guide/topics/manifest/uses-permission-element.html | |||
| SEC51-J. Minimize privileged code | Applicable in principle | The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android, because Android does not use AccessController. The following text supplements that section, to make it applicable to Android.: Minimize the code running as system, with permissions defined in another app’s manifest, or in shared user ID applications. System API calls are code running as system, and apps which make system API calls require standard permissions the app must specify in the application manifest with "<uses-permission>". Only applications which are signed with the same signature and also request the same sharedUserID are granted a shared user ID. Data/files stored by apps which share a user ID are accessible to all those apps.http://developer.android.com/guide/topics/security/permissions.html http://developer.android.com/guide/topics/manifest/uses-permission-element.html | |||
| SEC52-J. Do not expose methods that use reduced-security checks to untrusted code | Not applicable | ||||
| SEC53-J. Define custom security permissions for fine-grained security | Applicable in principle | The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android. The following text supplements that section, to make it applicable to Android.: Applications are able to define their own new permissions, to restrict access to their components by other applications. Applications indicate the procedure the system should follow when determining whether to grant another app the permission, depending on protectionLevel – e.g., setting protectionLevel to “signature” so it is automatically granted to other applications requesting the permission which are signed with the same key. In addition to defining their own new permissions, applications can declare the requirement for (self-defined, other-app-defined, or system-defined) permissions, to restrict access to their components by other applications. | |||
| SEC54-J. Create a secure sandbox using a security manager | Not applicable | ||||
| SEC57-J. Do not let untrusted code misuse privileges of callback methods | Unknown | ||||
| DCL53-J. Minimize the scope of variables | Applicable | ||||
MSC50-J. Minimize the scope of the @SuppressWarnings annotation | Applicable | ||||
| OBJ51-J. Minimize the accessibility of classes and their members | Applicable | ||||
| CON52-J. Document thread-safety and use annotations where applicable | Applicable | ||||
| MET54-J. Always provide feedback about the resulting value of a method | Applicable | ||||
| FIO51-J. Identify files using multiple file attributes | Applicable in principle | On Android, better to use openFileOutput/openFileInput for file I/O. | |||
| DCL56-J. Do not attach significance to the ordinal associated with an enum | Applicable | ||||
| NUM52-J. Be aware of numeric promotion behavior | Applicable | ||||
| DCL58-J. Enable compile-time type checking of variable arity parameter types | Applicable | ||||
| DCL59-J. Do not apply public final to constants whose value might change in later releases | Applicable | ||||
| DCL60-J. Avoid cyclic dependencies between packages | Applicable | ||||
| ERR51-J. Prefer user-defined exceptions over more general exception types | Applicable | ||||
| ERR53-J. Try to gracefully recover from system errors | Applicable | ||||
| MSC53-J. Carefully design interfaces before releasing them | Applicable | ||||
| OBJ52-J. Write garbage-collection-friendly code | Applicable | ||||
| DCL51-J. Do not shadow or obscure identifiers in subscopes | Applicable | ||||
| DCL52-J. Do not declare more than one variable per declaration | Applicable | ||||
| DCL54-J. Use meaningful symbolic constants to represent literal values in program logic | Applicable | ||||
| DCL55-J. Properly encode relationships in constant definitions | Applicable | ||||
| MET55-J. Return an empty array or collection instead of a null value for methods that return an array or collection | Applicable | ||||
| ERR50-J. Use exceptions only for exceptional conditions | Applicable | ||||
ERR54-J. Use a try-with-resources statement to safely handle closeable resources | Not applicable | The current Android SDK does not support Java7, thus try-with-resource is not available | |||
| MSC60-J. Do not use assertions to verify the absence of runtime errors | Applicable in principle | On Android, assert() is ignored by default. | |||
| EXP55-J. Use the same type for the second and third operands in conditional expressions | Applicable | ||||
| SEC56-J. Do not serialize direct handles to system resources | Applicable | ||||
| MSC58-J. Prefer using iterators over enumerations | Applicable | ||||
| OBJ53-J. Do not use direct buffers for short-lived, infrequently used objects | Applicable | ||||
| OBJ55-J. Remove short-lived objects from long-lived container objects | Applicable | ||||
| DCL50-J. Be careful using visually misleading identifiers and literals | Applicable | ||||
| DCL57-J. Avoid ambiguous overloading of variable arity methods | Applicable | ||||
| ERR52-J. Avoid in-band error indicators | Applicable | ||||
| EXP51-J. Do not perform assignments in conditional expressions | Applicable | ||||
| EXP52-J. Use braces for the body of an if, for, or while statement | Applicable | ||||
| MSC51-J. Do not place a semicolon immediately following an if, for, or while condition | Applicable | ||||
| MSC52-J. Finish every set of statements associated with a case label with a break statement | Applicable | ||||
| MSC54-J. Avoid inadvertent wrapping of loop counters | Applicable | ||||
| EXP53-J. Use parentheses for precedence of operation | Applicable | ||||
| FIO50-J. Do not make assumptions about file creation | Applicable in principle | On Android, java.nio.file is not available. | |||
| NUM50-J. Convert integers to floating-point for floating-point operations | Applicable | ||||
MET53-J. Ensure that the clone() method calls super.clone() | Applicable | ||||
| MSC55-J. Use comments consistently and in a readable fashion | Applicable | ||||
| MSC56-J. Detect and remove superfluous code and values | Applicable | ||||
| MSC57-J. Strive for logical completeness | Applicable | ||||
| CON50-J. Do not assume that declaring a reference volatile guarantees safe publication of the members of the referenced object | Applicable | ||||
CON51-J. Do not assume that the sleep(), yield(), or getState() methods provide synchronization semantics | Applicable | ||||
| NUM51-J. Do not assume that the remainder operator always returns a nonnegative result for integral operands | Applicable | ||||
| EXP50-J. Do not confuse abstract object equality with reference equality | Applicable | ||||
| EXP54-J. Understand the differences between bitwise and logical operators | Applicable | ||||
| IDS55-J. Understand how escape characters are interpreted when strings are loaded | Applicable | ||||
| MET50-J. Avoid ambiguous or confusing uses of overloading | Applicable | ||||
| MET51-J. Do not use overloaded methods to differentiate between runtime types | Applicable | ||||
| OBJ50-J. Never confuse the immutability of a reference with that of the referenced object | Applicable | ||||
FIO53-J. Use the serialization methods writeUnshared() and readUnshared() with care | Applicable | ||||
Applications are able to define their own new permissions, to restrict access to their components by other applications. Applications indicate the procedure the system should follow when determining whether to grant another app the permission, depending on protectionLevel – e.g., setting protectionLevel to “signature” so it is automatically granted to other applications requesting the permission which are signed with the same key. In addition to defining their own new permissions, applications can declare the requirement for (self-defined, other-app-defined, or system-defined) permissions, to restrict access to their components by other applications. | |||||
| SEC57-J. Do not let untrusted code misuse privileges of callback methods | Unknown | ||||
| FIO51-J. Identify files using multiple file attributes | Applicable in principle | On Android, better to use openFileOutput/openFileInput for file I/O. | |||
ERR54-J. Use a try-with-resources statement to safely handle closeable resources | Not applicable | The current Android SDK does not support Java7, thus try-with-resource is not available | |||
| MSC60-J. Do not use assertions to verify the absence of runtime errors | Applicable in principle | On Android, assert() is ignored by default. | |||
| FIO50-J. Do not make assumptions about file creation | Applicable in principle | On Android, java.nio.file is not available. | OBJ54-J. Do not attempt to help the garbage collector by setting local reference variables to null | Applicable |
Bibliography
| [Long 2013] | Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs |
...