Insecure Data Storage

We've totally interacted with our app now it's time to see the files created locally.

Many developers assume that storing data on client-side will restrict other users from having access to this data. Interestingly, most of the top mobile application security breaches have been caused by insecure or unnecessary client-side data storage. File systems on devices are no longer a sandboxed environment and rooting or jailbreaking usually circumvents any protections.

One needs to understand what different types of data are there and how are these stored insecurely.

Data - Usernames, Authentication tokens or passwords, Cookies, Location data, Stored application logs or Debug information, Cached application messages or transaction history, UDID or EMEI, Personal Information (DoB, Address, Social, etc), Device Name, Network Connection Name, private API calls for high user roles, Credit Card Data or Account Data, etc.

All apps (root or not) have a default data directory, which is /data/data/<package_name>. By default, the apps databases, settings, and all other data go here.

• databases/: here go the app's databases

• lib/: libraries and helpers for the app

• files/: other related files

• shared_prefs/: preferences and settings

• cache/: well, caches

For interact with device or emulator

adb shell

Sqlite database file

Once you are able to access the SQLite database file on an emulator, rooted device or via adb shell / run as [package name], there are a few options to inspect the schema and your SQLite database on device.

Inspect SQLite db via a GUI tool

Pull the file from device first, then use a GUI software to look the schema and content. I use SQLite browser which allows you to see the database schema, table content, as well as executing some simple SQL scripts.

adb pull /data/data/package-name/databases/sqlitedatabse

Inspect SQLite db via sqlite3 command line tool

For me the easier option is to use sqlite3 command line tool to inspect the database from adb shell.

cd data/data/package-name/databases/

sqlite3 db-name

.tables

.schema table-name

Example in the real life:

Shared Preferences Files

The SharedPreferences API is commonly used to permanently save small collections of key-value pairs. Data stored in a SharedPreferences object is written to a plain-text XML file. The SharedPreferences object can be declared world-readable (accessible to all apps) or private. Misuse of the SharedPreferences API can often lead to exposure of sensitive data. Consider the following example:

SharedPreferences sharedPref = getSharedPreferences("key", MODE_WORLD_READABLE);
SharedPreferences.Editor editor = sharedPref.edit();
editor.putString("username", "administrator");
editor.putString("password", "supersecret");
editor.commit()

Once the activity has been called, the file key.xml will be created with the provided data. This code violates several best practices.

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
  <string name="username">administrator</string>
  <string name="password">supersecret</string>
</map>

Example in the real life: