Android Apps Security

Google entered the mobile phone market in a style that only multibillion-dollar companies can afford: it bought a company. In 2005, Google, Inc. purchased Android, Inc. At the time, Android was relatively unknown, despite having four very successful people as its creators. Founded by Andy Rubin, Rich Miner, Chris White, and Nick Sears in 2003, Android flew under the radar, developing an operating system for mobile phones. With a quest to develop a smarter mobile phone that was more aware of its owner’s preferences, the team behind the Android operating system toiled away in secrecy. Admitting only that they were developing software for mobile phones, the team remained quiet about the true nature of the Android operating system until the acquisition in 2005.

The basis of all meaningful applications is information, and we design and build applications to exchange, create, or store it. Mobile applications are no different. In today’s well-connected mobile landscape, information exchange is the name of the game. To illustrate this point, imagine an Android phone without mobile network or WiFi coverage. While there would still be uses for such a phone, you would have lost access to some of the more important applications on your device. For example, e-mail, instant messaging, web browsing, and any other application that require the Internet would now be nonfunctional.

In Chapter 2, we looked at a simple example of how we can protect information using encryption. However, that example did not make use of Android’s built-in security and permissions architecture. In this chapter, we will take a look at what Android is able to offer the developer and end user with regard to security. We will also look at some direct attacks that can take place on applications and how to take the necessary safeguards to minimize the loss of private data.

In this chapter, we will merge together all the topics we discussed in the previous chapters. If you recall, we discussed the Proxim application, through which we looked at data encryption. We will analyze its source code in detail here. We will also work through some examples of applications that require and use permissions.

We touched on cryptography very brie fly in Chapter 4. This chapter will focus more on the importance of using cryptography to obfuscate and secure user data that you will either store or transport. First, we will cover the basics of cryptography and how they apply to us in the context of application development. Next, we will look at the various mechanisms of storing data on the Android platform. Along the way, I will give examples of how to store and retrieve data from different mechanisms and outline what function each store is ideally suited to perform.

At some point, you will have to interface with a web application. Whether you’re talking to a RESTful API from a third party or exchanging data with your own back-end web application, your mobile app needs to be open to the idea of interaction with other applications. Naturally, as a responsible developer, it is your job to ensure that the data exchange is done so that attackers cannot access or alter private data belonging to the end user. We spent time exploring “data at rest” in previous chapters, when we looked at data storage and encryption. In this chapter, we will cover “data in transit.”

All along, we have been looking at mobile applications from the perspective of individual developers. Although I believe that individual developers or smaller developer fi rms far outweigh enterprise developers, I think it would be useful to focus a bit on the enterprise developer and the unique challenges he can face. You might be tempted to skip this chapter because you do not fit into the “enterprise developer” category; however, I would urge you to consider this: most enterprises these days look at outsourcing their development work.

In this chapter, as in Chapter 4, we will take a closer look at source code and applications that implement some of the theoretical concepts we’ve discussed. This will give you a better feeling for how to apply them in practice. This chapter’s code examples will focus on secure authentication and safeguarding passwords on the device. Recall that we’ve discussed two mechanisms of logging in to back-end applications without storing credentials on the device. Here, we will explore more detailed source code related to that.

You may decide that you want to make some cash by selling the applications that you’ve spent countless hours developing. With the way the mobile space has evolved lately, it is now easier than ever for an individual developer to market, sell, and earn income from his applications. Apple has the iTunes App Store, BlackBerry has AppWorld, and Android has the Market. The process of selling your apps is simple: sign up as an application seller and publish your app on the online store. Once approved, your app will be instantly available for download by Android users. In this chapter, we will examine this process in a bit more detail, and I’ll cover the basics of how you can get your app listed on the Android Market. Along the way, I’ll touch on what steps are involved from the time when you’ve decided your app works well, up until the point you decide to publish it online. I am also going to cover another important point when it comes to selling your apps online: revenue protection. If your app becomes popular on any of the online stores, then it is more than likely that you’re going to attract individuals who want to “crack” and pirate your app. Unless you’ve planned to give out your app for no charge, this could hurt your income. I will spend some time on this topic and explore how you can write good license key and registration routines that will deter piracy. During this section, I will also shed some light on some of the things your app may have to go through if it finds itself in a hostile environment.

Like the personal computer, the mobile smartphone is susceptible to various types of malware. Throughout this chapter, I will refer to malware and spyware collectively as malware. Even though I do this, it is essential to know the difference between each of these types of hostile applications.