1022 23rd USENIX Security Symposium USENIX Association
party component under test. Rather than relying on GUI
manipulation (which requires page layout analysis) we
rewrite the application under test to directly invoke the
callback functions that trigger the desired page transi-
tions.
We built Brahmastra to implement our approach for
Android apps. Our tool statically determines short exe-
cution paths, and dynamically tests them to find one that
correctly invokes a target method in the third-party li-
brary. At this stage, behavior that is specific to the li-
brary is checked. Because our techniques do not require
human involvement, Brahmastra scales to analyze a large
number of applications. To show the benefits of our ap-
proach, we use our tool for two new studies that con-
tribute results to the literature: 1) checking whether chil-
dren’s apps that source advertisements from a third-party
comply with COPPA privacy regulations; and 2) check-
ing that apps which integrate the Facebook SDK do not
have a known security vulnerability [30].
From our analysis of advertisements displayed in 220
kids apps that use two popular ad providers, we find that
36% apps have displayed ads whose content is deemed
inappropriate for kids—such as offering free prizes, or
displaying sexual imagery. We also discover that 80%
apps have displayed ads with landing pages that attempt
to collect personal information from the users, such as
name, address, and online contact information—which
can be a violation of the Children’s Online Privacy Pro-
tection Act [6]. Apart from creating an unsafe environ-
ment for kids, this also leaves the app developers vulner-
able to prosecution, since they are considered liable for
all content displayed by their app.
For our analysis of a vulnerability in third party login
libraries, we run a test case proposed by Wang et al. [30]
against 200 Android apps that bundle Facebook SDK.
We find that 13 of the examined apps are vulnerable.
Contributions: We make two main contributions. The
first is Brahmastra, which embodies our hybrid approach
of static and dynamic analysis to solve the third-party
component integration testing problem for Android apps.
We discuss our approach and key techniques in §4 and
their implementation in §5. We show in §6 that our
techniques work for a large fraction of apps while ex-
isting tools such as randomized testing (Monkey) often
fail. We have made the static analysis part of Brah-
mastra available at https://github.com/plum-
umd/redexer.
Our second contribution is an empirical study of two
security and privacy issues for popular third-party com-
ponents. We find potential violations of child-safety laws
by ads displayed in kids apps as discussed in §7; several
apps used in the wild display content in potential viola-
tion of COPPA due to the behavior of embedded compo-
nents. We find that several popular Android apps are vul-
nerable to the Facebook access token attack as discussed
in §8; A Facebook security team responded immediately
to our findings on 2/27/2014 and had contacted the af-
fected developers with the instructions to fix.
2 Background
As our system is developed in the context of Android,
we begin by describing the structure of Android apps and
support for runtime testing.
Android app structure: An Android app is organized as
a set of pages (e.g., Figure 1) that users can interact with
and navigate between. In Android, each page is repre-
sented by an
activity object. Each activity class repre-
sents one kind of page and may be initialized with differ-
ent data, resulting in different
activity instances. We
use the terms page and activity instance interchangeably.
Each page contains various GUI elements (e.g., buttons,
lists, and images), known as
views. A view can be as-
sociated with a callback function that is invoked when a
user interacts with the view. The callback function can
instantiate a new activity by using a late binding mecha-
nism called
intent. An intent encapsulates the descrip-
tion of a desired action (e.g., start a target activity) and
associated parameters. The main
activity (or the first
page) of an app, defined in its manifest file, is started by
the application launcher by passing a
START intent to it.
For example, in Figure 1, clicking the “Done” button
on activity
A1 invokes its event handler, which calls a
callback function defined by the app developer. The call-
back constructs an intent to start activity
A2 with nec-
essary parameter
P12. The Activity Manager then con-
structs an instance of
A2, and starts it with P12 as parame-
ters. We refer to the documentation of Android internals
for more details [2].
Automated dynamic analysis: Recent works have used
a class of automation tools, commonly called a Mon-
key, that, given a mobile app binary, can automatically
execute it and navigate to various parts (i.e., states) of
the app. Examples include PUMA [23], DECAF [25],
AppsPlayground [26], A3E [14], and VanarSena [27]. A
Monkey launches the app in a phone or an emulator, in-
teracts with it by emulating user interactions (e.g., click-
ing a button or swiping a page) to recursively visit vari-
ous pages, and performs specific tasks (e.g., checking ad
frauds in the page or injecting faults) on each page.
In Figure 1, a Monkey may be able to visit the se-
quence of states
A1 → A2 → A3→ A4 if it knows the
right UI actions (e.g., type in mother’s name and select
“Due Date” in
A1) to trigger each transition. However, if
Monkey clicks a button in
A3 other than “Account”, the
app would navigate to a different activity. If the goal of
testing is to invoke specific methods (e.g., Facebook lo-
gin as shown in the example), then without knowing the
structure of the app, a Monkey is likely to wander around