BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Secure Coding for the Android Platform

Secure Coding for the Android Platform

This item in japanese

The CERT Secure Coding team, part of the Software Engineering Institute at Carnegie Mellon University, have recently released secure coding guidelines specific to Java's application in the Android platform.

The Android guidelines follow and extend previous work done at CERT, which led to the publication of CERT Secure Coding Standard for Java in 2013 and gave birth later to a Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs book. Thus, the new Android coding rules and guidelines are partially a mapping of the existing Java rules and guidelines to the Android platform, although they also include new Android-only rules which addresses mobile-specific concerns.

According to Lori Flynn, one the researchers who authored CERT Android coding rules and guidelines, "Android secure coding advice also exists elsewhere, but we found it in incomplete sets and in disparate locations across the web." CERT researchers used three main techniques to develop the new Android coding rules and guidelines:

  • Mining already existing CERT secure coding standards;
  • Mining vulnerability databases, including the Department of Homeland Security’s National Vulnerability Database;
  • Mining current literature on security, e.g., research papers, online articles, and security conference presentations.

All rules and guidelines are publicly available on CERT wiki. Each begins with a summary and an explanation of security issues it addresses and also includes an example of non-conforming code. The wiki also provides a score encasing the severity and likelihood of exploitation for any vulnerability as well as an analysis of the cost of remediation if a violation is found in the code.

InfoQ reached out to Lori Flynn to ask her about CERT Android secure coding rules and guidelines. Lori's ongoing work at CERT goes beyond the development of new secure coding rules and includes composable static analysis of apps to check for compliance with data flow rules on Android platforms. Past experience includes network security research, standards-based security analyses, and collaboration on a novel static analysis method for polymorphic program detection that resulted in a patent. Flynn earned her PhD in computer science from the University of California at Santa Cruz, where her research focused on secure multicast routing protocols for ad hoc mobile networks.

Lori, could you please briefly describe who are the intended recipients of the Android secure coding rules and guidelines?

The secure coding rules and guidelines for Android that we have developed so far are primarily intended for developers of Java language Android apps. However, we have also begun to develop secure coding rules and guidelines for apps coded in native (non-Java) languages such as C and C++. Our primary intention is to help programmers to build reliable and secure systems, but the rules and guidelines are also helpful for achieving other quality attributes, such as reliability.

All organizations and individual developers who want to protect their customers’ systems from compromise benefit from their programmers applying rules and guidelines to produce secure code. Financial, health, and defense systems all must be careful to secure the information their apps handle. Many apps handle sensitive data —for example, users’ credit card information, locations, texts, contacts, and photos. In addition to potential harm to users, insecure code might put the developer at financial risk from lawsuits, might cause loss of confidence by the public (and loss of sales) for a whole company, or might result in embarrassment and lack of sales for a single app that is publicly shown to be insecure.

Consequently, awareness of the secure coding rules and guidelines for Android is helpful for large organizations as well as independent single app creators. Software development managers, software acquirers, or other software development and acquisition specialists can use these secure coding standards as a set of proscriptive requirements. Educators can use them, as well, to help students to develop secure coding methods for Android apps.

What do you envision as the main challenge that mobile stakeholders face when it comes to app security? Do you see any specific security-related concerns in the mobile arena?

Beyond the known, generally accepted secure coding issues and their fixes suggested in our rules and guidelines, one challenge is the lack of sufficient control of where app data can go. Information leaks are prevalent because of the way Android apps interact. We are currently developing static analysis tools that can be used to discover and eliminate these vulnerabilities. The method we are working on will enable users—both individuals and organizations–to have more confidence about data leakage with respect to a particular set of apps. However, even though the method we are working on advances security analyses, it does not address native code or reflection. Data flow security is a big challenge, and many great researchers are working on these issues in both industry and academia.

Another part of the problem is usability. Even when thorough analyses of data flow are available, users need to be presented with options and must understand the implications of those options without having to spend a great deal of effort to do so and without having to be developers themselves. Adrienne Porter Felt (at Google) has published some especially good research papers analyzing user interface security problems and suggesting possible fixes. Her work also covers usability issues for programmers, such as inadequate APIs about permissions leading to well-meaning developers requesting more permissions than needed, which can be exploited by malicious apps.

