Difference between revisions of "OWASP Mobile Security Project"

Please visit the project page for current information.

About this list

In 2013, we polled the industry for new vulnerability statistics in the field of mobile applications. What you see here is a result of that data and a representation of the mobile application threat landscape.

Our goals for the 2014 list included the following:

• Updates to the wiki content; including cross-linking to testing guides, more visual exercises, etc;
• Generation of more data; and
• A PDF release.

This list has been finalized after a 90-day feedback period from the community. Based on feedback, we intend on releasing a Mobile Top Ten 2015 list following a similar approach of collecting data, grouping the data in logical and consistent ways.

Feel free to visit the mailing list as well!

Call to Action for 2015

We are currently looking for vendors, consultants, or other industry experts within the appsec community that are willing to participate in the OWASP Mobile Top Ten 2015. Participation could include any of the following: gathering data, promoting awareness, etc.

We have published a Call for Data document and have also (in the name of transparency) published a document which lists which entities/vendors/individuals/etc that we have reached out to. These requests were made because we know these entities to be thought leaders in the mobile application space. If we missed you, and you have data or feedback to contribute, we apologize. Please email one of us!

Top 10 Mobile Risks - Final List 2014

• M1: Weak Server Side Controls
• M2: Insecure Data Storage
• M3: Insufficient Transport Layer Protection
• M4: Unintended Data Leakage
• M5: Poor Authorization and Authentication
• M6: Broken Cryptography
• M7: Client Side Injection
• M8: Security Decisions Via Untrusted Inputs
• M9: Improper Session Handling
• M10: Lack of Binary Protections

Project Leads, Credit, and Contributions

• Mobile Top Ten Contributions Page

Project Methodology

• We adhered loosely to the OWASP Web Top Ten Project methodology.

Archive

• The list below is the OLD release candidate v1.0 of the OWASP Top 10 Mobile Risks.  This list was initially released on September 23, 2011 at Appsec USA.  
  • The original presentation can be found here: SLIDES
    
  • The corresponding video can be found here: VIDEO
  • 2011-12 Mobile Top Ten for archive purposes

iMAS

iMAS is a collaborative research project from the MITRE Corporation focused on open source iOS security controls. Today, iOS meets the enterprise security needs of customers, however many security experts cite critical vulnerabilities and have demonstrated exploits, which pushes enterprises to augment iOS deployments with commercial solutions. The iMAS intent is to protect iOS applications and data beyond the Apple provided security model and reduce the adversary’s ability and efficiency to perform recon, exploitation, control and execution on iOS mobile applications. iMAS will transform the effectiveness of the existing iOS security model across major vulnerability areas including the System Passcode, jailbreak, debugger / run-time, flash storage, and the system keychain. Research outcomes include an open source secure application framework, including an application container, developer and validation tools/techniques.

iMas Project Page

The source code for iMAS is available on GitHub: iMAS Source Code

GoatDroid

OWASP GoatDroid is a fully functional and self-contained training environment for educating developers and testers on Android security. GoatDroid requires minimal dependencies and is ideal for both Android beginners as well as more advanced users. The project currently includes two applications: FourGoats, a location-based social network, and Herd Financial, a mobile banking application. There are also several features that greatly simplify usage within a training environment or for absolute beginners who want a good introduction to working with the Android platform.

As the Android SDK introduces new features, the GoatDroid contributors will strive to implement up-to-date lessons that can educate developers and security testers on new security issues. The project currently provides coverage for most of the OWASP Top 10 Mobile Risks and also includes a bunch of other problems as well.

You can find GoatDroid on GitHub: GoatDroid Source Code

GoatDroid Project Page

iGoat

iGoat is a learning tool for iOS developers (iPhone, iPad, etc.). It was inspired by the WebGoat project, and has a similar conceptual flow to it.

As such, iGoat is a safe environment where iOS developers can learn about the major security pitfalls they face as well as how to avoid them. It is made up of a series of lessons that each teach a single (but vital) security lesson.

The lessons are laid out in the following steps:

1. Brief introduction to the problem.
2. Verify the problem by exploiting it.
3. Brief description of available remediations to the problem.
4. Fix the problem by correcting and rebuilding the iGoat program.

Step 4 is optional, but highly recommended for all iOS developers. Assistance is available within iGoat if you don't know how to fix a specific problem.

iGoat is free software, released under the GPLv3 license.

iGoat Project Page

The iGoat source code is available on Google Code iGoat Source Code

Damn Vulnerable iOS Application

Damn Vulnerable iOS application is a project started by Prateek Gianchandani which gives mobile testers and developers an iOS application to practice attacking/defending skill sets. Each challenge area corresponds to an in-depth article designed to teach the fundamentals of mobile security on the iOS platform. Some challenge categories include multiple challenge types.

The current challenge categories:

• Insecure Data Storage (4 exercises)
• Jailbreak Detection (2 exercises)
• Runtime Manipulation (3 exercises)
• Transport Layer Security (1 exercise)
• Client Side Injection (1 exercise)
• Broken Cryptography (1 exercise)
• Binary Patching (4 exercises)

DVIA Home Page

DVIA OWASP Project Page

DVIA Github Source

DVIA Learning Resources

MobiSec

The MobiSec Live Environment Mobile Testing Framework project is a live environment for testing mobile environments, including devices, applications, and supporting infrastructure. The purpose is to provide attackers and defenders the ability to test their mobile environments to identify design weaknesses and vulnerabilities. The MobiSec Live Environment provides a single environment for testers to leverage the best of all available open source mobile testing tools, as well as the ability to install additional tools and platforms, that will aid the penetration tester through the testing process as the environment is structured and organized based on an industry­‐proven testing framework. Using a live environment provides penetration testers the ability to boot the MobiSec Live Environment on any Intel-­based system from a DVD or USB flash drive, or run the test environment within a virtual machine.

Project Page

MobiSec can be downloaded from Sourceforge: MobiSec Download Repository

Androick

Androick is a collaborative research project from PHONESEC Ltd. With our tool, you can evaluate some risks on Android mobile applications. Androick is a tool that allows any user to analyze an Android application. It can get the apk file, all the datas and the databases in sqlite3 and csv format. Only for Pentesters or Researchers.

Androick Project Page

NowSecure App Testing Community Edition

The NowSecure App Testing Community Edition is the freely downloadable version of the powerful App Testing suite. Users are offered a number of features such as network capture, automation, import / export, and reporting to test and secure mobile apps.

It provides the opportunity to complete mobile app security tests on any application on Android or iOS mobile devices (or installed in an emulator).

The suite is provided as a preconfigured virtual machine (VM). After downloading the VM and licensing your version of the suite you will have everything you need to test the security of mobile apps.

Built in emulator - Don’t have a device? No worries. The suite includes a built in Emulator that may be used to test the security of your mobile applications.

NowSecure App Testing Suite

OWASP Summer of Code 2008

The OWASP Foundation sponsored the OWASP Application Security Verification Standard Project during the OWASP Summer of Code 2008.

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 tester’s 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 application’s 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 application’s local interprocess communication surface, forensic analysis of the local filesystem, 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.

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 application’s binary, and a forensic review of the data created and modified by the application’s 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 Project’s 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 “shouldn’t”.

Prerequisites of this phase may require specific operating systems, platform specific software development kits (SDK’s), 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).

