Industrial Process

6.
1 Structure
6.2 Intents
6.3 Deep Links
6.4 AIDL
6.5 Messenger
6.6 Binder
6.7 Components
6.8 Permissions
6.9 WebViews
6.10 Share UID
Mobile Application Security and Penetration Testing v 2.5 - Caendra Inc. © 2017
As we previously discussed, there are two major components
to any Android app:
• the Java code which makes up the heart of the program
• XML which defines configurations, such as string values
and the app’s identity.
Now, we’ll take a deeper look at each of these separately and
how they fit together.
For most of us, we consider that Android uses Java, end of
story.
For the lawyers at Google and Oracle, there are considerable
distinctions on exactly what that means. The distinctions are
still a point of litigation.
Oracle owns the Sun flavor of Java, but Android employs open
source versions of Java.
These are namely, Apache Harmony in Android versions up to
4.4 and the OpenJDK flavor used in later versions.
This will usually only matter to you if you need to research
the specific capabilities of an API in the documentation. This
does not come up frequently when testing apps.
Regardless of the Java flavor, it makes up the core of nearly
every Android app. While it is possible to use languages such
as C, or C++, using the Android Native Development Kit (NDK)
is the best option.
Java is used for the majority of apps and their primary
components, which we will discuss later.
In this and some of the following sections, we’ll be taking a
deeper dive into the aspects of the AndroidManifest.xml file.
Without this file, the Android operating system is unable to
run the app.
It defines things such as the name of the app, all its major
components, how the components are protected, what
versions of Android the app will run on, the UID it will run
with and much more.
Each of the configurations is specified in an attribute to one
of numerous xml elements. Some of these elements
themselves may contain multiple sub-elements as well.
You should be aware that if an attribute begins with a dot (.),
it is treated as relative to the package name, specified in the
manifest element’s package attribute.
For example, if the package named com.example.elearn had
an element attribute specifying .test as the value, it would be
equivalent to using com.example.elearn.test.
For a complete explanation of the syntax and various
elements, you can view the documentation here, but we will
dive into this a bit more shortly.
Some of the most important items in the
AndroidManifest.xml file are those specified in the <uses-
sdk> element.
It has one or more of the following attributes:
• minSdkVersion,
• targetSDKVersion
• and/or maxSdkVersion.
The minSdkVersion specifies the earliest version of Android
the app will run on. Failing to specify a value results in a
default of 1, which would allow the app to run on any version
of Android, back to the very first.
The issue with supporting these old versions, from a security
perspective, is that your app inherits the security
vulnerabilities of the Android version it runs on.
Without any changes to your code, your app can have
dramatically different security postures on different devices,
based on their Android versions.
If a developer fails, or is unable to account for this in their
application design, the app may inherit some serious
vulnerabilities.
Businesses frequently want to support the widest ranges of
devices possible, in order to reach the maximum number of
consumers. It is important for developers to strike the right
balance between compatibility and security.
If older versions must be supported to meet business
requirements, steps should be taken to engineer around
potential vulnerabilities for the versions you wish to support.
The targetSdkVersion specifies which version of Android the
application has been tested to be compatible with.
This setting controls how compatibility features are applied to
the application for Android versions greater than the
specified version.
If not set, it will fall back to the same value as minSDKVersion.
It is not generally recommended to set the maxSdkVersion at
all, because it essentially prevents the application from being
installed, or may cause it to be removed from, devices which
run an Android version newer than the one specified.
In general, neither the targetSdkVersion nor maxSdkVersion
have any significant security impact.
Intents are the primary means by which Android apps
communicate between their components or with other apps.
These message objects can also carry data between apps or
components, similar to how GET and POST verbs are
commonly used in HTTP communications.
Intents are commonly used to invoke an action or set of
actions in the receiving component or application. As we’ll
discuss shortly, these can be directed to specific components
and/or applications, or can be sent out without a specific
recipient designated. This leaves it up to all potential
recipients as to whether they are interested in the message.
More information on intents can be found here.
Implicit Intents are those that do not specify a particular
app’s component, but rather specify an Action to be taken
and therefore potentially allow any application to receive and
process the intent.
An Action is a string that specifies the name of an action to
perform, which the receiving component will process based
on its configuration.
These are specified as ACTION_X where X describes an action
to perform such as VIEW or SEND.
An intent’s action is specified either via the setAction()
method or within the Intent constructor itself.
Intents are programmatically created using an Intent
constructor like the one shown below.
Intent email = new Intent(Intent.ACTION_SEND,
Uri.parse(“mailto:”));
In the above example, the Intent’s name is email, the Action

