...
| 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. | |
| 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. | |
| 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.
|
...