• Identify the networking interfaces used by the application, for instance:
  • Mobile Communication (GSM, GPRS, EDGE, LTE)
  • Wireless (Wi-Fi (802.11 standards), Bluetooth, NFC)
  • Virtual Interfaces (i.e. VPN)

• Determine what the application supports for access 3G, 4G, wifi and or others

• What networking protocols are in use?
  • Are secure protocols used where needed?
  • Can they be switched with insecure protocols?

• Does the application perform commerce transactions?
  • Credit card transactions and/or stored payment information (certain industry regulations may be required (i.e. PCI DSS)).
  • In-app purchasing of goods or features
  • 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)

• What frameworks are in use?

• Identify if the application appears to interact with any other applications, services, or data such as:
  • Telephony (SMS, phone)
  • Contacts
  • Auto correct / dictionary services
  • Receiving data from apps and other on-device services
  • Google Wallet
  • iCloud
  • Social networks (i.e. Facebook, Twitter, LinkedIn, Google+)
  • Dropbox
  • Evernote
  • Email
  • Etc.

• Can you determine anything about the server side application environment?
  • Hosting provider (AWS, App Engine, Heroku, Rackspace, Azure, etc.)
  • Development environment (Rails, Java, Django, ASP.NET, etc.)
  • Does the application leverage Single Sign On or Authentication APIs (Google Apps, Facebook, iTunes, OAuth, etc.)
  • Any other APIs in use
    • Payment gateways
    • SMS messaging
    • Social networks
    • Cloud file storage
    • Ad networks

• Perform a thorough crawl of exposed web resources and sift through the requests and responses to identify potentially interesting data or behavior
  • Leaking sensitive information (i.e. credentials) in the response
  • Resources not exposed through the UI
  • 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 application’s 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 application’s binary
  • extract the application from the device
  • follow the appropriate steps for your platform’s 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
  • are free of vulnerabilities
  • expose functionality that requires elevated privileges (access to location or contact data)
  • native code

• Does the application check for rooted/jailbroken devices? How is this done? How can this be circumvented? Is it as easy as changing the case of a file name or name of executable or path?

• 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 platform’s 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
  • From web service calls
  • Receiving data from other apps and on-device services
  • Inbound SMS messages
  • Reading information from the filesystem

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.

• Determine if the application utilizes information beyond username/password such as
  • contextual information (i.e.- device identifiers, location)
  • certificates
  • tokens

• Does the application utilize visual swipe or touch passwords vs. conventional usernames and passwords?
  • Assess the method of mapping the visual objects to an authentication string to determine if adequate entropy exists

• 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?
  • How does the application handle excessive failed attempts at authentication?
  • are failed attempts logged?
  • what mechanisms exist to inform the user of a potential attack?

• Single Sign On, e.g.
  • OAuth
  • Facebook
  • Google Apps

• SMS
  • How is the sender authenticated?
    • password
    • header information
    • Other mechanism?
  • Are one time passwords (OTP) used or is other sensitive account data transmitted via SMS?
    • Can other applications access this data?

• Push Notifications
  • If the application consumes information via push notifications, how does the application verify the identity of the sender?

Authorization

• Review file permissions for files created at runtime

• Determine if it is possible to access functionality not intended for your role

• • 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 application’s intended workflow

• Licensing
  • Can licensing checks be defeated locally to obtain access to paid-for data resources? (i.e.- patching a binary, modifying it at runtime, or by modifying a local configuration file)
  • Does the code suggest that licensed content is served with a non-licensed app but restricted by UI controls only?
  • Are licensing checks performed properly by the server or platform licensing services?
  • How does the application detect and respond to tampering?
    • Are alerts sent to and expected by the developer?
    • Does the application fail open or fail closed?
    • Does the application wipe its data?

Session Management

• Ensure that sessions time out locally as well as server side

• 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 derived from i.e. a password?
  • Based on the algorithms and approaches used to encrypt data, do implementation issues exist that degrade the effectiveness of encryption?
  • 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.)
  • Directories that may end up in backups or other undesired locations (iTunes backup, external storage, etc.)
  • Cloud storage services such as Dropbox, Google Drive, or S3

• Does the application write sensitive information to the file system at any point, such as:
  • Credentials
    • Username and/or password
    • 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
  • Does the application log data? Is sensitive information accessible?
  • How are the logs accessed, if so, and by which mechanism/functionality? Is log access protected?
  • Can any of the logged information be considered a privacy violation?
  • Is the device identifier sent that could be used to identify the user? (i.e.UDID in Apple devices)

• Caches
  • Predictive text
  • Location information
  • Copy and paste
  • 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
  • Does sensitive data leak in crash logs?

• Third Party Libraries and APIs
  • What permissions do they require?
  • Do they access or transmit sensitive information?

Review licensing requirements for any potential violations.

• • Can their runtime behavior expose users to privacy issues and unauthorized tracking?

Web Application Issues

• XSS and HTML Injection
  • 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
• Command Injection (if the application utilizes a shell)
  • 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
  • Determine if an attacker can inject arbitrary commands or manipulate the intended command in any way
• 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?

Transport Layer Protection

• Does the application properly implement Certificate Pinning?

• Are certificates validated to determine if:
  • The certificate has not expired
  • The certificate was issued by a valid certificate authority
  • 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

Helpful Search Strings and Regular Expressions

-To do

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 device’s 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.

• Mobile Hybrid Applications:Applications can leverage web browser functionality within native applications, blending the risks from both classes of applications.

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

• Generate File System Baseline Fingerprint (before app installation)
  • 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.

• Install, Configure and Use the Application
  • 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)?
  • Generally, pay attention to credentials, payment information, or other highly sensitive information being saved to the device. Also take a look at databases, log files, predictive text caches, and crash logs.

Debugging

• Attach a debugger to an application to step through code execution and setting breakpoints at interesting code within the application

• Monitor logged messages and notifications generated at runtime

• Observe interprocess communications between the target application and other applications and services running on the mobile device.

Active Testing

Local Testing

• Exposed IPC interfaces
  • Sniff
  • Fuzz
  • Bypass authorization checks

Cryptography

• Brute force attacks against keys, pins, and hashes
• Attempt to reconstruct encrypted data through recovery of keys, hardcoded secrets, and any other information exposed by the application

Web Applications

• XSS and HTML Injection
  • 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?

• Command Injection (if the application utilizes a shell)

• CSRF

• SQL Injection

• Cookies
  • Are cookies issued by a server secured by using the HTTP-only and Secure flag?
  • Is there any sensitive information stored in the cookies?

• HTML5 Storage

Authentication

• Assess the methods an application uses to authenticate peers
  • NFC
  • SMS
  • Push notifications
  • Across IPC channels (identify the calling application’s privileges and identity)

Authorization

• Instrument, patch, or interact with application at runtime to bypass methods intended to prevent usage of privileged or premium features

• Determine if configuration or locally stored data can be manipulated in order to elevate a user’s privileges

• Check the filesystem permissions for any files created at runtime

File System Analysis

• Assess the application’s behavior throughout it’s lifecycle to determine if special functionality is triggered to persist an application’s state when it enters different stages:
  • Placed into the foreground
  • Sent into the background
  • Upon exiting the application

• Data storage in Cache

• Looking for artifacts left on device

• Unencrypted data storage on the device

• Encryption of data in backups

• Username/password, or app-specific unique device id stored on the device

• Application Permissions , Privileges and Access controls on the device

• Generally, pay attention to credentials, payment information, or other highly sensitive information being saved to the device. Also take a look at log files, predictive text caches, and crash logs.

