OWASP MSTG Alpha - Release PDF
OWASP MSTG Alpha - Release PDF
OWASP MSTG Alpha - Release PDF
SECURITY GUIDE
Project by:
Jonathan Carter and Milan Singh Thakur
Index
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.
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.
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:
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
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
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
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
Ref:
http://developer.android.com/reference/android/telephony/TelephonyManager.html#getLine1Number
%28%29
https://mobiforge.com/design-development/useful-x-headers
POC/Example Screenshot:
16
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.
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