is ACTION_SEND and it includes an Extra of mailto, whose
type is Uri.
This example is used for sending a mailto link to an
application which is capable of generating an email message.
An Extra is the term for the portion of the Intent which
carries data.
We’ll cover working with Extras a bit later in the course.
In the receiving app’s manifest, it would be necessary to have
a component with an intent-filter element, which matches
our action. In the example below, the component is an
Activity and the action’s name attribute is specified in
hierarchical form.
More details on intent-filters can be found here.
<activity android:name=”ShareActivity”>
<intent-filter>
<action android:name=”android.intent.action.SEND”/>
<category android:name=”android.intent.category.DEFAULT”/>
<intent-filter>
</activity>
In addition to a matching action, an intent and its
corresponding intent-filter in the receiving component, are
paired with their data and category.
In order to receive any implicit intent, the app also needs to
specify the default category, as in the previous example
(android.intent.category.DEFAULT).
From a security perspective, it is very important to recognize
that the recipient of an implicit intent is not specified by the
sending application. This means that any data sent in an
implicit intent could trivially be stolen by a malicious app.
Developers need to be mindful of the fact that the recipient
of this type of intent can never be assured.
The “Intent resolution” process queries the system’s Package
Manager process. It is used to determine which apps are
capable of handling the Intent based on if they match the
category, action and type.
The resolution process also considers the priority attribute
which can be specified in the intent-filter for a component.
The app with the higher priority value will be selected if there
are multiple matches on the other criterion.
While the documentation suggests the limits for priority
values be between -1000 and 1000, at one point, the OS
didn’t necessarily enforce this.
This allowed apps to use the SYSTEM_HIGH_PRIORITY value,
which is the system’s maximum possible integer value,
allowing them to compete with system apps for intents.
During the Intent resolution process, if a conflict arises, the
default behavior is that a “chooser” window appears, which
prompts the user to choose the application to use to handle
the Intent.
In 2013, a vulnerability related to this process (along with a
logic flaw) was discovered, related to the use of Google’s own
Play Billing Library.
This allowed thieves to complete in-app purchases, without
actually being charged any money. Thieves would simply build
a malicious app, which matched the Play Billing Library’s
intent-filter, but specifying an equal or higher priority.
Since the exploit was exploited locally on the thief’s device,
they would simply select their app from the chooser menu
(assuming priority contention), to resolve the payment intent,
then send back a response which emulated a successful
payment.
An explicit intent is one that specifies the class name it is
targeting in the intent constructor. This ensures the receiving
app is the one you intended and prevents a malicious app
from intercepting or eavesdropping on the intent contents.
For internal classes, you’d simply specify the class name in the
constructor.
The following is an explicit intent example:
Intent downloadIntent = new Intent(this,
DownloadService.class);
For classes in other applications, you’d use either the
setComponent or setClass methods from the Intent
constructor.
Explicit intent example:
Intent intent = new Intent();
intent.setClassName("com.other.app",
"com.other.app.ServiceName"); context.startService(intent);
Unlike the intents we’ve previously discussed, which are
ultimately only received by one app, broadcast intents can be
received by multiple apps. When sending broadcasts, care
needs to be taken so that no sensitive data is leaked in the
process.
If you need to ensure that only a select app receives a
broadcast, starting with API version 14 (Android 4.0 - Ice
Cream Sandwich), you can specify the app, using
Intent.setPackage.
Alternatively, you can specify a permission when sending the
broadcast. The receiving app(s) would need to specify the
uses-permission element in their AndroidManifest.xml file,
with the permission in its name attribute value, as described
here.
We’ll discuss how permissions work in a later section.
There are two types of Broadcasts: Normal and Ordered.
Normal Broadcasts are asynchronous and can be processed
by multiple applications in any order, or potentially
simultaneous.
Ordered Broadcasts are run one at a time, in a daisy-chained
fashion.
The order is determined by the priority defined within the
corresponding receiver element, within the receiving app’s
AndroidManifest.xml file.
This means that each app can process, then relay, or drop, the
Broadcast.
If you need to ensure delivery of the Broadcast, you’ll either
need to use the appropriate permissions, or a Normal
Broadcast (if the Broadcast isn’t sensitive).
To send a broadcast intent, with a permission specified, you’d
use something like the example below:
sendBroadcast (intent, receiverPermission)
Keep in mind, that unless the permission you declare is