• Is sensitive information cached within the application’s UI back stack?

• 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:
  • Logging out of the application
  • Transition between UI components

• Is it possible to obtain encryption keys, credentials, payment information and other sensitive information by dumping device or application memory?

Remote Application/Service Testing

Authentication

• What methods are available (3G, 4G, Wifi, etc)?

• What happens if the remote authentication service becomes unavailable?

• Assess strength of password requirements

• Test how account lockouts are implemented

• 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

• Single Sign On (SSO)

• SMS Based
  • One Time Passwords (OTP)
  • Two Factor Authentication

• Push Notifications

• Licensing

Authorization

• What happens if the remote authorization handling service becomes unavailable?

• Test if direct access to backend resources is possible

• Access controls to server side resources not enforced

• Vertical and horizontal privilege escalation

Session Management

• Entropy analysis
• Device identifier related?
• Are session tokens refreshed between logouts?
• Lifetime and expiration
• Handling the session token on the device (stored, in memory, etc.)
• Privilege Escalation
• Ineffective Session Termination

Transport Layer Testing

• Man-in-the-middle attacks
• Eavesdropping
• SSL checks (cypher strengths/weakness etc.)

Server Side Attacks

• Triggering unhandled exceptions
• Cross-Site Scripting
• SQL Injection
• XML Bombs
• Buffer overflow
• Unrestricted File Upload
• Open Redirect

Server, Network & Application Scanning

• 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.

Mobile Cheat Sheet Series

Cheat sheets provide the information most relevant to a developer or security engineer with minimal "fluff". The goal of the project is to build a collection of cheat sheets that provide actionable, useful, and straight to the point guidance for a plethora of mobile security issues.

Platform Agnostic

Mobile Jailbreaking Cheat Sheet

Android

iOS

• iOS Developer Cheat Sheet
• iOS Application Security Testing Cheat Sheet

Windows Phone

RIM

Secure Mobile Development Guidelines Objective

The OWASP Secure Development Guidelines provides developers with the knowledge they need to build secure mobile applications. An extendable framework will be provided that includes the core security flaws found across nearly all mobile platforms. It will be a living reference where contributors can plug in newly exposed APIs for various platforms and provide good/bad code examples along with remediation guidance for those issues.

Mobile Application Coding Guidelines

The purpose of this section is to provide application developers guidelines on how to build secure mobile applications, given the differences in security threat between applications running on a typical desktop as compared to those running on a mobile device (such as tablets or cell phones).

Using the guidance provided here, developers should code their applications to mitigate these malicious attacks. While more general coding guidelines should still be followed as applicable, this page lists additional considerations and/or modifications to common guidelines and is written using the best knowledge available at this time.

Authentication and Password Management

This is a set of controls used to verify the identity of a user, or other entity, interacting with the software, and also to ensure that applications handle the management of passwords in a secure fashion.

1. Instances where the mobile application requires a user to create a password or PIN (say for offline access), the application should never use a PIN but enforce a password which follows a strong password policy.
2. Mobile devices may offer the possibility of using password patterns which are never to be utilized in place of passwords as sufficient entropy cannot be ensured and they are easily vulnerable to smudge-attacks.
3. Mobile devices may also offer the possibility of using biometric input to perform authentication which should never be used due to issues with false positives/negatives, among others.
4. Wipe/clear memory locations holding passwords directly after their hashes are calculated.
5. Based on risk assessment of the mobile application, consider utilizing two-factor authentication.
6. For device authentication, avoid solely using any device-provided identifier (like UID or MAC address) to identify the device, but rather leverage identifiers specific to the application as well as the device (which ideally would not be reversible). For instance, create an app-unique “device-factor” during the application install or registration (such as a hashed value which is based off of a combination of the length of the application package file itself, as well as the current date/time, the version of the OS which is in use, and a randomly generated number). In this manner the device could be identified (as no two devices should ever generate the same “device-factor” based on these inputs) without revealing anything sensitive. This app-unique device-factor can be used with user authentication to create a session or used as part of an encryption key.
7. In scenarios where offline access to data is needed, add an intentional X second delay to the password entry process after each unsuccessful entry attempt (2 is reasonable, also consider a value which doubles after each incorrect attempt).
8. 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).
9. When utilizing a hashing algorithm, use only a NIST approved standard such as SHA-2 or an algorithm/library.
10. Salt passwords on the server-side, whenever possible. The length of the salt should at least be equal to, if not bigger than the length of the message digest value that the hashing algorithm will generate.
11. Salts should be sufficiently random (usually requiring them to be stored) or may be generated by pulling constant and unique values off of the system (by using the MAC address of the host for example or a device-factor; see 3.1.2.g.). Highly randomized salts should be obtained via the use of a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). When generating seed values for salt generation on mobile devices, ensure the use of fairly unpredictable values (for example, by using the x,y,z magnetometer and/or temperature values) and store the salt within space available to the application.
12. Provide feedback to users on the strength of passwords during their creation.
13. Based on a risk evaluation, consider adding context information (such as IP location, etc…) during authentication processes in order to perform Login Anomaly Detection.
14. Instead of passwords, use industry standard authorization tokens (which expire as frequently as practicable) which can be securely stored on the device (as per the OAuth model) and which are time bounded to the specific service, as well as revocable (if possible server side).
15. Integrate a CAPTCHA solution whenever doing so would improve functionality/security without inconveniencing the user experience too greatly (such as during new user registrations, posting of user comments, online polls, “contact us” email submission pages, etc…).
16. Ensure that separate users utilize different salts.

Code Obfuscation

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.

1. Abstract sensitive software within static C libraries.
2. Obfuscate all sensitive application code where feasible by running an automated code obfuscation program using either 3rd party commercial software or open source solutions.
3. For applications containing sensitive data, implement anti-debugging techniques (e.g. prevent a debugger from attaching to the process; android:debuggable=”false”).
4. 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).
5. 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 application’s memory.

Communication Security

This is a set of controls to help ensure the software handles the sending and receiving of information in a secure manner.

1. Assume the provider network layer is insecure. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee a Wi-Fi network (if in-use by the mobile device) will be appropriately encrypted.
2. Ensure the application actually and properly validates (by checking the expiration date, issuer, subject, etc…) the server’s SSL certificate (instead of checking to see if a certificate is simply present and/or just checking if the hash of the certificate matches). To note, there are third party libraries to assist in this; search on “certificate pinning”.
3. The application should only communicate with and accept data from authorized domain names/systems. It is permissible to allow application updates which will modify the list of authorized systems and/or for authorized systems to obtain a token from an authentication server, present a token to the client which the client will accept.
4. To protect against attacks which utilize software such as SSLStrip, implement controls to detect if the connection is not HTTPS with every request when it is known that the connection should be HTTPS (e.g. use JavaScript, Strict Transport Security HTTP Header, disable all HTTP traffic).
5. The UI should make it as easy as possible for the user to find out if a certificate is valid (so the user is not totally reliant upon the application properly validating any certificates).
6. When using SSL/TLS, use certificates signed by trusted Certificate Authority (CA) providers.

Data Storage and Protection

This is a set of controls to help ensure the software handles the storing and handling of information in a secure manner. Given that mobile devices are mobile, they have a higher likelihood of being lost or stolen which should be taken into consideration here.

