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
Java Rules/Unknown Applicability to Android
| Guideline | Comments |
|---|---|
Java Recommendations/Unknown Applicability to Android
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 | 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. | |
| 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.
|
