...
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. |
Unknown
Bibliography
| [Long 2013] | Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs |
...
| Guideline | Android app development applicable? | Original Comments | TC Comments | Responses to TC comments |
|---|---|---|---|---|
| OBJ03-J. Do not mix generic with nongeneric raw types in new code | [Applicable] | I couldn't find a page with this title. This page has the same number: OBJ03-J. Prevent heap pollution. Do you want me to link to this page? | Per this copy of the Java standard book, the body of the previously-named OBJ03-J looks like the current DCL61-J. Do not use raw types . This points to a problem: When the rule/rec belonging to a different standard is changed, its applicability to Android might also change. It would be very helpful to have an automated notification system, which would quickly provide a list of rules/recs which need re-review for applicability. Perhaps it would be useful to provide this info to readers as well, so they would know if the rule/rec has changed since the last analysis of applicability (and it would be good if they could easily check what was changed in the rule/rec since the last analysis of applicability). Another important point you bring up: For totally new rules, (for example the new DCL61-J), which we haven't yet reviewed for applicability, those needs entries in lists/tables of Android applicability. An automated solution for identifying rules/recs which have not been analyzed for applicability would be quite helpful here, since any human-process-only solution is much more fallible. | |
| 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. | Please leave deleted. | |
| FIO11-J. Do not attempt to read raw binary data as character data | [Applicable] | The link on the left does not work. Do you want to link to this page? STR03-J. Do not convert between strings and bytes without specifying a valid character encoding | Yes, please link instead to STR03-J. FIO11-J is another rule that used to exist and was published in the book form of the CERT Oracle Java secure coding standard. Is there some way to track historical development of rules? If not a current capability, we need that. If rules in programming language standards just get changed without tracking, that poses a big problem for the Android standard development and maintenance. | |
| OBJ56-J. Provide sensitive mutable classes with unmodifiable wrappers | Unknown | ? | How should this be categorized? | Not yet determined if applicable or not |
| SEC57-J. Do not let untrusted code misuse privileges of callback methods | Unknown | How should this be categorized? | Not yet determined if applicable or not | |
| 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? | Another one that used to exist (see https://books.google.com/books?id=FDun60sHwUgC&pg=PA24&dq=%22IDS00-J.+Sanitize+untrusted+data+passed+across+a+trust+boundary%22&hl=en&sa=X&ei=cys5VdK6H_WOsQTQvYDoBg&ved=0CCgQ6AEwAQ ), so same issues discussed above apply. This advice applies: https://www.securecoding.cert.org/confluence/display/java/Input+Validation+and+Data+Sanitization I did a quick wiki search on the previous rule title text, and found a lot of potential Java rules which inherited from the old rule. Some I checked out, and we already have analyzed those for applicability above. The others I don't have time to look at today.
|
...