1. Only collect and disclose data which is required for business use of the application. Identify in the design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each data type.
2. Classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs, etc.). Process, store and use data according to its classification
3. Store sensitive data on the server instead of the client-end device, whenever possible. Assume any data written to device can be recovered.
4. Beyond the time required by the application, don’t store sensitive information on the device (e.g. GPS/tracking).
5. Do not store temp/cached data in a world readable directory. Assume shared storage is untrusted.
6. Encrypt sensitive data when storing or caching it to non-volatile memory (using a NIST approved encryption standard such as AES-256, 3DES, or Skipjack).
7. Use the PBKDF2 function to generate strong keys for encryption algorithms while ensuring high entropy as much as possible. The number of iterations should be set as high as may be tolerated for the environment (with a minimum of 1000 iterations) while maintaining acceptable performance.
8. Sensitive data (such as encryption keys, passwords, credit card #’s, etc…) should stay in RAM for as little time as possible.
9. Encryption keys should not remain in RAM during the instance lifecycle of the app. Instead, keys should be generated real time for encryption/decryption as needed and discarded each time.
10. 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 limit the impact of attacks such as buffer overflows.
11. Do not store sensitive data in the keychain of iOS devices due to vulnerabilities in their cryptographic mechanisms.
12. Ensure that sensitive data (e.g. passwords, keys etc.) are not visible in cache or logs.
13. Never store any passwords in clear text within the native application itself nor on the browser (e.g. save password feature on the browser).
14. When displaying sensitive information (such as full account numbers), ensure that the sensitive information is cleared from memory (such as from the webView) when no longer needed/displayed.
15. Do not store sensitive information in the form of typical strings. Instead use character arrays or NSMutableString (iOS specific) and clear their contents after they are no longer needed. This is because strings are typically immutable on mobile devices and reside within memory even when assigned (pointed to) a new value.
16. Do not store sensitive data on external storage like SD cards if it can be avoided.
17. Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet app not usable if GPS data shows phone is outside Europe, car key not usable unless within 100m of car etc...).
18. Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier, use a randomly generated number instead.
19. Make use of remote wipe and kill switch APIs to remove sensitive information from the device in the event of theft or loss.
20. Use a time based (expiry) type of control which will wipe sensitive data from the mobile device once the application has not communicated with its servers for a given period of time.
21. Automatic application shutdown and/or lockout after X minutes of inactivity (e.g. 5 mins of inactivity).
22. Avoid cached application snapshots in iOS: iOS can capture and store screen captures and store them as images when an application suspends. To avoid any sensitive data getting captured, use one or both of the following options: 1. Use the ‘willEnterBackground’ callback, to hide all the sensitive data. 2. Configure the application in the info.plist file to terminate the app when pushed to background (only use if multitasking is disabled).
23. Prevent applications from being moved and/or run from external storage such as via SD cards.
24. When handling sensitive data which does not need to be presented to users (e.g. account numbers), instead of using the actual value itself, use a token which maps to the actual value on the server-side. This will prevent exposure of sensitive information.

Paywall Controls

This is a set of practices to ensure the application properly enforces access controls related to resources which require payment in order to access (such as access to premium content, access to additional functionality, access to improved support, etc…).

1. Maintain logs of access to paid-for resources in a non-repudiable format (e.g. a signed receipt sent to a trusted server backend – with user consent) and make them securely available to the end-user for monitoring.
2. Warn users and obtain consent for any cost implications for application behavior.
3. Secure account/pricing/billing/item information as it relates to users. If client has made any purchases via the application for instance, we should ensure that what they bought, the size of purchase, the quantity of the purchase, etc… should all be treated as sensitive information.
4. Use a white-list model by default for paid-for resource addressing.
5. Check for anomalous usage patterns in paid-for resource usage and trigger re- authentication. E.g. significant change in location occurs, user-language changes, etc...

Server Controls

This is a set of practices to ensure the server side program which interfaces with the mobile application is properly safeguarded. These controls would also apply in cases where the mobile application may be integrating with vended solutions hosted outside of the typical network.

1. Ensure that the backend system(s) are running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.
2. Ensure adequate logs are retained on the backend in order to detect and respond to incidents and perform forensics (within the limits of data protection law).
3. Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the risk from DoS type of attacks.
4. Carry out a specific check of your code for any sensitive data unintentionally transferred between the mobile application and the back-end servers, and other external interfaces (e.g. is location or other information included transmissions?).
5. Ensure the server rejects all unencrypted requests which it knows should always arrive encrypted.

Session Management

This is a set of controls to help ensure mobile applications handle sessions in a secure manner.

1. Perform a check at the start of each activity/screen to see if the user is in a logged in state and if not, switch to the login state.
2. When an application’s session is timed out, the application should discard and clear all memory associated with the user data, and any master keys used to decrypt the data.
3. Session tokens should be revocable (particularly on the server side).
4. Use lower timeout values to invalidate expired sessions (in contrast to the typical timeout values on traditional (non-mobile) applications).

Use of 3rd Party Libraries/Code

This is a set of practices to ensure the application integrates securely with code produced from outside parties.

1. Vet the security/authenticity of any third party code/libraries used in your mobile application (e.g. making sure they come from a reliable source, will continue to be supported, contain no backdoors) and ensure that adequate internal approval is obtained to use the code/library.
2. Track all third party frameworks/API’s used in the mobile application for security patches and perform upgrades as they are released.
3. Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before incorporating their use into an application.

Mobile Application Provisioning/Distribution/Testing

This is a set of controls to ensure that software is tested and released relatively free of vulnerabilities, that there are mechanisms to report new security issues if they are found, and also that the software has been designed to accept patches in order to address potential security issues.

1. Design & distribute applications to allow updates for security patches.
2. Provide & advertise feedback channels for users to report security problems with applications (such as a [email protected] email address).
3. Ensure that older versions of applications which contain security issues and are no longer supported are removed from app-stores/app-repositories.
4. Periodically test all backend services (Web Services/REST) which interact with a mobile application as well as the application itself for vulnerabilities using enterprise approved automatic or manual testing tools (including internal code reviews).
5. Based on risk assessment of the application, have the application go through Security Assessment for a review of security vulnerabilities following the Team’s internal security testing of the application.
6. Utilize the Enterprise provisioning process (e.g. IDM) to request and approve access for users on the mobile application.
7. Ensure the application is sufficiently obfuscated prior to release by conducting tests which attempt to reverse engineer the obfuscated application.
8. Distribute applications via an app-store type of interface (when appropriate) as many app-stores monitor applications for insecure code which we may benefit from.
9. Digitally sign applications using a code signing certificate obtained via a trusted Certificate Authority (CA).

OWASP/ENISA Collaboration

OWASP and the European Network and Information Security Agency (ENISA) collaborated to build a joint set of controls. ENISA has published the results of the collaborative effort as the "Smartphone Secure Development Guideline": http://www.enisa.europa.eu/activities/application-security/smartphone-security-1/smartphone-secure-development-guidelines

Contributors

This document has been jointly produced with ENISA as well as the following individuals:

• Vinay Bansal, Cisco Systems
• Nader Henein, Research in Motion
• Giles Hogben, ENISA
• Karsten Nohl, Srlabs
• Jack Mannino, nVisium Security
• Christian Papathanasiou, Royal Bank of Scotland
• Stefan Rueping, Infineon
• Beau Woods, Stratigos Security

Top 10 mobile controls and design principles

1. Identify and protect sensitive data on the mobile device