reserved for system level apps, any app could also have
declared the same permission. The only protection offered in
this situation is at app install time, but as we’ll see later, even
that has suffered from vulnerabilities.
If the Broadcast only needs to be received by components
within the same application it is being sent from, you can use
the sendBroadcast method from the LocalBroadCastManager
class, as described here.
Unlike the sendBroadcast method from the Context class, the
sendBroadcast method from the LocalBroadCastManager
ensures that your broadcast never leaves your app, which
also means you don’t have to export a receiver component.
Because you don’t export the receiver, you also minimize
your application’s attack surface, giving you one less thing
that you have to safeguard.
Sticky Broadcasts are similar to Broadcasts in that many apps
may receive the data. The significant difference here is that
the system maintains these Broadcasts, so they can be
accessed long after they were initially sent, instead of in real-
time, the way normal Broadcasts are.
Luckily, this functionality was deprecated in API Level 21, but
you will still find them used in some apps.
According to the Android documentation here, “Sticky
broadcasts should not be used. They provide no security,...no
protection,...and many other problems”.
Documentation is rarely that definitive with regards to
security, so you know it’s bad.
As with any Broadcast, Sticky Broadcasts allow for data
leakage when received by a malicious app.
But they also allow for malicious apps to modify the data as
well.
The lesson here is if you’re reviewing an app and see any
method that contains the word “sticky”, like
sendStickyBroadcast, sendStickyBroadcastAsUser, etc., you
should definitely examine the potential impact and do
everything you can to get it removed.
If you’re a developer, just forget that this functionality ever
existed.
Pending Intents allow other applications to take actions on
behalf of your application, using your app’s identity and
permissions.
When constructing a Pending Intent, developers specify an
intent and action to perform. If this intent is not an Explicit
Intent, a malicious application could receive it and perform
the action on behalf of the victim app.
Obviously, allowing a malicious application to perform an
action as if it was yours, can have potentially serious security
consequences.
As described in CVE-2014-8609, the Android Settings app
suffered from a privilege escalation vulnerability, due to its
use of an Implicit, rather than Explicit Intent when
constructing a Pending Intent.
Additionally, the Settings app failed to specify an action,
allowing the attacker to control not only the destination, but
the action to be performed as well.
Finally, to make matters worse, the Settings app runs with the
SYSTEM permission, so nearly unlimited damage could be
done by a malicious app, including completely deleting all the
user data such as performing a factory reset.
The vulnerable line of code is shown below.
mPendingIntent = PendingIntent.getBroadcast(this, 0, new Intent(), 0);
Here the new Intent() is what creates the empty and

therefore Implicit intent.
A safe example would replace that section with something
like this:
new Intent(SampleAction, SampleUri, this, Example.class)
Note: “this” is the Context.