Another issue with Android security is that when security issues are found and fixed by Google, mobile carriers that have special “flavors” of Android phones may take a long time to roll those security updates out to their users. Consequently, the data associated with apps may be vulnerable for the length of time that the ISP takes to roll out the security update.

What kind of benefits can be expected from the application of the secure coding rules and guidelines for Android? Have you got any story about bugs being introduced in apps that would have been avoided if the guidelines had been followed?

Data and systems are more secure if the secure coding guidelines for Android are correctly applied. For example, DRD00-J prohibits sensitive data from being written to SD cards that other apps can access, and DRD01-J limits access to sensitive data in content providers. One well-known vulnerability occurred in the Skype app for Android whereby contact information and personal user information was stored in a database unencrypted and without enforced permissions. Compliance with DRD01-J would have prevented this flaw.

SCI participates in the development of international standards for programming languages to improve the security of these languages, working to help prevent code vulnerabilities in those standards and incorporating information gathered through development of CERT secure coding standards and conformance testing.

Would you suggest any specific approach to applying CERT secure coding rules and guidelines, whether it is tools, processes, or other method? What should an interested party start with?

I suggest that developers first read our short technical report, Mobile SCALe: Rules and Analysis for Secure Java and Android Coding, and then take a look at the Android secure coding landing page. We plan to produce a separate CERT coding standard, which like all the other CERT secure coding standards will be accessible from the CERT Coding Standards wiki main page. The landing page describes our efforts so far toward developing the Android secure coding standard: analysis (for applicability) and augmentation of existing Java rules, analysis (for applicability) and augmentation of Java guidelines as they were being developed, and development of Android-only secure coding rules, which are not necessarily specific to only the Java language. Links to those three main areas of Android secure coding standards development appear on the landing page.

Next, I recommend that developers look over the DRD rules and guidelines and consider how they apply to their app coding. Then, I recommend they review the Android-applicable Java rules published in The CERT Oracle Secure Coding Standard for Java (Addison-Wesley Professional, 2011) and on the wiki, focusing on areas relevant to their work. The rules must always be followed for secure apps, which is why they should be examined before the guidelines. Next, the Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs (Addison-Wesley Professional, 2013) should similarly be examined. Although not all of the rules and guidelines are immediately useful to the developer’s work, the topics skimmed will likely be remembered, and when the developer programs an app to which the rule or guideline applies, the standard can be reexamined. It is worthwhile to subscribe to the secure coding newsletter, Secure Coding Forum, on LinkedIn, and to notifications on the secure coding wiki, as new rules and guidelines are constantly being added. These media also help keep the security fixes in the developer’s mind.

Is your work on the secure coding guidelines for Android complete, or do you envision more areas to be covered in the future?

We are continuing work on the secure coding guidelines for Android. One area in particular that we want to pursue is analyzing the applicability of the CERT secure coding guidelines for C and C++ to Android. We have performed an initial analysis, but more work is needed to examine how Android’s native code interface affects the applicability of those rules. Also, our initial rules and guidelines with respect to reflection will be further developed.

What similar projects is your group working on?

Our CERT Secure Coding Initiative (SCI) has produced secure coding standards for the C, C++, Java, and Perl programming languages, and some of our standards have been adopted at corporate levels by companies such as Cisco and Oracle. We encourage developers and others working with those programming languages to apply our relevant secure coding standards, which provide benefits similar to those of the Android secure coding rules and guidelines.

The goal of SCI is to reduce the number of vulnerabilities to a level that can be fully mitigated in operational environments. This reduction is accomplished by preventing coding errors or discovering and eliminating security flaws during implementation and testing. SCI continues to develop the Source Code Analysis Laboratory (SCALe), which supports conformance testing of systems against our coding standards, including our new conformance testing specific to mobile platforms (Mobile SCALe). Mobile SCALe currently focuses on Android because that is the first mobile platform we developed secure coding rules and guidelines for. We plan to add Apple’s iOS and Microsoft’s Windows 8 to the set of mobile platforms we support with secure coding standards and conformance testing.

Rate this Article

Adoption
Style

BT