Risks: Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure: Mobile devices (being mobile) have a higher risk of loss or theft. Adequate protection should be built in to minimize the loss of sensitive data on the device.

• 1.1 In the design phase, classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs, etc.). Process, store and use data according to its classification. Validate the security of API calls applied to sensitive data.
• 1.2 Store sensitive data on the server instead of the client-end device. This is based on the assumption that secure network connectivity is sufficiently available and that protection mechanisms available to server side storage are superior. The relative security of client vs server-side security also needs to be assessed on a case-by-case basis (see ENISA cloud risk assessment (3) or the OWASP Cloud top 10 (4) for decision support).
• 1.3 When storing data on the device, use a file encryption API provided by the OS or other trusted source. Some platforms provide file encryption APIs which use a secret key protected by the device unlock code and deleteable on remote kill. If this is available, it should be used as it increases the security of the encryption without creating extra burden on the end-user. It also makes stored data safer in the case of loss or theft. However, it should be born in mind that even when protected by the device unlock key, if data is stored on the device, its security is dependent on the security of the device unlock code if remote deletion of the key is for any reason not possible.
• 1.4 Do not store/cache sensitive data (including keys) unless they are encrypted and if possible stored in a tamper-proof area (see control 2).
• 1.5 Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet app not usable if GPS data shows phone is outside Europe, car key not usable unless within 100m of car etc...).
• 1.6 Do not store historical GPS/tracking or other sensitive information on the device beyond the period required by the application (see controls 1.7, 1.8).
• 1.7 Assume that shared storage is untrusted - information may easily leak in unexpected ways through any shared storage. In particular:
  • Be aware of caches and temporary storage as a possible leakage channel, when shared with other apps.
  • Be aware of public shared storage such as address book, media gallery and audio files as a possible leakage channel. For example storing images with location metadata in the media-gallery allows that information to be shared in unintended ways.
  • Do not store temp/cached data in a world readable directory.
• 1.8 For sensitive personal data, deletion should be scheduled according to a maximum retention period, (to prevent e.g. data remaining in caches indefinitely).
• 1.9 There is currently no standard secure deletion procedure for flash memory (unless wiping the entire medium/card). Therefore data encryption and secure key management are especially important.
• 1.10 Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc)
• 1.11 Apply the principle of minimal disclosure - only collect and disclose data which is required for business use of the application. Identify in the design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each data type.
• 1.12 Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so (use a randomly generated number – see 4.3). Apply the same data minimization principles to app sessions as to http sessions/cookies etc.
• 1.13 Applications on managed devices should make use of remote wipe and kill switch APIs to remove sensitive information from the device in the event of theft or loss. (A kill-switch is the term used for an OS-level or purpose-built means of remotely removing applications and/or data).
• 1.14 Application developers may want to incorporate an application-specific "data kill switch" into their products, to allow the per-app deletion of their application's sensitive data when needed (strong authentication is required to protect misuse of such a feature).

2. Handle password credentials securely on the device

Risks: Spyware, surveillance, financial malware. A user's credentials, if stolen, not only provide unauthorized access to the mobile backend service, they also potentially compromise many other services and accounts used by the user. The risk is increased by the widespread of reuse of passwords across different services.

• 2.1 Instead of passwords consider using longer term authorization tokens that can be securely stored on the device (as per the OAuth model). Encrypt the tokens in transit (using SSL/TLS). Tokens can be issued by the backend service after verifying

Smartphones secure development guidelines for app developers the user credentials initially. The tokens should be time bounded to the specific service as well as revocable (if possible server side), thereby minimizing the damage in loss scenarios. Use the latest versions of the authorization standards (such as OAuth 2.0). Make sure that these tokens expire as frequently as practicable.

• 2.2 In case passwords need to be stored on the device, leverage the encryption and key-store mechanisms provided by the mobile OS to securely store passwords, password equivalents and authorization tokens. Never store passwords in clear text. Do not store passwords or long term session IDs without appropriate hashing or encryption.
• 2.3 Some devices and add-ons allow developers to use a Secure Element e.g. (5) (6) – sometimes via an SD card module - the number of devices offering this functionality is likely to increase. Developers should make use of such capabilities to store keys, credentials and other sensitive data. The use of such secure elements gives a higher level of assurance with the standard encrypted SD card certified at FIPS 140-2 Level 3. Using the SD cards as a second factor of authentication though possible, isn't recommended, however, as it becomes a pseudo-inseparable part of the device once inserted and secured.
• 2.4 Provide the ability for the mobile user to change passwords on the device.
• 2.5 Passwords and credentials should only be included as part of regular backups in encrypted or hashed form.
• 2.6 Smartphones offer the possibility of using visual passwords which allow users to memorize passwords with higher entropy. These should only be used however, if sufficient entropy can be ensured. (7)
• 2.7 Swipe-based visual passwords are vulnerable to smudge-attacks (using grease deposits on the touch screen to guess the password). Measures such as allowing repeated patterns should be introduced to foil smudge-attacks. (8)
• 2.8 Check the entropy of all passwords, including visual ones (see 4.1 below).
• 2.9 Ensure passwords and keys are not visible in cache or logs.
• 2.10 Do not store any passwords or secrets in the application binary. Do not use a generic shared secret for integration with the backend (like password embedded in code). Mobile application binaries can be easily downloaded and reverse engineered.

3. Ensure sensitive data is protected in transit

Risks: Network spoofing attacks, surveillance. The majority of smartphones are capable of using multiple network mechanisms including Wi-Fi, provider network (3G, GSM, CDMA and others), Bluetooth etc. Sensitive data passing through insecure channels could be intercepted. (9) (10)

• 3.1 Assume that the provider network layer is not secure. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee that the Wi-Fi network will be appropriately encrypted.
• 3.2 Applications should enforce the use of an end-to-end secure channel (such as SSL/TLS) when sending sensitive information over the wire/air (e.g. using Strict Transport Security - STS (11)).This includes passing user credentials, or other authentication equivalents. This provides confidentiality and integrity protection.
• 3.3 Use strong and well-known encryption algorithms (e.g. AES) and appropriate key lengths (check current recommendations for the algorithm you use e.g. (12) page 53).
• 3.4 Use certificates signed by trusted CA providers. Be very cautious in allowing self- signed certificates. Do not disable or ignore SSL chain validation.
• 3.5 For sensitive data, to reduce the risk of man-in-middle attacks (like SSL proxy, SSL strip), a secure connection should only be established after verifying the identity of the remote end-point (server). This can be achieved by ensuring that SSL is only established with end-points having the trusted certificates in the key chain.
• 3.6 The user interface should make it as easy as possible for the user to find out if a certificate is valid.
• 3.7 SMS, MMS or notifications should not be used to send sensitive data to or from mobile end-points.

Reference: Google vulnerability of Client Login account credentials on unprotected wifi - [1]

4. Implement user authentication,authorization and session management correctly

Risks: Unauthorized individuals may obtain access to sensitive data or systems by circumventing authentication systems (logins) or by reusing valid tokens or cookies. (13)

