...
Guideline | Comments |
|---|---|
| MSC59-J. Limit the lifetime of sensitive data | 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 (?) |
| SEC55-J. Ensure security-sensitive methods are called with validated arguments | On Android, accessControlContext is not available. |
| IDS56-J. Prevent arbitrary file upload | |
| IDS51-J. Properly encode or escape output | |
| IDS52-J. Prevent code injection | ScriptEngineManager is not included in the Android SDK. |
| IDS54-J. Prevent LDAP injection | Applicable in principle for android apps that tries to implement its own LDAP |
| SEC50-J. Avoid granting excess privileges | 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 | 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 | 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. |
| FIO51-J. Identify files using multiple file attributes | On Android, better to use openFileOutput/openFileInput for file I/O. |
| MSC60-J. Do not use assertions to verify the absence of runtime errors | On Android, assert() is ignored by default. |
| FIO50-J. Do not make assumptions about file creation | On Android, java.nio.file is not available. |
...
Bibliography
| [Long 2013] | Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs |
Issues
There are issues with the entries in this table. See the comments column.
| Guideline | Android app development applicable? | Original Comments | TC Comments | |
|---|---|---|---|---|
| OBJ03-J. Do not mix generic with nongeneric raw types in new code | [Applicable] | Could not find a page with this title. Should it go to this page, which has the same number? OBJ03-J. Prevent heap pollution | ||
| 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.> Do you want to link to this page? STR03-J. Do not convert between strings and bytes without specifying a valid character encoding | ||
| OBJ56-J. Provide sensitive mutable classes with unmodifiable wrappers | Unknown | ? | How should this be categorized? | |
| SEC57-J. Do not let untrusted code misuse privileges of callback methods | Unknown | How should this be categorized? | ||
| IDS00-J. Sanitize untrusted data passed across a trust boundary | 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. | Which page should this entry link to? |
Bibliography
...
CERT Oracle Coding Standard for Java