Deep Links allow you to trigger an Intent via URL, embedded
in a website. This allows the app to start and pass in data, as
described here.
In order to receive the Intent, you need to configure your
AndroidManifest.xml to confirm the action, category and
data, in the Deep Link’s URL, match up with the intent-filter
element for the receiving component.
Your intent-filter must also include a category with the
following value:
android.intent.category.BROWSABLE
As with any external input, the data carried in an Intent, from
a Deep Link, should be validated before being used in the
application. You also need to consider the contexts in which
the data is used.
For example: whether it is used in a WebView and could
potentially lead to an XSS, or other vulnerability.
Once the Deep Link Intent reaches the application, there is
basically no difference than any other type of Intent, so the
data, action, etc. are pulled from it using the same methods
you would with any Intent.
AIDL (Android Interface Definition Language) is an Android
specific IDL, which essentially describes an API offered by a
Service to external applications.
AIDL enables IPC (InterProcess Communication) by allowing
the client to understand what the service is expecting, in
terms of primitives.
The client app can then create these objects and rely on the
underlying operating system to deliver them to the service in
another app.
Depending on whether you need multi-threading and
concurrency, there are other alternatives as well, which will
be covered in upcoming modules.
Services which use AIDL are referred to as Bound Services and
are a bit more complicated to implement than most
components.
In the Service’s class you will find an onBind method, which
returns the service object to the client app, in the form of an
IBinder. It is important to understand that the onBind method
is where the client interaction begins with the service.
When looking for potential vulnerabilities, you will want to
begin with the onBind method and follow the application’s
logic to determine what actions are invoked as a result of the
requests from client apps and where the data passed in from
these requests are used.
When exposing a service using AIDL, you’ll also need to
ensure you’ve properly configured the permissions in the
AndroidManifest.xml to limit which apps can connect to it.
We’ll discuss these permissions, and services in general, in an
upcoming module.
Since we’re mainly concerned with the security implications,
we’re not necessarily diving deep into the programming
details, but we’d recommend you consult the linked
documentation to learn more about how they are
constructed.
A Messenger is another type of IPC mechanism available in
Android to share a service with other apps. As explained here,
the client invoking a Messenger receives an IBinder that can
be used to send data to the service.
Since a Messenger is also a “Bound Service”, the data passed
in from the client app is also processed through the onBind
method.
When reviewing a class that implements a Messenger
interface, you’ll need to begin evaluating this method.
This is done by looking for the invocation of sensitive
functionality or unsafe handling of data sent from a client
app.
Again, we’re not going to focus deeply on the internal
workings of a Messenger. For our purposes, it’s sufficient to
understand they are meant to pass in data from other apps. It
is also the place to begin the process of tracing the execution
from source to sink via static code analysis.
As with AIDL services, and other IPC mechanisms meant to
expose components to other applications, the first step in
securing them and limiting the attack surface, is configuring
the permissions properly in the AndroidManifest.xml.
It is unlikely that you’ll see a Binder class directly invoked,
unless a custom RPC protocol is needed. It is much easier to
use AIDL, which, like Intents, ultimately abstracts the Binder
class.
For our purposes, it is enough to understand that Binder is a
kernel-level driver, which moves data from one process’s
memory to another’s.
While the internals are beyond the scope of this course, if you
would like to learn more, you can find an overview here.
There was also a great presentation at BlackHat Europe on
the topic of Binder and its security implications.
Components is a generic term used to describe the more
commonly used and familiar parts of an Android application.
These include Activities, Services, Broadcast Receivers and
Providers.
Each component type has a unique role to play in an Android
application, although they are not all present in every app.
They are implemented as needed, depending on the goals of
the developer.
The implementation of these components is done in Java, but
each has a corresponding element in the
Activities are the visual screens you see in applications. With
a few exceptions, every image, button, web page, menu, etc.
are implemented via an Activity. Details on the Activity class
can be found here.
Most applications intentionally expose at least one Activity
which can be invoked by an Intent. Remotely invoking an
Activity, that just spawns the associated UI elements, is not a
real security concern (even if left unprotected). There are
however, some special cases, which we’ll take a look at.
In addition to supporting Java code, Activities are defined in
an activity element in the AndroidManifest.xml file.
Obviously you shouldn’t be able to bypass a “Login” activity
and gain access to a protected part of the app, without
authenticating. But even if this is possible, its usefulness to an
attacker is often questionable.
Forcing, or allowing, a user to see a UI element that they
should have logged in to see, is not much benefit to an
attacker, unless the attacker is the user trying to hack the app
(e.g. game cheating).
For this vulnerability to be meaningful, a developer would
have to already had to have violated the cardinal rule of
client-side security: Never rely on client-side code alone to
protect data or functionality.
The most direct situations where an improperly protected
Activity could be exploited would be those where it returns
data to a caller.
In order to locate situations where this could occur, you’ll
need to examine the Activity code for the setResult method,
described here.
The key here is to evaluate what data is passed into the
setResult method’s Intent parameter.
If this data is sensitive in nature, you would have an
information leakage vulnerability. This is exploitable by all
applications capable of communicating with the Activity.
Services are used to perform long-running processes, even if
the user starts using a different application. Services run in
the background and therefore don’t provide a UI themselves.
In addition to the supporting Java code, Services are defined
in a service element in the AndroidManifest.xml file.
If the client calls a service using the startService method, it
will run indefinitely, until the stopService method is invoked.
If the service is only needed as long as the client is connected,
the client should “bind” to it using the bindService method.
Depending on how the service is created or started, there are
several methods which can receive malicious input and need
to be reviewed for vulnerabilities.
The first place to look for vulnerabilities, would be from the
Intent, passed into the onStartCommand method for
“started” services.
You’ll want to look for any sensitive functionality invoked
because of this Intent. Or any use of the Extras from the
Intent used in a sensitive function, which have not been
properly sanitized first.
For a “bound” service, you’ll perform the same process, but
you would start with the Intent passed to the onBind
method, looking for the same types of issues.
Broadcast Receivers are the components which listen for
Broadcast Intents sent from applications.
Broadcast Receivers can be statically defined in
AndroidManifest.xml, in a receiver element, or dynamically
defined using the registerReceiver method.
Receivers are primarily used for processing input from other
applications.
The keys to properly securing them are:
• validating the data received from other applications
• potentially limiting which application’s broadcasts your
receiver accepts.
When statically defined, you can limit which app’s broadcasts
you accept through the use of permissions within the
receiver element, defined in the AndroidManifest.xml.
When dynamically defining a receiver, you pass the
permission as an argument to the registerReceiver method.
We’ll dive into permissions more in another section.
You’ll want to start your examination of potentially tainted
data flow. This begins with the Intent passed to the
onReceive method in the class that implements the
BroadcastReceiver.
You should ensure that the data is properly validated and no
sensitive functions can be invoked by malicious applications.
Ordered Broadcasts present a unique case because not only
can the other receivers of the Broadcast Intent receive and
potentially drop it, they also have the ability to modify the
contents of the Intent, using one of the setter methods. You
can read about that here.
Therefore, you need to either ensure that only trusted apps
can:
• Receive the broadcasts via permissions
• and/or ensure that any attempt to read the results via the
getResultX getter methods properly validates the data
received.
You would also want to ensure that the processing of the
received data is coded in such a way that bogus (but
otherwise valid) data does not open your app up to security
vulnerabilities.
Content Providers are the means by which Android apps
share structured data, such as relational databases (e.g.
SQLite).
As with other component types, securing Content Providers
begins with determining whether your business requirements
allow you to prevent or at least limit other apps from
connecting to them.
As previously discussed, this begins with setting the correct
exported attribute value within the provider element of your
Using permissions and the appropriate protection level limit
the apps which can connect to the Content Providers.
Unlike other elements, Content Providers also have a second
layer of permissions which, when present, take precedence
over the permission attribute.
The readPermission and writePermission attributes specify
which permissions an app must have, in order to query the
database or make changes to the data.
Content Providers also provide the ability to allow for
temporary exceptions to these two layers of permissions.
This is accomplished by first, setting the grantUriPermission
attribute value to true. Then configuring the appropriate
parameters in the grant-uri-permission element, within the
provider element, of the app’s AndroidManifest.xml file.
The grant-uri-permission element has three attributes: path,
pathPrefix and pathPattern. These are used to specify which
paths in the content: URI are available:
• The path attribute allows specifying the entire path to exclude.
• The pathPrefix attribute allows you to specify the beginning of the
path, in case you need to exclude multiple child paths.
• The pathPattern allows the use of wildcards and symbolic
replacements, to gain more granular control. For example: allowing all
URI, which end in a similar value, but are located under different
parent paths.
Despite the numerous means to limit access to your Content
Providers, this may not be sufficient, or even possible in some
cases.
Usually you still need to ensure that the code protects itself,
in order to prevent common vulnerabilities like data leakage
and SQL Injection attacks.
Note: SQLi in Android does not have the exact same meaning
as the one for Web Apps.
As with any functionality involving potentially tainted data,
programmatically creating defenses, such as whitelists of
expected values, will eliminate many types of vulnerabilities.
To prevent SQL Injection attacks, you’ll want to use
parameterized queries, as you would with a web application.
This however does not prevent injection in where the select
parameter used in one of the query methods (query, update,
delete), is created by concatenation of untrusted data.
We have mentioned permissions several times in this course,
now dive into the different types and their usages.
These various usages play an integral part in the security of
many aspects of Android applications.
The term Permissions is repeatedly used to describe several
different configurations for Android apps, so we’ve separated
the sections to clarify which we are referring to.
When the average user thinks of Android permissions, they
think of the prompts they receive when they install
applications, such as access to your Contacts, GPS location
and so on.
These prompts are a direct result of the configuration of the
uses-permission elements in the AndroidManifest.xml file.
The uses-permission element has two attributes, name and
maxSdkVersion.
The name attribute will either be standard system
permission, in which case it will begin with
android.permission, or a custom permission defined in
another application. We’ll review how an app can declare
these custom permissions in an upcoming section.
Whether the system prompts a user to approve permissions
depends on the type of permission requested. We’ll cover
these differences in an upcoming section.
In Android version 5.1 and lower, these permissions were
only requested at the time of installation, but starting in
version 6.0, it is now possible for users to control permissions
after installation.
The maxSdkVersion attribute simply stops your app from
asking for permission on versions higher than the one
specified.
This is used if there is a change to the Android operating
system, making the request unnecessary after some version.
When an app needs to expose information or functionality
from one of its components, it will export it to make it
available. By defining a custom permission, using the
permission element, the app can limit access to only those
apps that have the specified permission.
The app requiring the permission would define the uses-
permission element’s name attribute, which matched the
name element in the hosting app’s permission element.
The permissions element has three attributes which are
directly related to security.
• The name attribute is a string identifying the permission.
• The protection-level attribute, dictate how the permissions
are granted. We’ll cover this in the next section.
• The permission-group attribute, which allows for grouping
related permissions.
Protection levels are specified within the permission element
for a component and are what ultimately dictate how the
permissions are granted.
There are four types of protection levels: Normal, Dangerous,
Signature and SignatureOrSystem.
The appropriate protection level is dependent on several
factors, including which apps should communicate with the
component.
Normal protection-level is used for many common
permissions where there are no known threat to the
application, user or operating system.
The user is not required to approve permissions which use
this protect-level, because they have been deemed harmless.
Permissions of this type are used for system functionality, as
described here.
Dangerous protection-level, implies that this permission will
grant the requesting application, elevated access to data or
system functionality.
Users will receive a prompt requiring approval whenever an
app needs dangerous protection level permission.
Permissions of this type are used for system functionality,
which is potentially harmful.
Signature protection-level is used to ensure that only apps
signed with the same certificate, as the app exporting the
component, can be granted permission.
This type of protection level is used by organizations to
permit their apps to communicate with each other, while
preventing others.
This is the strongest type of protection offered in Android and
doesn’t rely on any approval from the user.
SignatureOrSystem protection-level is used to ensure that
only apps signed with the same certificate, as the app
exporting the component, or apps running with system-level
access, can be granted permission.
This protection-level is used by applications on the system
image and generally not ones which are installed by users.
You would likely find this protection level used in apps from
OEMs or cellular providers.
WebViews are effectively web browsers (aka clients) which
are embedded into Android apps.
WebViews can render HTML, execute JavaScript and even run
active content (version dependent).
The content loaded into WebViews can be pulled from
remote sites or files which are already included in the app,
such as HTML templates.
Developers often opt to use local files to improve the
responsiveness of their applications, and use remote content
when they need current content or the ability to change the
content without updating the client.
Unfortunately, the functionality and flexibility offered by
WebViews dramatically expand the attack surface for Android
apps.
WebViews are potentially vulnerable to all of the same
vulnerabilities as any other web browser and may allow
exploitation of many of the OWASP Top 10 vulnerabilities in
web applications.
Luckily, there are some limitations and configuration options,
which can limit the exploitation possibilities, depending on an
app’s requirements.
In Android 4.4, the WebView became based on the open-
source Chromium browser, partly to resolve rendering
inconsistencies with the Chrome browser. While still not
identical, they are much more aligned than in previous
versions.
Initially, WebViews were unable to be updated without
updating the Android operating system.
This proved to be problematic, due to the delays in releasing
the updates, introduced by the carriers and OEMs.
In particular, there were several vulnerabilities which may
have spurred a decision by Google to abandon creating
patches for older WebViews, potentially leaving them
vulnerable indefinitely.
In Android 5.0, Google decoupled the WebView from the OS,
allowing WebViews to be updated the same way as any other
app. This takes the carriers and OEMs out of the equation
completely.
There are two types of WebViews used in Android.
The WebViewClient is best suited for simple HTML rendering,
whereas the WebChrome client is effectively a full-fledged
Chrome browser.
One key difference for a security tester is that the
WebViewClient will not run/display the Javascript alert()
function, so many common XSS (Cross-site scripting) tests are
rendered invalid and require modification.
WebViews have their own cookie jar, without any access to
the app’s other cookies by default. To be clear, they also have
no access to the native browser’s cookies.
There are several steps involved in creating a functional
WebView. They include passing in the URL or content to load,
using the loadUrl, loadData or loadDataWithBaseURL
methods.
You’ll want to ensure that the parameters to these methods
are not derived from unsanitized, user-controlled data.
There are many settings which can potentially impact the
security of an app’s WebView(s), primarily by
enabling/disabling functionality.
These settings are configured through the WebSettings
object, obtained via the getSettings method of a WebView.
We’ll discuss several of these settings in the following
sections.
The general philosophy for WebViews is simply to limit the
functionality to only that which is essential to meet business
requirements, nothing more.
By reducing the attack surface, we have fewer avenues of
exploitation.
One easy way to avoid vulnerabilities is to disable JavaScript
on WebViews which don’t require it.
JavaScript is enabled/disabled by using the
setJavaScriptEnabled method and passing it the value, true or
false.
While not always possible, disabling JavaScript for a WebView
completely eliminates the possibility of XSS, which is a huge
win from a security perspective.
This step can potentially prevent the exploitation of other
types of vulnerabilities which rely on JavaScript as well.
The JavaScript “Bridge” functionality is a way to inject Java
objects into a WebView by making them accessible to
JavaScript.
In Android version 4.1 and earlier, all public methods in the
class passed to addJavascriptInterface were automatically
available to the JavaScript in a WebView.
Unfortunately, this would allow malicious JavaScript, loaded
into a WebView (with the bridge enabled), to potentially
access protected device functionality and bypass the
WebView’s Same Origin Policy.
Recognizing the potential for abuse, this was changed in later
versions. In Android 4.2 and later, methods must be
annotated with @JavascriptInterface in order to be
accessible to the Javascript running in the WebView, provided
the targetSdkVersion is set to 17 or higher as well, in the
AndroidManifest.xml.
The folks at Cigital performed a thorough write-up of the
topic here.
WebViews can be allowed to access Content Providers via
content:// URLs by passing true to the
setAllowContentAccess function.
This can pose a security risk if the data in the Content
Provider is sensitive and the WebView loads malicious
content, or if an attacker can control the content:// URL,
causing malicious data to be loaded into the WebView.
Passing false to set AllowContentAccess, prevents the
WebView from opening content:// URLs, eliminating the
chance for exploitation. If access must be allowed, then it is
critical to ensure the content:// URL is not unsafely
influenced by attacker controlled input.
Local files within the app, can be accessed via file:// URLs by
default. This could potentially allow the loading of malicious
data into a WebView. If the attacker can influence the URL in
some way.
Depending on the context from which the request is made,
there are multiple settings which can disable the WebView’s
ability to access files.
Passing false to setAllowFileAccess prevents access to the
filesystem, with the exceptions of assets and resources via
file:///android_asset and file:///android_res. These paths
only should be used for non-sensitive data, such as images, so
if the app is constructed properly, this should generally be
safe.
There are two additional related methods which can control
the ability for a WebView to access file:// URLs:
setAllowFileAccessFromFileURLs and
setAllowUniversalAccessFromFileURLs.
Both methods take a single Boolean argument.
If the getter method (corresponding to the setter methods
above) for getAllowUniversalAccessFromFileURLs returns
true, the getAllowFileAccessFromFileURLs method’s return
value is ignored.
In Android 4.0.3 and below, the default returned value of
true, is unsafe for getAllowFileAccessFromFileURLs. This is
because it allows malicious JavaScript loaded in a WebView,
in a file URL context, to access any files from the filesystem
available via a file:// URL.
To be exploitable, an attacker would need to control which
file is loaded in the WebView and its contents.
The setAllowUniversalAccessFromFileURLs method controls
whether JavaScript, running in a file:// URL context, can
access content from any origin.
The default setting value of true, for Android 4.0.3 and below,
is unsafe. Because it would allow an attacker who controls a
file loaded in the WebView to access content from any other
domain loaded.
Older versions of Android allowed for the running of content-
specific plugins in WebViews, such as Flash players. The
plugin status was configurable via the setPluginState method.
This method offered three possible settings ON, OFF and
ON_DEMAND, which allowed clicking content to start the
plugin.
Plugins were deprecated in Android 4.3, but you may find this
setting in apps supporting older versions.
From a security perspective, if the plugins are not expressly
needed, they should be set to OFF to prevent any possible
exploitation. Luckily, OFF is the default setting.
OWASP (Open Web Application Security Project) is an
organization devoted to sharing information on application
security. As part of this effort, they publish frequent ranked
lists of most commonly found vulnerability classes.
While they do have a Mobile Top 10 list as well, we wanted to
stress the importance of the Web Top 10, where WebViews
are concerned.
Since WebViews are essentially browsers themselves, they
suffer from all the client-side security issues as browsers that
run as independent apps. In particular, you need to be
mindful of Cross-site Scripting issues (XSS) and Cross-site
Request Forgery (CSRF).
In addition to the specific configuration options we
mentioned previously, there are some other considerations
regarding XSS in apps.
The first, is that by default, WebViews have their own cookie
storage, separate from the rest of the application. Unless a
developer modifies this, an XSS will not have access to the
cookies used by the other parts of the app.
As a developer, you may also want to store local HTML
templates, which can be accessed from file:// URLs, rather
than loading everything remotely.
Not only does this speed up the app, but it changes the origin
in terms of the Same Origin Policy for Javascript, limiting the
potential damage an XSS may cause.
On a side note, if you do opt to use local HTML templates,
you should create a means to update them dynamically
(without the user having to download an updated app
version). This allows you to have the client automatically
request a new copy of the template, in case there is a
vulnerability discovered.
As you already know every application must be signed to
identify the application author and allow the developer to
update or edit his applications.
Also, applications signed with the same key can share the
same UID (User ID) and Application Sandbox.
While using the same UID may be useful to share data
between applications of the same author, if not properly
configured, this configuration may be dangerous. For
example, if two applications (A and B) share the same UID,
and the app B exposes a service, a receiver or it is vulnerable
to code execution, directory traversal, etc., B may be
exploited to access files of application A.
To share the same UID, applications must define the same
‘android:sharedUserId’ value in their manifests. Here for
example, the application A defines it as follow:
App A
In the same way, application B must declare the same
sharedUserID in its manifest. The following screenshot shows
the AndroidManifest.xml of the application B.
App B
The following code creates a new file named ‘myfile’ in the
application A sandbox.
APP A
Indeed if we navigate the application folder
/data/data/com.els.app.a/files, we can see that the file is
created with the following permissions.
The code (next slide) implemented in the application B,
simply opens the file at the path
‘/data/data/com.els.app.a/files/myfile’ and copies its content
in the TextView object defined in the application.
APP B
Since both applications share the UID, every file stored in the
application A folder, is accessible to application B and vice
versa. Indeed if we run app B, we are able to access the file
created by application A and read its content.
Here we can see that B is able to read the content of the file
stored in the application A context.
As you can imagine, if we delete the sharedUserID entry from
one of the two applications manifests, the application B is not
able to read the file anymore and we get a permission denied
error:
We have covered a lot of important material in this section.
Hopefully, you’re not feeling too overwhelmed at this point. If
so, take some time to re-read any sections that are unclear.
This section is the core to your understanding of how
Android applications function.
Once you feel you have a good grasp on the topics discussed,
you’ll be ready to build on the knowledge you’ve acquired so
far.
Litigation Apache Harmony
OpenJDK Android Manifest
Intent Intents Filter
Implicit Intent Uses Permission

