CWAC Security: Helping You Help Your Users Defend Their Data
This project contains utility code related to Android security measures.
At present, it contains:
-
a
PermissionUtils
class with acheckCustomPermissions()
static method, to help you detect if another app has defined your custom permissions before your app was installed -
a
RuntimePermissionUtils
class to help you with the Android 6.0+ runtime permission system -
a
SignatureUtils
class to help you determine the SHA-256 hash of the signing key of some package, to compare against known values, to help detect whether you are about to be communicating with some hacked version of an app -
a
ZipUtils
class with anunzip()
method, that safely handles a few types of malformed ZIP archives when attempting to unzip the contents to your desired directory -
a
FlagSecureHelper
for working around Android framework bugs involvingFLAG_SECURE
NOTE: the TrustManagerBuilder
implementation in this project is deprecated, replaced by a similar class in the CWAC-NetSecurity library.
This Android library project is available as a JAR or as an artifact for use with Gradle. To use that, add the following blocks to your build.gradle
file:
repositories {
maven {
url "https://s3.amazonaws.com/repo.commonsware.com"
}
}
dependencies {
compile 'com.commonsware.cwac:security:0.8.+'
}
Or, if you cannot use SSL, use http://repo.commonsware.com
for the repository URL.
NOTE: The JAR name, as of v0.3.1, has a cwac-
prefix, to help distinguish it from other JARs.
Usage: checkCustomPermissions()
Custom permissions in Android are "first one in wins". In other words, whatever app first has a <permission>
element for a given android:name
gets to define, for all subsequent apps, what the details are for that permission. And, courtesy of Android's rules for informing users about permissions, the app that defined the permission can hold the permission without the user's knowledge.
This has some security implications, which are covered in greater detail in this paper.
The checkCustomPermissions()
method is designed to help you detect if another app has defined the same custom permissions that you are defining. Typically, developers expect to be the first one to define the custom permission, but that may not be true, with consequences for the developers and their users.
Calling checkCustomPermissions()
is easy: just pass it a Context
, such as your launcher Activity
.
What it returns is a HashMap<PackageInfo, ArrayList<PermissionLint>>
, which will require some explanation.
What checkCustomPermissions()
does is find all of the custom permissions in your app that you have declared via <permission>
elements. Then, it scans all other apps on the device, finding all their custom permissions, and sees if there is a match on the permission name ( android:name
attribute).
Each entry in the HashMap
represents one app that has redefined one or more of your custom permissions, keyed by the PackageInfo
object describing that application. Each permission that has been so redefined will be in the ArrayList
. So, if you define two custom permissions, but some other app only redefined one, there will only be one entry in the ArrayList
.
Each PermissionLint
in the ArrayList
contains the following public
fields:
-
PermissionInfo perm
providing details of the permission as declared in the other app -
boolean wasDowngraded
, which will betrue
if you declared the permissison to besignature
, but the other app declared it to benormal
ordangerous
-
boolean signatureDiffers
, which will betrue
if you declared the permission to besignature
, and the other app also declared it to besignature
, and the other app is signed by a different signing key than was your app -
boolean wasUpgraded
, which will betrue
if you declared the permission to benormal
ordangerous
, but the other app declared it to besignature
-
boolean proseDiffers
, which will betrue
if, for the user's configured device locale, the label or description of the other app's edition of this permission differs from your edition of this permission
Hence, if all four boolean fields are false
, the permission in the other app is functionally identical to your own definition, at least for this user and this locale.
The expectation is that you would call checkCustomPermissions()
on the first run of your app after installation. If you get back an empty HashMap
, then you can continue your first run normally. If you get back a non-empty HashMap
, you can decide what to do with the information, including:
-
warning the user about possible data leakage to other apps
-
sending information about the pre-defined permission to your servers, so you can track possible malware attacks targeting your application and users
RuntimePermissionUtils
Usage: Create an instance using the constructor, passing in any handy Context
, such as your Activity
:
utils=new RuntimePermissionUtils(this);
From there, you can call the following on the instance, regardless of API level of the device that you are on:
-
haveEverRequestedPermission()
, which takes the name of adangerous
permission (e.g.,Manifest.permission.READ_CONTACTS
) and returnstrue
if you have ever calledmarkPermissionAsRequested()
for that same permission. Use this to track whether or not you have asked for permissions that you are not automatically asking for on the first run of your app. -
hasPermission()
, which takes the name of adangerous
permission and returnstrue
if the user has granted you the permission,false
otherwise. -
shouldShowRationale()
, which takes anActivity
plus the name of adangerous
permission and returnstrue
if you previously requested the permission and the user denied it, orfalse
otherwise. Use this to determine if you should be showing some information to the user to help convince them to grant you the permission in some subsequentrequestPermissions()
call. -
wasPermissionRejected()
, which takes anActivity
plus the name of adangerous
permission and returnstrue
if you previously requested the permission, the user denied it, and the use checked the "don't ask again" checkbox. Use this to determine if you need to direct the user to the Settings app in order to grant you the permission manually. -
netPermissions()
, which takes aString[]
of permission names that you want to pass torequestPermissions()
, and returns the subset of that array representing the permissions that you do not yet hold. This allows you to declare theString[]
as afinal static
constant, yet does not force the user to have to click through dialogs for permissions they have already granted.
The demoRuntimePerms/
project in this repo demonstrates the use of these methods.
Usage: SignatureUtils
To find out the SHA-256 hash of some app, call SignatureUtils.getSignatureHash()
, passing in some Context
and the package name of the app. This returns a capitalized, colon-delimited SHA-256 hash string... the same format that you get when using Java 7's keytool
to examine a signing key. You can then compare this value with the expected value (e.g., a string resource in your own app), and take steps if they do not match.
You can find out your own package's signature via the convenience method SignatureUtils.getOwnSignatureHash()
, just supplying a Context
as a parameter. While you might be tempted to use this for the purposes of seeing if you have been tampered with, whoever does the tampering would likely remove your call to getOwnSignatureHash()
as a part of that tampering. Hence, this will only catch stupid attackers, which may or may not be worth the investment in effort.
There is also a family of methods for validating an Intent
, to identify who will respond to it and ensuring that the app housing that third-party comoponent is signed by an expected signing key. These methods include:
validateActivityIntent()
validateBroadcastIntent()
validateServiceIntent()
You supply:
- any
Context
- an
Intent
that you intend to use, probably withsetPackageName()
called on it to narrow it down to a single app - the expected signature hash of that app (either as a single
String
or as aList<String>
if there are multiple possibles hashes, such as a Play Store hash and an F-Droid hash) - a
boolean
flag (failIfHack
)
In general, there are three possible outcomes of calling this method:
-
You get a
SecurityException
, becausefailIfHack
is true, and we found some component whose app does not match the desired hash. The user may have installed a repackaged version of this app that is signed by the wrong key. -
You get
null
. IffailIfHack
istrue
, this means that no component was found that matches theIntent
. IffailIfHack
isfalse
, this means that no component was found that matches theIntent
and has a valid matching signature. -
You get an
Intent
. This means we found a matching component that has a matching signature. TheIntent
will be a copy of the passed-inIntent
, with the component name set to the matching component, so theIntent
will only go to this one component.
Usage: ZipUtils
Use the static unzip()
methods to unzip a ZIP-style archive. Both methods have the same first pair of parameters:
-
a
File
pointing to the ZIP archive -
a
File
pointing to the destination directory where the ZIP archive should be unzipped (note: this directory does not have to already exist; if it does exist, it must be empty)
One unzip()
method just takes those parameters. The other takes a pair of additional integers:
-
the maximum number of entries in the ZIP archive; archives with more entries than this will be rejected
-
the maximum size in bytes of the unzipped contents; archives larger than this will be rejected
Both unzip()
methods throw a ZipUtils.UnzipException
if there is a problem. If an UnzipException
is thrown, unzip()
will also "roll back" any existing work and delete the destination directory.
Both unzip()
methods can throw an IOException
. This will indicate that the destination directory that you provided existed and was not empty. In this case, the destination directory is left alone.
If you wish to unzip the archive, and have its contents go into a directory that already has files in it, you will need to first unzip to a temporary directory, then move over the files you want to move.
The approach used here is based on CERT's suggested unzip code, with minor modifications to make it a bit more Android-friendly.
Usage: FlagSecureHelper
The documentation for FlagSecureHelper
has been pulled out into a separate page.
Dependencies
This project has no runtime dependencies. It is tested and supported on API Level 9 and higher. It may well work on older devices, though that is unsupported and untested. If you determine that the library (not the demos) do not work on an older-yet-relevant version of Android, please file an issue.
Also note that testing of TrustStoreBuilder
has only been done using HttpsURLConnection
and OkHttp
. It should work with HttpClient
and other stacks.
Version
This is version v0.8.0 of this module, meaning it is coming along rather nicely.
Demo
In the demoA/
sub-project you will find an application that uses checkCustomPermissions()
to see if some other app has already defined a custom permission. The demoB/
sub-project does not use CWAC-Security, but defines that permission, so that you can verify that demoA
works as expected.
There is an instrumentation test suite in the androidTest
sourceset of the main security
module. It contains a ZipUtilsTest
class that tests the ZipUtils
code.
The demoRuntimePerms/
project in this repo demonstrates the use of RuntimePermissionUtils
.
Additional Documentation
The Busy Coder's Guide to Android Development demonstrates everything from this library, over a series of chapters.
License
The code in this project is licensed under the Apache Software License 2.0, per the terms of the included LICENSE file.
Questions
If you have questions regarding the use of this code, please post a question on StackOverflow tagged with commonsware-cwac
and android
after searching to see if there already is an answer. Be sure to indicate what CWAC module you are having issues with, and be sure to include source code and stack traces if you are encountering crashes.
If you have encountered what is clearly a bug, or if you have a feature request, please post an issue. The contribution guidelines provide some suggestions for how to create a bug report that will get the problem fixed the fastest.
Do not ask for help via Twitter.
Also, if you plan on hacking on the code with an eye for contributing something back, please open an issue that we can use for discussing implementation details. Just lobbing a pull request over the fence may work, but it may not. Again, the contribution guidelines should help here.
Release Notes
- v0.8.0: deprecated
TrustManagerBuilder
, moving it to CWAC-NetSecurity - v0.7.0: added
FlagSecureHelper
, demo project, and related docs - v0.6.3: added more
Intent
validation options - v0.6.2: added
validateBroadcastIntent()
- v0.6.1: bug fix for unzipping some directory structures
- v0.6.0: added
RuntimePermissionUtils
- v0.5.2: require the destination directory for
unzip()
to be empty or not exist - v0.5.1: added
sync()
call to ensure stuff written to disk by the timeunzip()
returns - v0.5.0: reorganized
security
into official Android Studio structure, addedZipUtils
- v0.4.1: updated for Android Studio 1.0 and new AAR publishing system
- v0.4.0: added signature check and
signatureDiffers
toPermissionUtils
- v0.3.1: added
cwac-
prefix to JAR - v0.3.0: added certificate memorization to
TrustManagerBuilder
- v0.2.1: added
SignatureUtils
- v0.2.0: added
TrustManagerBuilder
and supporting classes - v0.1.0: initial release