• 4.1 Require appropriate strength user authentication to the application. It may be useful to provide feedback on the strength of the password when it is being entered for the first time. The strength of the authentication mechanism used depends on the sensitivity of the data being processed by the application and its access to valuable resources (e.g. costing money).
• 4.2 It is important to ensure that the session management is handled correctly after the initial authentication, using appropriate secure protocols. For example, require authentication credentials or tokens to be passed with any subsequent request (especially those granting privileged access or modification).
• 4.3 Use unpredictable session identifiers with high entropy. Note that random number generators generally produce random but predictable output for a given seed (i.e. the same sequence of random numbers is produced for each seed). Therefore it is important to provide an unpredictable seed for the random number generator. The standard method of using the date and time is not secure. It can be improved, for example using a combination of the date and time, the phone temperature sensor and the current x,y and z magnetic fields. In using and combining these values, well-tested algorithms which maximise entropy should be chosen (e.g. repeated application of SHA1 may be used to combine random variables while maintaining maximum entropy – assuming a constant maximum seed length).
• 4.4 Use context to add security to authentication - e.g. IP location, etc...
• 4.5 Where possible, consider using additional authentication factors for applications giving access to sensitive data or interfaces where possible - e.g. voice, fingerprint (if available), who-you-know, behavioural etc.
• 4.6 Use authentication that ties back to the end user identity (rather than the device identity).

5. Keep the backend APIs (services) and the platform (server) secure

Risks: Attacks on backend systems and loss of data via cloud storage. The majority of mobile applications interact with the backend APIs using REST/Web Services or proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow attackers to compromise data on the mobile device when transferred to the backend, or to attack the backend through the mobile application. (14)

• 5.1 Carry out a specific check of your code for sensitive data unintentionally transferred, any data transferred between the mobile device and web-server back- ends and other external interfaces - (e.g. is location or other information included within file metadata).
• 5.2 All backend services (Web Services/REST) for mobile apps should be tested for vulnerabilities periodically, e.g. using static code analyser tools and fuzzing tools for testing and finding security flaws.
• 5.3 Ensure that the backend platform (server) is running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.
• 5.4 Ensure adequate logs are retained on the backend in order to detect and respond to incidents and perform forensics (within the limits of data protection law).
• 5.5 Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the risk from DDoS attack.
• 5.6 Test for DoS vulnerabilities where the server may become overwhelmed by certain resource intensive application calls.
• 5.7 Web Services, REST and APIs can have similar vulnerabilities to web applications:
  • Perform abuse case testing, in addition to use case testing
  • Perform testing of the backend Web Service, REST or API to determine vulnerabilities.

6. Secure data integration with third party services and applications

Risks: Data leakage. Users may install applications that may be malicious and can transmit personal data (or other sensitive stored data) for malicious purposes.

• 6.1 Vet the security/authenticity of any third party code/libraries used in your mobile application (e.g. making sure they come from a reliable source, with maintenance supported, no backend Trojans)
• 6.2 Track all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile applications using these third party APIs/frameworks.
• 6.3 Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before processing within the application.

7. Pay specific attention to the collection and storage of consent for the collection and use of the user’s data

Risks: Unintentional disclosure of personal or private information, illegal data processing. In the European Union, it is mandatory to obtain user consent for the collection of personally identifiable information (PII). (15) (16)

• 7.1 Create a privacy policy covering the usage of personal data and make it available to the user especially when making consent choices.
• 7.2 Consent may be collected in three main ways:
  • At install time
  • At run-time when data is sent
  • Via “opt-out” mechanisms where a default setting is implemented and the user has to turn it off.
• 7.3 Check whether your application is collecting PII - it may not always be obvious - for example do you use persistent unique identifiers linked to central data stores containing personal information?
• 7.4 Audit communication mechanisms to check for unintended leaks (e.g. image metadata).
• 7.5 Keep a record of consent to the transfer of PII. This record should be available to the user (consider also the value of keeping server-side records attached to any user data stored). Such records themselves should minimise the amount of personal data they store (e.g. using hashing).
• 7.6 Check whether your consent collection mechanism overlaps or conflicts (e.g. in the data handling practices stated) with any other consent collection within the same stack (e.g. APP-native + webkit HTML) and resolve any conflicts.

8. Implement controls to prevent unauthorized access to paid-for resources (wallet, SMS, phone calls etc.) Risks: Smartphone apps give programmatic (automatic) access to premium rate phone calls, SMS, roaming data, NFC payments, etc. Apps with privileged access to such API’s should take particular care to prevent abuse, considering the financial impact of vulnerabilities that giveattackers access to the user’s financial resources.

• 8.1 Maintain logs of access to paid-for resources in a non-repudiable format (e.g. a signed receipt sent to a trusted server backend – with user consent) and make them available to the end-user for monitoring. Logs should be protected from unauthorised access.
• 8.2 Check for anomalous usage patterns in paid-for resource usage and trigger re- authentication. E.g. when significant change in location occurs, user-language changes etc.
• 8.3 Consider using a white-list model by default for paid-for resource addressing - e.g. address book only unless specifically authorised for phone calls.
• 8.4 Authenticate all API calls to paid-for resources (e.g. using an app developer certificate).
• 8.5 Ensure that wallet API callbacks do not pass cleartext account/pricing/ billing/item information.
• 8.6 Warn user and obtain consent for any cost implications for app behaviour.
• 8.7 Implement best practices such as fast dormancy (a 3GPP specification), caching, etc. to minimize signalling load on base stations.

9. Ensure secure distribution/provisioning of mobile applications

Risks: Use of secure distribution practices is important in mitigating all risks described in the OWASP Mobile Top 10 Risks and ENISA top 10 risks.

• 9.1 Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.
• 9.2 Most app-stores monitor apps for insecure code and are able to remotely remove apps at short notice in case of an incident. Distributing apps through official app- stores therefore provides a safety-net in case of serious vulnerabilities in your app.
• 9.3Provide feedback channels for users to report security problems with apps – e.g. a security@ email address.

10. Carefully check any runtime interpretation of code for errors

Risks: Runtime interpretation of code may give an opportunity for untrusted parties to provide unverified input which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls provided by app-stores. It can lead to injection attacks leading to Data leakage, surveillance, spyware, and diallerware.

Note that it is not always obvious that your code contains an interpreter. Look for any capabilities accessible via user-input data and use of third party API’s which may interpret user-input - e.g. JavaScript interpreters.

• 10.1 Minimize runtime interpretation and capabilities offered to runtime interpreters: run interpreters at minimal privilege levels.
• 10.2 Define comprehensive escape syntax as appropriate.
• 10.3 Fuzz test interpreters.
• 10.4 Sandbox interpreters.

Appendix A- Relevant General Coding Best Practices'

Some general coding best practices are particularly relevant to mobile coding. We have listed some of the most important tips here:

• • Perform abuse case testing, in addition to use case testing.
  • Validate all input.
  • Minimise lines and complexity of code. A useful metric is cyclomatic complexity (17).
  • Use safe languages (e.g. from buffer-overflow).
  • Implement a security report handling point (address) [email protected]
  • Use static and binary code analysers and fuzz-testers to find security flaws.
  • Use safe string functions, avoid buffer and integer overflow.
  • Run apps with the minimum privilege required for the application on the operating

system. Be aware of privileges granted by default by APIs and disable them.

• • Don't authorize code/app to execute with root/system administrator privilege
  • Always perform testing as a standard as well as a privileged user
  • Avoid opening application-specific server sockets (listener ports) on the client device.

Use the communication mechanisms provided by the OS.

• • Remove all test code before releasing the application
  • Ensure logging is done appropriately but do not record excessive logs, especially those

including sensitive user information.

Appendix B- Enterprise Guidelines

• • If a business-sensitive application needs to be provisioned on a device, applications should enforce of a higher security posture on the device (such as PIN, remote management/wipe, app monitoring)
  • Device certificates can be used for stronger device authentication.'