Vulnerability Element
Local Broadcast
Context
Manager
Pending Intent
Deep Links
Vulnerability
AIDL Bound Services
IBinder Messenger
Bound Services
Static Code Analisys
Messenger
Binder Android IPC Mechanisms
BlackHat Europe - Binder Activity
Activity - setResult Services
Broadcast Receivers Content Provider
Provider Element Uses-permission
Normal Permission OWASP Top 10
WebViews Vulnerbility WebViewClient
WebChrome client XSS
WebSettings setJavaScriptEnabled
addJavascriptInterface JavaScript Bridge
Getter Mobile Top 10

Industrial Process

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Industrial Process

Uploaded by

Copyright:

Available Formats

6.

6.3 Deep Links

6.10 Share UID

In the above example, the Intent’s name is email, the Action

Keep in mind, that unless the permission you declare is

Here the new Intent() is what creates the empty and

Note: “this” is the Context.

OpenJDK Android Manifest

Intent Intents Filter

Implicit Intent Uses Permission

AIDL Bound Services

Binder Android IPC Mechanisms

BlackHat Europe - Binder Activity

Activity - setResult Services

Provider Element Uses-permission

Normal Permission OWASP Top 10

WebViews Vulnerbility WebViewClient

addJavascriptInterface JavaScript Bridge

Getter Mobile Top 10

You might also like