Professional Documents
Culture Documents
sensitive data)
Native code execution
Ability of user to protect the device and lost device scenarios
Application licensing
Insufficient authorization from mobile client to back-end systems
Session hijacking
Security of device backup mechanisms
Introduction
A major priority of the OWASP Mobile Security Project is to help standardize and disseminate
mobile application testing methodologies. While specific techniques exist for individual platforms,
a general mobile threat model can be used to assist test teams in creating a mobile security
testing methodology for any platform. The outline which follows describes a general mobile
application testing methodology which can be tailored to meet the security testers needs. It is
high level in some places, and over time will be customized on a per-platform basis.
This guide is targeted towards application developers and security testers. Developers can
leverage this guide to ensure that they are not introducing the security flaws described within the
guide. Security testers can use it as a reference guide to ensure that they are adequately
assessing the mobile application attack surface. The ideal mobile assessment combines dynamic
analysis, static analysis, and forensic analysis to ensure that the majority of the mobile
application attack surface is covered.
On some platforms, it may be necessary to have root user or elevated privileges in order to
perform all of the the required analysis on devices during testing. Many applications write
information to areas that cannot be accessed without a higher level of access than the standard
shell or application user generally has. For steps that generally require elevated privileges, it will
be stated that this is the case.
This guide is broken up into three sections:
Information Gathering- describes the steps and things to consider when you are in the
early stage reconnaissance and mapping phases of testing as well as determining the
applications magnitude of effort and scoping.
Static Analysis- Analyzing raw mobile source code, decompiled or disassembled code.
As this guide is not platform specific, you will need to know the appropriate techniques & tools for
your target platform. The OWASP Mobile Security Project has also developed a number of other
supporting resources which may be able to be leveraged for your needs.
In this current draft release, the guide is a work in progress. We need additional
contributors to help fill in the blanks. If you think something is missing (there certainly is),
add it.
As this guide is not platform specific, you will need to know the appropriate techniques & tools for
your target platform. The OWASP Mobile Security Project has also developed a number of other
supporting resources which may be able to be leveraged for your needs,
The steps required to properly test an Android application are very different than those of testing
an iOS application. Likewise, Windows Phone is very different from the other platforms. Mobile
security testing requires a diverse skillset over many differing operating systems and a critical
ability to analyze various types of source code.
In many cases, a mobile application assessment will require coverage in all three areas identified
within this testing reference. A dynamic assessment will benefit from an initial thorough attempt at
Information Gathering, some level of static analysis against the applications binary, and a
forensic review of the data created and modified by the applications runtime behavior.
Please use this guide in an iterative fashion, where work in one area may require revisiting
previous testing steps. As an example, after completing a transaction you may likely need to
perform additional forensic analysis on the device to ensure that sensitive data is removed as
expected and not cached in an undesired fashion. As you learn more about the application at
runtime, you may wish to examine additional parts of the code to determine the best way to
evade a specific control. Likewise, during static analysis it may be helpful to populate the
application with certain data in order to prove or refute the existence of a security flaw.
In the future, contributors to the testing guide should consider adding entries under each section
relevant to a specific platform. Over time, OWASP contributors will write platform specific guides
and expand upon this body of knowledge.
If a specific area of interest is not covered in this guide, please feel free to either:
write the material yourself by registering for a wiki account and contributing content: Wiki
Registration
bring this up as a topic on the Mobile Projects mailing list: Mobile Mailing List
Collaboration on building the guide is being performed within Google Docs. You can find the
latest and greatest material here: Testing Guide Google Doc
Information Gathering
As a result of this initial information gathering exercise, the tester will be better prepared for the
future testing phases. Testers, Developers and Security people often fail to take the time to learn
the target application and supporting infrastructure, opting to dive in blind, possibly losing
valuable time and missing possible attack vectors. Without a solid understanding of how the
application should work as well as the technologies in use, the tester will not be able to identify
when the application behaves in a manner that it shouldnt.
Prerequisites of this phase may require specific operating systems, platform specific software
development kits (SDKs), rooted or jailbroken devices, the ability to man-in-the-middle secure
communications (i.e. HTTPS) and bypass invalid certificate checks.
Manually navigate through the running application to understand the basic functionality
and workflow of the application. This can be performed on a real device or within a
simulator/emulator. For deeper understanding of application functionality tester can proxy
and sniff all network traffic from either a physical mobile device or an emulator/simulator
recording and logging traffic (if your proxy tool permits logging, which most should).
Determine what the application supports for access 3G, 4G, wifi and or others
Make note for future phases to determine does the application store payment
information? How is payment information secured?
Monitor and identify the hardware components that the application may potentially
interact with
NFC
Bluetooth
GPS
Camera
Microphone
Sensors
USB
Perform open source intelligence gathering (search engines, source code repositories,
developer forums, etc.) to identify source code or configuration information that may be
exposed (i.e. 3rd party components integrated within the application)
Identify if the application appears to interact with any other applications, services, or data
such as:
Contacts
Google Wallet
iCloud
Dropbox
Evernote
Etc.
Can you determine anything about the server side application environment?
Payment gateways
SMS messaging
Social networks
Ad networks
Perform a thorough crawl of exposed web resources and sift through the requests and
responses to identify potentially interesting data or behavior
Error messages
Cacheable information
Static Analysis
There are two primary ways static analysis will generally be performed on a mobile application:
1. Analyzing source code obtained from development team (prefered)
2. Using a compiled binary.
Some level of static analysis should be performed for both dynamic and forensic analysis, as the
applications code will almost always provide valuable information to the tester (i.e. logic,
backend targets, APIs, etc).
In scenarios where the primary goal is to identify programmatic examples of security flaws, your
best bet is to review pure source code as opposed to reverse engineering compiled software. For
source code reviews, it is highly beneficial to have access to either a development or production
instance of any web services. This includes both source code and a working test environment to
perform the assessment within in order to expedite understanding of the code.
Getting Started
If the source is not directly available, decompile or disassemble the applications binary
follow the appropriate steps for your platforms application reverse engineering
some applications may also require decryption prior to reverse engineering (note:
decryption and code obfuscation are not the same thing)
Review the permissions the application requests as well as the resources that it is
authorized to access (i.e. AndroidManifest.xml, iOS Entitlements or Windows Phone's
WMAppManifest.xml)
Are there any easy to identify misconfigurations within the application found within the
configuration files? Debugging flags set, world readable/writable permissions, etc.
What frameworks are in use? Is the application built using a cross-platform framework?
Identify the libraries in use including both platform provided as well as third party. Perform
a quick review on the web to determine if these libraries:
are up to date
native code
Does the application check for rooted/jailbroken devices? How is this done? How can this
Determine what types of objects are implemented to create the various views within the
application. This may significantly alter your test cases, as some views implement web
browser functionality while others are native UI controls only.
Is all code expected to run within the platforms standard runtime environment, or are
some files/libraries dynamically loaded or called outside of that environment at runtime?
Attempt to match up every permission that the application requests with an actual
concrete implementation of it within the application. Often, developers request more
permission than they actually need. Identify if the same functionality could be enabled with
lesser privileges.
Locate hard coded secrets within the application such as API keys, credentials, or
proprietary business logic.
Identify every entry point for untrusted data entry and determine how it enforces access
controls, validates and sanitizes inbound data, and passes the data off to other interpreters
Authentication
Locate the code which handles user authentication through the UI. Assess the possible
methods of user impersonation via vectors such as parameter tampering, replay attacks, and
brute force attacks.
certificates
tokens
Does the application utilize visual swipe or touch passwords vs. conventional usernames
and passwords?
Does the application implement functionality that permits inbound connections from other
devices? (i.e.- Wi-Fi Direct, Android Beam, network services)
Does the application properly authenticate the remote user or peer prior to
granting access to device resources?
OAuth
Google Apps
SMS
password
header information
Other mechanism?
Are one time passwords (OTP) used or is other sensitive account data
transmitted via SMS?
Push Notifications
If the application consumes information via push notifications, how does the
application verify the identity of the sender?
Authorization
Identify if the application has role specific functionality within the mobile
application
Locate any potential flags or values that may be set on the client from any
untrusted source that can be a point of privilege elevation such as
databases
flat files
HTTP responses
Find places within an application that were not anticipated being directly
accessed without following the applications intended workflow
Licensing
Does the code suggest that licensed content is served with a non-licensed app
but restricted by UI controls only?
Session Management
Is sensitive information utilized within the application flushed from memory upon session
expiration?
Data Storage
Encryption
Are the algorithms used best of breed or do they contain known issues?
How are keys managed and stored on the device? Can this reduce the
complexity in breaking the encryption?
Identify if the application utilizes storage areas external to the sandboxed locations to
store unencrypted data such as:
Places with limited access control granularity (SD card, tmp directories, etc.)
Credentials
API keys
Authentication tokens
Payment information
Patient data
Signature files
Is sensitive information written to data stores via platform exposed APIs such as
contacts?
Information Disclosure
Logs
How are the logs accessed, if so, and by which mechanism/functionality? Is log
access protected?
Is the device identifier sent that could be used to identify the user? (i.e.UDID in
Apple devices)
Caches
Predictive text
Location information
Application snapshot
Browser cache
Non-standard cache locations (i.e the various SQLite databases that apps can
create if they use HTML UI components)
Exceptions
Can their runtime behavior expose users to privacy issues and unauthorized
tracking?
Identify places where the application passes untrusted data into a web view or
browser
Determine if the application properly output encodes or sanitizes the data within
the appropriate context
Where the application permits usage of the shell, identify the entry points to
manipulate or alter the commands via user input or external untrusted data
CSRF
SQL Injection
Cookies
HTML5
Networking
Are insecure protocols used to send or receive sensitive information? Examples- FTP,
SNMP v1, SSH v1
Are there any known issues with the specific libraries you are using to implement the
protocol?
The remote destination information matches the information within the certificate?
Are certificates validated only by the operating system or also by the application that
relies on it?
Identify if code exist to alter the behavior for traffic transiting different interfaces (i.e.3G/4G comms vs. Wi-Fi)? If so, is encryption applied universally across each of them
Dynamic Analysis
Armed with data collected during the Information Gathering and Static Analysis phases, the
tester can begin an informed vulnerability assessment of the mobile application client, server and
associated services.
Dynamic analysis is conducted against the backend services and APIs and the type of tests
varies depending on mobile application type.
Application Types
Native Mobile Application: Native mobile applications can be installed on to the device.
This type of applications generally store most of their code on the device. Any information
required can be requested to the server using the HTTP/s protocol
Web services for Mobile Application: Native mobile application that uses SOAP or REST
based web services to communicate between client and Server
Mobile Browser Based Application: Web browser based applications can be accessed
using devices browsers such as Safari or Chrome. Most of the commercial applications are
nowadays specifically designed and optimized for mobile browsers. These applications are
no different than traditional web application and all the web application vulnerabilities apply
to these apps and these should be tested as traditional web apps.
In this phase, the mobile client, backend services, and host platform is analyzed/scanned in
attempt to uncover potential risks, vulnerabilities and threats. The use of an intercepting proxy
tool as well as automated vulnerability scanners are core to this phase. In many cases, you will
also need some type of shell access to the device.
The following outline can be used as a Dynamic Analysis guide in planning a mobile
assessment.
Establishing a Baseline
Application interactions with the host file system must be reviewed and analyzed
at various stages of testing; starting with baseline capture. This may require a shell or
GUI depending on platform and/or preference.
Manually inspect the file system to determine what files/databases were created,
what and how data is stored. Did the application store sensitive data unencrypted or
trivially protected (i.e. encoded)?
Debugging
Active Testing
Local Testing
Sniff
Fuzz
Cryptography
Attempt to reconstruct encrypted data through recovery of keys, hardcoded secrets, and
any other information exposed by the application
Web Applications
Is it possible to inject client side code (i.e. JavaScript) or HTML into the
application to either modify the inner working of the application or it's user interface?
CSRF
SQL Injection
Cookies
Are cookies issued by a server secured by using the HTTP-only and Secure flag?
HTML5 Storage
Authentication
NFC
SMS
Push notifications
Across IPC channels (identify the calling applications privileges and identity)
Authorization
Utilize forensic tools to determine if deleted data can be recovered from the filesystem as
well as within databases
Memory Analysis
Determine if sensitive information persists within memory after performing the following
actions:
Analyze (monitor traffic) how each method performs authentication. Note target wifi as
this is a common area where authentication can be weak. Ensure authentication is robust
and not based on trivial attributes (i.e. MDN, ESN, etc).
Verify that authentication tokens are terminated after a user initiates a password reset
SMS Based
Push Notifications
Licensing
Authorization
Session Management
Entropy analysis
Privilege Escalation
Man-in-the-middle attacks
Eavesdropping
Cross-Site Scripting
SQL Injection
XML Bombs
Buffer overflow
Open Redirect
Based on prior phases you should have 1 or more target servers (i.e. URLs) as
candidates for automated vulnerability scanning. Mobile applications often leverage existing
web services/applications (i.e. hybrid applications) which must be tested for security
vulnerabilities.
Conclusion
Mobile applications are continuing to mature and evolve thus to be effective, security testers
must strive to advance their knowledge and skills. Please check back periodically for updates
and share your feedback with us.