Practical Advice for Building Secure Android Databases in SQLite
- Android Database Security Issues
- Hiding the Key
- SQL Injection
In Android development, when we say “databases” we primarily mean SQLite and all of its variants. These are typically small databases used to store or cache user information locally on the device. It would be fair to say that databases and shared preferences contain the bulk of an application’s dynamic data that is stored on a phone. In this chapter we’re going to look at how developers have used SQLite and, more importantly, how they have tried to secure that data in progressively more secure ways so you don’t make the same mistakes.
Android Database Security Issues
Android databases are typically used to cache application data so that it can be retrieved more quickly than doing a web service call to a back-end database server across the Internet. Every app will have its own databases folder. So if the app’s package name is com.riis.sqlite3, then you can find all its databases in the /data/data/com.riis.sqlite3/databases folder. You can see this in Figure 5-1 where we’re doing an adb shell command to get us a list of the files in the database folder.
Figure 5-1 SQLite databases on your phone
Android databases are not a good place to store sensitive information. As we’ll see later in the chapter, it is all too easy for someone to do a backup command and quickly find what you’re trying to hide.
However, many apps ignore this issue because using SQLite is so convenient for storing data. Facebook keeps a lot of its user information in SQLite databases, which they have openly admitted is for performance reasons. Figure 5-2 shows a Facebook database that’s been taken off an Android device using the adb backup command. The “text” column in the threads.db database shows all the thread messages that a user has sent and received in Facebook via the website as well as on the mobile app.
Figure 5-2 Viewing SQLite databases on your PC using SQLitebrowser