References"

• 1.ENISA. Top Ten Smartphone Risks . [Online] http://www.enisa.europa.eu/act/application-security/smartphone-security-1/top-ten-risks.
• 2. OWASP. Top 10 mobile risks. [Online] https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_Ten_Mobile_Risks.
• 3. Cloud Computing: Benefits, Risks and Recommendations for information security. [Online] 2009. http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment.
• 4. OWASP Cloud Top 10. [Online] https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_10_Project.
• 5. Blackberry developers documents. [Online] http://www.blackberry.com/developers/docs/7.0.0api/net/rim/device/api/io/nfc/se/SecureElement.h tml,.
• 6. Google Seek For Android. [Online] http://code.google.com/p/seek-for-android/.
• 7. Visualizing Keyboard Pattern Passwords. [Online] cs.wheatoncollege.edu/~mgousie/comp401/amos.pdf.
• 8. Smudge Attacks on Smartphone Touch Screens. Adam J. Aviv, Katherine Gibson, Evan Mossop, Matt Blaze, and Jonathan M. Smith. s.l. : Department of Computer and Information Science – University of Pennsylvania.
• 9. Google vulnerability of Client Login account credentials on unprotected . [Online] http://www.uni- ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html.
• 10. SSLSNIFF. [Online] http://blog.thoughtcrime.org/sslsniff-anniversary-edition. 11. [Online] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02.

Smartphones secure development guidelines for app developers

• 11. [Online] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02.

*12. NIST Computer Security. [Online] http://csrc.nist.gov/publications/nistpubs/800-57/sp800- 57_PART3_key-management_Dec2009.pdf.

• 13. Google's ClientLogin implementation . [Online] http://www.uni- ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html.
• 14. [Online] https://www.owasp.org/index.php/Web_Services.
• 15. EU Data Protection Directive 95/46/EC. [Online] http://eur- lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:HTML.
• 16. [Online] http://democrats.energycommerce.house.gov/sites/default/files/image_uploads/Testimony_05.04.11 _Spafford.pdf.
• 17. [Online] http://www.aivosto.com/project/help/pm-complexity.html.
• 18. [Online] http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html.
  • 19. Google Wallet Security. [Online] http://www.google.com/wallet/how-it-works-security.htm.

Mobile Application Threat Model - Beta Release

This is the first release (February 2013) of the Mobile Application Threat Model developed by the initial project team (listed at the end of this release). Development began mid-2011 and is being released in beta form for public comment and input. It is by no means complete and some sections will need more contributions, details and also real world case studies. It's the hope of the project team that others in the community can help contribute to this project to further enhance and improve this threat model.

Mobile Threat Model Introduction Statement

Threat modeling is a systematic process that begins with a clear understanding of the system. It is necessary to define the following areas to understand possible threats to the application:

• Mobile Application Architecture - This area describes how the application is designed from device specific features used by the application, wireless transmission protocols, data transmission mediums, interaction with hardware components and other applications.
• Mobile Data - What data does the application store and process? What is the business purpose of this data and what are the data workflows?
• Threat Agent Identification - What are the threats to the mobile application and who are the threat agents. This area also outlines the process for defining what threats apply to the mobile application.
• Methods of Attack - What are the most common attacks utilized by threat agents. This area defines these attacks so that controls can be developed to mitigate attacks.
• Controls - What are the controls to prevent attacks. This is the last area to be defined only after previous areas have been completed by the development team.

Target Audience for the Mobile Threat Model

This model is to be used by mobile application developers and software architects as part of the “threat modeling” phase of a typical SDLC process. The model can also be used by Information Security Professionals that need to determine what typical mobile application threats are and provide a methodology for conducting basic threat modeling.

How to Use the Mobile Threat Model

This threat model is designed as an outline or checklist of items that need to be documented, reviewed and discussed when developing a mobile application. Every organization that develops mobile applications will have different requirements as well as threats. This model was designed to be as organizational and industry agnostic as possible so that any mobile application development team can use this as a guide for conducting threat modeling for their specific application. Real world case studies as examples will be integrated to this threat model in the near future.

Mobile Application Architecture

The mobile application architecture should, at the very least, describe device specific features used by the application, wireless transmission protocols, data transmission medium, interaction with hardware components and other applications. Applications can be mapped to this architecture as a preliminary attack surface assessment.

Architecture Considerations

Although mobile applications vary in function, they can be described using a generalized model as follows:

Wireless interfaces

Transmission Type

Hardware Interaction

Interaction with on device applications/services

Interaction with off device applications/services

Encryption Protocols

• What is the design of the architecture (network infrastructure, web services, trust boundaries, third-party APIs, etc)
  • Carrier
    • Data
    • SMS
    • Voice
  • Endpoints
    • Web Services
      • RESTful or SOAP based
      • Third Party (Example: Amazon)
    • Websites
      • Does the app utilize or integrate the “mobile web” version of an existing web site?
    • App Stores
      • Google Play
      • Apple App Store
      • Windows Mobile
      • BlackBerry App Store
    • Cloud Storage
      • Amazon/Azure
    • Corporate Networks (via VPN, ssh, etc.)
  • Wireless interfaces
    • 802.11
    • NFC
    • Bluetooth
    • RFID
  • Device
    • App Layer
    • Runtime Environment (VM, framework dependencies, etc)
    • OS Platform
  • Apple iOS
  • Android
  • Windows Mobile
  • BlackBerry
    • Baseband
• Common hardware components
  • GPS
  • Sensors (accelerometer)
  • Cellular Radios (GSM/CDMA/LTE)
  • Flash Memory
  • Removable Storage (i.e.- SD)
  • USB ports
  • Wireless Interfaces
    • 802.11
    • Bluetooth
    • NFC
    • RFID
  • Touch Screen
  • Hardware Keyboard
  • Microphone
  • Camera
• Authentication
  • Method
    • Knowledge based
    • Token based
    • Biometrics
  • Input Type
    • Keyboard
    • Touch screen
    • Hardware peripheral
  • Decision Process
    • Local (on device)
    • Remote (off device)
• Define app architecture relative to OS stack + security model
  • What should or shouldn't the app do?

Mobile Data

This section defines what purpose does the app serve from a business perspective and what data the app store, transmit and receive. It’s also important to review data flow diagrams to determine exactly how data is handled and managed by the application.

• What is the business function of the app?
• What data does the application store/process (provide data flow diagram)
  • This diagram should outline network, device file system and application data flows
  • How is data transmitted between third party API’s and app(s)
  • Are there different data handling requirements between different mobile platforms? (iOS/Android/Blackberry/Windows/J2ME)
  • Does the app use cloud storage APIs (Dropbox, Google Drive, iCloud, Lookout) for device data backups
  • Does personal data intermingle with corporate data?
  • Is there specific business logic built into the app to process data?
• What does the data give you (or an attacker) access to
  • Data at Rest
  • Example: Do stored credentials provide authentication?
  • Data in Transit
  • Example: Do stored keys allow you to break crypto functions (data integrity)?
• Third party data, is it being stored/transmitted?
  • What is the privacy requirements of user data
  • Example: UDID or Geolocation on iOS transmitted to 3rd party
  • Are there regulatory requirements to meet specific to user privacy?
• How does other data on the device affect the app (sandboxing restrictions enforced?)
  • Example: Authentication credentials shared between apps
