The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

PROJECT INFOWhat does this OWASP project offer you?

RELEASE(S) INFOWhat releases are available for this project?

what

is this project?

Name: OWASP Mobile Security Project (home page)

Purpose: Our primary focus is at the application layer. While we take into consideration the underlying mobile platform and carrier inherent risks when threat modeling and building controls, we are targeting the areas that the average developer can make a difference. Additionally, we focus not only on the mobile applications deployed to end user devices, but also on the broader server-side infrastructure which the mobile apps communicate with. We focus heavily on the integration between the mobile application, remote authentication services, and cloud platform-specific features.

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.

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

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

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

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:

Analyzing source code obtained from development team (prefered)

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

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

Networking

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.

Secure Mobile Development Guidelines Objective

The OWASP Secure Development Guidelines will provide 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.

Share this:

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.

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 controls and design principles

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

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

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.

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.

GoatDroid

The OWASP GoatDroid Project is a fully functional and self-contained environment for learning about Android security.

Introduction

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.

Description

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

Contributions will always be needed in order to keep this project moving at a pace that can support the seemingly endless new problems to tackle. If you are interested, please contact the project's leaders or send an email to the OWASP Mobile Security Project mailing list. We welcome code contributors, beta testers, new feature suggestions, and feedback always!

Licensing

GoatDroid is published by OWASP under the GPLv3 license. You should read and accept the LICENSE before you use, modify, and/or redistribute this software.