Skip to end of metadata
Go to start of metadata

The top two tables list the Java rules and Java recommendations that are Applicable in principle, meaning that it can be applied to Android but the examples shown in the guideline are not relevant to Android, and in some cases the guideline's full description also needs edits (the latter are provided in the Comments column). The third table lists Unknown rules and recommendations, meaning that we have not yet determined if the guideline can be applied to Android platforms.

Contents

Rules/Applicable in Principle to Android

Rule

Comments

IDS00-J. Sanitize untrusted data passed across a trust boundaryThe 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 themAndroid apps can receive string data from the outside and normalize it.
IDS02-J. Canonicalize path names before validating themThe 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 ZipInputStreamAlthough 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() methodRuntime.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 localeA developer can specify locale on Android using java.util.Locale.
EXP01-J. Never dereference null pointersAndroid 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 assertionsThe 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

Mezzofanti for Android contained an integer overflow which prevented the use of a big SD card. Mezzofanti contained an expression:

(int) StatFs.getAvailableBlocks() * (int) StatFs.getBlockSize()  

to calculate the available memory in a SD card, which could result in a negative value when the available memory is bigger than Integer.MAX_VALUE.

Note these methods are deprecated in API level 18 and replaced by getAvailableBlocksLong() and getBlockSizeLong().

NUM04-J. Do not use floating-point numbers if precise computation is requiredThe 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 
NUM11-J. Do not compare or inspect the string representation of floating-point valuesComparing or inspecting the string representation of floating-point values may have unexpected results on Android.
MET01-J. Never use assertions to validate method argumentsThe 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 methodsThe 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 finalOn 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 JVMOn 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 
LCK05-J. Synchronize access to static fields that can be modified by untrusted code 
LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy 
THI00-J. Do not invoke Thread.run()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 
THI03-J. Always invoke wait() and await() methods inside a loop 
THI04-J. Ensure that threads performing blocking operations can be terminated 
THI05-J. Do not use Thread.stop() to terminate threadsOn Android, Thread.stop() was deprecated in API level 1.
TPS00-J. Use thread pools to enable graceful degradation of service during traffic bursts 
TPS01-J. Do not execute interdependent tasks in a bounded thread pool 
TPS02-J. Ensure that tasks submitted to a thread pool are interruptible 
TPS03-J. Ensure that tasks executing in a thread pool do not fail silently 
TPS04-J. Ensure ThreadLocal variables are reinitialized when using thread pools 
TSM00-J. Do not override thread-safe methods with methods that are not thread-safe 
TSM01-J. Do not let the this reference escape during object construction 
TSM02-J. Do not use background threads during class initialization 
FIO00-J. Do not operate on files in shared directoriesOn 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 permissionsCreating files with weak permissions may allow malicious applications to access the files.
FIO04-J. Release resources when they are no longer neededThe 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 
FIO13-J. Do not log sensitive information outside a trust boundaryDRD04-J. Do not log sensitive information is an Android specific instance of this rule.
FIO14-J. Perform proper cleanup at program terminationAlthough 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 
SEC01-J. Do not allow tainted variables in privileged blocksThe code examples using the java.security package are not applicable to Android but the principle of the rule is applicable to Android apps.
SEC02-J. Do not base security checks on untrusted sourcesThe 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 arbitrary classesOn Android, the use of DexClassLoader or PathClassLoader requires caution.
SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fieldsReflection 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.
JNI 03-J. Do not use direct pointers to Java objects in JNI code Applicable to API versions 14 and above, with NDK versions 7 and above.
ENV02-J. Do not trust the values of environment variablesOn 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 verificationUnder 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 informationHard 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/Applicable in Principle to Android

Guideline

Comments

MSC59-J. Limit the lifetime of sensitive dataThe 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 (?)
SEC55-J. Ensure security-sensitive methods are called with validated argumentsOn Android, accessControlContext is not available.
IDS56-J. Prevent arbitrary file upload 
IDS51-J. Properly encode or escape output 
IDS52-J. Prevent code injectionScriptEngineManager is not included in the Android SDK.
IDS54-J. Prevent LDAP injectionApplicable in principle for android apps that tries to implement its own LDAP
SEC50-J. Avoid granting excess privilegesThe 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 codeThe 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 securityThe 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.
FIO51-J. Identify files using multiple file attributesOn Android, better to use openFileOutput/openFileInput for file I/O.
MSC60-J. Do not use assertions to verify the absence of runtime errorsOn Android, assert() is ignored by default.
FIO50-J. Do not make assumptions about file creationOn Android, java.nio.file is not available.

 

Bibliography

[Long 2013]Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs

 

 

 

 

 

3 Comments

  1. I believe some "Not applicable"s should be changed.

     

    16. Avoid granting excess privileges | Not applicable | Android does not use AccessController.

    I think this is very much applicable. If possible application should use as few "<uses-permissions>" in AndroidManifest.xml as possible, it should also avoid signature/system/dangerous permissions, and having shared system UID.

     

    17. Minimize privileged code | Not applicable | Android does not use AccessController.

    Minimize the code running as system/root/privileged user. Either in services or in shared UID applications or just normal applications with interesting privileges.

     

    19. Define custom security permissions for fine-grained security | Not applicable

    Applications are able to define their own permissions to restrict access to ie. other applications signed with the same key.

     

  2. I agree with your recommendation to change the "Not applicable"s for Guidelines #16, 17, and 19. This concomitantly required changing our definition of Applicable in principle at the top of this page, since this requires edits beyond the guidelines’ examples (compliant and noncompliant) - edits are needed to the guideline full description. The previous definition of Applicable in principle said only the examples needed edits. The brief phrases (for example, Avoid granting excess privileges) applies to Android, as you describe. However, the paragraphs of text which explain guidelines #16, 17, and 19 (published in the hardcopy book) specify non-Android platform details throughout and don’t mention Android.

    I added to the guideline comments by incorporating most of what you wrote. For your #17 suggestion, I’m not sure what you mean by minimizing “in services”. (What about Activities, etc.?)

    Thank you for your recommendations! I welcome any additional review comments.

  3. Sorry for the confusion (hey, there's at least 3 types of services on Android (tongue)). By services I meant the non-android native services, ie. netd, rild. Those usually run as root or system.