• What is the impact of Jailbroken/Rooted vs Non Jailbroken/Rooted device and how this affects app data (can also relate to threat agent identification)

Threat Agent Identification

What are the threats to the mobile application and who are the threat agents. This area also outlines the process for defining what threats apply to the mobile application.

Identifying Threat Agents

The process of identifying a threat agent is very simple and have been mentioned in the below steps:

S1: Take the list of all sensitive data (or information to protect) listed down from Section 2 – Mobile Data

S2: Make a list of all the ways to access this data

S3: The medium used to access the same listed in S3 is the Threat Agent to be identified

Threat Agent Identification Example

Let us understand it in a better way using an example of a Financial Application (specifically a Banking Application). Following the process as mentioned above:

S1: Sensitive data present in the application has been listed as: Beneficiary Details stored in some form in the Phone Application Memory and User Credentials used for authentication transmitted to the server. S2: List the various ways of accessing information:

1. Beneficiary Details:
   1. A device user aiming to browse through the memory card / phone memory
   2. An adversary using a jail broken phone; starts reading the content through putty/WinSCP via SSH
   3. An adversary while sniffing the WiFi, traffic sniffs the content travelling through the network
   4. Another malicious application while reading the phone memory contents, stumbles upon this data as the device is Jailbroken
   5. Another application which is sending data through SMS sends this data.
   6. A Web Application executing a script on the browser tries to get steal the phone memory and send it to its server.

S3: From the above points, we list down the medium used:

1. Any user who has the device (Stolen device/ friend / etc)
   1. Any malicious application (installed / Web based script)
   2. An adversary sniffing the Wifi.
   3. etc.

From the above example you should have a clear picture on how to identify Threat Agents. Below is list of threat agents, which were identified while analyzing various commonly used applications.

Listing of Threat Agents - By Category

Human Interaction

• Stolen Device User: A user who obtained unauthorized access to the device aiming to get hold of the memory related sensitive information belonging to the owner of the device.

• Owner of the Device: A user who unwillingly has installed a malicious application on his phone which gains access to the device application memory.

• Common WiFi Network User­: This agent is aimed at any adversary intentionally or unintentionally sniffing the WiFi network used by a victim. This agent stumbles upon all the data transmitted by the victim device and may re-use it to launch further attacks.

• Malicious Developer: A human user who has the intent of writing an application which not only provides a commonly known function like gaming / calculator / utility in the foreground but steal as much information from your device as possible in real-time and transmits it to the malicious user. This agent can also be looked at an angle from which he codes an app to perform DOS by using up all the device resources.

• Organization Internal Employees: Any user who is part of the organization (may be a programmer / admin / user / etc). Anyone who has privileges to perform an action on the application.

• App Store Approvers/Reviewers: Any app store which fails to review potentially dangerous code or malicious application which executes on a user’s device and performs suspicious/ malicious activities

Automated Programs

• Malware on the device: Any program / mobile application which performs suspicious activity. It can be an application, which is copying real time data from the user’s device and transmitting it to any server. This type of program executes parallel to all the processes running in the background and stays alive performing malicious activity all the time. E.g. Olympics App which stole text messages and browsing history:[2]http://venturebeat.com/2012/08/06/olympics-android-app/

• Scripts executing at the browser with HTML5: Any script code written in a language similar to JavaScript having capability of accessing the device level content falls under this type of agent section. A script executing at the browser reading and transmitting browser memory data / complete device level data.

• Malicious SMS: An incoming SMS redirected to trigger any kind of suspicious activity on the mobile device. There are multiple services which keep running in the background. Each of these services have listeners which might be active to listen for the content of an incoming SMS. An SMS message may be a sort of trigger for the service to perform some suspicious activity.

• Malicious App: Failure to detect malicious or vulnerable code and the likelihood of a compromise or attack against the app store itself, potentially turning legitimate code into hostile things including updates and new downloaded apps.

Below is a diagram illustrated to understand the Threat Agents and Threats in a visual manner:

Figure 1 : Pictorial Representation of Threats and Agents

Methods of Attack

In this section, we will observe different methods an attacker can use to reach the data. This data can be sensitive information to the device or something sensitive to the app itself.

Attack’s Flowchart

Destruction of the asset is normally classified as attack. Attack can be further categorized as a planned attack or an unplanned one. Unintended attacks are normally caused due to some form of accidental actions.

Figure 2: Attack Workflow

Attack Scenario

“Method aimed to read the local application memory”

The above mentioned attack methodology is the one in which the data which is targeted is application specific memory and the method used is memory based analysis. The attacker steals any sensitive data like passwords, userid, user account information which is stored in the application memory by reading the device memory.

We have listed down other methods below which can be mapped with the second section in a similar fashion:

The classification of attacks based on the way data is handled:

• Carrier Based Methods

1. Man in the middle (MiTM) attacks which can steal data packets including SMS or voice packets
2. Hijack wireless transmission.

• Endpoints based methods

1. Inject code to tamper with web application or web services
2. Many of the OWASP Mobile Top 10/OWASP Web Application Top 10
3. Publishing Malwares in the app store
4. Stealing user sensitive phone contents using Malwares
5. Cloud storage
6. Targeting malicious corporate network. (e.g. VPN Keys, etc)

• Wireless interfaces based methods

1. Stealing data when its in-transit using wireless channel like 802.11, NFC based data exchange or Bluetooth based data exchange. Application Level Attacks

• OS and application level methods

1. Exploit the Input validation on client-side by by-passing the checks
2. An adversary steals sensitive data by reading SD Card based stored content
3. Exploiting vulnerabilities within an app or runtime environment. (VM, framework dependencies, etc)
4. An adversary exploits OS level functionalities steal data from device or server
5. Rooting or Jailbreaking the phone to access sensitive data from memory

• Miscellaneous Methods

1. Method used to exploit and steal GPS based signals which falls in users personal information
2. Method used to exploit the flash memory
3. Method used to perform “tap jacking” based attacks.
4. Method used to steal keyboard cache or logs.
5. Method used to steal microphone recordings of a user
6. Method used to exploit and misuse the camera functionality.

Controls

What are the controls to prevent attacks. This is the last area to be defined only after previous areas have been completed by the development team.

• What are the controls to prevent an attack?
  • Defined by platform
    • Apple iOS
    • Android
    • Windows Mobile
    • BlackBerry
• What are the controls to detect an attack?
  • Defined by platform
    • Apple iOS
    • Android
    • Windows Mobile
    • BlackBerry
• What are the controls to mitigate/minimize impact of an attack?
  • Defined by platform
    • Apple iOS
    • Android
    • Windows Mobile
    • BlackBerry
• What are the controls to protect users private information (privacy controls)
  • Example: prompts for access to address book/geolocation
• Create a mapping of controls to each specific method of attack (defined in Section 4 – Methods of Attack)
  • Create level of assurance framework based on controls implemented. This would be subjective to a certain point, but it would be useful in guiding organizations who want to achieve a certain level of risk management based on the threats and vulnerabilities
• Case studies, control examples

Project Contributors

Special thanks to the following team members who contributed to the initial release of the threat model:

Tom Eston (Project Lead)

Jack Mannino

Sreenarayan Ashokkumar

Swapnil Deshmukh

Brandon Knight

Steve Jensen

Shimon Modi

Rodrigo Marcos

Brandon Clark

Yvesmarie Quemener

Yashraj Paralikar

Ritesh Taank